Our recruitment process is not perfect, of course, it has its flaws, which we want to get rid off. Work on making it better is neverending.
Here are a few steps, and these steps are a bit different for each level of expertise of the candidate. We learned that there are two layers of the whole process.
On the one hand, we need to be sure that the candidate is the right person for us and have all the necessary knowledge/skills/experience. On the other hand, we need to make the process smooth and stress-free for the candidate as we are talking about “candidate experience” here (still — more companies are looking for developers than quality developers out there).
The “candidate experience” layer is quite simple, and it requires following a few rules. It has to be quick, candidate need to be informed about the whole process, what and when will happen next and he needs to receive feedback — no matter if it is positive or negative.
The verification layer is more complicated and has more variations — let’s stick with the “senior developer route” (as per the title of this post) to make the description simpler. When we have a candidate, the first step is a screening call made by our HR manager. She verifies if the person is real, if the cv is not fake, gathering all general information, making initial English conversation. If the role requires advanced English (C1+ level), we are running another call with our linguistic partner for additional verification. Sheis also doing first cultural fit; she is checking soft skills, motivation, further plans etc. Then we receive the notes and confirm if we see the candidate as a BTN team member. If all is good, we are setting up a meeting with Lukasz, Magda or one of the other two people who are handling the recruitments now, and the candidate. On our end, there are always at least two people.
And then we have an on-site meeting — when we speak with the senior-level person. We expect this to be quite a high-level conversation. It is about the architecture, philosophy of coding, his approach to coding, his experience with different technologies, projects, companies and teams. What we have learned over the years is that for senior developers it is not a problem to code, solve a problem and to adjust his ways of writing code (even on a level of specific language). The issue is when his mindset is wrong from the very bottom — or maybe not “wrong” but rather not fitting our expectations.
In the past, we also had some coding exercises — but we discussed this vigorously, and in the end, we decided that coding tests will be run only for the low-level roles. We believe that asking senior-level people to solve coding tests is a waste of their time. If they do not pass such a test — it will only mean that they got distracted, stressed or sth — and in the real world projects, they would make it with no problem. If that weren’t true, they would not be able to work 7–8+ years in this business, and they would not be able to talk with us the way we want to speak with them.
Long story short — what we believe and what’s working for us is to find people who match our expectation on a soft skills and company culture level. In terms of coding skills, for senior-level positions, we check it on a high level. We use a form of open discussion about technologies and past projects, rather than on a low level (like the implementation). After 30–60 minutes of conversation with a senior developer about a real-world problem we can understand his approach, we can scratch the surface of how he is dealing with architecture, time pressure, teammates, code quality — we can see a much bigger picture of his skills than after any code riddles/puzzles.
Summing up — the way we want to talk with developers is to do more of high-level conversation, and we go lower if we expect any lacks.
We go on pure code level rarely.
It works for most cases.