Recruiting a developer in France [SERIES 1/4] – The Interview


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.

  1. 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.
  2. 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.
  3. 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.
  4. 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.

TL:DR Version

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:

5 Responses

  1. John

    “If you like sports, that’s a great icebreaker too if it’s a guy.”
    But if it’s a girl this will be a rubbish icebreaker because girls totally don’t get sports.
    “Any racist remark or female-bashing, is a no-no for me.”
    uh-huh. So I see. Still, I’m glad that male-bashing is still OK.
    Pet peeves about the latent sexism in the software development world aside, this article left me unsatisfied. This is probably partly because recruitment is one of the most difficult things you will have to do in business so trying to summarise it in one article is always going to be difficult. But there is more to my dislike of the article than that. There is the fact that Wessel has taken a number of prejudices and opinions and proposed them as generic rules for recruitment (e.g., being late, wearing shorts, some reasons for previous gaps in employment). There is also the fact that the method he outlines – a 45 minute chat – has never been a reliable way of finding good candidates in the past for me.
    If you were interviewing for a chef, would you get them to explain some great omelettes they have cooked before and ask them technical questions about making an omelette? Or would you get them to cook the omelette and see what it tastes like? Hiring developers has some similarities – they will be taking their skills, knowledge and experience and using it to create something. The only way to know how good they are is to get them to do it. If you are hiring a PHP developer, get them to write some code for you. Better yet, get them to work with the team to write some code. The most effective interview technique I’ve found for developers is to get someone in for 1 day to work with the team doing the job you expect them to do. This is expensive and difficult to organise it, but hiring the right people is such an important task – especially for a startup – that it is time well spent. (Of course, this doesn’t guarantee that someone who looked good for one day won’t turn out to be, for example, a sociopathic idiot, but no interview technique is perfect. This is what probationary periods are for.)
    The other thing that Wessel doesn’t mention is that it is extremely difficult to hire for jobs you don’t understand. If you haven’t done the work yourself, how will you understand what is required for it and whether or not the candidate knows what they are talking about. If you’re a non-technical founder hiring a developer then gaining this knowledge might seem prohibitively difficult, but that doesn’t make it any less essential. If you are hiring for a role you haven’t done yourself then you might as well put all of the names into a hat and pick one out at random. (Of course the same can apply to a technical founder hiring a head of sales, etc…)
    On a more positive note, the importance of trying to make people feel comfortable is spot on. The more you can get people to really be themselves, the more chance you will have of finding out if they really are a good fit. Confrontational interviews don’t benefit either party.

    • Wessel Kooyman

      Hi John,
      Thanks for commenting! You point out a couple of things that are totally correct – i assumed but did not mention that it should be a technical person doing the interviewing. Otherwise you can’t really ask the gory details that i talked about. I also wasn’t suggesting that you should hire someone based on ONLY this interview, but again, i did not say it explicitly. In future articles i will talk about the whole process, in which this is only one step. I also do the sit-down-and-code thing, but usually not at the same moment as the interview.
      As for prejudices, it’s not like it never happens that people show up in shorts, or late. Whether you call that prejudice or experience, i’m simply naming a common occurence, and my rules for it. 
      Again, thanks for your comment. This is part one in a five parter, so you’ll have plenty more chances to take a shot at me!

    • David Bruant

       I’ve taken some time to respond to your post:
      “i assumed but did not mention that it should be a technical person doing the interviewing.”
      ” I also wasn’t suggesting that you should hire someone based on ONLY this interview, but again, i did not say it explicitly.”
      => You didn’t publish a newspaper. It’s the web. You can still push an update 😉
      John: “There is the fact that Wessel has taken a number of prejudices and opinions and proposed them as generic rules for recruitment”
      => Totally. You (Wessel) giving how you approach recruitment and share your experience is extremely enriching. Thanks for doing it.
      However, advertising it as “Recruiting a developer” is plain wrong. There are a lot of things in what you’ve written that are either not necessary or could be done or approached very differently.
      For a starter, let’s talk about communication:
      “If the developer will have to work extensively with your other departments, or even worse, your clients, then it’s essential.”
      => The initial “if” is a recipe for disaster. If the developer is isolated, s/he cannot as well capture what the end user wants, needs, what the constraints are. The hardest part of a software project is not the code. That part is hard for those who just learned programming. The hard part is understanding the need of the end user, because they are usually unable to express it or in worst cases, they don’t even really know what they want. The further a developer is in touch with this need, the hardest is the work.
      “Step Three: Assess their Character & Communication Skills”
      => You spend an entire paragraph talking about ego. I don’t really understand why it matters. On the other hand, you completely ignore the ability of the person to work in team. Some people have a huge ego, but are able to step back in the context of team work. Some people are great at communication, but can’t work in team.
      Regardless of ego and communication, if you hire someone who isn’t used to work in team and suck at it, you’re in a pretty bad situation.

    • John

      Hi Wessel,
      Thanks for replying and for the clarifications. I look forward to reading the rest of the series.
      Rereading what I wrote about ‘prejudices’ and your reply to it, I’m not sure I expressed it very well. I wasn’t talking about whether or not things happen, I was trying  to say that approaching an interview with a preconceived set of rules about what makes a good candidate is a mistake. The person who turns up late wearing shorts who missed 6 months of work while overcoming a drug problem might be the person who can really add a lot to your business. Applying these rules to an interview is no more useful than thinking ‘obvious red flags are black people or people don’t like to go to a strip club on Friday nights’. I’m not trying to equate the two sets of prejudices here – I’m just comparing their relative usefulness when interviewing people. For example, you might think that lateness suggests people are unreliable – just like some people think that women aren’t very good at logic – but neither is a reliable method of determining whether or not you the candidate is the best fit for the role. Now I’m sure you could reply that you don’t rely on just these rules for interviewing, but my point is that you shouldn’t rely on them at all. The fact that you are assessing people on issues beyond whether or not they are the best candidate for the role is unhelpful.
      I think that this is very similar to your advice about letting your ego go. Let your prejudices go too. See what is in front of you and be open to choosing the best candidate based purely on their ability to move your company forward.

  2. Camille

    By the way, I’m looking for a joomla developer

Leave a Reply

You must be logged in to post a comment.