3 ms·

This is an even worse idea than just asking for white-board coding, but it seems to come along every time. Not only are you putting the candidate under pressure

by joesmo 12y ago

This is an even worse idea than just asking for white-board coding, but it seems to come along every time. Not only are you putting the candidate under pressure, where thinking is difficult, now you expect them to walk you through their thought process and narrate what they're thinking, disrupting the thought process. I personally need to think things on my own without having the pressure of having to tell the interviewer what I'm thinking. Not only does it alter my thought pattern and remove a lot of the ability to think, but the extra pressure from wondering whether I'm saying the right things or taking too long to think before stopping myself so I can please the interviewer pretty much removes my ability to solve any sort of complex problem I haven't solved before. Not to mention the anger under the surface at such a daft and counter-productive approach to problem solving. This might work on TV and might be useful when collaboratively brainstorming, but in an interview, the only thing it's testing is the interviewee's ability to deal with social pressure.

bostik 12y ago
I will have to disagree with this part: > Not only are you putting the candidate under pressure, where thinking is difficult, now you expect them to walk you through their thought process and narrate what they're thinking, disrupting the thought process. I expect a capable developer to be able to explain to themselves why they are choosing (or avoiding) an approach. If they cannot to that, would I trust them to be able to explain their methods or WIP problems to other developers? When I do interviews, I care less about the solution the candidate comes up with, and a lot more how they ended up with the particular solution they used. The process of iteration and dead-end elimination is fascinating. This means that the best questions have N+1 different solutions. Some will be less optimal, but that's life. I also find discussing the effects of different solutions fruitful, on the less common occasions when the candidate ends up tossing one approach and settling on something altogether different. And by the way, I really dislike the idea that you're supposed to do an interview in less than 1h. For anything remotely realistic, that doesn't even let you scratch the surface.

by joesmo 12y ago

bostik 12y ago

I will have to disagree with this part: > Not only are you putting the candidate under pressure, where thinking is difficult, now you expect them to walk you through their thought process and narrate what they're thinking, disrupting the thought process. I expect a capable developer to be able to explain to themselves why they are choosing (or avoiding) an approach. If they cannot to that, would I trust them to be able to explain their methods or WIP problems to other developers? When I do interviews, I care less about the solution the candidate comes up with, and a lot more how they ended up with the particular solution they used. The process of iteration and dead-end elimination is fascinating. This means that the best questions have N+1 different solutions. Some will be less optimal, but that's life. I also find discussing the effects of different solutions fruitful, on the less common occasions when the candidate ends up tossing one approach and settling on something altogether different. And by the way, I really dislike the idea that you're supposed to do an interview in less than 1h. For anything remotely realistic, that doesn't even let you scratch the surface.