At my previous employer, the Adrenaline Group, we used the saying “No Chumps” to describe our team.  I always loved the elegance of that line.   There are so many chumps in the software business, and it these chumps that make so many IT jobs miserable.  When hiring for a new position, you have to realize that most of the resumes you will see are of people you would not want to work with.  Most of the people you will interview (phone or face-to-face) will not be offered a position.  If this bothers you, find a less picky team, spend a year or two enjoying the frustration of working with some chumps, and then see if the “No Chumps” rule makes sense. 

So the question becomes how do we avoid chumps during the hiring process.  When looking for a candidate, I am really evaluating across five criteria.

  • Are they intelligent? 
    • Are they curious?
      • Can they get stuff done?
        • Will they fit into the team?
          • Do they have the right experience? </ul> > SIDENOTE:  Let me give some credit to others right away.  I am heavily influenced by the author’s in the references section.  Joel has clearly described the need to find smart people that get stuff done.  DeMarco (no relation) and Lister talk at length about fit into the team.  You should read their work.

          Let’s dive deeper into these questions.

          Are They Intelligent?

          Do they have the raw brainpower to hold everything in their head to be successful at their job.  When you are designing a system, you have a million different things that you need to think about.  How should it work?  How do I need to approach the problem?  What are the appropriate technologies to use?  Where will the system need to go?  How should the system be architected?  What are the pertinent design patterns?  How can I test this?  For complicated applications, these are hard questions to answer.  It requires experience, good judgement, good analytical and problem solving skills, the ability to learn new skills (both technical and domain specific), an understanding of the appropriate tools, and the ability to hold conflicting ideas in your head at the same time.  Can they propose solutions and handle other intelligent people challenging them?  The people that I am looking for love to be challenged by other smart people.

          SIDENOTE:  Do not confuse intelligence and education.  Some of the best developers never graduated from college and lots of bad programmers have Comp Sci degrees.  Undergraduate and graduate degrees prove an individual is educated but ARE NOT NECESSARILY a sign of effective intelligence.  Then again, I do not know many stupid Ph.Ds from MIT.

          Are They Curious?

          Have they ever decompiled a Java class to figure out what was going on.  Have they downloaded the source for an open source project to help with debugging?  Do they tinker with different technologies at home?  Do they read a lot?  Will they dig deep to figure out why something is working or are they satisfied just getting something that passes basic tests.  I am looking for people who want to understand what the business problem we are trying to solve is and figure out the best way to accomplish it.  I am not looking for automatons that will just execute whatever they are told to do.  Curious people crave a better understanding of the world and make wonderfully innovative engineers.

          Can They Get Stuff Done?

          Copied straight from Joel Spolsky…Sometimes smart and curious people spend so much time analyzing what is the best way to do something that they ignore the importance of getting SOMETHING done.  There is a saying that delivering 80% today is better than delivering 100% never.  Has the candidate ever shipped software to production or managed an operational system (you would be amazed at the number of people that have never had their code in a real production system)?  Have they ever had to deliver under pressure.  Do they like the pressure?  Do they like the sense of accomplishment?  Will they not rest until the problem is solved?  This tends to be an area where many people with strong academic backgrounds fall down in the interview process.  The mentality in a corporate software environment is very different than the attitude and pressures in an academic environment.

          Will They Fit Into the Team?

          In the book Peopleware, Tom DeMarco (not related, he spells his name wrong) and Tim Lister describe a candidate that did not get a job at one software company.  The candidate was qualified, but the interviewers did not feel he would fit on the team because they did not think he would find the concept of lips on a chicken hysterical as they all did.  An arbitrary criteria, but if someone will not mesh in the team dynamic, they will be a cancer and will drag down the overall team performance.  When looking for fit, I am looking both at personality and experience.  When evaluating the candidate, would you be excited about working with them?  Why or why not?  Will their experiences (both at work and off hours) complement the experiences of the team.  Will they be excited to learn from others?

          Do They Have The Right Experience?

          Notice that the experience question is the last of the criteria for evaluation.  Appropriate experience does matter, but it is probably the ONLY one of the criteria that an employee can improve on over time. At HMS, we use Java 5 (soon to be Java 6), JBoss 4, and Maven 2.  Does it matter if an incoming employee has worked with any of these technologies?  Should I reject a good candidate just because he hasn’t gone through the pain of building a multi-POM project?  No way.  A smart, curious person that gets along with the team and wants to do a good job can LEARN these tools.  In three months, they’ll be completely up to speed.  I’m not hiring a three month contractor, I’m making an investment in a full-time hire that hopefully will be around for years. 

          SIDENOTE:  There are some positions where experience is more important, but in general it is the most overrated criteria

          Now that we know what we are looking for, let’s figure out how to answer these questions.

          Step One: Reading the Resume

          First step at eliminating the chumps comes when looking at the resume.  Some things that I look for:

          • Is there anything interesting on the resume that I would like to talk more about with the candidate.  An interesting project or an interesting technology.  A big achievement.  When you see a resume and all of the accomplishments seem like they should have taken less than a day to complete (e.g. used JDBC to save data in a relational database), that means the candidate is probably failing one or more of the intelligence, curiosity, or getting stuff done questions.  For recent college graduates/intern candidates, I like to look at what classes they took or what research they have done.
            • Have they done different things, both on and off the job.  I love seeing resumes for people where they have worked/studied in a wide range of things.  Resumes where the person has been just working on one technology, on one platform means that person is probably failing the curiosity test.
              • Have they advanced in their career.  Smart people who get stuff done tend to not be satisfied with their position and their projects for very long. 
                • Did the person put some time into the resume?  Grammatical errors or spelling errors are a big problem for me. </ul> ## Step Two: The Phone Interview

                So the person’s resume is interesting enough to move on to the next step, the phone screen.  This is a basic sniff test to decide if the candidate is a chump or if we want to invest serious time in them.  Phone interviews should generally last 10-15 minutes and are meant to screen out candidates who clearly fail one or more of the criteria.  In a phone screen, I try to find out if they have a good knowledge of the technology that they have been working on and an idea of what they actually did on the projects that they have been working on.  Sample questions may be:

                • Simple Technical Question like “What’s the difference between a list and a set?” or “What’s the difference between an abstract class and an interface?”  If a software candidate cannot get that right, they are probably not going to get through the rest of the interview.
                  • Digging Deeper Question like “What was the biggest challenge you faced on your last project?” or “What do you enjoy the most about your last few projects?” or “What do you wish you had done differently/better on your last project?”   The goal of these types of questions is to get a deeper understanding of what they have been doing.  Good candidates tend to have interesting answers to these questions.
                    • Awareness Question like “Are there any technologies you would like to work with and why?” or  “Has there been any book/website/blog that has made you think differently about how you should work?”  These questions tend to shed light on the curiosity, intelligence, and motivation of the candidate. </ul> Remember the point of the phone interview is to screen out chumps as quickly as possible, not to make a final decision on the candidate.  Fifteen minutes tends to be sufficient to make a decision whether you would never want to work with this person or whether it is worthwhile to bring someone in for a deeper interview. 

                    Step Three: The Face-to-Face Interview

                    The goal of the face-to-face interview is to discover whether we can affirmatively answer all five of the questions posed for this candidate.  When conducting the interview, you should be thinking about how a candidate’s response to your questions can help you answer your questions.  I like interviews to be conducted with 1-3 interviewers (ideally 2 people) talking with the candidate in a relatively informal setting for about an hour.  At least three groups should meet with the candidate to get a decent range of opinions.  It is better if the groups co-ordinate beforehand and decide on what questions or areas each will explore to minimize overlap. 

                    I usually like to start with simpler questions to get the candidate talking and  then move onto harder questions.  In the course of the interview, the candidate should actually have to demonstrate how they would do the job.  For a developer job, a candidate MUST write code.  Watching how someone writes code can give enormous insight into their intelligence, creativity, and ability to work with others.  How long it takes a candidate to answer a code/design question is usually a great tip off to the quality of the developer.  Candidates that quickly and accurately answer questions tend to be much better than candidates who struggle but eventually get the answer (SIDENOTE:  Be aware of the candidate’s experience level though, as that can impact the time depending on the complexity of the problem).  Similarly, a business analyst should be given a task to write down requirements for a given system and a project manager should have to build out a schedule.

                    Thought questions like “How many gas stations are there in Philadelphia?” can also be good.  They can give great insight into how a candidate thinks about solving a problem, but make sure that the question isn’t a “trick” question and that the focus is on the decision making process, not on the answer.

                    Coming up with good questions takes practice, as you do more and more interviews, it becomes easier.  Just remember, you are trying to decide if the candidate meets all of the five criteria and your questions should help you figure that out.  Remember, the goal of the interview is for you to make a Yes or No decision.  If you are wavering in between, try to figure out what area you are wavering on and dive deeper into that area.  The worst thing that can happen is you leave an interview not having effectively answered the five questions.

                    If it is clear to the interviewers that this candidate will fall short of our criteria, they should politely end the interview.  There is no point in wasting the candidate’s time or our time if the answer is going to be a no.

                    Step Four: Decision Time

                    When it comes time to make a decision, all of the team members that have interviewed the candidate should talk.  Generally I find people to be in one of four camps, Strong No, Weak No, Weak Yes, Strong Yes.  For a candidate to be hired, at least one person MUST be a Strong Yes and NO ONE may be a Strong No.  At least one of the interviewers, and usually more than one, should love the candidate and be demanding for that candidate to be put on their team.  For people who are Weak Yeses or Weak Nos, I like to dig into their concerns.  What didn’t they love about the candidate?  Did other people see the same weaknesses?  The goal is to come to an honest consensus on the candidate.  If anyone is a Strong No, it is a No Hire.  If there is no consensus, it is a No Hire.  If everyone is a Weak Yes on a candidate, it is a No Hire (although it may also be a sign that the questions that were asked did not do a good job in answering the five criteria about the candidate).  The goal is to get great hires and avoid chumps; it is not a time to take big risks.

                    Important Lesson: WHEN IN DOUBT, DO NOT HIRE!!!

                    Hiring great people and avoiding chumps is hard work.  It takes a lot of time and effort and can be frustrating, but it is essential to have a great performing team.

                    Some Questions

                    You are an elitist prick.  Why would anyone want to work with you?

                    You are right.  I am elitist.  I spend more of my waking time working than I do with my family, my friends, or my hobbies.  I want my workplace to be filled with people that I respect and that I enjoy working with.  I am lucky enough to play a role in deciding who I will work with.  I want those people to meet my criteria.  But in my experience the people that do meet the criteria WANT to work with other, similarly talented people.

                    Won’t you miss some good people this way?

                    Absolutely.  The system that I have described is designed to minimize false positives (hiring chumps) at the expensive of having false negatives (not hiring someone who would be good).

                    Isn’t it hard to grow your team?

                    Yes it is.  We go through a lot of resumes and candidates before we make a hire.  This makes recruiters unhappy.  But it is not my job to keep recruiters happy, it is my job to build the best team possible.

                    I interviewed with you, but you didn’t hire me.  Does that mean you think I’m a chump?

                    Not necessarily. It just means that we weren’t positive that you were great.  We have been wrong before, just chalk it up to us being wrong again.

                    References

                    Joel Spolsky’s Guerrilla Guide to Interviewing

                    __Peopleware by Tom De Marco and Tim Lister

                    ****Good to Great by Tom Collins

                    Edited for grammar improvements, 3/30/2008