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