
Dhh: I would fail to write bubble sort on a whiteboard - devnonymous
https://twitter.com/dhh/status/834146806594433025
======
cousin_it
There seems to be a growing and vocal subgroup of programmers who think
solving algorithm problems is about memorization. That worries me. Don't they
understand that problems can be solved by thinking? That they're being asked
about the most timeless and beautiful parts of programming, which don't depend
on the technology of the day, and whose beauty is that you _can_ figure out
everything from scratch? Or that solving such problems gave us computers and
the internet in the first place?

...I must be getting old. I have nothing but ugly things to say about that
attitude. Sorry, HN.

~~~
viraptor
Unless you specifically work in a scientific environment, when do you ever
solve problems using a novel, non trivial algorithm designed by yourself? An
amazing amount of programmers are simply doing CRUD, batch processing, and
mapping data from one format to another. It's not rocket science.

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.

------
Eridrus
The first twitter response is pretty great IMO "Hopefully we won't get to the
point where people take as much pride in ignorance about CS as they currently
do about math."

Maybe you don't use bubble sort, but it is truly trivial and these arguments
seem quite anti-intellectual.

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

~~~
curtis
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.

~~~
geebee
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
> _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.

~~~
curtis
> _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'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.

------
gimpthrow
I recently experienced this filter when I applied to one of the big tech
companies without bothering to re-memorize my undergraduate-level algorithms.
I figured having run two companies and fifteen years of industry experience
with a dozen languages was good enough.

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.

------
pfranz
While I think the focus on knowing undergraduate level algorithms verbatim and
gotcha riddles are silly and a waste of time, they're exaggerations of very
useful techniques. Something like fizz buzz is simple enough and trips up a
surprising number of people that were able to talk their way into the
interview. Puzzles allow you to assess their critical thing skills without
letting them get caught up in semantics that tends to happen if you make it
about programming (too many questions about libraries, coding style, etc).

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.

------
ejlangev
How many times in your career have you needed to implement bubble sort without
the ability to google it? In my experience I can say never and imagine that's
what other people would say too.

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.

~~~
oftenwrong
I want to hire people that can write robust, maintainable software.
Unfortunately, I do not know how to test for that. At my company we do not do
algorithm quizzes because, for better or for worse, algorithm mastery is not
really important for most of our work. We mainly talk about work experience in
the interview.

------
joeax
While I don't think you should know how to implement bubble sort on the fly in
an interview, you should probably understand what it is at a conversational
level, along with merge sort and quick sort, especially if the position is
senior or lead and requires a CS degree.

~~~
viraptor
I think that's just a bad substitute for the real question: What's the big-O
notation, how do algorithms differ based on the CPU / memory usage and
existing data format. Nobody uses merge/quick sort as originally defined
anyway. In reality it's going to be some mix of algorithms with a threshold.

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)

------
chrisbennet
If you're hiring for "great", you need to realize it is a two way street.

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.

------
devnonymous
Fwiw I think the emphasis on the ability to write code instead of ability to
read and understand it has been given disproportionate importance when the
reality is that we spend a lot of time (perhaps even more time) reading rather
that than writing.

I blogged about this at length here:
[http://lonetwin.github.io/blog/html/2016/07/01/code_reviews_...](http://lonetwin.github.io/blog/html/2016/07/01/code_reviews_instead_of_whiteboard_for_interviews.html)

------
gumballhead
Does anyone agreeing with this tweet know what bubble sort is? It's fine if
you don't but if it's explained to you it should be pretty trivial.

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.

~~~
gumballhead
Looks like this is related to
[https://twitter.com/cyberomin/status/835888786462625792](https://twitter.com/cyberomin/status/835888786462625792),
which is a _bit_ different. So nevermind.

------
z3t4
they could just as well ask to do multiplication without a calculator. many
programing languages already have a sorting function in its standard library.

------
codr4life
Agreed, the stupid quiz culture is getting old. I suspect people who cling to
this tradition wouldn't be able to code their way out of a paper bag outside
the sphere of well defined problems with canned solutions.

~~~
bdcravens
Or the hiring process is optimizing for "nerd culture", whereas most
development is optimized for solving business problems, and the two are often
at odds.

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

