|
I've had good and bad on both sides. The interviewer is so critical to how things go for me. In some cases, I've had people who are not interested in interviewing or have zero social skills that make it difficult, and other times people are very rigid on what they want to hear and if you don't outright say it, you fail. One case with the later was an interview @ Microsoft, on the Live team at the time. Like on the third guy I talked to we go to lunch. Everything has gone fine to this point and we're getting along. We sit down in the cafeteria and he starts asking me a question. He describes a scenario in which his sister owns a salon or something and has a lockable bathroom, but the key keeps getting lost, how would I solve it. I talk about how other places attach the key to something large or whatever in an effort to avoid the issue and he then goes, Ok that's great but now let's say I have the key and I tell you about this problem and I say that I need copies made, but the key says on it, 'DO NOT DUPLICATE', what would you do? Now I just started detailing a dozen ways to make a copy of a key like that. I literally used the term social engineering in regards to how easily it would be to convince someone who could cut keys, to do it. I just kept on coming up with ways to get more keys that I was in my head like I'm killing this with my creativity. Of course that guy didn't see it the way I did, in that my problem solving capabilities were limitless, the whole point of the question was to identify that exact scenario as social engineering. On the flip side as an interviewer, I've found success using a two step approach in questioning. The first is as noted earlier, constructing a scenario or asking them a question for which the answer should be almost so trivial to a quality developer that they almost second guess themselves. My go to is a problem that is so obvious a situation for recursion that we didn't even have people write up things, we were just looking for them to understand the problem enough to know what basic tool they would use. This literally eliminates 50% or more of people. We've cut so many interviews short as people stand there searching for some way to traverse a tree. The next part is, presuming they have a recursive solution, you now start to add constraints or change parameters, forcing them to come up with alternative solutions. Creative problem solving is a huge aspect of what we do, so throwing real life constraints at them, and observing how they respond is very helpful to see how things will really go. That all allowed me to find great skilled people but there is another aspect that is harder to pinpoint. There are a lot of different phases to products and not everyone is keen on working at different phases, and even if they are aware that they prefer building new things versus maintaining them, if you need a job you aren't going to talk about that. I lost some great developers for that reason, the phase of the product was just not a great match for what they wanted and it's hard to discern in the interview how that part of things will go.
|
#
¿
Mar 28, 2016 21:40
|
|
|
|
| # ¿ May 10, 2024 01:43 |
|