The whiteboarding in the problem setting might be the issue. How many engineers actually whiteboard regularly? It's as old fashioned as waterfall design. Everything has a REPL shell (even Java!) now. Hell, even CloudFormation stacks let you fiddle with entire architectures through a command line. Engineers have always poked and prodded at things to learn and refine them. Whiteboards are for throwing around ideas; not for solving problems.
I spent most of my grad school years researching learning and memory. The medium and environment of the fact recall/problem solving can greatly affect performance. Now compound that with the stress of your standard technical interview and you'll get some flubs.
You might want to take a step back and consider how you're asking them to show competence in addition to what you're asking them to show competence of.
Would it really be any better if I handed them a laptop with Notepad or some IDE and asked them to type in their ideas?
What I'm asking is the bitbanging equivalent of "store 2+2 in a variable", so setting up an entire coding ritual for 3-4 lines of code isn't really what I had in mind.
To answer your question with a question - Would you be satisfied if they could solve the problem in that setting? Is making a laptop available to them for problem solving that much trouble?
Or, rather than looking for _any_ competent candidate, are you looking for someone like you and your coworkers, who can give direct answers without a pause? I ask because in one case it's more like an attempt to hire capable employees and the other is perhaps a subconscious attempt to maintain a monoculture.
You know that's a good question and, to be honest, if they could only solve this at a keyboard then I wouldn't be satisfied.
We constantly draw things out and scribble over it again when we're designing. If you can't translate and communicate to others then it's not a good fit for me.
> whiteboard ... it's as old fashioned as waterfall design.
Call me old-fashioned then. I like to map out the data flow and process flow a bit. A little planning now, saves quite a bit later. Call it, pre-re-factoring.
You don't go scuba diving, hiking, camping, etc, without a plan.
I spent most of my grad school years researching learning and memory. The medium and environment of the fact recall/problem solving can greatly affect performance. Now compound that with the stress of your standard technical interview and you'll get some flubs.
You might want to take a step back and consider how you're asking them to show competence in addition to what you're asking them to show competence of.