Identifying Top Developers

Most companies realize that having top-notch software developers can have a significant impact on the success of their software projects. So how do you identify the best software developers during the hiring process? Many companies realize that the difference in productivity between a "rock-star" programmer and an average performer can be huge, by a factor of 10:100. As a result many companies are desperate to attract the creme-de-la-creme of programmers. However, most job interviews are constructed in a manner that overlooks many excellent candidates. The following is a list of tips for how to improve your interview process when looking for top-notch programmers: •Stop thinking that "only the top 1 percent will do". The top 1 percent is actually a misnomer, because different people are top performers in different circumstances. No one is a "rock-star" all the time. The reality is that our profession attracts lots of very talented, smart, and creative people. Given the right circumstances, about 25 percent of the candidates you will encounter can be top performers. •Make the interview process a low-stress and relaxed environment. Programmers do their best work "in the zone", which is hard to get in to in a single hour. It like judging marathon runners based on how well they run the 100-meter dash. •The really outstanding candidates are very hard to recognize on paper and in interviews. They can sometimes be shy, or nervous, or not particularly good at promoting themselves. Give the candidate lots of opportunities to show what they are made of. Work with the candidate to help them demonstrate their abilities. You want to create a positive environment that makes interviewees feel safe. •Don't expect the best candidates to tell you that they are the best candidates. They better someone is, the more likely they are to be humble. •Be aware about who is conducting the interview. An interviewer who has insecurities may have a desire to bring down the candidate to make themselves feel better about their own achievements. •Tell programmers in advance (at least a day or two, if not more) what you will be asking questions about. In the real world we have time to prepare for meetings, and to propose solutions to problems. This is a job interview, not a high-school exam. •Interviews need to be be much longer than an hour, and should not be on a stop-watch. Programming is not a high intensity quick-fire activity. I think of traditional one-hour interviews (or series of one-hour interviews) like judging marathoners by their ability to sprint. •Don't let non-technical people filter resumes. Some companies filter resumes according to traditional techniques. Certain key accomplishments are going to be overlooked by non-programmers, whereas a software engineer would more likely catch the significance of these items. •Potential hires are as important as customers, so treat them as customers. A well-run business is only successful because of its employees, and the employees will generate many times their cost in revenue (directly or indirectly). The trend nowadays is to treat applicants as people begging for change and that they are lucky if you choose to respond to their questions. •Hire people, don't fill positions. Talented programmers can adapt to any scenario. Don't get hung up on the details of the specific technical knowledge. •Do not misrepresent your job demands and search for overqualified people. Be honest to yourself and the applicant about the level of technical expertise that is really needed. •Do not automatically reject overqualified applicants if they are aware of the job requirements. People sometimes want a job that is technically less demanding, so that they have more free time, and less stress. •Get to know an employee's strengths and passions. Don't just ask about "one project they are proud of". It takes more than a single question, and five minutes to really get know what a person is passionate about. •Open-ended problem solving challenges are good, but don't just give just one puzzle and judge the candidate based on the outcome. Puzzles often require "eureka moments" to solve. Problem solving in general requires a certain amount of inspiration and creativity, which can't be summoned on a moment's notice, and requires a certain amount of relaxation. Letting the programmer choose can relax them, and bolster their confidence in the interview process. •Don't test people's knowledge of language specifications. In our jobs we have access to books, people, and the Internet. Good programmers know how to look up references, and use their tools effectively to write code. Not everyone can properly use reference manuals, and apply them to specific problems. •When testing programmers, consider a take-home portion of the exam. Give people a chance to go home and relax, and see what they come up with. People have most of their moments of brilliance in the shower, or while they are lying in bed. •When interviewing recreate the working environment, provide a computer, compiler, and access to the Internet. Don't ask programmers to write on a whiteboard. Some have been using a keyboard for so long, they can barely write their own name with a pen. •Adapt your interview process to slow thinkers. Programming is a job that is a good fit for people that like to think long and slow about a problem before solving it. It sometimes takes a programmer an hour or two sometimes to do simple stuff, however when they hit the zone they can churn out reams and reams of really complex code in a very short time. •Give a long list of programming problems, and let the candidate approach it how they want. Programming is not a linear activity, we do something here and something there, and pull it together in the end. By letting a programmer choose their problems, you may be surprised that they choose to solve the harder problems with ease, or conversely they may choose to try to solve the traveling salesman problem in an interview indicating a certain level of naivete. You can gain a lot by observing a candidate's thought process in a more open-ended environment. •Don't judge too harshly negatively based on one or two mistakes. A bad assumption is that if someone makes a basic mistake then they automatically suck, and can't possibly be good, even if they are capable of amazing coding feats. There can be many reasons for a mistake, especially in a stressful and artificial environment like an interview. You need to give people as many opportunites to succeed as possible in the interview process, to reveal all the potential top-performers. In summary my advice is to try and recreate the working environment when interviewing and evaluating programmers. Try and give them every opportunity to expose their qualities. No matter how much opportunity you give them, mediochre programmers will simply never really impress you, but the really talented people will sometimes only shine brightly if you have aim the light just right.