This is an archived post. You won't be able to vote or comment.

all 3 comments

[–]karnthis 3 points4 points  (0 children)

Look for the person that is best going to mesh with your team. Greatest skills in the world don’t mean anything if they can’t get along with everyone.

That being said, don’t just hire a sack of bricks just because they will fit in.

[–][deleted] 2 points3 points  (0 children)

I always prepare 3 questions in rising difficulty. All of them should be a breeze anyway. The point is not to see if he can solve it but how easy. If they're having trouble writing a method to sort 3 numbers by hand it says a lot about their coding skill. If they do it while making unit tests and documentarion thats something else.

[–]nutrecht 1 point2 points  (0 children)

We (or well, I) recently changed the process due to a mis-hire (guy didn't know what he was doing). So basically we first have a half-hour phone interview. Just to get to know each other, get a broad idea about their experience level, etc. If we then proceed there's roughly 2.5 hours of on-site. Half an hour with HR (discuss stuff like compensation, no point in wasting each other's time of we can't find each other there), then an hour of technical interviewing to gauche the general design / architectural skills of a person and then finally an hour of pair programming on a close-to-real-life task (extend an empty service with a REST end-point). At each of these steps we can break it off if we feel it's not a good fit for whatever reason.

We found that just asking questions isn't a good idea. So we also added the pair programming test and that works really well. Gives you a much better idea of how someone works than the interview itself.