4 ms·
Why? Note that the point of the problem isn't if you can solve it. It is how you approach it. A problem like this gives you a lot of signal. * Can the person p
by kevincox 6y ago
Why? Note that the point of the problem isn't if you can solve it. It is how you approach it. A problem like this gives you a lot of signal.
* Can the person program at all.
* Do they consider the performance of possible solutions.
* Are they good at explaining their thought process.
* Do they consider edge cases?
* Do they write tests?
I'm not saying that it should be the only interview, or it is the most important. But it clearly provides differentiation between candidates. I'm also not saying it is the perfect way to get this differentiation, but I think it is far from "terrible".
- xienze 6y ago> * Can the person program at all. * Do they consider the performance of possible solutions. * Are they good at explaining their thought process. * Do they consider edge cases? * Do they write tests? All good things to look for. The problem is, day-to-day you don't have to do all of those things in 45 minutes while several people at the table watch you. Personally I'm a fan of a short programming exercise (perhaps even this problem) that you can take home and walk through with the team at a later time. I know those are detested by some, but I think they're fair (assuming the task is not something outrageous; something that can be knocked out in an evening perhaps) and give a much better idea of what an employee is capable of.
- vanusa 6y agoCan the person program at all. Do they consider the performance of possible solutions. * Are they good at explaining their thought process. * Do they consider edge cases? * Do they write tests?* That's what you'd like to think it's testing for. In reality, it's testing for: "Here's a hoop - would you like to jump through it for me please? BTW not only will stumbling or even hesitating pretty much disqualify you - we love to dish after hours about those who fail to make the cut."