Qualities of a good dev team member

Part of my job is to build an awesome application development team. A team involves a lot of different skill sets of course. This includes the developer, but also the architect, PM, BA, QA, DBA, etc.

There are certain qualities that we look for when we are trying to find a new person to add to the team. These qualities are in addition to the certain skills and attitudes a specific position might require. I think all of these are things that you learn as you are young, and may be complimented by a certain amount of inborn talent.

The following three qualities are the baseline to get started. These are qualities that can be hard to see in a person in interviews. We usually go through 3-5 rounds of interviews, which culminate in an 'audition' in front of the team. More on this later.

So, what are these wonderful, Zen like qualities?

0. Learn Quickly, and Unlearn Quicker

I used to say 'Everything you know today will be worthless in two years.' I was corrected by a team member recently who pointed out that isn't really true. Problem solving skills, learning skills, etc. may improve, but they don't go out of use. I agree. So, technical knowledge you have today, will be worthless in two years. But how you get that technical knowledge will last a lifetime.

As time marches on, it is important to know when to move on from something that you do "KNOW", and move on to the next thing. For example, it used to be that Client/Server was the end all be all. The last architecture you will ever need. Then came n-tier. Then came SOA. So, don't just learn the next platform, but be ready to leave behind outdated concepts and ideas.

How do we figure this out in an interview? Ask them about some of the latest and greatest. See what they think of Atlas, or WCF, or anything. Have they played with it, learned it? What was the last thing they learned? How do they like to learn? What was the last book you read? Our interviews tend to be conversations, not SAT style interrogations. It is about the discussion, and about your gut feeling as an interviewer. [OK, there is ONE interview that is a quiz, and that is the technical interview. We want to know what your chops are. Where do you lie on a range of skill levels, and across several parameters. People have cried. It's a long story.]

1. Problem Solving

Our jobs are about problem solving. We solve problems. Our clients have problems, and we provide solutions; solutions that solve those problems. Usually within a bizarre set of technical, business, and financial constraints.

Problem solving goes directly to how to solve that business problem, the best business process, how to get that code to work, why is the trigger not firing, how do I map that XML document?

Problem solving skills are some of the hardest skills to learn.

How do we find this in a person? Ask them about difficult problems they have faced, and how did they solve them, or try to solve them? Get them to talk about their problems, and solutions. What process did they use? Did they work with the team? Did they do their own research first? If they talk about how they haven't had problems to solve, then show them the door. Don't waste your time.

2. Passion, preferably for what you do

Passionate people are infectious. They put more effort into what they are doing, they build team energy, and they become a force multiplier on their team.

We look for people who show passion for technology. There are plenty of good candidates that are good developers, but will never be on the team, because they aren't passionate. It is fine to be a nine-to-fiver. Those are fine people. Really, they are. I just choose to work with people that stand up and applaud when the BizTalk team annouces you can now zoom in the orchestration designer, or people who take a long van trip to the VS2005 launch, or people who take time outside of work to learn about things you don't have to learn for your job.

The best way to find this is to be part of the community. If I can get to know you at user groups, then it is a lot easier to get through the interview process. If I see you at code camps, CodeMash, conferences, Usenet, etc., then I know you are engaged in what you do. Perhaps you blog. Perhaps you just voraciously read blogs. I want to see engagement. HINT: I Google you before I ever call you for an interview.

 

These aren't the only things we look for, but I feel they are the most important three.

Auditions? Yes, auditions, but you don't have to sing. We generally go through several interviews before the audition.

0. Recruiter screen - Are you an axe murderer? Do you have the required skill sets and attitudes? Team culture match?

1. Technical screen - You say you have nine years of .NET experience. Sure. Prove it. You don't have to score a 95%. We try to see where you are from one to ten across several aspects of your role.

2. Personal Interview- The candidate will meet with me, or someone on my leadership team. We spend a lot of time listening to the candidate, trying to figure out the above three aspects, as well as their general attitude, and direction. What are their career goals?

I heartily believe that a person has a career vector, and a company has a vector. The vector represents where they are going, how they are getting there, and what their other goals are. If these two vectors aren't close, or don't converge, then neither the employee nor the company will be happy. It's ok. They are not a bad person, they just have to know it might not be a great match. We also spend a lot of time talking and showing how our business and team works. We want you to feel like you KNOW what you are getting into. That there is a strong ownership culture. That you WANT what we have. That you know what your day is going to be like. What your role will entail. We aren't talking about a ridiculously vague position description (which all end with 'and other duties as assigned'). We are talking about what life in a day of a team member is like. I don't want the candidate to feel like what they thought they were getting, and what the job really is are two different things.

3. Then the audition. A time is set. The candidate picks a topic of their choosing. Must be technology related. Doesn't have to be related to the project, or even their role or primary skill set. Preferable something they have learned recently, and something we don't know inside and out already.

The audition serves several purposes. You can ask people about the pillars of OOP all day long, and what generics are, but until you see them flying around visual studio, you really won't know if they know what they are doing.

Also, you get some free training/exposure for your team on something new. You get a sense for how that person can communicate in a group, and transfer their ideas and complex technical concepts.

At the beginning of the audition, I will introduce the candidate, and hand out their resume. I then leave the room and get a water. I let the team interact without my presence being an influence. There is 30 minutes of slides/code (we're agile, so we prefer code), and 30 minutes of Q&A on any topic. The Q&A is in both directions, so I expect a good candidate to come prepared with questions they want to ask the team.