Every once in a while people ask us how we hire and interview software developers at Plataformatec. In this post, we share the key things we do when looking for and interviewing job candidates. We focused the post on actionable hints, from the basic tips up to some specific characteristics to the hiring process at Plataformatec. This is what has been working for us and we hope it is useful for you too.
Part One – define your Candidate Profile
Having a well defined candidate profile can save a lot of your time and is fairly simple to put together. A Candidate Profile makes easy for a non-technical person (an HR colleague for example) to help you find and identify potential candidates. These are some examples of what could be in your profile description:
- common “job titles” (specially if you are using LinkedIn Search to find candidates. ex.: software engineer, software craftsman, ruby developer, and so on)
- the most common skills
- their degrees and/or the universities the candidates went to
- their graduation year (if you’re looking for recent grads)
- companies they have worked for in the past
- also, it helps a lot to describe the things you are NOT looking for
But be careful not to make this list too long, it is supposed to be something simple to use. Our experience says that 4 to 5 characteristics are enough. If you want, you can download a Candidate Profile template at the end of this post.
Part Two – preparing your interview questions
The interview is a great opportunity for you to detect evidences (strong signals) that a candidate would be a great match with your team and that he/she is able to do the job… but you’ve got only 60min to do it. Wow, that’s hard! Where to start?
We’d suggest that you follow these steps:
1) Think about your company Culture and Values
- identify which behaviours…
- …reinforce your company culture
- …are definitely against your company culture
2) Think about the challenges of being in the role/job
- make a list of the key skills that the candidate must have to perform it’s activities
- describe a typical day of a person in this position
- think about the most difficult tasks this position requires
3) Focus on ‘how the candidate solves a problem’ rather than ‘the right answer’
- So, when building technical questions:
- avoid technical questions that are “right or wrong” type
- prefer questions where the candidate has to compare X and Y and present you good arguments (the pros and cons), ex.:
- “When would you recommend using X and when you would use Y?”
- we usually ask the candidates to criticize something that they really like, e.g.:
- “Tell me three things you don’t like about Ruby on Rails.”
4) Test your questions
- once you have finished writing your questions, ask them to yourself, to your colleagues or friends. Take notes about the type of answers you’re getting.
- remember, your job during the interview is to look for EVIDENCES, so if the answers you are getting are not providing you any evidences, then you need to refactor your questions.
Part Three – the interview
All right, you are about to finally meet with the candidate face to face. And if you’re using Skype or Google Hangouts please turn on your camera and ask the candidate to do the same. For the interview here are a few notes and reminders:
- Ice-breaking is important, and so is being nice. There’s high probability that the candidates will be nervous when the interview starts. So, the first step is to make them feel comfortable. This is good for them and for you too. If they feel comfortable, they will be able to be more authentic, show their real personalities. So, it is your job to turn the interview into a pleasant conversation. If the candidate is stressed during the whole interview you probably won’t be able to find any of your evidences.
- Pair-Interviewing. At Plataformatec, we like to interview candidates in pairs because we believe that two people can detect evidences better than just one. Usually one of us conduces most of the interview while the other pays close attention and takes notes. But try to avoid more than two interviewers as it could increase the stress level for the candidate and that wouldn’t help at all.
- The candidate should interview you too. Remember to spare a reasonable amount of time (preferably after you have asked your questions) to present your company to the candidate and to answer her/his questions. It is a respectful gesture. They have saved a few hours preparing and answering your questions and the least you can do is to return the gesture. And don’t forget that they are choosing where they want to work with you too. At Plataformatec, we feel that we had a good interview if the candidates leaves our office with more admiration and appraisal to our company’s culture, even if they are not moving on to the next steps of the hiring process.
- Look for for Cultural Fit evidences. As an interviewer, your job is to detect if there is a fit between the candidates and your company. Sometimes we hear from others interviewers comments like “We scared the sh#@ out of the candidate!”. That is a very corrosive attitude. Besides making candidates uncomfortable and being disrespectful, it is unlikely they will suggest your company to their colleagues.
Well, that’s it. I would love to hear your experiences in this topic and I wish you good luck in finding great teammates for your company! 🙂
Download the Candidate Profile template
Fill in the form below so that we can send you a link for downloading the template. That document can help you on defining your candidate profile.
Nice post!
What do you think about having starter projects as part of the interview process? I recently had to create a “hack and throw away” app. I had 2 days and in the end I made a presentation to explain the decisions I made, difficultities, etc. It was the first time I actually did something like that and I thought it was really nice.
We think that starter projects it’s a great idea for a developer hiring process and actually, we do that in our own process.
We believe that in order to hire a developer, you need to see his code, even if because of that the process will take longer.
Have you folks ever tried to do a live coding session with the candidate, either using a computer, whiteboard or pen and paper? If so, what were the results?
I have mixed feelings about it. Some candidates might be caught by surprise, and react in different ways — some may naturally solve the problems without effort, some may get too nervous and do things they would normally avoid. Still not 100% certain this is a good way to assess one’s skills.
I think the best way is telling the candidate beforehand. Candidates shouldn’t be afraid of coding; just don’t ask stupid/out of scope/incredibly hard questions.
I don’t think paper/whiteboard is any good. The candidate will use Google/StackOverflow/Blogs in daily basis, so just give a problem and a timeframe, and watch how the solution is elaborated, asking questions along the way.
In fact, we do something like live coding sessions, we do a pair-programming session. But we don’t do that in the middle of the interview, it’s a separate step in the process and we explain the whole process the first time we talk to the candidate.
We don’t look for right answers, we actually pay attention to how the candidate thinks and communicates his ideas. We focus more on the process and less on the output.
The results were great so far. It’s different to review code that the candidate wrote on his own time from seeing how he thinks, structures his ideas, explains them and implements then in real time. Also, the pair-programming session works as way to feel how would be to work with the candidate. We don’t look just for people who can code, we also look for people who we’ll enjoy work with.
I think getting a background as to how the candidate ended doing what he does is also very important. Understanding his learning journey will help while deciding the amount of experience he has