Hiring!

gistfile1.md

0. Create a list of skills that you feel would be valuable to the team. ("Android Development", "Conflict Resolution", "Ability To Eat Many Hot Dogs") For each skill, decide which member of your team would be best equipped to evaluate that skill.
1. For each skill, have the subject-matter-expert on your team prepare two to three open-ended non-trivia questions about that skill. ("How many hot dogs would you say that you can eat?" "Describe a time when you have eaten many hot dogs.")
2. Prepare a five-point scale for every skill, with a loose definition of what a person should be expected to know for each point on the scale.
3. Pick a language that nobody has ever programmed in, ever, like Rust, Eiffel, O'Caml, or M.
4. Choose a trivial problem space that is very well defined, like "Scoring Poker Hands", or "Scoring Yahzee".
5. Think of a single thing to change about the problem space, after the fact. "2s are now wild".
6. Let your prospective candidate know every step in the hiring process from the get-go, with a friendly chat with the team lead that lasts at least 30 minutes.
7. Have the candidate take home a copy of every open-ended question, as well as a description of the problem space. Ask them to produce a library, with documentation, in Obscure Language, that allows users to solve problems in that space. Try not to allow the candidate more than one day to work on the library.
8. Have every member of your team look at the library. Score each library on how easy it is to learn to use, how flexible it is, how easy it would be to adapt the code to account for the change in the problem space, and how easy the code itself is to understand.
9. If the library meets the criteria, bring the candidate in for the interview. Grouping by team-mate, have the subject-matter-experts ask their prepared questions. Estimate their skill using the rubrics.
10. Have two team-mates ask the candidate questions about their library, asking how they would change the single thing about their problem space, and to talk about any technical decisions that they made.
11. To get a lot of useful baseline data, perform this series of steps on all of the people in your current team (making sure to ensure them that their jobs aren't at risk).