3 ms·

Having taken some interviews myself I can see some value in having the interviewee do some small coding exercise when they do not have any personal projects to

Having taken some interviews myself I can see some value in having the interviewee do some small coding exercise when they do not have any personal projects to show. I think it can filter out some false positives of candidates that can talk well but can’t actually write code (you’d be surprised how many candidates can’t) What surprises me most is the lack of flexibility in the process. If a candidate shows up with a broad portfolio I’d rather talk about that then doing some random coding problem. Yet our HR manager insists on the fixed program. This is worse when the candidate is interviewing for a senior role where I don’t really care. Then I am mostly interested in their past experiences and knowledge on how to build things that don’t fall apart after six months. Again it is definitely process over people here… not sure if it is better in other places. I would also say that these exercises are most effective when they are quite simple. They let you test ‘can this person write a function’. The complicated ones often filter more for people who have studied those type of problems. Harder problems != better coder. At least not for the projects I work on which are more integrating existing services than investing new novel highly efficient code.

lostcolony 4y ago
Yeah; that's what I've preferred to do. Interestingly, I've had just as good results with the hires I've made regardless of the process used, from whiteboard coding that is little more than fizzbuzz, to actual pairing with an engineer on a real problem, to leetcode, across multiple different companies. Maybe the softer parts of the the interview, which was largely the same (and prioritized people who could talk intelligently about stuff on their resume, those who when led to places they had no experience were comfortable saying "I don't know" or similar, and those who seemed interested in learning new things), was better for distinguishing mediocre from excellent (with the coding being helpful for distinguishing imposters from everyone else).

lostcolony 4y ago

Yeah; that's what I've preferred to do. Interestingly, I've had just as good results with the hires I've made regardless of the process used, from whiteboard coding that is little more than fizzbuzz, to actual pairing with an engineer on a real problem, to leetcode, across multiple different companies. Maybe the softer parts of the the interview, which was largely the same (and prioritized people who could talk intelligently about stuff on their resume, those who when led to places they had no experience were comfortable saying "I don't know" or similar, and those who seemed interested in learning new things), was better for distinguishing mediocre from excellent (with the coding being helpful for distinguishing imposters from everyone else).