Senior Developers Are Getting Rejected for Jobs

I should note that my statements below may be FOC; I do not myself have a CS or EE degree, so take what I say with a modicum of salt...

But first, note that I wrote "function", not "circuit".

It could be argued that CS, on the whole, is a subset of mathematics, particularly that of boolean algebra and logic. As such, the functional equivalency between the abstract of boolean logic/algebra, and its implementation on a physical substrate, could be considered among the most important of CS concepts.

One could also argue (maybe?) that Turing's "equivalency theorem" might be related to such as well. Consider the case of an emulation of hardware done in software; one could consider that - at a base level, it is boolean logic expressed physically, being expressed equivalently as boolean software functions.

The opposite it also true, of course - that it is possible to express software boolean functionality in the equivalent physical form.

What form it physically takes does not matter (other than speed of course), which is why I also didn't ask for an implementation/representation in electrical terms or schematic form, but rather a diagram of something that could be expressed as a physical and mechanical object. If the person were so inclined, they could express it as a series of levers and marbles, or in LEGO, or Meccano, or any other similar option.

EE knowledge is not needed here, I don't believe (Martin Gardner might agree).

lol wat

did you talk like this to the CS masters, no wonder they left

No, you mean that hyperbolically.

Not only does it simply not happen that "the vast majority of applications cannot code at all" -- this literally has never happened at all, in my experience.

What does happen is that you get a range of people on a spectrum. And yeah, a fair number of them can't code very well. They're slow, they don't see smart solutions, whatever - or are just plain sloppy. But that's quite different from "not being able to code at all."

As to those people who (supposedly) can't "write a function that adds two numbers or counts the number of elements in a list" -- most likely they're simply freezing up from the anxiety of being whiteboarded by a perfect stranger for the first time in a great while - or perhaps ever. (In fact that's exactly what happened to me, on my very first on-site interview after college).

Or that is to say: they haven't internalized -- and produced defenses for -- the (intentionally) awkward and humiliating ritual of the modern tech interview process.

And again, you should only be actually seeing these people once in a blue moon. Unless the people running your incoming "pipeline" are utterly incompetent, and are constantly feeding you a stream of unqualified candidates. In which case your companies much bigger problem a lack of engineers who are able to "ace" HackerRank problems in 59 minutes or less.[1]

[1] Which, lest be honest now -- basically can only happen after extensive time spent on practicing these problems in advance. Or that is, by blatantly gaming your hiring "filter".

And one more thing:

How, you ask? By ... dodging responsibility.

No - their jobs just have different metrics for "responsibility" than yours. That's just the way many businesses are run, whether you like it or not.

From this perspective, a technical whiteboard interview is one of many tools. Interviews I give usually start with “so your boss asks you to solve problem X ... where do you start?”. Then I throw more and more problems at them (technical, organisational, etc) and see how they respond. “It’s in production and people start complaining that it’s slow. Where do you look first?”. “What problems do you foresee with this design down the line?”. “If you had $1m/yr budget to hire a team to scale this system, what would your ideal team look like? How would you spend the money?”. “An inexperienced team implements this and it’s buggy. What mistakes are you worried they might have made?”

Ultimately we get the traits we hire for. Being able to code (and debug!) is important. But I also want employees who I can delegate to, and trust that they’ll figure things out. I’ve been able to pass whiteboard interviews since second year uni. But I have not stopped learning, and the non technical skills I’ve gained since then are at least as important. Test for them.