Earlier in my career, I have been asked to design circuits in interviews. Phone screens have also included in depth discussions of component tradeoffs for various circuits. My most recent interview, after 20+ years of experience, wasn't very technical at all, mostly focusing on team fit and personalities. The whole discussion here of software engineers with 20+ years of experience having to code up fairly simple things on a white board is very strange to me, and fairly far outside my experience.

> The whole discussion here of software engineers with 20+ years of experience having to code up fairly simple things on a white board is very strange to me, and fairly far outside my experience.

Once you start interviewing people with a lot of experience and see how poorly some do with FizzBuzz or 'merge 2 sorted arrays', it becomes immediately obvious why this is done. If 20 years experience was a good indicator, it would be used instead. For positions where there's no coding, this wouldn't be asked. All at least in my experience.

Maybe its a mismatch between practice and experience. When asked how to map phone numbers into words in a dictionary (or whatever), I don't start coding. I draw pictures and data maps and constraints. Maybe I write a critical condition algebraically. After fleshing out all the corners and dark places, then I may choose a programming language and code approach.

So coding exams are almost a litmus test for "inexperienced programmer" in my view. Because an experienced developer doesn't start by coding at all.

You could certainly do all of those things during a coding test, as much as was appropriate for such small problems. I'm sure that would impress people if you did it competently.

> So coding exams are almost a litmus test for "inexperienced programmer" in my view.

You certainly could call them that when they weed out people with 20 years of experience who can't merge 2 sorted lists.

What you've said is true, that it is remarkable how many applicants who look great on paper actually can't code simple things, but these technical interviews go way beyond those simple questions. I've personally failed to pass the technical interview stage at more than one company, and I wouldn't have had any trouble at all coding fizzbuzz or merging two sorted arrays.

Granted, this was at a company with a notoriously difficult technical screen, but it goes far beyond fizzbuzz or merging two sorted arrays. If you can't do that, there's no way you'll pass, but I'd say you need to be prepared to solve difficult questions from "cracking the coding interview" at the whiteboard in 45 minutes or less, without needing a great deal of help. Minor syntax errors are fine, but your code needs to be pretty tight and close to working.

I walk around with the ability to do fizzbuzz or merge two sorted arrays in my head, and I could code up merge sort or find the path from a root node to descendant in a binary tree with a little thought. But really, no joke, in my experience, these interviews take far, far more than that. I can't speak for everyone, but I personally need to study, hard, for a few weeks to a few months to get into this kind of form, depending on how long it's been since I last did it.

I have no doubt that the degree of technical grilling varies considerably between companies, which is why I'm not doubting what you've said here. However, I am certain that it doesn't tell the whole story - and that many of the companies that claim that there is a desperate shortage of software engineers have set the "no hire" standard to the point where they are rejecting people who could easily do what you've described, and much more.

I though that, too. But then I heard from a co-worker that some companies do ask grads to take technical quizes/tests.

Because 95% of electrical engineers have degrees that mean something.