If you haven’t read the introduction to this article, I would suggest starting there.
The first challenge in creating a great developer is finding someone who has the right raw attributes to start with. There are two parts to this: finding candidates and screening them to choose hires.
To facilitate the former, I work to establish connections within the local community. I sit on advisory boards for a number of local interactive programs, I get to know the instructors, I give occasional guest lectures to classes, and I try to contribute to (and in some cases, establish) local user groups. This lets me help steer what (and how) students are being taught. More importantly, it helps me identify the rising stars in each class and in the community.
I look for people who are smart, creative, communicative, and demonstrate a genuine passion for the field. I want someone who can solve problems, and is going to be very self-motivated about learning new things and building cool projects.
Once I’ve identified candidates, I invite them in for an interview. Two days before the interview, I send them code from a small internal project, and ask them to familiarize themselves with it. I also ask them to bring in samples of work that they are especially passionate about, or think best demonstrates their abilities.
Our interviews tend to be very casual. They start by meeting the full team, to introduce them to the people they’d be working with. We sit down, and I ask them a few general-purpose interview questions about their interests, goals, strengths and weaknesses.
I have the candidate show me their previous work, and ask them a lot of leading, high-level questions. “Why did you want to build this?” “How did you plan the project?” “Why did you build it this way?” “Why did you approach this problem in this specific way?” “Why not this way instead?” This lets me judge a bit about what motivates them, their technical expertise, and their ability to communicate.
Next, I open up the code I sent them earlier, and start asking questions about it. I try to ask questions that involve both technical understanding and problem solving, such as why they think a certain block of code was written in a particular way. I also ask questions about UX design, because this is such a critical part of interactive development. I start simple and ramp up quickly, hitting them with questions that are both a little beyond their technical comfort zone and far beyond it.
Throughout this process, I encourage them to talk me through how they are solving the problem. I also teach them about more advanced concepts, then I ask them related questions. This is important, because I’m more interested in how they learn than what they know.
I spend a lot of time just listening. I let them decide when they are done answering a question. It’s pretty amazing how much you learn about a potential hire by just letting them talk until they are done, while fixing them with an inscrutable look. Some people babble themselves into an ever-deepening hole of incorrectness (bad). Some stop, and admit ignorance (good). Some talk their way towards a solution (better). A rare few ask appropriate questions to guide their response (best).
This approach lets me gauge their technical & UX knowledge. More importantly, it reveals their intelligence, creativity, and problem solving process. It also lets me see how they perform under pressure, and how effectively they communicate technical concepts. I also try to judge how well they will fit into our corporate culture.
If things go well, we’ll talk a bit about what it’s like working at gskinner.com, both the benefits (cool projects, bonuses, benefits, etc), and the potential drawbacks (a lot of learning, taking a beating from the team early on, and the odd high stress moment). We’ll also start a dialog on compensation. Sometimes we’ll finish up with a game of ping pong or foosball with a few members of our team to get a better sense for their personality in a more casual setting.
If things didn’t go well, I’ll give them some honest feedback on why, and try to give some suggestions for how they might be able to improve. If I think it’s likely that they’ll be able to rectify the issues, I might invite them to come back in the future when they feel they are ready for it.
Finally, I generally try to hire in pairs, with the same start date. This allows us to train them together, which reduces the time spent and helps with retention (because they can help each other). It also gives them a “buddy” at a similar level that they can identify, work, and learn with.
The next part of this article, “Orientation”, can be found here.