Hacker News Reader

Comment by askyourmother | Hacker News Reader

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.

View on HN

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

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

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

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

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

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

[http://interviewkickstart.com]

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.

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.

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

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.

Reply on news.ycombinator.com