How do you get them to demonstrate successful problem solving and coding and design abilities without seeing them code, then? You're right that it's kind of a silly test, but the problem is that it's a key part of their job and there's no other way to check for these skills, that I know of. And there's also plenty of people who have the experience on the resume and just can't design or code much. It's hardly like the whiteboarding is done for no reason - there are plenty of people it weeds out.

A much better analogy would be asking an F1 mechanic to look at a car you had up on a lift. Sure, they don't fix Hondas all day log, but if they can't see obvious problems and don't know how to solve those obvious problems, it would be a serious red flag.

Even in your silly example, you'd be smart to question it if the mechanic couldn't label a lot of parts they should be able to label, and it would itself only be a small part of the interview.

A good way to confirm that they know their stuff is to talk to their references. What tasks did they do there? What problems were solved using what tools and techniques used? Nobody knows their skills better than those who already worked with them. If their reference seems to be an idiot, that's informative too.

Ask them to bring in an interesting example of their own code to the interview. Let them explain their design and implementation choices. Ask about the problem they needed to solve, the range of input data, the form of output, the acceptable ways it could/should fail. Propose changes to each of these and how they would respond. Propose variations to their algorithms or data structures or fault tolerance or input data to explore their range. Ideally, make the variations appropriate to your business' practices and needs.

> A good way to confirm that they know their stuff is to talk to their references. What tasks did they do there? What problems were solved using what tools and techniques used? Nobody knows their skills better than those who already worked with them. If their reference seems to be an idiot, that's informative too.

Really? You could easily fake that, have a friend who still works somewhere say anything.

> Ask them to bring in an interesting example of their own code to the interview.

That's great if you're willing to weed out people who only code at work.

> Let them explain their design and implementation choices. Ask about the problem they needed to solve, the range of input data, the form of output, the acceptable ways it could/should fail. Propose changes to each of these and how they would respond. Propose variations to their algorithms or data structures or fault tolerance or input data to explore their range. Ideally, make the variations appropriate to your business' practices and needs.

That's what you can do without their own code, but it fails to prove they really wrote it.

No one asks an electrical engineer to design a circuit in an interview, or to identify a bunch of parts. All my interviews have involved talking about projects I've worked on, and about type of work the company does - no test type questions at all.

Why are electrical engineers able to evaluate each other through conversation when software engineers apparently are not?

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.