A much more common example is that (particularly young) candidates tend to make job interviews into big, stressful things in their head. Then they don't sleep properly the night before, and during the interview they can't think creatively or access deep memories (which are both well known symptoms of stress). They can't answer your questions. You think its because they don't know, but actually the problem is that they're too stressed to think at all.
Long programming questions work great for my anxiety because I can zen out while I'm programming and forget the interviewer is there. But everyone is very different with this sort of thing.
The more general way to work around this problem is to listen and pay attention to the candidate. If you asked "Lawrence" in this story what he was thinking about during this interview, he'd tell you about fluid dynamics and partial differential equations. That tells a story. Another candidate will tell you that they felt really awkward programming through an SSH connection because they're used to Visual Studio. Or how they really do (or don't) like some aspect of the programming style on display. Or how (to crib from another commenter) the programming was easy enough, but they're worried that doing so introduces a race condition between atomic multiply and add instructions if they're interleaved. And they hate doing the work because they feel like they're introducing a bug.
None of that really helps with stress bunnies, but you learn so much about what sort of employee they'll be by asking.
This idea keeps me up at night, but do you have any evidence for it?
I've interviewed plenty of people with 15+ years of experience who really struggled to do basic programming tasks. And who didn't show any obvious signs of stress.
To this day I have no idea how many of them were not performing because they were stressed out of their minds but hiding it. Vs how many were simply not very good at programming. I have no idea how to tell the difference when they don't make it obvious to me.
Ergo, I strongly suspect the current tech hiring culture filters out anyone who has above average sensitivity.
Note that aside from some minor body language cues, there aren't a lot of outward signs of panic. How it looks and how it feels are very different.
Because weak candidates need to submit a lot of applications to get a job, most job applications are from weak candidates. Its easy to feel compassion for people who have panic attacks. Its much harder to make a filter for weak candidates which doesn't also filter out people with performance anxiety.
Seems like we don't even know how big a this problem is. Is it 1% of the candidates? 10%? 50%? I have no idea. And it sounds like nobody here has any real idea either.
This is a solved problem already. Do we use whiteboard interviews for standardized tests or certifications? No.
>Seems like we don't even know how big a this problem is.
Seems like you don't know.
>Is it 1% of the candidates? 10%? 50%? I have no idea. And it sounds like nobody here has any real idea either.
How much time did you spend trying to find out before giving up?
> Do we use whiteboard interviews for standardized tests or certifications? No.
Your position is not clear here. Are you claiming a written exam would be a better assessment for programming ability? That sounds bad?
For what its worth, I don't think whiteboards are the best way to assess programming skill either. My preference is for supervised programming assessments - like this article suggests. Whats your preference and why?
>> Seems like we don't even know how big a this problem is.
> Seems like you don't know.
Correct; I don't know. That is why I asked.
If the answer is obvious to you, maybe instead of insults you could link to a study?
> their testing procedures had proven that he was not intelligent enough to do anything else
I see the final sentence as entirely detached from the rest of the story.
My take: Their testing procedures had detected he had lacked basic awareness of the situation. When he received a (written!) communication, he wasn't able to imagine that the author was not the smarter version of himself despite a multitude of clues. The idea didn't occur to him.
Man, and that is a LONG book, but I clearly remember that section for some reason.
Lawrence immediately saw that it was a trick question. You would have to be some kind of idiot to make the facile assumption that the current would add or subtract 5 miles per hour to or from the speed of the boat. Clearly, 5 miles per hour was nothing more than the average speed. The current would be faster in the middle of the river and slower at the banks. More complicated variations could be expected at bends in the river. Basically it was a question of hydrodynamics, which could be tackled using certain well-known systems of differential equations. Lawrence dove into the problem, rapidly (or so he thought) covering both sides of ten sheets of paper with calculations. Along the way, he realized that one of his assumptions, in combination with the simplified Navier-Stokes equations, had led him into an exploration of a particularly interesting family of partial differential equations. Before he knew it, he had proved a new theorem. If that didn't prove his intelligence, what would?
Then the time bell rang and the papers were collected. Lawrence managed to hang onto his scratch paper. He took it back to his dorm, typed it up, and mailed it to one of the more approachable math professors at Princeton, who promptly arranged for it to be published in a Parisian mathematics journal.
Lawrence received two free, freshly printed copies of the journal a few months later, in San Diego, California, during mail call on board a large ship called the U.S.S. Nevada. The ship had a band, and the Navy had given Lawrence the job of playing the glockenspiel in it, because their testing procedures had proven that he was not intelligent enough to do anything else."