I Don't Want to Hire You If You Can't Reverse a Binary Tree
thecodebarbarian.comThis 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.)
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.
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.
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.
So this article leads off with @mxcl's tweet about google not offering him a job because he wasn't able to reverse a binary tree on a whiteboard.
I don't think that being able to describe an algorithm you haven't had to implement in more than decade (at least, that would be the case for me, college is starting to be a long time ago for me).
Honestly right now, without looking up the answer, I probably can't reverse a binary tree on a whiteboard. I could, however, do it by test driving a solution with a real computer (I haven't flexed those muscles in a long time, but test driving would help me dig into the recesses of my brain).
Which skill set is more useful for production quality software? I can say for sure that it's not white boarding.
Deriving trivially provable algorithms in a test-driven way, by trial and error, hoping that no edge cases are missed? Sounds really, really depressing. The future of software engineering is very bleak if this approach is a new norm.
My point was that I would start by test driving to "dust off the cobwebs", as it were.
Personally, I don't actually believe in truly "mindless", trial and error TDD, as oftentimes it will miss the forest for the trees.
Amusingly now, three days later, I'm certain I could do this nonsense on a whiteboard now, as thinking about it three days ago seems to have primed my subconscious to dig it up.
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.
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.
What? You do not need to know anything at all. The very wording of this problem is already a solution. No thinking required. No prior knowledge required.
They also teach things like this in boot camps now. The graduates are trained to game these tests because placement rates are so important to boot camps.
Assuming someone is a good programmer because of trivial examples like reversing a binary tree or, worse, writing a bubble sort is like asking someone you to use a wrench to prove that you're an architect.
But surely an example question with only 2 right answers doesn't give you a good cross-section of the person's understanding. What if they understand the reverse relationship but choose the more concise option for many other reasons. The desire to understand a developer's thinking is good. This question does not well accomplish that goal.
> knowing how to devise algorithms to accomplish a given task is a necessary competency
Agreed. Why not use a realistic problem and setting?
Because realistic problems tend to be far bigger than the small, fundamental building blocks.
That's a really big obstacle, but it's not insurmountable. My companies often ask if the candidate is willing to be a contractor for a couple of weeks. If they're not currently working, it gives them some income to continue the job search, and it allows us to see what it's like working with them.
I can usually tell that someone is unacceptably bad within a few days of working with them, so it makes sense to do those few days before hiring (if possible).
Imagine you have one position, and 15 people were screened for an interview. What would you do with 15 contractors? Even if you run a Microsoft department it would not make much sense.
Trivial problems are a good filter, as long as you manage to maintain a non-stressful interview environment. Whiteboard coding is a good thing, because it shows that one really understands things, not just memorised keystrokes.
Doing about 80% of my work on a piece of paper, I cannot really comprehend all the moaning about whiteboard being "detached" from anything practical.
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.
It's not 100% false that to use a library effectively you have to be able to write it.
"To use a library effectively, you have to be able to write it."
That's a blanket statement. If we find one exception to this rule, then we can say that it's 100% false (since its truthfulness is binary -- it's either true or false).
To find one exception, we only need to find a single "good" piece of software whose author can't write 100% of the dependencies, including: (probably) C/C++ compilers, FS drivers, low-level network libraries, and the widely-used monster that is SSH.
You're not 100% wrong but you chose the wrong examples.
Compilers & drivers aren't libraries. Low-level network libraries, using libuv as an example, have concurrency gotchas that require awareness on the part of the app developer. Using TCP as an example, think of the pain people go through over nagling.
Security software is the best example of something we use without understanding but it has gotchas; you need a nontrivial understanding of the internals to guard against sidechannel attacks.
"Compilers & drivers aren't libraries"? I've used LLVM as a library to just-in-time compile from Python. How is that not a library?
BTW, I've used primality testers I don't understand and couldn't implement on my own. How might I be more effective in calling is_prime()?
Well, to pick on Valeri, this is simply wrong
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.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.This depends a lot on data size & shape. There've been some applications where I benchmarked a std::map (a tree, in practice) against Google's highly-tuned hashmap for a small (~25-50 item) container and the tree came out ahead. For such a small data structure, everything fit in L1 cache, and comparisons to follow pointers could usually be resolved by looking at the first word of the key.
One thing often forgotten with hashmaps is that they aren't actually O(1); they're O(k), where k is the length of the key, and often need to examine the entire key to derive a hashcode. This oftentimes makes them significantly slower than a binary search tree when the size of the key is large compared to the size of the container.
As always, measure before optimizing. YMMV.
Everything in programming is trees. If you write a program that calls functions, that call other functions, that's a tree.
I believe continuation-passing style is an alternative to the direct style you mention. Return-oriented programming and threaded programming may be specific counter-examples.
Unlikely. Unless a single function corresponds to a possibly infinite set of nodes, most programs are not trees.
A single node is a tree. main() is a tree.
You do not need to represent a binary tree as a structure with two pointers. See how a typical Huffan tree is implemented, for example.
How do you represent hierarchical data in a single hashmap?
Depending on your problem domain, you might be able to flatten it by just combining keys together (subject to keys being combinable like with string concatenation, using separators to ensure uniqueness of combined keys, etc.)
E.g., turn {"foo": {"bar": "moop"}} into {"foo-bar": "moop"}. This also requires writing accessor fns, but it might be worth it, depending.
Right, that works fine so long as you only ever go up the hierarchy, but going down the hierarchy would require a prefix search, which is the one place where trees actually do win over hashes.
You can frequently buy a performance increase by representing nested calculation logic in hashmaps via memoization.
I lost him at: "I think homebrew is an awful piece of software that should never be used by anyone."
Yeah I clicked through the link looking for further explanation and only found suffering.
I wish he'd give some points as to why Homebrew is an awful piece of software. To date, I've had 0 issues...
IIRC homebrew doesn’t handle inter-package dependencies very well - it’s no apt - but apart from that it seems to mostly work OK.
He doesn't explain. Just a link to video that says exact same thing as the essay.
An clicking that link takes you to a talk about MongoDB & MEAN stack... the irony is strong in this one.
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.
and (him) as a javascript developer, isn't npm in a similar place?
> "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.
Have you ever stored a dictionary inside a dictionary? (e.g. something like the JSON:
That's a tree.{foo : {bar : "baz"}}...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.)
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).
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.
> "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...
You summed up everything I was thinking reading these comments good sir.
> 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.
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?
my thoughts exactly, never had to do that once.
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.
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.
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.)
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.
It's not a "brain teaser" or a "trick question". It's an ordinary software engineering problem.
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).
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.
If you were hiring a mechanic, why would you test them on their ability to design engines?
> 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.
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.
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.
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;
}yep - this would throw an exception. ...and it's missing other things too. ;-)
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.
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
That's okay; I definitely don't want to work for you either.
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.
> 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."
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.
> "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.
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.
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.
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.
Wait. This is the same guy that uses the MEAN stack and likes to think he can distinguish good software from bad. Obvious troll.
He doesn't just use the MEAN stack. He coined the term.
In which case as most have already noted the irony is just too sweet.
ironic that his reverse function is incorrect.
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.
In all fairness he does work for a DB company.
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.
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.
front page because the 'reversing binary trees considered harmful' article got a lot of attention last year
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.
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?
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
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.
The point is that this is not a "know it or not" question. You should be able to derive this answer, even if you've never seen it before, by combining things that you should have seen, because they show up all the time in CS.
In the first approach he gives, you need to divide the problem into smaller subproblems, knowing that a tree is the combination of either two branches that are themselves trees or a single leaf node. What's the rule for determining whether two trees are symmetric? Well, if both of them are leaves, the answer is trivially true. If one of them is a leaf and the other is a branch, the answer is trivially false. If they are both branches, then you need to make sure that the left branch matches the reversed copy of the right branch, and vice versa, i.e. left is symmetric to right and right is symmetric to left. And you have the solution he gave.
That also clues you in to the second solution, where you define "symmetric" as "the reverse of tree1 is equal to tree2", and then write appropriate recursive helper functions for this.
What the author's really testing for is "Can you decompose problems that you don't know how to do into problems that you do know how to do?" This is a critical skill for doing anything new, and the vast majority of economic gains in the software industry go to people producing new stuff and not looking up other peoples' solutions. Effectively, what he's trying to select for is folks who don't believe this is a matter of received wisdom and instead are willing to figure it out themselves.
(Interestingly, there's a bug in his code. It doesn't affect the correctness of the point he's trying to make, but would be infuriating to an actual Javascript programmer working with this function. See if you can spot it before he merges my pull request...)
> The point is that this is not a "know it or not" question. You should be able to derive this answer, even if you've never seen it before, by combining things that you should have seen, because they show up all the time in CS.
Sure, you don't absolutely need to know the problem to be able to derive an answer on the spot, but the problem with a widely known question like this is that candidates who already know it will have an almost insurmountable advantage over those who have never heard of it before, which makes it in essence a "know it or not" question.
There is very little you can do to distinguish between the candidates who knew the question beforehand but feigned ignorance versus those who actually managed to figure it out on the spot.
That can be pretty easily compensated for by asking the candidate to explain their thinking out loud (which you'd want to do anyway). Someone who's seen it before will be too perfect: they'll just rattle off a solution and it'll be right. Someone who's actively working through it will pause, they'll hesitate, they'll get things wrong and have to correct themselves.
I've occasionally seen candidates who had the answers to interview questions I asked. They actually came clean and said they'd heard it before, but I was already pretty suspicious that they were actively familiar with the question.
> Someone who's actively working through it will pause, they'll hesitate, they'll get things wrong and have to correct themselves.
Candidates who know the solution can and sometimes will do the same. Sure, you can try to catch candidates that try to fake it, but then the process becomes a cat and mouse game between the interviewer and candidate that distracts both parties from the real purpose of the interview, which is to find the most qualified candidate for a position.
None of this would be necessary if the interviewer simply used a lesser known question (or better yet, a more practical question adapted from something taken from the part of the codebase that they'd be working on) to begin with.
...and can you reason though all of this in 15 minutes with 1-2 people staring at you?
Why not?
(I get that some people have legitimate anxiety issues when placed in a situation where they're being judged and have to perform rationally under pressure. Hell, I face this every day when I think about getting customers and delivering to them. But these are worth working through on their own: there are many situations besides interviews where you will be forced to make clear & correct decisions under time pressure and are being judged on the results. The key is to focus on the thought process, not the judgment: the interviewer is irrelevant, if he doesn't like what you do go off and find another interviewer.)
It is a 1 minute question, to be honest. Even FizzBuzz requires more thinking.
> If you hire using know it or not questions about binary trees
The article author doesn't think of his question as a "know it or not" question, but a "you should be able to figure this out" question:
> Here's the first reason why this question is so good: a skilled programmer can map their intuition to code. You can tell at a glance whether a binary tree is symmetric, but beginners will often struggle with a question like this because they approach this problem from a visual/intuitive angle rather than the logical angle.
I think it's a fair criticism to say that, at this point, "reverse a binary tree" is something a lot of applicants will have simply memorized rather than figuring out on the fly. But (to play Devil's Advocate) isn't the goal of the question - to test a candidate's ability to think logically and problem-solve on the fly - a reasonable one?
It seems to me the real problems with whiteboard-coding interviews aren't that what they're trying to test - problem-solving on the fly - isn't useful or valuable, but that whiteboard coding is confounded by so many irrelevant variables: ability to think under pressure, ability to code "in your head" (without an editor, IDE or REPL), memorizing solutions, and so forth.
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.
I think most people here miss the point, thinking that they need to know about symmetric binary trees in order to be able to answer such questions.
These kind of tests are aiming to find developers who can think out of the box and start solving problems they haven't heard of before. This is quite a simple problem to solve if you start thinking about it. If you get stuck because of the binary tree and because you've never done that before, then I believe you would be a mediocre dev (which is not a problem in many companies).
" 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?"
It's an excellent heuristic. It doesn't separate good vs bad programmers; it identifies programmers who love solving problems, and see their careers as problem solvers instead of as limited-view coders who are assigned a javascript task.
Like you said, it also takes time to develop this. So it also identifies programmers who have taken the time to hone that kind of problem-solving intuition, which is far more difficult to develop, than throwing up a webpage with bootstrap.
I run a successful coding interview prep bootcamp for a living. Among other things, we also go thru several Data Structures and Algorithms. Primary objective is to practice intuition on some of these problems. Those who work hard at it, invariably develop irreversible intuition to this stuff.
> 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.
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.
> 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.
> 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?
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.
> Programmers are so sensitive, and honestly all your "sighing" is obnoxious.
> I'm actually not annoyed
TIL that programmers can be both sensitive and deny being sensitive.
when i interviewed at yahoo as a full stack web developer, i was dismissed after getting the a single tree related question wrong. was a trivial 'trick' question about balancing certain types of trees, similar to this article. having been through that, i wouldn't have wanted to work there based on that being the bar of entry.
Seeing as Yahoo! completely lost the race to hire the "best and brightest," and is now teetering on the brink of dissolution, I'd say that you:
a. dodged a bullet b. should basically do the exact opposite of every part of their hiring practices
You dodged a bullet there. Maybe you can use this as a canary to tell if a company is one you want to work for based on questions they ask.
It also doesn't mean the candidate will get along with their co-workers, take direction well, ask for help when needed, or bathe before coming to work. Since when have we required that a necessary qualification be a sufficient qualification?
At the very least, it means they studied up on the tricks. That's good for something.