I Don't Want to Hire You If You Can't Reverse a Binary Tree

[minimaxir]

This submission is surprisingly not satire, and misses the points of the arguments around whiteboard coding. (the added interview stress and the limited real-world applications of the code in day-to-day work)

It is not an accurate measure of candidate technical skill, hence the rise of take-home tests. (the submission reminds me of the blog post "I Won't Hire You If You Can't Pass These Programming Questions Because Otherwise You Suck" that was written awhile ago but I can no longer find. That post backfired hilariously because author provided the wrong solution for one of the questions.)

[nanis]

A long time ago, I interviewed with a major bank. As part of an all day grilling (arrive in city at 1 am, interviews start at 7:30 am, last until 6:30 pm with a lunch break), after lunch, I was given a programming task. By that time, I had already been interviewed by three people. The task was something that may have sounded trivial at first blush. I was given a computer and an hour.

After the hour was up, my code was reviewed by six people while I interviewed with the DBA who took joy in pointing out my admitted deficiencies with SQL. I then had another hour discussing the code with the six reviewers.

The program worked on the sample data I was given. I was later told that the other candidate's programs also worked on the sample data. Except, mine was the only one which actually ran to completion with their real data sets. I was also the only interviewee without a formal CS "education".

I got an offer which I ended up not taking due to location considerations.

If you are going to ask someone to write code, give them a computer and some quiet time. You can grill them about the thinking process after they came up with something. Having someone watch over one's shoulder every time one puts a pen to the stupid whiteboard will eliminate a lot more candidates for the wrong reasons than one ought to consider desirable.

[victorhugo31337]

Couldn't disagree more with the author. How many developers need to implement their own binary-tree? This is why code-bases become convoluted with six different implementations of standard data structures.

[JamilD]

That's missing the point of the article.

The author says that the candidate's thought process behind arriving at the solution provides insight into the candidate's skill.

There's no reason to implement your own binary tree, but knowing how to devise algorithms to accomplish a given task is a necessary competency.

[smt88]

Even if a developer did need to implement a binary tree, she wouldn't be doing it in a high-pressure, interview setting, nor would she be doing it using a marker on a white board.

Furthermore, the business value of a programmer is rarely how she writes code in isolation. It's how she writes code on a team. I'd take a B-level programmer who is excellent at writing clean, readable, simple code over someone who is a savant at white-board problems.

[awinter-py]

It's not 100% false that to use a library effectively you have to be able to write it.

[x0x0]

Well, to pick on Valeri, this is simply wrong

   Trees are the single most important data structure in computer science. Just 
   about everything you do in your programming career will be related to trees.

Trees are a horrid data structure for any modern processor. Pointer chasing thrashes caches. The actual most important data structure is a hashmap. The same speed in theory, much faster in practice.

[gariany]

I lost him at: "I think homebrew is an awful piece of software that should never be used by anyone."

[jakeva]

Yeah I clicked through the link looking for further explanation and only found suffering.

[dimgl]

I wish he'd give some points as to why Homebrew is an awful piece of software. To date, I've had 0 issues...

[dkarapetyan]

He doesn't explain. Just a link to video that says exact same thing as the essay.

[yomism]

An clicking that link takes you to a talk about MongoDB & MEAN stack... the irony is strong in this one.

[minimaxir]

He clarified in the comments:

> I just couldn't resist a chance to take a snipe at homebrew, because I've spent more time than I care to admit sorting through the mess junior devs, designers, and non-technical people make of their dev machines with homebrew and when it comes time to upgrade everything inevitably goes horribly wrong.

The comment implies that real developers do not use Homebrew.

[danmanstx]

and (him) as a javascript developer, isn't npm in a similar place?

[ToastyMallows]

> "Just about everything you do in your programming career will be related to trees."

I've never knowingly used a tree structure since college, everything is abstracted away from me. Now whether this is a good thing or a bad thing remains to be seen, but it has not been a problem yet.

[aidenn0]

Have you ever stored a dictionary inside a dictionary? (e.g. something like the JSON:

    {foo : {bar : "baz"}}

That's a tree.

[w8rbt]

Very good point. If you write C++, std::set and std::map use trees. And most people who use them don't know that and 99% of the time, that's OK.

[levemi]

> "Bad programmers worry about the code. Good programmers worry about data structures and their relationships."

The sizable problem with this statement is that it is using a solution to pigeonhole a person. It takes a bit of audacious hubris, something Torvalds (an extraordinary engineer no doubt) is known for, to paint an entire person and their capacity and skill into a singular and simple quote.

Here's a novel idea: sometimes a person is a good programmer and sometimes they're a bad programmer. There's definitely a skill level that people fall into, but these aren't neat lines delineated with tired generalisms about "worrying about code" versus worrying about "data structures". Put your question into an interview and get different people to ask it and sure pick the people who were able to get a better solution. Hopefully you're asking more than one question. That's totally OK, but please don't attribute someone's performance at one question or assume that you've mastered everything it takes to know to paint someone as a "bad programmer" from one interview loop[0] or performance with their performance for that one question.

Sometimes it's obvious someone has no idea what they're doing and you can tell that from a question, but even in that case they could become better. There might be a weakness in a fundamental area they need to learn and sure you don't want to hire them until they do, but that doesn't make them a "bad programmer". All it is is a specific problem that the candidate should recognize and improve on to up their skill. They shouldn't walk away from your massive ego rethinking their career as you puff your chess out and write a haughty blog post about what you think about people and their skills.

[0] http://steve-yegge.blogspot.com/2006/03/truth-about-intervie...

[jdefr89]

You summed up everything I was thinking reading these comments good sir.

[wvenable]

> Trees are the single most important data structure in computer science.

And yet I've never professionally had to reverse one or know if they are symmetrical.

[nostrademons]

I've had to recurse on a tree many, many times, though. Think of filesystems, DOM nodes, parse trees, control-flow graphs, nested annotations, tiered lookups, query builders, JSON structures, etc.

That's what this question is actually testing: can you decompose a problem statement, expressed in plain English, into subproblems and then solve the subproblems?

[eonw]

my thoughts exactly, never had to do that once.

[jere]

Invert. Invert a binary tree. Max never gave any details on what that meant exactly, but the question is not necessarily the same as reversing a tree.

Also, way to back up your claim that Homebrew is bad software by pointing to another guy not explaining anything about Homebrew but just dogpiling on Howell again.

[voidhorse]

Terrible way to hire in my opinion.

Personally, I'd rather hire employees who are resourceful, can admit when they don't know something, can follow up with others and conduct proper research to tackle cases where they don't know the solution to a problem, and most of all, are a pleasure to work with and bring good and diligent attitudes about work into the office.

Hiring based on questions like this will get you someone ahead of the curve who perhaps you can trust to execute well immediately but will probably turn out to be a massive pain in the rear in the long run.

I'd rather hire people with good attitudes and willingness to learn and spend the extra time training them and helping them out rather than hire someone because they happened to get in enough rote technical exercises before coming into the interview.

[kwindla]

By coincidence, I just posted some notes on what I've learned over the last 15 years of hiring software engineers. I prefer giving people real-world, fairly large, programming tasks to do, and then having them talk through the code they write, rather than posing puzzle-style questions.

https://medium.com/@kwindla/hiring-software-engineers-98498c...

(This is also on HN/new right now.)

[apitaru]

I found the spirit of article a bit narrow-minded for all the reasons mentioned here already.

It did however make me think of an almost opposite activity for the next time I interview someone:

Pick a difficult trick question (like Binary Tree reversal but harder/arcane) that neither of us can solve, and spend some time working on the problem together with the candidate.

After all, solving problems together (directly, or indirectly) is what we'll be doing day to day.

This might not be a good idea, but I'll definitely try it out once and find out.

[Torgo]

It's not a "brain teaser" or a "trick question". It's an ordinary software engineering problem.

[eric_h]

Doing it on a whiteboard is an academic computer science problem.

Doing it on a computer is more along the lines of a software engineering problem, though still it is largely academic and counter to one of the tenets of good software engineering (that all code is a liability, and thus new/non battle tested code should be avoided whenever possible).

[Delmania]

> By the time I get to the whiteboard stuff, I'm looking for someone to want to engage with me, not an attempt to stump them.

Dredging this comment, because while this article is not about whiteboard coding, it would inevitably be mentioned.

I think many people, including many interviewers, completely miss the point of whiteboard coding. I think this article needs to be shared: http://darrenkopp.com/posts/2013/04/19/Post-mortem-of-my-fai...

The key point is that the interviewer is, or should be, a friend. He should not be out to stump a person or out to get him; he should genuinely want a person to succeed at the interview. If not, it's better just to reject the person outright. White board coding should be seen as a way for person to engage in collaborative problem solving, which is something that we do on a daily basis. Can you explain your thought process? Can you admit your stuck? Can you have an intelligent discussion about your solution, listen to feedback, etc. The problem should be challenging and relevant, but it should not be a test of coding skill.

[leovonl]

You don't reverse a binary tree, you iterate in the opposite direction (right-to-left). Reversing is generally a pointless operation, and which would be much more efficient if not done at all.

[Delmania]

As I mentioned in my response, knowing that trees are used for various artifacts is important for the people who are implementing said artifacts. A well done implementation hides that detail, focusing on ensuring the implementation is correct. To use his analogy of Wehlings, there are standard procedures for blood transfusions, and the doctor doesn't need to know about the heart, he just needs to know who to ask since he doesn't work in a vacuum.

The other thing is that knowing a tree is symmetric and know how to reverse one don't count as new and unknown challenges that author mentions. Both are well documented and easily accessible to anyone who needs to know that information.

I recently had an interview where I was presented with a problem the company had to solve. That was new and exciting, not some minor detail from CS100 I learned years ago.

[gone35]

I don't know JavaScript (maybe it somehow handles this automagically) but isn't his reverse function missing the base case of a NULL tree?

  function reverse(t) {
    var tmp = t.left;
    t.left  = reverse(t.right);
    t.right = reverse(tmp);
    return t;
  }

[tomjohnson3]

yep - this would throw an exception. ...and it's missing other things too. ;-)

[pan69]

I think the problem with interview questions is the following;

Asking candidates about algorithmic problems is great, if that's what you're hiring for. However, what has happened over the past decade is that a lot of companies who aren't even close to solving those kind of problems (e.g. digital ad agencies, web dev & mobile app shops) have started to ask these kind of puzzle questions in their interviews because "that's what Google does" and if Google does it, well, then it must be good.

Interviewing is hard and hiring the right candidate is even harder. A lot of interviewers don't even come close to having the experience of hiring a fellow colleague. A lot of these interviewers are basically hiring themselves meaning; if the interviewer has a PhD then the candidate they're looking should also have a PhD. If the interviewer loves Haskell then the candidate should also have this quality, if the interviewer can reverse a binary tree then, well.. regardless whether or not this has any application to the position they are hiring for,

When I interview I try to look for smart people who can explain and articulate problems well. I'm looking for people who are thoughtful and have a strong sense of integrity and an absence of ego. If they can talk about building software and programming I can easily spot if they bullshit or not. Smart people can easily learn how to reserve a binary tree.

[ketralnis]

This misses the point. You showed how easy it is to do this stuff in a real text editor without a time constraint with the luxury of testing and research before you published the post about how easy it is. That's not at all the same as solving an artificial problem on a whiteboard while nervous and in a rush and no ability to test or research

[dimgl]

That's okay; I definitely don't want to work for you either.

[strommen]

It's all about context.

If your software team works on code with lots of binary trees, interview questions about them makes a ton of sense.

If your software team is making a website that just displays stuff from databases and web services, interview questions about binary trees makes no sense at all.

[kstrauser]

> If your software team works on code with lots of binary trees, interview questions about them makes a ton of sense.

Not really, because anyone reasonably competent could be up to speed on tree operations in an afternoon on the job. Interviewing them to see if they already know likely takes more energy than having them learn about them.

That holds true for lots of things. "You say you haven't used GitLab. Too bad: that's what we use so we'll have to hire someone else." "Huh? I'm pretty sure I can figure it out in a couple of hours." "Nope. We need someone ready to hit the ground running."