The most annoying thing is when you show yourself perfectly capable of doing the technical challenge and still get passed up on the interview because they completely ignore the results and/or then check your ability to script on a whiteboard. I’d say the work sample is a waste of time if I didn’t view it as a learning exercise.
I couldn't possibly agree more. The current cargo-culted trend of take-home problems is a scourge. If you can't hire almost directly off the results of your challenges, you're wasting time and shouldn't do them at all.
> The current cargo-culted trend of take-home problems is a scourge
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.
I think something people tend to miss is when these problems are appropriate. If you are hiring from a pool of recent graduates for a junior position, or any such situation where you have a demand for the position, then this might be a good idea as a first step.
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.
>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
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.
I see whiteboarding as a skill that is very useful in presenting or defending design ideas. I've had several cases where I used a whiteboard to layout a design interactively to an audience in a design review. I find I am at my best when I have marker in hand as it gives me control of the conversation.
Yes, but that's a different application of white-boarding.
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.
