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.
Like seeing the inside of an interesting hiring process. 🙂
Although, not everyone has the same skill level in everything when hired in pairs… even if they come from similar backgrounds — it is a lot less intimidating when you’re learning with someone that also doesn’t know how the place “works” yet.
UX Design is so important that a lot of developers seem to forget that it’s there and should be part of your solution. If there’s no way to actually use your product, what’s the point? Sometimes it’s hard for me to convince follow programmers that it’s an integral part of a app.
I think some studios and agencies should ear your thoughts about “building” new developers. In many cases we have a different reality.
keep the article!
I will keep this in mind. A good blog that i have read about how to identify the right candidate for work.
Awesome! Thanks for writing this, was really looking forward to it.
I also believe in similar approach. Looking forward to more articles.
thanks
Your thoughts on hiring new developers are much appreciated, and well thought through. Some very interesting points which I think a lot of teams could be well adviced to think through.
Sounds like a awesome place to work. More companies should hire like that!
wow. reading this just made me realise what a crummy company I work for.
I felt jealous of every part of the care and sensitivity you clearly want to show for new employees.
And I bet that it pays off for the company too. I bet that you get the best out of the best recruits. Inspirational.
Anyone interested in knowing how to hire developer should check out books and blog posts by Joel Spolsky ( http://www.joelonsoftware.com/ )
Many consider him the definitive expert on how to hire developers.
Douglas Crockford from Yahoo also has many great talks and articles on this topic as well
Thanks, I do hiring at Papirfly and this helps us refine the process.
Alan mentions Joel Spolsky – we’ve used a tip from him:
Ask the applicant to write a simple method on a whiteboard. It should be something well within reach for any half decent programmer. Observing how fast and precise they solve the task gives a surprisingly good benchmark of their programming skills.
One example would be to write a method that takes a string and adds all the numeric characters: getStringSum(“as14b35”) = 13. Super simple stuff, but revealing. We’ve also ran the test on members of the team to get a baseline.
Just wanted to say thanks for posting this series of articles. I think its helpful not only for people interested in hiring good developers, but also for people who might not know what to bring to the table or how to handle themselves when interviewing for a development position.
@Torbjørn Caspersen
var num:Number = getStringSum(‘as14b35’);
trace(num)
function getStringSum(value:String):Number {
var num:Number = 0;
var sum:Number = 0;
var v:Array = value.split(”);
var len:Number = v.length;
for(var i:Number=0;i
Nice start to a series–looking forward to reading the rest.
I like the point about hiring someone with less specific experience. I tell students this all the time–that they can pitch their lack of experience as an asset. Naturally, if you have a ton of experience you’re wise to pitch that.
One thing though–and I don’t mean to pick a fight–but I get the sense you’re saying “younger” people fit that model. Besides the fact that “old” people often have wisdom/experience that can be super valuable… perhaps you’re overlooking the fact people can transition from another industry into this. Or, even the fact some people are more adaptable.
As to the psychological interviewing techniques. Yeah, it’s fun to mess with people. But the thing is that there are tons of types of personalities. Often you don’t know what kind you (as a company) can benefit from until you’ve experienced one. Of course a whacko personality can teach you what you DON’T want. Whichever. I’ve personally experienced some pretty funky similar interviews (back when I was looking for fulltime work 20 years ago!). Anyway, if you like that kind of thing you might check some traditional organization management texts for more ideas.
Anyway, keep up writing this series!
business use blogs
by Tim Moran Yoo Hoo! It’s me, Telenoid. Ready for our budget meeting? There is probably not a weirder area of business- technology R&D than “telepresence.” We took at look, a while back, at Vgo, a remote avatar telepresence robot that…
It sounds like you’re not as much creating developers as finding ones with no professional experience and then making them better. But then again, the term “developer,” “designer,” and “programmer” has been thrown around lightly among the Flash community. So if you’re saying you’re not a developer until you have developed, then I see what you’re saying. You want raw meat, not any of that pre-seasoned, pre-marinated stuff. But you also want the best cut. Interesting.
“Inscrutable looks” — sounds terrifying. However, the ping pong in the end balances it all out I suppose. Unless… Do you also get any tells with how a potential candidate handles crushing defeat via your uber ping pong skills?