Recruiting a dev / tech in a startup
During my career, as a CTO and consultant, I've been lucky enough to be in positions where I've helped recruiters screen and interview candidates, and I even recruited for my own company.
I'm not HR, far from it, but I've always found the process fascinating, requiring an understanding of both the recruiter's motivations, and what lies at the bottom of a Resume or cover letter (to explain to younger people what a cover letter is: no, forget about it, it's a boomer thing 😎). I don't pretend to take the place of a recruiter, but I do have a very tech and project-based view of how to recruit, which is useful, especially when the recruiters don't quite know what they're looking for.
Having been at Station F in the Founders 2.0 (an accelerator program for startups), I was lucky enough to be able to help a young startup with a BackEnd recruitment process.
When you're starting up a promising company, you quickly need to fill certain vital roles - tech very often - and the founders don't always have the experience to recruit. I thought it would be interesting to share my experience.
Recruiting, yes, but why?
A friend once told me: “in a startup, you should only recruit when you have no other choice.” Sounds like common sense, but sometimes startups recruit just to increase the head count - and the presumed valuation of the company, even if it means having to figure out what the newcomers will do next... Not a very good strategy.
What role for the first team members?
The first team members are the most valuable in a startup - you can't afford to miss out on hiring them, as they'll have a profound influence on the launch of your business.
If you know nothing about tech and need to recruit a developer, surround yourself with people who will help you!
You'll need to determine the role you're looking for:
- Tech Lead: are you looking for the person who will manage all the technical problems that arise - and help other, less experienced developers?
- Architect : do you need someone to design your system architecture? And if so, who will build the system?
- CTO : will he or she manage a tech team, as well as infra needs, discussions with partners, cross-functional issues and overall dev. management?
- Or a little of everything at once?
It's also important to define whether you need a senior person to manage or develop, or whether you need a human Swiss Army knife, ready to take on any role.
In a startup, a Swiss Army knife is a great help, and allows you to pivot more easily.
How to find them?
These days, there are many channels for recruiting. These include Welcome to the Jungle, LinkedIn, SkillValue...
It's also possible to approach competent people already in a company (not very fair-play, but that's life 🙄 ), or to suggest to a competent freelancer on Malt that they could join a startup adventure...
The dev recruitment process
What I'm about to write is far from a universal truth: everyone has their own opinion on the subject. As far as I'm concerned, there are several points to consider:
- technical skills
- fit with the company's vision
- ability to work in a team
- autonomy
- balance between quality / speed of development
The technical aspect is of course very important, but for me, the deciding factor between two candidates will be their adherence to the company's vision and their ability to develop quickly in order to pivot / or more slowly to focus on quality, in line with the company's needs.
The benefits of screening candidates
We've already seen the potential sources of recruitment. You're likely to see a lot of candidates, so please filter the list right from the start! Search engines are rarely very relevant, so don't hesitate to eliminate people who seem to you :
- they don't have the right technical background
- too junior? Too senior?
- in a too different time zone?
- ... anything that strikes you as prohibitive.
Once again, it's a good idea to be helped by the right people!
Don't forget that a recruitment process takes a long time, so if you have any doubts from the outset, don't proceed!
A classic process
In general, the steps involved in recruitment are as follows:
- Candidate screening
- Initial contact (email /DM...)
- First call by a founder (to gauge the personal fit)
- If ok: technical test
- If test ok: Call with other founders and/or employee(s) to validate
- If ok : job offer!
Note: It's important to first call the candidate to check that the CV and what you've read are up to date, and that the contact is going well - there is a personal fit.
Then move on to a technical test.
Why a technical test?
Opinions are often divided on the subject. Some people hate it...
A technical test isn't a panacea, but depending on how it's done, it's a good indicator of technical level and suitability for the job.
If your candidate doesn't want to hear about it, maybe he's not the right candidate? 😎
Which technical test?
In general, each type of hiring requires a specific test, depending on the position sought (FrontEnd, BackEnd, Data Scientist, Mobile developer...) and the seniority required, to be revealing.
In terms of length, a technical test takes between 2 hours 30 and 3 hours 30. I like to break it down into several stages - it's up to you to adapt the sequence and duration:
1- Generic MCQ test (45 minutes)
2- Completion of a project (2 hours to 2 hours 30)
3- Open-ended technical subjects (optional: 30 minutes)
Note : I usually agree a time slot with the candidate, who then takes the test at home, unsupervised, but with a critical time limit to respect!
The generic test is fairly simple to set up, and there are a number of apps that let you choose the questions you want to ask. Take TestDome, for example, which lets you create a multiple-choice test by selecting questions of varying difficulty and theme. Each question has an approximate duration, so you can build a MCQ.
For me, the project realization test is the most interesting: the candidate is given a more or less precise (potentially with recommendations to be respected) specification / requirements document, and asked to produce a project that meets the requirements, and to provide the tools to test the product. In general, requirements are not coupled with one another - this way, the candidate can stop when he's running out of time, and deliver something functional. The quality of the result and compliance with the requirements will be checked.
Finally, open-ended technical subjects can be a good way of gauging the candidate's curiosity and knowledge, or the way they respond to a particular problem.
To be adapted!
As mentioned above, the test must be adapted to the job in question.
For example, for a BackEnd, it might be a good idea to ask to perform :
- An API, in REST or GRPC, with CRUD functions that queries a database? And check the quality of error or exception feedback?
(if you didn't understand the previous sentence, don't worry, it's technical 😉 )
For a Data Scientist, on the other hand, the emphasis will be on the clarity of the explanations and the ability to make the subject understandable, as well as mention of the tools or techniques used, even if the candidate hasn't had time to finish everything.
The value of the test
I wasn't previously convinced of the value of technical testing.
But I've met people whose ability to sell themselves was far superior to their real skills... the test has avoided several recruitment problems, on many occasions.
The other advantage of the test: it's relatively long, time is limited and it's very strict: we put the candidate in a stressful situation, so we can see how he or she handles it - in a start-up, this kind of situation is commonplace.
In conclusion
Here, then, is some feedback on the recruitment experiences I've had. Once again, I don't claim to be an HR specialist, but I had to adapt a system that would enable me to quickly get a clear picture of a candidate's qualities and shortcomings, and his or her suitability for the job.
And if, by any chance, you're in the recruitment business and my presentation caught your eye / interested you / horrified you, don't hesitate to let me know!
