The Best Way To Interview A Developer

InterviewLets face it, traditional interviewing techniques absolutely suck when it comes to hiring developers. You read resumes, you do phone interviews, technical interviews, culture-fit interviews, tests and in the end you basically ‘go with your gut’ and hire people who might be good and still get it wrong half the time. Not an ideal situation. This is because developers are craftsmen and no amount of talk will tell you how good a craftsman is at what he (or she :)) does.

Why Traditional Interviews Fail

How much preparation time do you give your people when you ask then to help with the interview process? Chances are it is probably not much (if it’s anything greater than 5 minutes you’re already ahead of the game :)), so your interviewers end up reading the resume literally as they are walking to the interview and I am not even going to talk about actually preparing some questions in advance. With this level of forethought, how likely are you to uncover anything you didn’t already know from the resume? Even when people have some preparation time, how much training have they got in interviewing techniques? Interviewing is a skill just like any other, having great social skills does not a good interviewer make :). People don’t know the right kinds of questions to ask and even when they accidentally ask the right question, don’t know what to look for in the answer they are given.

So, lack of training and preparation can be an issue, but you can address that, does that improve the situation? It does slightly, still, what do you do during an interview to test:

  • learning ability
  • interpersonal/teamwork skills (outside the interview process)
  • ability to compromise and still achieve objectives
  • working to deadlines
  • depth of experience in the skills that you need
  • breadth of experience in a multitude of other skills
  • etc.

All you can do is ask and take what you’re told as the truth. Not to mention the fact that many good people don’t do well when they are put on the spot during an interview process. Do you just discard those? You’re actually extremely fortunate if you’re interviewing someone based on a recommendation that you trust, but what if you’re not? Luckily, there is a much easier way to find out – let the craftsman show you what they are made of, get them to write some code.

No, Not On The Whiteboard

No, coding on the whiteboard or on paper, or even the 5 minute exercise on the laptop is not really coding. You need to put a craftsman into their element and then you need to step back and observe. Observe how they work, how they interact, how others interact with them. Seth Godin proposes that we need to work with our prospective hires for months, while that would be nice it may not be practical, but we don’t really need to go that far. I say one day can give you enough information to make a good decision. When you have a prospective candidate in mind, rather than iterating through rounds and rounds of interviews, put them into your team for a day and watch them work. After the day is over get your team together and let them tell you if you should hire this person or not.

The advantages of this approach are clear. You don’t need to assume culture fit (or do multi-choice psych analysis), you simply test it. You find out first hand from the people you trust if they would be happy to work with this person, after all that’s what they will have to do. You get a glimpse of the depth of your applicant’s skills as well as the breadth. You find out how easily and well they can grok a new system and absorb what they are being told. And you do all this in an atmosphere which is a lot less formal than an interview and one where a developer can feel a lot more comfortable. This is further enhanced if you ask your people to put the prospective candidate ‘through their paces’ beforehand.

Innovate To Attract The Innovators

Surely we can’t ask a person to spend a whole day working and interviewing before we even hire them. Can you not? Why not, are you not a compelling enough place to work? If your face is getting red right now – fix that first and then work on your hiring process. If you’re worried about inconveniencing a person by asking them to give up so much of their time for free, just imagine how inconvenienced you’ll be when you realize you’ve hired a crappy candidate 6 months too late. Be innovative and you will draw people who enjoy an innovative atmosphere, people who will be happy to take a day just so they can go through an interesting and different interview process. You need to become the kind of company that will attract the sort of employees you want to hire. Your interview process and the way you hire people is the first step. It is up to you if you want to take it.

For more tips and opinions on software development, process and people subscribe to today.

Image by kevincole

  • This is certainly an interesting idea, but I see three primary problems:
    1. It takes longer than a day for a person to become proficient on a new project, so you wont really be seeing them in their element.
    2. People tend not to like this, but you are giving away a certain amount of Intellectual Property by doing this.
    3. You’re also wasting the time of the people on the team by basically having them spend a day training someone who wont be hired.

    But I think the point that you don’t know if a developer is any good until you’ve gotten them into their element and worked with them is certainly true.

    • It is not about getting a person proficient on a project. The idea here is to be able to see if a person can bring something to the team. For example, if a person can ask the right questions about why you do certain things the way you do or maybe voice a few of their ideas about your process. In a few isolated cases they might even be able to show you a thing a two in using the technologies that you use. This is the kind of thing you’re looking for and the kind of person that you potentially want. Of course for more junior people you need a somewhat different set of metrics.

      I’ve heard the intellectual property argument so many times before. It is really a non-starter. Unless you’re working on top secret government tech it makes very little difference. The only intellectual property you can lose in one day is an idea. And you’ll lose that anyway the first time you release :). There is not enough time to lose anything else but does let you evaluate a person a lot better.

      It is probably better to ‘waste’ a few days and hire a person who is really a good fit on many levels, than to hire someone who wasn’t a good fit and then waste months training them before you have to get rid of them and try to hire someone else.

  • Ville Laurikari

    Alan, bringing in candidates for a day to interact with the team feels like a good idea. I would perhaps try this as a last step in the hiring process. Weed out candidates with the usual screenings, and bring in the top two or three for a full day. Any more than that would be too taxing for the hiring manager and team. The hiring process takes a lot of time and energy.

    I’m not sure what realistic work we could find for someone coming in cold for just one day. So far, we’ve tried to emulate realistic discussions (mostly about design, programming, and problem solving) in the interviews. I’ll keep in this mind when we are hiring the next time.

    Finally, your last point is perhaps the most important. All the screening and interviewing and hiring and training is useless if the people you reel in don’t stay for long.

    • It is definitely more of a last step in the hiring process, you wouldn’t want to do this with 100 candidates. But it does allow you to find out for sure if the people you have a ‘good feeling’ about can walk the walk rather than just being good talkers.

      As I mentioned in the above comment it is not about finding the person realistic work to do, it is about getting them to interact with your team, maybe pair with someone and then watching their attitudes and contributions. If they can contribute something meaningful in terms of skills and ideas in one day, you know you’re onto a good thing with that person. Even if they can’t their attitude and how they interact with the people and with the work can be a great indication of their real value as a developer.

  • Todd


    The traditional interviewing process fails because it’s a bunch of people lying to each other. OK, well maybe lying is a bit harsh, but selling to each other.

    Having someone come in for a day is a great idea, the trick would be getting both sides to stop selling while they are there. This is why it takes so long to figure out if someone is worthwhile. It takes that long for the true nature of things to come out — on both sides.

    • There is an easy way to overcome this if you’re looking for a particular skill, ask them if they are an expert, if the answer is yes then ask the following:
      “Here is a specific problem we have right now, could you solve it for me thanks?”

      If they can while noone else on your team could, you know they are at least better than anyone you have which is a good start :).

      It is tougher if you’re looking for a good developer in general (not a specific skill), but there are still ways and means to cut through the crap. Someone just has to make the first step in that direction, if that person is you than most good developers will meet you have way straight away and you’re no longer selling. The not so good ones will continue trying to spin crap.

  • scotty

    It’s actually much easier. Just check their web presence over last few years, and check the code they contributed to open source projects.

    no webpresence, no contributions to open projects = no hire

    • I believe that’s a very shortsighted view. Contributing to open source is not a requirement of being a great developer. Many people prefer to work on their own projects without creating and releasing open source libraries.

      It is certainly a bonus if someone is contributing to open source, but I wouldn’t be bounded by it.

  • I’ve seen this done in several variations in the past and it worked with some candidates not with others.
    A general observation is that some of the best developers out there are introverts. They don’t interview well and they don’t just jump in a new team.
    They usually take time to get into the group – feel accepted – then they become productive. One of the best developers I’ve worked with didn’t have a watercooler chat with me for at least a month.

    The best candidates are still referrals. Someone needs to vouch for their work and abilities.

    • It can indeed be an issue with people who are highly introverted. It is not a one size fits all approach. If you have people in your team who are good at making others feel comfortable and drawing them out it, you can get these to pair with your perspective hires to potentially get better results. Another way is to find a discreet task for the person, although this can be tough.

      I agree that referrals definitely rule when it comes to finding good prospects.

  • Moschops

    Have some prospective hire work for a day? This strikes me as hugely impractical. Are you going to pay this guy for his time? If so, you’ve got all sorts of worries – he’s a paid employee, or a contractor. Either way, there’s all sorts of paperwork and insurance, HR is going to to be not happy at all, IT is going to have to set this guy up with an account and a PC purely for the interview (given that it can take those chaps days to get it together, you’ll be very lucky) – what if you missed a programme he needs? Will you have a hotline to IT to get them down here on the double to install it, or will he have to wait a few days like everyone else.

    If this is an alternative to rounds and rounds of interviews, fix it by reducing that to one interview only, lasting a couple of hours. Replacing that with a differently broken interview is just silly.

    Of course, there’s the security aspects. Defence is a big player in software, and it can take weeks to get security clearance through. Furthermore, it often costs money – a fee is charged to the company, especially if they need it done very quickly.

    If you’re not going to pay him for his time, he’s working for you for free for a day; you’d better be a remarkably prestigious company. I’ve never had any trouble finding work and I’d tell any company that wanted to do this it was going to cost them. You’ll either get people who are insanely in love with the idea of working for you, or people who can’t get work elsewhere. Oh yes, the best of the best.

    • You will not be paying this guy. It is simply a day long interview process without any interviews. There are plenty of companies where the interview process can take way longer than 8 hours actual time and will stretch over weeks. You’re just doing things a little differently.

      You don’t need an account or a machine or anything else. Just put the person in your team and let them pair with your people. You don’t need to find them tasks or do anything special. As your people pair and work with this person they will be able to get more of feel for who they are than you ever will in an infinite amount of interviews.

      I’ve never worked for defense so can’t comment :).

      You’re normally happy to give up an hour three or four times to do interviews, when you’re trying to get hired by most companies. Which actually costs you potentially 3 hours every time if you factor in travel time and context switching and preparation. But setting side 8 hours at once is too much to ask?

      Ideally you want to get people who actually want to work with your company specifically rather than only interviewing because there is a ‘position’. This is not always possible but something to strive for.

  • Dana

    Years ago, I was interviewing with Earthlink, and I was given a homework assignment – to create a module for the DotNetNuke portal that met a list of criteria (CRUD and some tiny business logic). I’d never used DotNetNuke before. I was given access to a couple of team members, was allowed to go onsite if I wanted to get this done and I had three days to complete it. They were looking to see how you approached the entire problem. a) new platform or way of doing things, b) seeking help/tutorials/direction, c) basic mechanics any coder should know, c) small database design/integration and d) if you relied upon people to help.

    I got the job :) I was also later told that I was the first person who actually completed the assignment with all criteria met. I thought it was odd since there was a large team already, but then I realized the homework assignment was an EXERCISE so they could see how I work. The results were a normal *result* of how I worked. This was one of the best technical fits I’ve had in a work environment.

    I think it’s not realistic to expect employers to bring every candidate in for a day nor is it fair to ask any candidate to donate 8 hours of their time – honestly. But the assignment approach is definitely a great way to tell how well a candidate will get the job done.

    • I am not advocating doing this for every candidate. If you get 100s of resumes this is not possible. But you can pretty easily weed out the deadbeats, it’s the 4-5 candidates who actually look promising that you really want to look at more closely.

      But, I do agree that the homework assignment idea can also work especially if you can get some level of interaction between the person and members of your team. And if you actually look at it, the homework assignment can also take you longer than 8 hours to do, so you’re actually spending equal (or more) time :).

  • Phillip

    I don’t see the point of putting them in a team for a day. Most employment contract have a built-in “trial period” of a week or two. It is the job of HR to find the appropriate employee, the team will find the candidate simply a burden. If you try that with 3 employees the team will waste the good part of a week. Sitting the candidate down with the head of the team for an hour, who explains how they work and what they are working on, is a good idea. It’s always important to remember that the interview works both ways and you have to sell your company to the candidate.

    Nobody starts cutting real code on their first day, there is too much to absorb. A simple technical test will suffice for their skills. For example knowledge of basic algorithms, or deliberately introducing an error into short source code and getting them to debug the compile error. If they can’t produce on the day, they may not cope well to a tight deadline so that is a consideration.

    Honestly speaking, as a talented programmer that has had offers from practically every interview he has been to, if somebody asked me to work in their company for a day I would think it a bit of a joke. You want to have a free day of my time and do real work for you and not pay me? Tells me you are a cheap company and not to expect a rise any time soon. It’s something you would offer to a fresh graduate. Unless I was firmly told that at the end of the day I would be offered the job for sure unless I ‘failed’ in some way, I would consider it a waste of time and would be looking at other companies that took me more seriously.

    HR interviews? Fine. Paper technical tests? Fine. On the spot programming exam? Fine. Second interviews? Fine. Guided tour and brief chat with the team? Better. Chatting to the technical director about future direction and projects? Even better. Being asked my opinion on source control systems and best QA practices? Now I feel I’m contributing something. Emailing me tech specs of upcoming projects and asking me if this is something I would like to get involved in? Now I’m excited and even starting to feel potentially part of the team. Tip: offering developers a small percentage of their time to teach themselves new skills will often go down better than offering ‘certification’ courses and will be cheaper.

    There is no magic solution, and your idea appears worse than the current interview solution. HR has to ensure they are competant, use their judgement as to whether they will ‘fit’, then show the candidate basic respect and let them know that you will give them the tools to let them do what they do best.


    • The trial period is meaningless. Once you bring a person in for a trial period you have stopped your recruiting efforts. If you find your candidate is not a good fit, your other prospects have likely found other jobs by the end of the trial period, so you have to start from scratch.

      Knowledge of algos does not let you find out anything about their critical thinking, breadth of knowledge, how well they would gel with the rest of your people etc. Peppering your codebase with some deliberate errors will probably cost you more than 8 hours in the long run in set-up and clean-up time.

      You wouldn’t be told to ‘work for a day’. It is simply part of your interview process. Would you walk out of an interview if someone asked you to tell them how many hair dressers there are in your city? It is quite a common interview question these days, but there are just as many reasons for why it is a stupid question as for why it is a smart one.

      It sounds like you’re very good at your job and you approach interviews as “what can this company give me” because you know you can get a job somewhere else. There is nothing wrong with this, I am sure you’ve worked hard to reach this stage in your career. But if you’re someone who is doing the hiring, your primary concern is: “what can this guy do for my company”. It is great to send someone specs of future project to find out if they’re interested, but the goal is to find out if they can be valuable to the company/team rather than the other way around.

      As far as HR goes, all they can really do to help hire developers is to tick some keywords from a resume against a list they have. Does anyone think that is a good way of narrowing your pool of prospects?

      I agree there is no magic solution. I propose one that I think can mitigate some current issues, but I am open to others (and indeed have heard some others in the comments already).

  • I’ve certainly done my share of hiring of engineers over the years, and I like this idea in principal, but I think you run into a big problem right off the bat. Let’s say you’ve got a fairly standard environment, let’s say Rails, Aptana as your IDE, git as your repository, mySQL as your db. So you set up a machine for this new person to use, then sit them down in front of it. What then. What happens if they arn’t familiar with git, but rather use SVN. OK, maybe not a major problem, but still an issue – I can’t test if they have good code base management skills. What about if they’ve spent the last 6 years working with ProgreSQL rather than mySQL, now I’m unsure about their database skills. This is all very problematic because they may have fantastic skills, but they just don’t know the tools. This gets even worse if your environment is non-standard, maybe some in-house tools, maybe a different development environment (Mac to Linux to MS). So now, I have to have one of my guys sitting there nursing the candidate through this stuff. The candidate is now intimidated and the employee is not happy either. This does not bode well.

    Having said this, I might actually give this a try next time I have a candidate that I think could handle this, just to see.

    • Get the person to work WITH your team not IN your team. Get them to pair on tasks and join in design discussions. Get them to chat with your team about their current practices and the way they do things. Get them to shoot the breeze with their fellow developers and figure out if they can learn from each other. These are the goals. You don’t need to set up a new machine and they don’t need to be aware of any technologies you use.

      You’re not only finding out if the candidate is good fit, but also getting your whole team to collaborate in hiring decisions rather thn having people forced on them.

  • Does address this problem in any satisfactory way, I wonder?

    • Thanks for sharing that. It is interesting and can let you screen a large number of people for coding skills etc. But once you get down to the last few candidates it still doesn’t let you assess how well they will fit with the team, their ability to contribute meaningfully etc.

      I do believe it can be a step in the right direction.

  • “You need to become the kind of company that will attract the sort of employees you want to hire” I couldn’t agree more. Making your group an awesome place to work in will attract great talent. It also means you get to decide among several qualified candidates instead of a few decent ones and a bunch of poor ones.

    • In my book hiring good people and improving yourself as a company go hand in hand always. Especially given that one will perpetuate the other.

  • Some responses to responses:
    1) It’s common for a company to request an entire day of interviews, especially if the candidate is traveling from out of area.
    2) Hardware, IT support, tool familiarity — those are nonissues. The candidate is pairing. He can use his partner’s equipment, or ask his partner how to do things in the tools.
    3) For defense contractors, clearance is an issue, but many candidates will already have the necessary clearance AND most teams have some code that isn’t under the restrictions: infrastructure tools, etc.

    I’ve seen this idea work but not exactly how you’re describing. This is a rough timeline I’ve seen work well for an entire day of interviewing:
    Morning : traditional interviews
    Lunch with technical leader(s) of the dev team
    (end process if interviewers vote for not moving forward)
    Afternoon : Pairing with team, at least one senior member and one junior member.
    (end process if team votes for not moving forward)
    End of day : interview with final decision maker

    The point of the pairing isn’t to get free work. It’s to see how they interact with your team, how they learn new things, and if you’re lucky, how they teach others.

    IMO, you’re not going to learn much more from 8 hours of pairing than you will from 3 hours. And except for very senior positions, I believe it’s excessive to require multiple trips to your office for interviews.

    In an ideal world free of business constraints, you should only hire someone when your team is excited at the prospect of working with that person.

    • Thanks for your insights, to be honest this is kind-of the process I was envisioning when I was talking about working with a person for a day (the pairing and end of day interview with a decision maker etc) :).

  • Most of us don’t have time to try this approach and traditional questions, they don’t get to the heart of the matter. I have suggestions for 21st Century Interviewing for Developers:

    • What you propose in your article certainly makes sense, it’s basically called due diligence, even though a person looks and sounds good, you still do the hard yards and try to find out more. Having said that, I don’t buy the don’t have time, or don’t have money excuse. If you don’t find the time or money at interview time it will cost you way more down the line unless you get lucky.

      • I’ll still argue that if I have 10 candidates to vet using your method, I have to throw away 10 developer days to babysit them and check them all out. That feels incredibly inefficient. I would be willing to try that with the top two, just to check them out AFTER serious due diligence, but as valuable as your method is, it’s not easily justifiable on a development schedule. (No company I’ve ever worked with would ever give me that kind of leeway for sure, and I’ve worked a spectrum of them at this point…)

        • Yeah, I can’t argue with you there, most if not all companies would never allow it, so you have to come up with the best process you can working within the constraints that you’ve got. However this doesn’t make anything I’ve said any less true, a company with enough vision to implement a process such as the one I suggested will not only get better people but will also save a lot more money in the long run. Most companies however are not known for forward thinking.

  • Pingback: 面试开发人员的有效方法 - 博客 - 伯乐在线()

  • Pingback: 面试开发人员的有效方法 | EvilCode 邪恶代码()