Question: Do time bounded algorithmic coding problems efficiently reduce false negatives as opposed to a technical design interviews (whiteboard & marker), practical coding problem (here's a web-service, add a feature), hiring & exercising probation (this may be a UK thing)?<p>I know this question has been asked & discussed a million times but I want to take a some what different perspective on the matter other than bashing & moaning<p>My experience is that the industry norm to ask algorithmic coding problems, for example given two string '1100101' and '101' add together and return '1101010'. In the book 'Cracking the Coding Interview' by Gayle Laakmann McDowell they speak about how these exist to reduce false negatives. However my question is that under the artificial stress of an interview and time pressure, does this actually correlate with ones performance? Such that the classification technique is the best for such screening?<p>Would be interested to see what other people think?<p>Plus this is my first 'Ask HN' so go easy one me :)
> they speak about how these exist to reduce false negatives<p>This doesn't sound right. Are you sure that they were referring to false negatives? Or is there something specific about the example problem? As far as I understand the interviewing process, the false negatives is the group the employer cares the least about. To be clear:<p><pre><code> True positive = good candidate, got hired
False positive = bad candidate, got hired
True negative = bad candidate, got rejected
False negative = good candidate, got rejected
</code></pre>
As the hiring company, you don't care how many false negatives you have (i.e. how many good candidates you reject) as long as you get a high number of true positives and a low number of false positives. The metric for this is called precision.<p><pre><code> Precision = TP/(TP+FP)
</code></pre>
In my experience companies tend to optimise their hiring process for precision and algorithm interviews are a part of this.
When I interview candidates, for me the coding interview is an opportunity to see how the candidate reasons about a problem, how they communicate their thoughts and if they are able to ask for help or get pieces of advice and action on them.<p>Whether they can solve the problem or not it's almost secondary. Of course, there are expectations based on the level for that role, but I prefer to hire someone that fits the team culture rather than some random rockstar developer.<p>If the candidate can do the exercise correctly and efficiently that's, of course a plus, but again, not a blocker.<p>Finally, I do think that for more senior roles it is good to also try to have a whiteboard session where you can discuss more high level / architectural problems. This will help to get a full picture on the level of expertise of the candidate and it's another opportunity to have a conversation and see how the candidate explains their idea or react to rapidly evolving scenarios.<p>I hope this opinion helps, but keep in mind it is only my opinion :)
I would not call adding two binary numbers algorithmic.<p>Having candidates write code is always a good filter. You'd be surprised by the amount of people who can't write a nested loop with a decade of experience under their belt.