Live data from Hacker News

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

thecodebarbarian.com

101–110 of 115 posts

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

#101

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 answe…

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…

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

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

#102
post #64

Earlier quoted context omitted.

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

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 yo…

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

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

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

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

#104

Earlier quoted context omitted.

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…

> 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 wi…

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.

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

#105
post #87
post #38

Earlier quoted context omitted.

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.

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

#107

Earlier quoted context omitted.

> 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 wi…

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 answer…

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

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

#108

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 answe…

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 ? Programm…

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

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

#109

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.

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

#110

Earlier quoted context omitted.

Everything in programming is trees. If you write a program that calls functions, that call other functions, that's a tree.

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.
Post reply on HN