I have a very good track record of building incredible teams. At TSN, I found and recruited my first truly amazing team by getting to know great people, working with them for a while, and then bringing them on board along with me.  I met Loc, and John through the Globe and Mail’s technical team, and I was introduced to Liam from Discovery’s group. When it came to recruiting new people, I saw literally hundreds of resumes, interviewed dozens of people, and eventually hired both Neil and Kate.

My hiring back then was all trial and error, and I happened to luck into great people because I knew that I was looking for both a specific skill set, and also people that I would want to spend eight hours a day around.

My line of thinking has always been “I dated my wife for three years before I decided to spend a third of my life with her, but I only get to spend a couple of hours with you before we decide to make the same commitment.”  Much like marrying, I wasn’t looking for people who would be clones of me, I was always looking for people who complimented me in some way.  Who did things I couldn’t do, who were better than me in as many areas as possible, and who would challenge me to be better.

If you are the smartest person in the room, you are in the wrong room.

At Info-Tech, I’ve been primarily responsible for hiring nearly every person in application development over the last eight years. If I didn’t make the final decision itself, I was at the very least involved in some part of the interview process.

There were two books that really changed how I hire, and helped me to formalize my vision for hiring greatness.

The first was Joel Splosky’s “Smart and Get Things Done”.  The book is now eight years old, but it still holds up well. He has some really specific thoughts on how to create an amazing work enviornment, and he has a good summary of a framework for interviewing.

  1. Introduction
  2. Question about a Project the Candidate recently worked on
  3. Easy Programming Question
  4. Pointer/Recursion Question
  5. Are You Satisfied?
  6. Do You Have Any Questions?

He also goes into detail on how to test, and while I think his ideas are great, we have tweaked and adapted these ideas to serve not only developers, but also designers.

The second book that changed how I hired was “Drive” by Daniel Pink.

Drive talked about intrinsic motivation, and this became the basis for all of my management style. I worked to empower my people and get out of their way. To allow them the ability to master their crafts, to work autonomously, and to have a sense of purpose with their work.

The nature of what we do is that we throw things away, so giving them a sense of purpose by showing people that everything you do helps master your craft is important.

Hiring people who can work autonomously is hard. Many people are conditioned to do what is asked of them and not what is needed, so looking for those traits in an interview is important.

The last piece of the puzzle came when I stumbled upon Valve Software’s hiring guide.

One of the best pieces of advice was “hire your friends”, they want people to work with the best people, and their thinking is that smart people know smart people.  I like that thinking.

The other thing I really liked was the concept of a “T-Shaped Person”.

Valve’s handbook describes a T-Shaped person like this:

People who are both generalists (highly skilled at a broad set of valuable things — the top of the T) and also experts (among the best in their field within a narrow discipline — the vertical leg of the T). This recipe is important for success at Valve.

The handbook has good reasons for why you need a T-Shaped Person.

An expert who is too narrow has difficulty collaborating, while a generalist who doesn’t go deep enough in a single area ends up on the margins, not really contributing as an individual.

Once I had figured that part out, I started looking for “pillars” that helped to augment my entire team.  If I had someone strong in Javascript, I would be on the lookout for someone who was a master of CSS, or UX, or colour theory, or typography.

The final piece of the puzzle is the hardest one to teach. Every time I have gone against this last principle, I have regretted it.

There have been times I’ve “settled” with someone who didn’t quite fit my bill, and each time it simply hasn’t worked out.  Because of that, I’ve learned to “trust my gut”, there are a lot of people who on paper look right, but are missing something that doesn’t make the fit right, I realize they are not right for what we’re looking for.

I have boiled this down to a four stage interview process which I think works quite well.

Once resumes have been reviewed, the phases break down like this:

Phase One – Phone interview.  This weeds out communication problems very quickly, and helps us to make sure that they understand the role they have applied for.

Phase Two – In Person Interview. I call this my Voight-Kampff test, where we separate the humans from the replicants. In this one we talk about the company, discuss the role and the department, and then go through their resume, and finally I ask a series of boring HR questions like “You’re in a desert, you see a tortoise on its back baking in the sun. What do you do?”

So far nobody has figured out my clever Blade Runner joke.

Phase Three – Technical Test. We do a two part technical test, the first is a take home test, the second a simple coding problem that they do on the screen with us. For designers there is a print and web test, and then they get to defend their design choices, which mimics a real life demo.

Phase Four – Second Interview. Our second interview is held with members of the actual team doing the leading, I try to involve myself as little as possible, and at the end of the time, the team helps make the decision.

Of the thirty some odd people I have hired, I’d say I have read several hundred resumes, and conducted at least one hundred interviews.  While those numbers may seem high, the awesome team of Unicorn Ninjas that I get to work with make it all worth while.