I hire based on take-home problems. But then again I don't have candidates whiteboard.
I give candidates time to produce something in the comfort of their own environment that goes beyond solving puzzles on the fly and is actually a reflection of the work people will do day-to-day.
For more senior people this kind of test might even be more appropriate, because they are not always working on exactly the same type of thing in recent memory but in their own time will come up with a good solution quickly. However, for more senior people this type of test should certainly not be one of the first steps of the interview process.
You should ideally have much shorter and simpler technical tests during the first interviews to try to weed them out while also giving them exposure to what kind of environment they can expect to be working in, but also tell them this kind of task will be coming and why you are doing it. Once they're more committed to actually wanting the position they will be more likely not mind spending their personal time doing this kind of work exercise, or you could even offer to pay for their time on it to show you are not the kind of company that expects them to do work for free.
If you don't do this, you'll only come across more senior people who are desperate enough to jump through these hoops, which is rare and you better know for sure why they are desperate.
100% this.I find whiteboarding to be the actual scourge, as it involves unrealistic pressure in an unrealistic scenario. It reminds me of tests that inadvertently just test whether people are good test-takers versus assessing their command of the actual subject matter.
I believe hiring devs who are also good at whiteboarding have a bias--even blindspot--where candidate whiteboarding is concerned. They oddly believe it to be a prerequisite for a job that infrequently or never requires it.
As such, they may miss out on good devs who simply thrive in an environment more akin to reality.
In the case you describe, you've already done the more "valuable" dev work of thoughtful analysis/design, and you are merely presenting that work.
That's far different from being forced to devise that design at the whiteboard, singlehandedly, with onlookers.
That's not to say that devs don't hash out designs collaboratively via whiteboard (yet a different application). That certainly happens and is useful. But, you're likely to find that--even in those situations--team members have considered the problem offline prior to the collaboration.