I recently saw another article highlighting the many ways in which recruitment in software development is broken. Whiteboard coding, random trivia, poorly trained interviewers… it’s all very painful and it seems to be the situation in a lot of places.
However there are companies trying to turn this around. For instance I loved the “Companies that don’t have a broken hiring process” list, and I’m constantly working to make sure Drivy deserves its place in it.
Since this is still a major pain point, I decided to share how we handle recruitment for engineering positions at Drivy. I don’t think that it’s perfect or much out of the ordinary. I’m also convinced that it’s going to evolve as it has done in the past, but it’s been working well for us and we got good feedback so far!
Overall there are two big things we want to check: making sure that the person has the technical capabilities to do the job, and then making sure that they will bring a lot to the company’s mission and culture.
Here is basically how it goes:
This might seem that there are a lot of steps… and maybe it’s true. However we feel that it’s good for both parties if they get a good look at what working together would be like.
In terms of timing, we try to be as fast as possible, so that even if you get to see a lot of people, it can be condensed in a very tight schedule, grouping some interviews together if needed. We all know that processes that last forever are a major pain for applicants. Also most interviews don’t last more than one hour, so overall it still seems reasonable.
Let me explain the process for fullstack or backend developers. Note that your mileage might slightly vary, we don’t want to be completely rigid as we’re still young and growing. However we follow this exact process in most cases.
After applying, the applicant will quickly get a first skype call with someone in charge of recruitment. This first contact is usually a good place for the applicant to ask more information about the position and the company, as well as explaining why they’re interested in Drivy.
If the applicant is still interested, they will be given an assignment to complete at home. We spent a lot of time trying to provide something that can be completed in an acceptable amount of time while still reflecting what the job will be. You can check it on Github, it is based on our internal accounting system which is a massive part of the app since we are a marketplace and we have to deal with a lot of money moving around.
Once the applicant has done the assignment, it is reviewed by people in the engineering team. We mostly check if the applicant can write clear and simple object oriented code and is able to justify main decisions if necessary.
If it’s not considered good enough (the standard varies depending on the position), the process stops here and we try to give some insights on what to improve.
The next step is an interview with one of the senior member of the team - most likely me. There we discuss what they’ve done in the past, the position, motivation to work for Drivy and so on.
If we didn’t talk about salary range during the screening, it will be discussed here.
If this goes well, they move to an onsite technical interview with a couple of developers from the team. Depending on the position, the exact process and the people involved can vary, but the main objective is to talk about code.
The applicant is asked to bring code written before. It can be open source code, a side project, client work or a small subset of the codebase from a previous position (if this is something the candidate is allowed to do). We’ll sit around the applicant’s computer and challenge the choices made and how it turned out. We believe that it’s a good way to discover what a candidate is capable of. Of course we know that all code in a codebase can’t be perfect, but there’s a lot to be learned in the tradeoffs and teachings of old code.
We’re proud of our own code and often show pieces of it to candidates at this point in the process to see how they react to it and grasp it. This also helps them to get some confidence that they won’t be working on spaghetti code.
After this there is an interview with someone working a lot with product management. This is important because we consider ourselves a product company, so we are looking for people interested in what we are building. It is also a good opportunity for applicants to ask more questions about the project.
Finally the applicant has a small interview with someone from another team - it could be the person responsible for international expansion, the head of communication or someone at customer support. This is a way to make sure every department is aligned on who we hire as well as show the applicant what the rest of their future colleagues look like. It’s also an opportunity to for the applicant to get insights about the company’s culture - not just the engineering team.
Once everybody agrees that the person would be a good fit, we ask for past references to contact. In every case so far it’s been a formality, but we prefer to be safe on this one.
If this goes well we discuss all the remaining topics, like finalizing the exact offer.
Personally I think that this process works quite well. We avoid the pitfalls of whiteboard interviews, but still get a great sense of the technical capabilities of applicants.
It is a bit time consuming, but hiring is too important to be cutting corners, and I feel like the amount of time we ask of applicants remains reasonable. We also had a lot of people - that we hired or not - telling us that the process was a good experience because the exercices and conversations were interesting. The current team is also a great example that this process helps us find the right people.
Of course, like everything we do, this process will evolve and this post will probably be outdated soon. However the guiding principles of trying to have an interview process close to the reality of the job will remain the same.
I mostly talked about the process after a candidate applied, so here is a little information about how we hope to get candidate’s attention.
All our job offers try to give a sense of what the position is going to be about. We don’t shy away from sharing info about our stack, our projects or our internal processes. We also want to be inclusive by not requiring a specific degree, opening remote for certain positions and making otherselves visibles to as many communities as we can.
We are present in meetups so that anyone can meet a Drivy employee and ask questions about our open positions and have an informal chat. For instance lately we hosted ParisRB (large Ruby meetup), Women On Rails and Paris Ruby Workshop. Our developers also tend to go to various conferences and get to chat with a lot of people there as well.