Hacker News Reader

Comment by smallerfish | Hacker News Reader

Because sometimes the requirement is that the engineer being hired is able to come up with efficient algorithms. You don't have to be able to create the textbook binary tree algorithms, but you should be able to derive a reasonably performant algorithm with simple data structures if it matters to the position you're being hired for.

View on HN

> requirement is that the engineer being hired is able to come up with efficient algorithms.

Coding binary tree is not the way to discover that.

Presenting a task and observing people solving it and explaining computation complexity behind their solution and the thinking behind their solution is how you do that.

It's a fine way of doing it, although certainly it shouldn't be the only algorithms question.

It's a simple data structures / algorithms question. Can you think in terms of how data is stored in memory? Do you understand the tradeoffs of storing data in one form or another? Can you work with recursive algorithms? Given a challenge of having to think about data in a form you haven't recently, can you wrap your mind around the characteristics of that data structure?

If you're getting asked all this for a ReactJS UI building job, then the interviewer is probably off-base. But otherwise, make sure you're applying for jobs you're suited for. If you don't want a job where coming up with efficient algorithms is important, that's fine - there's plenty of others out there.

> Can you think in terms of how data is stored in memory?

If you're using a modern OS, you don't know this. The kernel remaps everything and pretends to give you a linear chunk of memory. You don't know what's in the various caches and what's been paged out of ram completely.

Everything is built on layers of abstraction. C is an abstraction layer that fits poorly into what modern CPUs and operating systems actually do, but everything is programmed to cater to C's assumptions so people don't need to rewrite their programs.

Higher languages don't necessarily use the data structure you think they do and they can switch the implementation details based on the size.

"Simple data structures" are only simple because you pick one specific layer of abstraction to work with.

That's not an excuse for not being able to reason about data structures if your job requires working with data structures and algorithms. The logical extension of your argument is "put everything in a linked list and let the OS work it out."

If I give a candidate a truly real world difficult problem with an hour or even a day to solve it, some people who are not so smart will get the correct answer by luck, some people who are brilliant will start off with a bad approach and not get there.

If I ask if you can do something basic binary tree things, I will also not know if you are brilliant, but I can at least rule out if you are totally clueless or not.

Sorry, but regurgitating binary tree operations is not "coming up with efficient algorithms".

Well hopefully there's some layering in the question if it matters to the job. If you have an engineering position in which a high degree of CS competence is required and the candidate can't even make it past the initial layer of "regurgitating binary tree operations" then you have the wrong candidate.

> If you have an engineering position in which a high degree of CS competence is required and the candidate can't even make it past the initial layer of "regurgitating binary tree operations" then you have the wrong candidate.

Or you have a candidate who understands binary trees, can implement it but can't regurgitate binary tree operations from the top of their memory.

For me the point would be that a no-frills binary tree is simple enough that any dev qualified for such a position should be able to figure out what needs to be done from the specification, without needing to regurgitate anything.

If they can't recall how balancing is done that would be fine with me, as long as they mention it.

Exactly. And that's the reason you'd probably layer the question with some more complex asks after the initial answer. If somebody has memorized the algorithm but then can't explain further, it's obvious they've "regurgitated" without really having a deep understanding of the problem being solved with the data structure. By contrast, a good candidate may not be able to immediately repeat the algorithm, but can reason their way there pretty quickly.

> By contrast, a good candidate may not be able to immediately repeat the algorithm, but can reason their way there pretty quickly.

I know dozens of good candidates who can't get there pretty quickly but are really good. I also know dozens of good candidates who can get there pretty quickly but won't be good enough on the job.

Maybe they'd be really good at other engineer positions, but if they can't get to a binary tree algorithm reasonably fast I wouldn't hire them for backend positions that require CS reasoning.

> Maybe they'd be really good at other engineer positions, but if they can't get to a binary tree algorithm reasonably fast I wouldn't hire them for backend positions that require CS reasoning.

You not hiring for backend positions doesn't mean they are not good at the positions. It just means they aren't good at your signals.

For me it's a strong signal, but it shouldn't be the only signal. And I do think it's good to have a diverse team.

Some of my coworkers are not nearly as strong as me when it comes to "CS details" like data structures or programming languages, but they have other attributes which complement me and which are good for the team.

Having a bunch of me's (or any of the others) would be a disaster.

You mean, "regurgitate" operations like this?

    find = lambda k, t: t if t is None or k == t.k else find(k, t.left) if k < t.k else find(k, t.right)

I mean, figuring out how to rebalance a red-black tree after insertion is more demanding, and you could legitimately quibble with my golfing here, but I feel like the reasoning required to write that function (given the tree definition) is just not that advanced. It's like the FizzBuzz of pointers.

Reply on news.ycombinator.com