Open source interviewing
When someone applies to Pillar, we invite them to submit a code example that solves a particular problem. We review the code as an input early in the interview process.
It’s a helpful component of getting acquainted with a candidate, but a few things aren’t ideal:
- For any toy project, the domain is going to be trivial enough that it isn’t likely to be very representative of a larger “real” project
- As I review more and more submissions which solve the same handful of problems, I’m finding it harder to evaluate each with a fresh set of eyes
- Ultimately, the code doesn’t have any utility—its lifecycle ends as soon as it has been reviewed and discussed. This despite the fact that many candidates invest a significant amount of time writing it
Here’s an idea that might address those concerns: let’s start asking candidates to submit something useful instead.
Ideas of more useful, realistic problems to ask applicants to solve and submit:
- Publish a wish list of features we’d like to see in our favorite open source projects (I, for one, would love to see a pull request adding Shared Example Groups to Jasmine)
- Point them to the backlog of an ongoing GiveCamp project
- Encourage the candidate to build something cool and share it with the world (though the real utility of every last Twitter widget on Heroku is perhaps suspect)
The only downside I’d anticipate hearing is that the reviewer would need to steep a while in the domain of the submission to be able to review it effectively. Still, I think it would be easier to answer the question “is this awesome?” if I were looking at code that actually did something awesome over merely implemented a code kata successfully.