4 ms·

This is a fun problem, but it's a terrible interview question for trying to hire software engineers.

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 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?* 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."
colinmhayes 6y ago
The point of leetcode problems isn't to find out if you're a good software engineer. It's to find out if you're willing to spend hundreds of hours practicing tedious bullshit to get a job and google. If you can solve this in the interview you can become a good software engineer.
- mcqueenjordan 6y ago
  Memorizing known solutions to known problems does not guarantee good problem solving skills. Furthermore, you’re now selecting for people that are highly willing to “spend hundreds of hours doing tedious bullshit.” If you were a CEO, is this the type of people you’d want to stack your organization with?
  - deleted 6y ago
    [deleted]

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 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?* 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."

colinmhayes 6y ago

The point of leetcode problems isn't to find out if you're a good software engineer. It's to find out if you're willing to spend hundreds of hours practicing tedious bullshit to get a job and google. If you can solve this in the interview you can become a good software engineer.

mcqueenjordan 6y ago
Memorizing known solutions to known problems does not guarantee good problem solving skills. Furthermore, you’re now selecting for people that are highly willing to “spend hundreds of hours doing tedious bullshit.” If you were a CEO, is this the type of people you’d want to stack your organization with?
- deleted 6y ago
  [deleted]