In my experience some of the biggest problems are solved best by the slowest thinkers
Those slow thinkers might have a good idea of the answer they likely want to give straight away - but maybe want to take another day or two before committing
Short meetings around a table can be quite frustrating for people that think slow - which is why many discussions can reach a better conclusion using email and time
Completely agree. My best decisions are not made on my feet, and I have often been responsible for difficult technical tasks. I also prefer to "communicate my thinking" in the form of readable, well-tested code that can be verified by a machine.
If that code is unsatisfactory for some reason, I'd rather figure that out after writing it, based on concrete evidence, than during an upfront design meeting with folks who likely won't be doing the actual work, but often feel the need to impose themselves in arbitrary ways. When a team focuses on excellent communication through writing, I find less planning and verbalizing is necessary, and a lot more gets done.
As a partial aside, one of my greatest annoyances when starting a new job is when after being grilled for technical skills during the interview, they walk you in to a messy, amateur codebase, where many of the ideals discussed during the interview clearly haven't been applied, but no one seems to acknowledge it. This has happened to me repeatedly, enough so that when these sorts of questions come up during the interview, I mentally start preparing for the disappointment. People sometimes seem to take more pride in trying to rattle candidates than they do in building anything admirable. Luckily, there are many fine places to work where the team can be honest with itself and with candidates. I don't really care about the current state of projects when I'm starting; I don't mind being a janitor (except in extreme cases). Just don't start our relationship off with a load of BS. I feel like this is such an elephant in the industry. A lot of our code is bad, real bad, but we can't admit it.
That hasn't been my experience at all. The opposite in fact.
Sure the biggest problems aren't solved in 5 minutes at a whiteboard, but they are solved by people who are able to think on their feet at a whiteboard discussion.
Not to put too fine a point on it, but when the decision is made on your feet at a whiteboard, only the people who are able to think on their feet at a whiteboard discussion can participate. If you have a whiteboard discussion and then say, "come back to me tomorrow with specific feedback" -- and privately ask people directly who you know are unlikely to make comments in public, I think you will get a completely different point of view (if you haven't weeded out all the good meticulous thinkers already, of course).
I think you missed my point. Hard problems are not solved at whiteboards (usually). But the ability to "do whiteboards" seems to correlate with the ability to solve hard problems.
When I worked as an independent consultant I'd get clients who needed fast turnaround on designing new feature architecture to a product I had not seen before, which is the closest analogy to the interview whiteboard design that I've experienced.
Even then, it's completely different. I'll first spend a couple hours with someone senior who can fill me in on all the relevant context. The dynamic is different because they need my help and are paying for it so they are highly motivated to give me all the context I need to help them. Only after that we go to the step where I whiteboard a few proposals and then we collaboratively decide which way to go. I'm quite good at this.
Interview whiteboard design is a different skill entirely, one which I don't believe has any relevance to job performance. Might be a good way to hire improv theater actors, but not engineers. Having to go from zero to solution in 45 minutes or less is not how it works in the real world. And doing so while being nitpicked by an interviewer more interested in showing off doesn't help. Instead of collaborating, the interviewer is there to grudgingly drop the occasional hint and then count it against you.
What was the relevance of finding that? Do you always do system design under a strict clock at your company?