Dhh: I would fail to write bubble sort on a whiteboard
twitter.com
twitter.com
...I must be getting old. I have nothing but ugly things to say about that attitude. Sorry, HN.
I'd bet that ~99% of programmers never created a new algorithm, or needed to. And that's fine. (where by new algorithm I mean an actual, unique solution lowering the bounds on some operation which is usually done in a simpler way) Outside of what's happening in ML research, I can't even think of recent known examples.
I found it infuriating at my google interview when I tried to pause for a minute to reason through the question (out loud) and my interviewer started prompting me with hints and pieces of the answer. It was obvious that I was losing points because I hadn't seen the question before.
It seems like companies are okay with this system anyways. MIT literally offers a course called "Hacking a Google Interview", and yet Google still hasn't changed their internship interview problems.
recently, I was constructing a small query engine based off of Prolog, a language which I have never delved into the internals of.
the rewarding moments were when it worked. I didn't work off of any documentation, only by thinking how I'd design something similar. going "from scratch" is incredibly rewarding because you start realizing that some parts of your thought are based on well-trodden ground. things start to light up.
I'll never get tired of that style of work.
Maybe you don't use bubble sort, but it is truly trivial and these arguments seem quite anti-intellectual.
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.
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.
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.
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've never had a big gripe about whiteboard coding exercises, but I'm with you on the take home projects.
My big complaint right now is that it has become increasingly difficult to get through the first level of screening to even get to a proper interview loop where someone could even ask me to code on a whiteboard.
Similar problem: "Most programmers think that with the above description in hand, writing the code is easy; they’re wrong. The only way you’ll believe this is by putting down this column right now and writing the code yourself. Try it." https://reprog.wordpress.com/2010/04/19/are-you-one-of-the-1...
Also, how often do you write complete implementations of anything on the whiteboard at work and therefore how useful is this skill?
I didn't get an offer. But the filter worked: I wouldn't have been happy at a place that places value on the ability to memorize and regurgitate search results.
We just raised a seed round on the back of a deeply technical demo I wrote in my spare time.
An immediate answer, even if correct, tells you nothing because it was something they memorized. I'm much more interested in how they assess and approach--I don't even care if they come up with an answer.
Completely unstructured interviews seem to be meandering and often you walk away with gaps in your assessment.
This approach is only really applicable to jobs where those skills are needed and isn't the whole interview.
I don't think the point is that we should take pride in not knowing things so much as that perhaps this way of evaluating potential hires is not very good. Doesn't seem controversial to point out that doing a technical interview that tests skills not required on the actual job might not work well for finding the people you need.
So why not ask what you really mean by either asking the theory (big-O), or real world practice (you're adding a number to a large ordered data structure - how would you do that, what's the chosen structure, tradeoffs)
As an employer, if you really think a white board quiz is the best way to see if you want to work with someone, ask the candidate to bring a couple of questions for the interviewer to solve, you know, so the candidate can tell if they want to work with you.
An interview is a date - you want to find out if you're compatible without coming off as a jerk.
That said, white board stuff never bothered me. I don't remember caring that much if I got the job and talking to other developers is kinda enjoyable.
I blogged about this at length here: http://lonetwin.github.io/blog/html/2016/07/01/code_reviews_...
It's like saying "why should I have to write fizz buzz for an interview." Of course you'll never have to write it. You won't even have to use it.
I just need to know if you can write software at all for this software developing job you applied for. Sure, we'll evaluate other, more important, things too.
If the desire is for peers rather than coworkers, you might as well ask, "In which Marvel parallel universe did Wolverine have claws made out of banana peels instead of Adamantium?"