E-mail, at the time, didn't need them - there was no search, no deduplication, no anything but "do a bunch of deterministic, bounded operations very quickly." Sure, some hash tables and plenty of linked lists, but that's about it.

Am I just a big fat outlier there, condemned to cram Skiena before every interview for the rest of my life?

Judging by the fact that you were able to do many deterministic bounded operations quickly, and understand why they were bounded and why they were quick, I get the feeling that you'd do much better at an algorithm interview than you give yourself credit for.

And I'd also cram CLRS before an interview :P I know I'm good at what I do compared to the avg coder, but compared to the average coder at Palantir, I have a long way to go. I'm in no way satisfied with my ability where it is today and its always smart to take a refresher before an interview.

What you said isn't condescending at all. If you are a self taught programmer and you haven't read up and gotten a good handle on big O notation, data structures, and algorithms, do yourself a favor and start.

By your definition, I am currently a "bad programmer" because I do not have fluency in algorithms.

(I will leave the objective truth of this statement as an exercise to the reader; God knows it might be so. However...)

I contend that I am capable of learning new material quickly enough that, if I were suddenly called upon at my job to write code which handles all of the slings and arrows of algorithmic complexity, I would be able to do so with very little friction. To phrase it differently: I (probably) don't know enough to write gorgeous, algorithmically sophisticated code on the first pass, but I know enough to know when it's time for me to hit the books, and where to start.

Obviously, it would take me longer than someone with prior experience in writing such code! If the overarching question is "does algorithmic fluency constitute a dealbreaker when hiring at certain positions", then I suppose the answer depends on how much longer it would take. I can only speculate on the difference in a flagrantly biased manner, as I would egotistically prefer to believe that I ought to be hired in more cases than not. :-)

Or, if we look through the Dunning-Kruger lens, we may conclude that lack of algorithmic fluency always constitutes a dealbreaker at certain positions, because even if the developer in question can learn on the job, he or she will still make errors and oversights with far-reaching implications that are invisible--unknown unknowns--to the algorithmically illiterate. This feels less plausible to me than the simpler consideration that "learning on the job" may simply be an undesirable speed bump.

I don't really have any concrete points or refutations to make; I'm just fascinated by the issue in general and enjoy exploring the possible angles.

(Also I shall likely just cut the Gordian knot and go play with algorithms until it simply isn't an issue anymore. Go figure)

EDIT: Actually, there is a point I forgot to make:

In your edit you wrote, "So a lot of "self taught" programmers have only taught themselves 10% of what they need to know and never bother learning the other 90%." I think this is the crux of the "good/bad" problem: "what they need to know" is very subjective and dependent on context.

I think it's reasonable to assert that there are programmers out there who have long and satisfying careers, but never learned X, or didn't learn it for many years. Who's to say whether they are "good" or "bad"? It's a judgment, and judgments are meaningless without context: "good programmers need to know X" doesn't really say anything, but "programmers need to know X if they want to Y" does.

You certainly went down this road in your comment, but your Y was "You do need good programmers to scale your product, add features efficiently, and architect solutions without making a crippling mess of your code.", and I feel like lack of fluency in algorithms is just not a surefire indicator of bad architecture skills (among the others you listed) as well.

And since actually getting a new person on-board is an expensive process, you aim for criteria that are a bit too stringent, if you can afford it.

There's also the issue that making a bad algorithmic decision at the center of the problem turns scaling into an insanely hard problem, sometimes. It's not so much about learning about it when you need it, but about avoiding issues in the first place.

True, there are many places where it truly doesn't matter - but if scaling/performance matter for your company, you don't want to head down the garden path because your developers didn't know better.

Not knowing algorithms won't exclude you from all jobs (or even many of them), but there are some jobs where it _will_ bite you. It's your choice if you want to go for those jobs. Personally, I think they are where the cool stuff is happening, but YMMV.

You are SERIOUSLY underestimating the amount of time required to learn that stuff. In essence, the full 4 years of a CS course deals with data structures, algorithm and math. Good luck finding a project where the stakeholders are willing to wait that much. Also, unless you are a very unique snowflake, you will not have the required discipline.

On the other hand, learning a new language is accomplished in a matter of days. Learning how to code well requires experience and willingness to learn from one's mistakes.

Which a candidate with a good CS background may already have.

The learning is often sufficient to serve the needs at the moment. If I have to quickly fix my juicer, I don't under go do Electrical and mechanical engineering courses for the next 4 years.

Instead what I do is, I define the problem. Search for the solutions on the internet. The solution requires me to understand some theory and some practical aspects of things with some tool usage. It is more than sufficient to that to solve the problem for the moment.

That is how most of the software is, its practically impossible to know every thing from the book. What is more important today is given the body of knowledge can a person study and solve the problems. A person can be productive and deliver the goods with the above approach, With a little discipline.

That's how most knowledge based work happens in the 21st century.

I also see a lot of people around me trading stocks, although they understand virtually nothing about economics in detail. For the most the part they can make 10-15% profit on their investment by just using some basic analytical skills.

This is the problem with kids these days.

We can argue as much as we can about generational differences. These days you can do a lot of things without knowing much about it before hand. That's the kind of advantage internet offers you these days.

If a person is unable to leverage this to his advantage, I feel sorry for him. And I see no reason why others shouldn't do this just because he can't.

After he left I went back to learn math for interest and got really into it. I now realise that literally six months of the work he did I could do in an afternoon as I now have a deeper understanding of the mathematics behind it than he did. I'm not smarter, far from it, just have more tools to call on. And this was a guy that taught the algorithms course at a good university.

We are all capable of learning almost anything, but a lack of knowledge about the subject matter constrains your solution search space to a large degree. I believe strongly that fluency in algorithms is a minimal prerequistite to be a decent developer. It's like learning calculus without knowing trig, you can do it, but you'll be reinventing (poorly) a tonne of work that came before and you'll be slower and less accurate. It's not like it's rocket science either, you could get a basic understanding in a concentrated day of work so there's no reason not to.

In computer science, there is the notion of the NP-complete problem, for which there is no known efficient solution. But if a solution is found, it can be verified very quickly. I think the analogy holds here.

Math is unreasonably effective. Just like knowledge of basic algorithmic analysis. I don't think that should be controversial.

How do you know whether or not this is true? Until you know it, how do you go about estimating how long it will take to you to learn it? How do you even assess when you've learned "enough" algorithmic complexity for the task at hand? Can you give any reasons someone looking to hire you should believe that you can learn the ins and outs of algorithmic complexity with "very little friction"?

Do you time your app at various loads (including well beyond expectations), graph the performance and look for non-linear increases?

It was condescending to my eyes, nothing more nothing less.