A job interview is a scary thing. A lot hangs in the balance for both parties. The goal should be to thoroughly learn about this person, and see if they are a good fit for the job position, and also for your company, and for your team.
This is a guest post by Wessel Kooyman. In 2001, Wessel founded Cole Street, a web and mobile development company that specializes in startups. Wessel is also a mentor at DojoBoost, a startup accelerator in Paris.
A job interview is a scary thing. A lot hangs in the balance for both parties. The goal should be to thoroughly learn about this person, and see if they are a good fit for the job position, and also for your company, and for your team. Here are four criteria you can use to assess a candidate.
- Relevant Skills: If your position is a PHP developer, we want to know if this person can develop in PHP. You can have that skill through either experience, or training, or both.
- Relevant Experience: If the position is for a PHP developer that has experience with Drupal (a common PHP based CMS), let’s see how much experience the developer has not only with PHP in general, but also with Drupal.
- Domain Knowledge: If your company is the next best thing in stamp collecting online (“we’re the eBay of stamps”), then does this person have any experience with stamp collecting? Or with online exchanges? It’s not a must, but a developer with relevant domain knowledge can be a major bonus.
- Communication Skills: This is a complicated issue with developers. In an ideal world, all developers would be great communicators. However, if you require that for all your developers, you’re excluding probably 80% of the labor pool. So figure out if your developer position requires good communication. If the developer is managed by another technical guy who’s a good communicator (like your CTO), then communication skills may not be very important. If the developer will have to work extensively with your other departments, or even worse, your clients, then it’s essential.
Step One: Get Them Comfortable
People give their best interview when they are not nervous and tense. So we should make every effort to put people at ease. I do this by trying to be friendly (ask people about their weekend/dog/kids) before I start the interview. If you like sports, that’s a great icebreaker too if it’s a guy.
Then, start by introducing yourself, your company, and the position the person is applying to. Do this in one or two minutes.
I always spend 10-15 minutes before the interview obsessing over the CV, so that I know already what the person is trying to sell. Now, everyone inflates their CV, which is OK. We want to eliminate the big lies.
I start with the person’s life timeline. Starting with the beginning of the CV (usually college/university), I ask about the school itself, pretending not to know the school at all. This gives the person an opportunity to relax, because I’m asking the easiest question in the world, which is both easy to answer, and you can’t really lose any points by talking about your school. So I aim to fill the first 10 minutes going through school(s), any jobs, internships, then all the jobs that came after that, all the way up to the present. So in my head, I am establishing a clear picture of this person’s life, while looking for any suspicious gaps.
People can have gaps in their CV. They will always try to cover these up. The causes can be very different – from drug abuse, unemployment (especially in France), sickness, laziness, failed relationships. Without trying to pry into their personal lives, try to get an idea of these gaps if you see them. Obviously the drug abuse is a red flag, and ‘I wanted to do nothing for 6 months and collect unemployment benefits’ is probably not a sign of a great work ethic.
Step Two: Drill Down on Experience
So after 10 minutes of effortless interviewing (you’re only asking simple questions inside their comfort zone), most people will now be much more relaxed. So now we can move on to the real questions. Also, if by now, the person is not yet relaxed, they won’t ever, so just be prepared to do the rest of the interview while they’re tense. It’s painful, and it hides the person’s real personality, but some people just can’t relax during a job interview.
So now we start talking about the actual skills required. If we stick with the PHP / Drupal example, we know from the timeline how much relevant experience there is. Zoom in on the most important/impressive job or project. Start asking details: What version of Drupal was used? (Research this beforehand, if you need to). How big was the team? Who managed the team? Was the site in production? How many users used it? What was the hosting situation? How was source control handled? Which bugtracker did you use? Were there any major problems? What were they? How were they resolved?
As you can tell, these questions are a lot tougher, and you will now either see the person warm up because he’s excited to be talking about something real and technical, or he’ll get intimidated because he now has to deliver and he overpromised.
So if the person gets too intimated, back off. Change the subject to another project, ask less detailed questions, and try to get the person back into their comfort zone.
If the person smiles and excitedly starts telling you all the details you asked for and more, then keep asking obviously! See how far you can go.
Step Three: Assess their Character & Communication Skills
Also, tech people often have big egos. First of all, if you have one yourself, take a deep breath and let go of it. You’re not there to impress the person with your awesome skills. You’ll just sound like an arrogant prick that no one wants to work for. So don’t get locked into a battle of who-knows-more. The second thing is, does the person have a big ego? If so, you have to decide if you can live with it. Some of the best developers are the bragging type, so you may not have any choice if you need a big talent. But there are also talented developers that don’t feel the need to show it off at every occasion. Get a feel for this person’s ego size now. Also, if your team already has a big ego developer, adding a second one can cause massive trouble.
So by now you have a clearer picture of this person’s skills and past experience. By now you also have a clearer picture of this person’s communication skills. Did the person look you in the eyes while talking? Fiddling nervously? Any weird tics? Badly dressed? Body language that reveals weird things? If you have doubts, ask some questions about how the person feels about meetings, about talking to clients, etc.
Also, spend a little bit of time asking about their workplace preferences. Open space or private office? Any specific wishes? Some people go nuts about getting free drinks and food, so see if there’s anything that may really want. If it’s a good idea (‘unlimited free fruit for all employees’), you may want to implement it regardless of if you hire this person.
Step Four: Sell Yourself
Now it’s time to sell yourself as an employer. (If the person is really awful and you’re sure you’ll never hire him, skip this part, of course.) Talk about your training program, talk about the great workstation they will work on (developers go nuts for multiple screens), talk about your flexible hours, the awesomeness of your technology, etc. In countries like Romania you can talk about the quality of the health insurance you are offering. In France, the bizarre system of ‘tickets restaurant’ is a must-have for an employer.
Finally, if the person has domain knowledge (he’s a stamp collector or has built eBay), ask the person about that. Someone that’s REALLY excited about your domain can be incredibly helpful.
I like interviews to last 45 minutes at the most, because it’s exhausting for both parties, and I usually interview at least 4-5 people for any position. The person is probably also doing a bunch of interviews, so don’t waste each other’s time! If you’ve covered everything in 20 minutes, don’t draw it out just for the sake of filling time. Also, if the person is interviewed by more than one person in your organization, you don’t want to exhaust them so they will suck at their next one. I also usually coordinate with colleagues that also interview to prevent too much overlap.
Step Five: Make First Impression Notes
When you finish the interview, resist the urge to provide immediate feedback. Simply thank them for their time, and say you will get back to them later in the week. After an interview I always immediately write down my impressions, categorized by the four areas (skill, experience, domain knowledge, communication skills). It’s important to write down, because if you interview 4 people, you will confuse them at some point. So spend 5 minutes documenting your thoughts.
Obvious Red Flags
- Any form of lateness: I’m Dutch, so I’m hardcore about being on time. If you can’t make it on time for a job interview, then you are not working for me. I don’t really care about any excuses, especially not bad traffic and broken metros. You should’ve created a margin of time to anticipate that, and if you didn’t, you won’t work for me. I personally am 30 minutes early for important meetings and hang out in café on the corner to kill that time.
- Poorly dressed: I don’t need to see a suit or anything, but flip-flops and shorts don’t work for me. This is a problem especially in California, where Mark Zuckerberg set an awful example. If you can’t bother to make the effort to put on socks for a job interview, you don’t work for me.
- Offensive behavior: Any racist remark or female-bashing, is a no-no for me. In theory I don’t care about what people think about this stuff, but if they need to air it during a job interview, they can keep looking for that perfect job position at the Front National.
- Technology religion: Some people are nuts about open-source/Linux, to the point where they refuse to work with closed-source software. For me that’s a practical problem (many of the programs we use are closed source), and it displays an extremist attitude that will be problematic.
Always assess candidates based off of four criteria: relevant skills, releveant experience, domain knowledge, and communciation sills. Before the interview, memorize the CV, look for weaknesses, and see what holds up in the interview. Before drilling down on the important stuff, make sure the candidate is comfortable so you get to see the best of them – though some people are always nervous. Once you’ve assessed their communication skills and their character, jot down quick notes: grade them on the four criteria, so that you can compare later between other candidates, and make a note of any obvious conflicts with the team or the position.
This is the first in a four part series of articles about the recruitment process with developer positions. Feel free to follow up with the rest of the series: