[nostrademons]

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

[lewisl9029]

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

[nostrademons]

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.

[lewisl9029]

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

[minimaxir]

...and can you reason though all of this in 15 minutes with 1-2 people staring at you?

[nostrademons]

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

[sklogic]

It is a 1 minute question, to be honest. Even FizzBuzz requires more thinking.