2 ms·
Lots of arguments on why not to hire this way, but if it works for you, all the best. However, do you find a pattern with candidates hitting snags that aren't
by djb_hackernews 15y ago
Lots of arguments on why not to hire this way, but if it works for you, all the best.
However, do you find a pattern with candidates hitting snags that aren't really technical? Like, environmental issues etc?
Think really the only way to do this right is to control it as much as possible, possibly providing a failing unit test, or extremely detailed instructions. I can see a lot of wasted time trying to figure out dependencies, system path problems, etc
- whit537 15y agoWhat are the arguments? And FYI, this isn't the only interview we do. It's one data point. I go back and forth on the question of "snags that aren't really technical." The fact is that on a distributed team with multiple projects going, setting up a screenshare and a dev environment for an existing project are not uncommon tasks in their own right. The first round cross-browser bug was controlled. But then the candidate isn't in their own environment and I'm getting burned out doing the same problem over and over. I want it to feel like we are working together on a problem rather than like the candidate is trying to guess an answer that I am trying to hide from them. This way it is genuine: I have no special canned knowledge of the problems we are working on. I'm trying to simulate an actual pair programming exercise ... by doing an actual pair programming exercise. ;)