
I Don't Want to Hire You If You Can't Reverse a Binary Tree - cherry_su
http://thecodebarbarian.com/i-dont-want-to-hire-you-if-you-cant-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.

~~~
minimaxir
Reversing a binary search tree is a binary (pun intended) answer: you either
know how to do it because you learned it in college/read Cracking the Coding
Interview, or you don't.

~~~
nostrademons
Is it not obvious that you reverse the left and right subtrees and then swap
them?

I learned how to think recursively in college. I never learned how to reverse
a binary tree.

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

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

~~~
pja
IIRC homebrew doesn’t handle inter-package dependencies very well - it’s no
apt - but apart from that it seems to mostly work OK.

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

~~~
KingMob
...unless it's a hashmap inside a hashmap. Or named fields in an object
holding pointers that use no keys after compilation.

The point being that hierarchical structures in programming languages abstract
away from the underlying representation, and you can use them without knowing
the details. (Though you should probably know anyway, so you understand your
Big-O tradeoffs.)

~~~
aidenn0
A hashmap inside of a hashmap is just as much of a tree as an array inside of
an array (which for a 2 element array describes a binary tree).

------
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...](http://steve-yegge.blogspot.com/2006/03/truth-about-
interviewing.html)

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

------
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...](https://medium.com/@kwindla/hiring-software-
engineers-98498cf6f2a#.dvbuqw664)

(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).

~~~
Torgo
I wouldn't solve all car engine problems by completely replacing the engine,
but if I was hiring a mechanic I'd want to verify he could replace the engine
if needed.

~~~
eric_h
If you were hiring a mechanic, why would you test them on their ability to
design engines?

------
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...](http://darrenkopp.com/posts/2013/04/19/Post-mortem-of-my-failed-
interview.html)

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

------
btilly
He undermines his own point by pointing to dictionaries as an example of
something that uses trees. Which suggests that he doesn't know that
dictionaries in most languages are implemented as hashes, and hashes are NOT
based on trees!

The truth is that interviews should test the skills your job actually
requires. For a variety of skills outside of that core, it is valuable to have
someone on your team who understands it for other people to go to. But if
you're not doing algorithms all the time, you don't need or want everyone to
have mastered that.

And I say this as someone who knows algorithms well enough to pass his
interview.

------
rabbyte
> "Skill in software engineering, like skill in any subject, is not cultivated
> by limiting yourself to a narrow set of knowledge and challenges."

Except you've done exactly this by selecting tree structures, something you
find intuitive, and using it as a measurement for everything else. If you hire
like this you will be successful in surrounding yourself with others who think
just like you. Maybe that's a strength for the product you're building but
it's a strength achieved by limiting yourself to a narrow set of knowledge.

------
crispyambulance
I think some folks get hung up on the idea that the answer to one question can
be used as a go/no-go for a hire decision.

Its never that simple, there's a lot more to consider, and the vast majority
of candidates will bomb a technical question or two eventually.

For those of you that are job hunting right now... don't get bent out of
shape, there are plenty of employers that won't hinge their acceptance on one
technical brain-teaser.

~~~
bbarn
Boom. I do ask at least one code it on a white board question usually, and
what I don't do is sit back twiddling my fingers and think to myself, he/she
gets this or else. I actually don't mind at all when a candidate doesn't know
it and asks me for help - provided they've made some good faith effort. That's
why we have so many other questions and conversations. 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.

------
Lendal
I don't want to work at a place where reversing binary trees is so important
to your everyday work that it deserves a place in the interview process.

------
dkarapetyan
Wait. This is the same guy that uses the MEAN stack and likes to think he can
distinguish good software from bad. Obvious troll.

~~~
nanodano
He doesn't just use the MEAN stack. He coined the term.

~~~
dkarapetyan
In which case as most have already noted the irony is just too sweet.

------
tomjohnson3
ironic that his reverse function is incorrect.

~~~
terio
Yes, he missed the base case for recursion.

Also, the first definition of symmetric tree is wrong. One more appropriate
would say that the left branch is the mirror image of the right branch.

------
sharemywin
In all fairness he does work for a DB company.

------
planetjones
Bad article IMO and no idea how it's front page. Yes a database may rely on b
trees under the hood, but thankfully someone else has implemented that
complexity so my web developer can concentrate on higher level interactions
with it.

His herpes analogy is ridiculous. And I've used brew since getting a Mac and
no I'm not suffering now.

~~~
Lendal
Exactly, I would take this interview question to mean that this place is so
cheap that they won't even invest in a proper database engine for the product
to run on. You have to implement the database engine yourself. And that you
probably won't get paid commensurately for it.

------
pacomerh
These questions shouldn't be asked expecting an exact solution in the
whiteboard, this adds layers of stress and time. They should be asked
expecting an explanation of how they work conceptually. You want to see if the
person understands the methods used to traverse, sort, manipulate them. Are
they important?, of course.

------
smt88
Many working programmers will disagree with this article. That's a good start,
but we should also work toward ending this practice:

1\. If your company does it, you should try to end it. Research alternatives
and propose them. Take-home problems that mimic real problems at your company
might be an option, as would hiring someone for a few contracting hours to do
solve real problems before hiring them full-time.

2\. If you apply to a company that uses these questions, politely excuse
yourself from the process (assuming you are at the point in your life where
you can refuse offers). That company probably doesn't really have the
employee-focused culture you'd want to be a part of. If enough candidates
refuse to do these tests, we might see them decline in prevalence.

3\. If your company used interview methods like this and then stopped, try to
create a case study. What did your company switch to? Do you have data to back
up the perceived benefits of the switch?

------
mrpoptart
Small edit would improve your statement a lot: I Don't Want to Hire You If You
Can't Learn How to Reverse a Binary Tree

------
askyourmother
Sigh. If you hire using know it or not questions about binary trees, then you
finally get to hire people who can study up and answer that specific question
in a manner Pavlov would approve of.

That does not mean the candidate will be able to design clean APIs, know how
best work with different types of data, or even how to troubleshoot existing
code.

Still, pat yourself on the back, I mean, your entire team can answer a
specific trick interview question, and that's all that matters, right? Right?

Sigh.

~~~
joslin01
How is that a "trick" question? I never been asked that in an interview
question and had the correct solution in my head in just a few seconds for the
very reason he gives -- experienced programmers can map their intuition to
code. This is certainly a skill that takes time to develop, and if you're
concerned with hiring the best, don't you think this is a decent heuristic to
throw in _with a bunch of others_?

Programmers are so sensitive, and honestly all your "sighing" is obnoxious.
You don't have it all figured out.

~~~
smt88
> _Programmers are so sensitive, and honestly all your "sighing" is
> obnoxious._

Perhaps instead of being annoyed, you could try to understand why people are
sighing. Many of them will have lost out on a job they were qualified to do
because of bullshit interviewing practices like this one. It has a real effect
on them. It's not a trivial issue.

> _You don 't have it all figured out._

No one here has claimed to have it all figured out, nor are the majority of
comments an implication of that. We're all just saying we have _one thing_
figured out: whiteboard interviews are terrible, alienating, unrealistic,
antiquated tools for hiring.

Your profile says you're a CTO, and you should know that research increasingly
shows that people don't quit jobs, they quit bosses. If you want to be the
kind of boss that programmers want to work for, you should be more open to
understanding why the vast majority of us feel strongly about a topic like
this instead of calling us obnoxious.

If you yourself are not a programmer, I'm not sure why you're weighing in on
this at all.

~~~
joslin01
I'm actually not annoyed nor do I misunderstand why people are sighing. Your
emotional appeal does not hold much weight when faced with real business
practices of hiring "the best" that every organization is going to strive for.

I'm somehow a poor boss to work for because I told the OP his sighing is
obnoxious? It is. It feigns authority and condescends the entire post for
being so dumb he has to sigh at it. While you might have your feelings hurt,
have you considered the feelings of the guy who took the time to write up an
entire post explaining his position in a rather civil & straightforward
manner? Have you considered the person at the other end of the interview
table?

> No one here has claimed to have it all figured out

> whiteboard interviews are terrible, alienating, unrealistic, antiquated
> tools for hiring.

Hm...

And ya man, I'm not a programmer but I figured out his coding puzzle in a few
seconds.

~~~
smt88
> _I 'm actually not annoyed_

Calling people obnoxious makes it sound like you were annoyed.

> _Your emotional appeal does not hold much weight when faced with real
> business practices_

People are highly emotional. Emotions explain the way people behave far better
than logic does. Hiring is partially a process of selling a product
(employment) to a customer with lots of options (the "best"). If you don't
consider the emotional impact of your hiring practices, you'll turn off some
of the "best" for no reason.

Considering and accommodating people's emotions also has a huge impact on
retention, which is also incredibly important.

> _considered the feelings of the guy who took the time to write up an entire
> post explaining his position in a rather civil & straightforward manner_

No. He didn't have to write the post. He wanted people to hear him and
respond, and that's what he got.

I consider the feelings of people applying for jobs because they have no other
choice.

> _Have you considered the person at the other end of the interview table?_

I've been that person for 10 years. That's the first person whose feelings
I've considered because they are my own.

Interviewing is boring, tedious, and almost impossible to turn into a
repeatable process. I understand the impulse to find repeatable, objective
ways to measure a candidate's abilities.

Unfortunately, people don't necessarily like being test subjects in high-
pressure situations.

> _Hm..._

As I stated above, saying _one thing_ about a very specific interview practice
is not claiming to know everything. It's claiming to know a single, specific
thing.

~~~
sklogic
> Unfortunately, people don't necessarily like being test subjects in high-
> pressure situations.

And yet somehow they love to play highly stressful, challenging video games
and love to be ranked against their peers. Something to think about, is not
it?

~~~
smt88
If the reward of a video game were a job, and the penalty was being unemployed
for, let's say, 2 more weeks, people would not play video games the same way
they do now.

 _Artificial_ pressure and competition is enjoyable, just as roller coasters
are enjoyable but riding a swaying bus on a mountain road without a guard rail
is not.

