I had an interesting discussion with someone recently about what “high performance” means in the context of development teams. Specifically, I mentioned to this person that I thought I had been able to build a high performance team at my startup, to which he immediately countered: “So what do you mean by high performance?”
I had used the phrase somewhat casually, as though it was obvious what it meant, but I realize that the term can mean very different things to different people. Everybody’s trying to build (or be part of) a high performance team, but how do you get to one?
In my experience, a high performance team has the following characteristics:
1. Lightweight processes are enough to maintain progress. A light agile process may be sufficient.
2. Everyone has a rough idea of what everyone else is working on
3. Made up largely of generalists. Specialists may be necessary for some functions, but most engineers are comfortable working on the front end or back end, and artists can be given work as far apart as UI or character animation.
4. People are curious and eager to take on new challenges; they have the “get stuff done / JFDI” trait
When hiring, I generally found that what I call “context-free programming questions” were effective only as a base-level filter. These are questions that test the interviewee’s ability to write code on a whiteboard, often after thinking of an algorithmic solution to an abstract problem: “Write a function to print a matrix in spiral order”, “Write an iterator which implements the next operator for a binary search tree” etc.
Programming problems can serve to show that the candidate has a base level of programming ability. I’d generally ask Fizzbuzz type problems which are even simpler than the ones above — they helped weed out people who were out of touch with programming in general. For artists, I’d ask them to sketch a background on a piece of paper in 30 minutes; this assumes that drawing skills are highly correlated with digital art skills (which is generally true in my experience).
Questions more complex than this run into issues of people getting nervous and freezing up, or simply being unable to think of the right solution to the problem in a limited amount of time. Either way, there isn’t much point in trying to infer a person’s long term fit for a job from such a small set of observational data.
The most high quality predictor of productivity on the job that I’ve found for programmers is to ask them in detail about their past projects, preferably ones that they did as side projects.
I interviewed mostly people at or close to the start of their careers, where side projects are an indicator of whether they are curious enough to do things that are not strictly necessary to get their college degree.
Questions like the following are very useful:
1. Describe one of your side projects
2. How big was your team? What did you do, specifically?
3. Why did you pick this problem?
4. Why did you pick this set of technologies to implement this project?
5. What was the most difficult technical challenge in this project? How did you solve it?
6. Describe the most complex bug you had to fix. How did you debug it, and what did you do to fix it?
New questions naturally emerge from the candidate’s answers to these questions, and are a good way to further drill down into their experience.
If a candidate answers “I don’t have any side projects” to question #1, that’s a strong indicator right there (although it’s typically not sufficient to simply stop the interview there).
I found over time that refining these questions, and maintaining answers from previously successful hires as a benchmark, helped me get better at determining who to hire or not.
Abhi's Blog 