5 ms·

I think the point is that memorizing bubble sort doesn't prove anything.

curtis 10y ago
I might have trouble remembering the difference between bubble sort and, say, selection sort off the top of my head. On the other hand, I can implement insertion sort from scratch. It is so simple I do not need to remember the algorithm, I can just figure it out whenever I want. I think there is a problem with the industry having forgotten the point of why we were asking questions like this in interviews in the first place. The question is not whether you can remember the algorithm, it's whether you can implement such a simple algorithm in any programming language that both the interviewer and interviewee know. Since the point is the implementation, not the memorization, even simpler algorithms than bubble sort might well make more sense. This is why we've got FizzBuzz for example. As an alternative, the interviewer could take a moderately simple algorithm like say the Fisher-Yates shuffle algorithm, explain it to the interviewee on the whiteboard, and then see if they can implement it. But again, the point is not to test the interviewee's memorization skills. These algorithms are simple enough that any software engineer who can actually program should be able to implement them from a diagram and some textual/verbal explanation. The question of coding on a whiteboard vs coding on the computer is a separate question.
- codr4life 10y ago
  The problem is that it's impossible to get an idea of someone's problem solving skills by feeding them artificial bullshit to solve. I strongly prefer the approach of having applicants show and discuss real code that they wrote themselves. And I'd consider not having any code to show a serious warning sign.
  - curtis 10y ago
    These kind of coding questions aren't about the interviewee's "problem solving" skills. It's purely a question of basic competence in the field. If it's general problem solving capability you're after, then you're right, there are much better ways to do that. In the case where a job interview involves multiple one-on-one interviews, it might make sense to have one interviewer focus on basic competence, and another interviewer to focus more on more general problem solving skills. You might think we ought to be able to assume a basic level of competence, but lots of people in the industry think you can't. And to the extent that you can, that's often because the person sitting in front of you in an interview had to get through an initial online screen where they had to do some sort of coding exercise.
    - Pinckney 10y ago
      Asking about bubble sort is a terrible question, though. Bubble sort is a bad algorithm by virtually every measure relative to the alternatives. You might as well ask candidates to implement bogo sort.
      - deleted 10y ago
        [deleted]
    - codr4life 10y ago
      But whiteboard coding says nothing about basic competence, unless writing algorithms on whiteboards is the actual job to be performed.
- geebee 10y ago
  Could you implement insertion sort from scratch at a whiteboard in less that 45 minutes? Including getting the partitioning part right? It's tricky, and at a whiteboard, it's particularly difficult to get right (well, for me it is). If you can, well, hat's off. I'd have to study and be prepped for this. I probably could have done this in the past, but I don't walk around ready to take my algorithms and data structures final exam from 15 years ago. That's the thing I don't want to do anymore. I feel like I've taken that test enough times. I'm pretty sure I'm all done with tech interviews. I'll look for some way to stay in the field that doesn't involve another 5 hours of whiteboard exams. There are other options. I'm aware that I have ruled out some possibly good opportunities, but I truly can not stand the idea of going through this all one. more. time. If it were just bubble sort or even insertion sort, eh, that wouldn't be too hard. I've only interviewed at google once, but I felt the questions were far more complicated and difficult than simply implementing insertion sort, and as far as I can tell, you really are expected to make good progress and write a lot of code. That was the reason they give for the "no hire", that I hadn't made enough coding progress on the problems in the time allotted. This is certainly their right (though I do get irritated when google lobbies congress to remedy the shortage of software developers, as if their recruiting and hiring process isn't part of why they're having trouble hiring!) But me? Yeah, I'm out. No more whiteboard oral exams, no more uncompensated "take home projects". Done. If this were part of some sort of professional certification, widely recognized in the industry, that I could properly prepare for and take as a lasting, industry respected credential, then I'd do it. But no more tech exams or take homes at the whim of a potential employer. I've wasted enough time on this.
  - curtis 10y ago
    > Could you implement insertion sort from scratch at a whiteboard in less that 45 minutes? Including getting the partitioning part right? It's tricky, and at a whiteboard, it's particularly difficult to get right (well, for me it is). I think you have confused insertion sort with quicksort. Let me stress that not only would I have difficulty doing quicksort correctly in 45 minutes on a whiteboard, I'd have difficulty doing it in twice that time on a computer. And for exactly the reason that you specify -- the partitioning part of the algorithm is very hard to get right. Insertion sort, on the other hand, is a breeze. It might be reasonable to ask somebody to code the recursive part of quicksort assuming that they already had a function to do the partitioning part. This might be useful to see if they understand recursion.

I might have trouble remembering the difference between bubble sort and, say, selection sort off the top of my head. On the other hand, I can implement insertion sort from scratch. It is so simple I do not need to remember the algorithm, I can just figure it out whenever I want. I think there is a problem with the industry having forgotten the point of why we were asking questions like this in interviews in the first place. The question is not whether you can remember the algorithm, it's whether you can implement such a simple algorithm in any programming language that both the interviewer and interviewee know. Since the point is the implementation, not the memorization, even simpler algorithms than bubble sort might well make more sense. This is why we've got FizzBuzz for example. As an alternative, the interviewer could take a moderately simple algorithm like say the Fisher-Yates shuffle algorithm, explain it to the interviewee on the whiteboard, and then see if they can implement it. But again, the point is not to test the interviewee's memorization skills. These algorithms are simple enough that any software engineer who can actually program should be able to implement them from a diagram and some textual/verbal explanation. The question of coding on a whiteboard vs coding on the computer is a separate question.

codr4life 10y ago
The problem is that it's impossible to get an idea of someone's problem solving skills by feeding them artificial bullshit to solve. I strongly prefer the approach of having applicants show and discuss real code that they wrote themselves. And I'd consider not having any code to show a serious warning sign.
- curtis 10y ago
  These kind of coding questions aren't about the interviewee's "problem solving" skills. It's purely a question of basic competence in the field. If it's general problem solving capability you're after, then you're right, there are much better ways to do that. In the case where a job interview involves multiple one-on-one interviews, it might make sense to have one interviewer focus on basic competence, and another interviewer to focus more on more general problem solving skills. You might think we ought to be able to assume a basic level of competence, but lots of people in the industry think you can't. And to the extent that you can, that's often because the person sitting in front of you in an interview had to get through an initial online screen where they had to do some sort of coding exercise.
  - Pinckney 10y ago
    Asking about bubble sort is a terrible question, though. Bubble sort is a bad algorithm by virtually every measure relative to the alternatives. You might as well ask candidates to implement bogo sort.
    - deleted 10y ago
      [deleted]
  - codr4life 10y ago
    But whiteboard coding says nothing about basic competence, unless writing algorithms on whiteboards is the actual job to be performed.
geebee 10y ago
Could you implement insertion sort from scratch at a whiteboard in less that 45 minutes? Including getting the partitioning part right? It's tricky, and at a whiteboard, it's particularly difficult to get right (well, for me it is). If you can, well, hat's off. I'd have to study and be prepped for this. I probably could have done this in the past, but I don't walk around ready to take my algorithms and data structures final exam from 15 years ago. That's the thing I don't want to do anymore. I feel like I've taken that test enough times. I'm pretty sure I'm all done with tech interviews. I'll look for some way to stay in the field that doesn't involve another 5 hours of whiteboard exams. There are other options. I'm aware that I have ruled out some possibly good opportunities, but I truly can not stand the idea of going through this all one. more. time. If it were just bubble sort or even insertion sort, eh, that wouldn't be too hard. I've only interviewed at google once, but I felt the questions were far more complicated and difficult than simply implementing insertion sort, and as far as I can tell, you really are expected to make good progress and write a lot of code. That was the reason they give for the "no hire", that I hadn't made enough coding progress on the problems in the time allotted. This is certainly their right (though I do get irritated when google lobbies congress to remedy the shortage of software developers, as if their recruiting and hiring process isn't part of why they're having trouble hiring!) But me? Yeah, I'm out. No more whiteboard oral exams, no more uncompensated "take home projects". Done. If this were part of some sort of professional certification, widely recognized in the industry, that I could properly prepare for and take as a lasting, industry respected credential, then I'd do it. But no more tech exams or take homes at the whim of a potential employer. I've wasted enough time on this.
- curtis 10y ago
  > Could you implement insertion sort from scratch at a whiteboard in less that 45 minutes? Including getting the partitioning part right? It's tricky, and at a whiteboard, it's particularly difficult to get right (well, for me it is). I think you have confused insertion sort with quicksort. Let me stress that not only would I have difficulty doing quicksort correctly in 45 minutes on a whiteboard, I'd have difficulty doing it in twice that time on a computer. And for exactly the reason that you specify -- the partitioning part of the algorithm is very hard to get right. Insertion sort, on the other hand, is a breeze. It might be reasonable to ask somebody to code the recursive part of quicksort assuming that they already had a function to do the partitioning part. This might be useful to see if they understand recursion.