[djipko]

Most companies that people put up as examples of asking "fundamentals" that are unrelated to the job, actually don't at all ask candidates to regurgitate fundamentals. Instead they ask them to solve a programming problem, which commonly requires them to apply their knowledge of some very basic fundamentals. This is very different. "Very basic" is important to note here, because almost no companies nowadays ask anything other than very basic application of common data-structures. If we are sticking to the music analogies - this is closer to asking a musician to perform a well known piece of music from a sheet than regurgitate esoteric music theory.

The performance part might be a problem for some people and I agree - programming is not music, and it's tricky and unnatural to program in front of an audience, but this is a completely learnable skill by practice. That said I agree that it will always penalise a subset of people who will always perform less good under pressure.

There is a flip side to this though which often goes overlooked and author hints at it: programming interviews are a great equaliser - there are no credential checks (or they are getting much less common) for getting into top companies, and you can be based almost anywhere in the world - all you need to do to get in is crush the coding interview which is totally a learnable skill. This has opened many doors and economic opportunities for people that did not have them even a decade ago, and I think we as an industry don't talk enough about the opportunities our attitude to barriers to entry create.

Finally there's the question of whether the skill tested in coding interviews are really unrelated to the job performance. I've seen arguments that state: "some data shows that how a person performed on the interview is unrelated to how they perform as an employee". But this kind of reasoning almost certainly suffers from selection bias, as we'd really need to include how people who did not pass the interviews perform at the job (for obvious reasons companies don't have this data). I would bet that there would be a much stronger link with interview performance in that case.

Overall I think it's more likely that coding interviews are the way they are because they work extremely well in practice, most of the time. They are also on average a massive equaliser and overall a good thing for almost everyone involved provided they are executed well. They do have their problems, but commonly proposed alternatives (like take home tests etc.) have problems too. Coding interviews are not a thing because there is some kind of collective madness in the whole industry, where people in charge of procuring the most expensive resource just can't help themselves succumb to group-think. They are a thing because they work well (but not perfectly).