[jblow]

If you can’t reverse a binary tree, or don’t even know how to approach the problem, you can’t do most of programming. Fixing this should be a high priority, but the author seems to have no awareness of this.

Programming is hard. It takes a lot of skill to do it well. If the author seemed interested in acknowledging this and developing skill, the article would not come off as whiny and pointless. But it does, because he’s not interested in identifying and fixing the problem, which resides in his own house.

[chowells]

Reversing a binary tree isn't some crazy algorithmic knowledge. I'm concerned that so many people here think it is. What's gone wrong that makes people think reversing a binary tree is up there with hand-coding machine learning techniques?

Reversing a binary tree is a basic test of whether you can implement a trivial requirement given a spec. How is that not related to what you do every day on the job? You get a lot of requirements, most of which are trivial tasks needed to maintain compatibility with some broken external system that will never get fixed. The solutions are two to five lines of code, once you've taken the time to understand the requirements properly - just like reversing a binary tree.

This is neither a task that needs to be studied for nor an unfair pop quiz. It's an easier version of fizzbuzz. (You don't even need to worry about gotchas like getting case ordering wrong the way you do in fizzbuzz.) All it checks is that you have the basic skills necessary for reading and comprehending requirements and then meeting them with trivial code.

If you can't do that, what should an interviewer conclude about your capacity to do the job?

[pedrosorio]

> up there with hand-coding machine learning techniques

A toy implementation of machine learning algorithms (e.g. backprop on an arbitrary neural network) on the CPU, is pretty simple as well.

[chowells]

If you already know the algorithms, sure. The thing about reversing a binary tree is that no one already knows the algorithm. It's not something you'll find in any textbook. It has no intrinsic meaning, so why would it be there?

That makes it far better for an interview question. It's just a test of how you handle the sort of nonsense task that makes up so much day to day work. "Why do I have to frobnicate these doodads?" "Because the doodad processor requires it. That's just how it works, so we need to do it."

[Der_Einzige]

If you're doing matrix multiplication from scratch it sure isn't!

But I do think that by hand implementations of k means or k-nn or cross validation would be appropriate for folks who are interviewing for ML positions...

[lostcolony]

"Can't reverse a binary tree" is different from "Can't do it flawlessly enough in an interview setting". It also isn't necessary to provide business value. The things I spend 98% of my time on at work are not raw data structures, but leveraging those data structures.

The fact many companies interview for something that is mostly unpracticed by candidates in the field (only those practicing it at home), and won't actually be done on the job if hired, is a very strange place our industry finds itself in.

[Kranar]

There's nothing strange about it. You are simply looking at the problem from the point of view of the candidate instead of from the point of view of the business.

The vast majority of developers can absolutely do 80% of the job I give them to some sufficiently reasonable degree, but I'm not hiring people for the 80% of the job. My issue as a company is finding people who can nail the remaining 20% of the job. That's very hard to find but it's absolutely critical in a business as competitive and cutthroat as technology.

The fact that most developers don't have a basic understanding of fundamental and core concepts really does have a measurable impact on the quality of software and almost all of us, as consumers of software, pay a penalty because of it.

We put up with slow, bloated, and inadequate software because we take for granted core computing concepts, fail to appreciate the hardware our software runs on, and write software in an unbelievably indulgent manner.

Some of this is alleviated by relying on frameworks provided by the major tech companies to deliver software and that certainly helps quite a bit but this benefit doesn't come for free; it results in vendor lock in, code rot, and a genericization where many software products end up being bland and derivative because everyone is gluing together the same frameworks.

[lostcolony]

Speaking as a hiring manager, it totally is from the point of the view of the business.

I don't need 100% of my hires able to handle 100% of the tasks. I have specialists at every level anyway; if I need someone writing data structure libraries I will focus on hiring for that. Most of what I, and most software shops need, is not that.

"The fact that most developers don't have a basic understanding etc" - citation needed. Most developers do. Even those untrained. But I don't need a developer to have reviewed data structure pedantry prior to an interview; I need developers that know they don't know everything, and know how to find answers.

"We put up with slow, bloated, and inadequate software because blah blah blah" - no, we put up with it because the market doesn't care about it. All the pressures on a business are features; speed is immaterial past a certain point.

[axguscbklp]

>"We put up with slow, bloated, and inadequate software because blah blah blah" - no, we put up with it because the market doesn't care about it.

Yep. Company culture / psychology is also a factor. You can hire a bunch of amazing programmers who deeply care about speed and elegance but unless business pressures exist to incentivize those things and also the company's process and management are set up to encourage those things, it will not matter. A developer can care about speed and elegance, but if his bosses want him to use bloated frameworks because "everybody uses them" and it is easy to find developers for them, or if the feature requirements keep shifting, or if his bosses want him to spend time writing some pointless tests because of supposed "best practices", or if any of a bunch of other factors are at play, it will not matter much.

So I am not sure that a shortage of developers who are competent at those things is the real bottleneck.

[Kranar]

>I don't need 100% of my hires able to handle 100% of the tasks.

No but every facet of your software that is treated as a specialty, or handled by a specialist, introduces a bottleneck in the development process.

Understanding the basic algorithms and data structures should not be something your developers have to specialize in and it should not be something that introduces bottlenecks into your work flow.

>"The fact that most developers don't have a basic understanding etc" - citation needed.

https://blog.codinghorror.com/why-cant-programmers-program/

And yes it is very much reproducible and I manage to reproduce it consistently. Every single applicant to a job posting of mine goes through an unbelievably simple screener similar to Fizz Buzz and the fail rate to this day and on a consistent basis is over 50%.

I suppose you hire a specialist for that as well.

>All the pressures on a business are features; speed is immaterial past a certain point.

No, it's that most businesses don't even realize the importance of performance because they have no idea how to even begin measuring its impact.

As an example of this... consider a research study Google conducted to determine the maximum number of search results to display per page. Google's survey said that users wanted 20 results per page, so Google conducted an A/B test to compare traffic between 10 results per page and 20 results per page.

Their finding was that 20 results per page resulted in a tremendous drop in traffic, despite what users had told them. So certainly users were wrong and Google should stick to 10 results per page, right?

Wrong.

After very carefully studying the numbers, what Google realized was that there was an unforeseen factor that they did not take into account in their experiment nor did they anticipate it even being a factor: performance.

The 20 results per page took something like a couple 100ms longer to deliver compared to the 10 results per page, and that small performance delay was all it took to degrade user engagement and traffic on their site.

Once Google normalized performance so that 10 results took as much time as 20 results... traffic on the 20 results was substantially improved over traffic on 10 results. Furthermore this result generalized, as Google improved the performance of search results they continued noticing an improvement in traffic.

In other words... performance is treated by users as a feature, and yet it's a feature that most people don't even realize they want until they know what it's like to use reasonably fast software. Furthermore, the more performance you have, the more of a "usability budget" you have available to deliver features to your users.

You are welcome to spend your "usability budget" on hiring developers who can't answer basic questions about data structures and algorithms, and honestly if that works for your business then do it. But please understand some of us do care about writing reasonably fast software and we wish to hire developers who can answer basic technical questions about the profession they are engaged in.

Sure, I end up paying more for those developers, a lot more... but in the end that cost is but a tiny fraction of the total cost of running a company and I'm more than happy to pay it knowing that I have a team of qualified professionals who are able to implement the fundamental data structures and algorithms that underlie this profession.

[dave_sullivan]

For the record, I did look it up (back then) and I know how to do it. It's really simple. I still think it's stupid to ask about in an interview.

[kingsuper20]

I'd say that reversing a binary tree can be solved in two ways.

1. Never having thought about it before, generate an acceptable whiteboard algorithm from scratch while having a person or three bore holes in your back.

2. Throw a canned answer on the board.

My impression is that large companies prefer Door Number 2.