If you are working on a tech or/and Saas product, you will for sure need talented engineers to reinforce your team sooner or later. You wish the best for your project and you want everything but losing time and money with a maladjusted person in your team.
Hiring engineers or developers can be difficult. Even if some resumes look promising: how to be sure about the authenticity of professional backgrounds and especially of technical skills? Will a candidate be quickly productive on your product? How to be sure you won’t lose precious time and energy in the process?
In this post, I share my experiences and best practices on how to hire efficiently tech profiles.
Why recruiting?
The optimistic meaning:
Most of the times, we are proud to hire someone, even if it will indubitably impact budget, we are enthusiastic because we finally see our project growing. We hope our new candidate will drastically improve our project’s productivity. Thus, we look forward to seeing the results.
The pessimistic meaning:
Most of the time, we forgot to mention that if we need to hire someone, that means we were no more able to execute enough by ourselves and therefore we are looking for help. It is completely ok to need help but we do not have to forget that: hiring can be extremely sensitive and destabilizing for a project. We need to be absolutely certain that the chosen one won’t disturb the team balance and culture and will also be beneficial for the project.
Does resume matters? (Not so much)
When I select resumes prior to schedule interviews, I don’t focus (only) on diplomas or professional experiences. I look for passionate people. The fact that the candidate has not graduated from a big school does not mean he did not teach himself the required skills or that it won’t be a fast learner driven by his passion for his job.
Passion is really what is most important to me. I have already seen people with perfect resume on paper being counterproductive (and sometimes lazy) simply because they took a wrong path in their career and were bored at work. Conversely, I already saw, several times, people with a resume that didn’t match profile expectations but was so passionate that their learning curve became exponential and they rapidly were more productive that old members of their team.
Interviews (How many and what)
I generally organize 3 interviews for each potential engineer: 2 technical interviews and one neutral/team interview.
2 technical interviews:
1°) the first interview is used to meet the person face to face and learn to know her. When it is possible, come with a tech leader or an engineer from your team, to gather other people’s point of view. This first interview is an oral exchange, a dialog to judge the candidate’s personality and ask him some questions regarding its curriculum.
This interview allows to understand how the candidate behaves and if there could be a match with the project, its culture and the existing team. Try to understand if the person sounds reliable, resourceful, and autonomous. During this first meeting, don’t go too deeply into technical questions, just check if he knows the theory (design patterns, common programming language question: POO related, etc).
At the end, if the person seduces you, the day after the first interview, ask him to come back for the second interview.
By the way, I recently read a really interesting post on BusinessInsider explaining people judge you based on 2 criteria when they first meet you. I strongly recommend you to read it (Link here : http://uk.businessinsider.com/harvard-psychologist-amy-cuddy-how-people-judge-you-2016-1?r=US&IR=T)
2°) The second interview will be dedicated to real technical tests (either on paper or on a computer).
Testing engineer skills can’t be done only orally or based on a resume. Too many developers are convinced they know a programming language simply because they followed once a basic tutorial and understood the logic behind the concept of a programming language.
You have to challenge them and check their capacities by yourself. Sometimes, they will be scared and you will even notice that some people will give up the hiring process being afraid of written tests. Don’t worry, if they left, you didn’t lose anything, either this person lied about its skills and is scared you might eventually discover its lack of knowledge, either he is a lazy person looking for an easy job. In both scenarios, you don’t need that.
Anyway, for each question we ask in our technical tests, there are always many ways to answer. We know for sure that it is impossible for developers to know everything. Computer engineering is pluri-disciplinary and we know we won’t find someone who knows exactly at 100% every technology necessary to develop our product. We just want to estimate the ability of the candidate to adapt, focus and provide a clear and logical answer with few resources. (No Internet access during tests, etc.)
3°) If I am satisfied with test results, I organize the third interview. This last one will be with the rest of the team members. What your team thinks should really matter. The future member and your team will work together day after day, it is important that they appreciate each other and that we all share the same team culture. Moreover, team’s feedback about the candidate are often very relevant. It is so difficult to judge someone and be sure it will be the one in only 2-3 interviews, the most feedback you can get the most confident you will be regarding your choice.
Required Qualities
Computer technologies are always evolving, your project will maybe from time to time need to readjust its technical components.
You should search for developers and engineers able to pivot with your project if required.
Autonomous:
Do you prefer someone who will lack of reassurance and always ask you for help, advice or to double-check his works?
Passionate:
Passion is key to success. Hire the most passionate people about your project. Otherwise, they will end up bored and will become lazy.
Adaptability & resourceful:
You may know what you need today but who knows how your project will turn out to be tomorrow. Hiring people able to adapt to any circumstances and able to change their work habits may be crucial.
Uniqueness:
Hire Different people versus similar people. Every engineer should have a specialty. If every member of your team has exactly the same skill sets, you will end up looking for other people with new skills sooner or later.
Experiences
As I already wrote my thoughts in the “Does resume matters?” part of this article, if the candidate has not graduated from a great school or has a resume mainly in other areas than those you are looking for, it does not mean that he won’t have the ability to learn them quickly. There is a quote saying: “Hire learners, not experts”.
Hiring experts is a good idea if you are a visionary and that you know exactly how your project will evolve and what type of expertise and profile you want on your team. Conversely, hiring learners is more judicious if you still don’t control every aspect of your project. For example, if your project will need at some point of experimentations, prototyping or testing: hire learners.
Conclusion
My last cofounder always said the following quote “One doubt, no doubt.’’ If we had even a little assumption or doubt about the candidate, we prefer not hiring him to maintain the successful team balance as it is.
Last advice: If you consider hiring someone, don’t rush, anticipate. (Hiring someone take times.)
..State of mind (Entrepreneur)
