Recruiting is never an easy process. It doesn’t matter on which side of the table we’re sitting – whether we’re applying for a job or interviewing candidates, there’s always some tension or misunderstanding, hence good recruitment is considered almost as an art. Since Software Development is an employee market, recruiting engineers is even harder. I’ve already wrote about hiring software testers, where I focused on bigger picture – from publishing job description, onboarding process, to creating skills’ development environment.
Although there’re still a lot of questions in this area, both from established companies and small startups. I’ve also noticed substantial concern about recruitment experience on few QA communities. Therefore I decided to revisit this subject and dig even deeper. In this post I want to focus on recruitment process from recruiter’s perspective, and in future one I’ll wear candidate’s hat. All thoughts are based on my own experience in recruiting candidates and being recruited myself, in various companies, domains and company cultures.
Different approaches
Number of different recruitment strategies is directly proportional to number of companies, multiplied by recruiters count – variation is huge. Although we can group hiring-strategies into two approaches: pre and post selection.
Pre-selection approach focuses notably on recruitment phase. It’s usually long and rigorous process, both for company and candidates. You put a lot of effort in interviews, recruitment tasks and evaluating cv’s with aim to hire only the best candidates available on the job market. It’s about quality over quantity. Pros of this approach is when you finally hire an engineer who passed this process, you can be confident about his knowledge and abilities and it’s highly unlikely for him to turns out to be ineffective.
Supposing this so-called pre-selection is about finding the best engineers available, are there any cons at all? Unfortunately yes – putting so much attention on recruitment phase makes it long and expensive. Due to its demanding nature there’s also a high risk of candidates dropping out in the middle of recruitment process.
An alternative way is post-selection. Recruitment process here is rather a form of smoke-test selection. Your goal is to put a bar lower and hire every candidate who fulfills your minimal requirements. Then you exercise their abilities during probation period and continue cooperation only with ones who succeed.
Pros? Recruitment procedure here is simple, very quick and you don’t have to put a lot of resources into it. There’re some significant disadvantages though – first of all you can end up with big resignation ratio and there’s no assurance of hiring right people as a result. Secondly, Software Engineers often follows word of mouth opinions, and post-selection approach can cause bad reputation for company’s hiring experience.
It’s pretty hard to adjust your optimum from these two approaches and only small group of companies decide to go entirely in one of them. There’re two main variables you should consider though: amount of time and resources you’re willing to allocate on recruitment and how much you care about your engineers being best people available.
Recruitment starts with recruiters
Recruiting is about hiring best people, yet sometimes we put a little attention to the people we choose to lead recruitments. I often see similar situation: there’s an candidate to be interviewed, so we’re searching for whoever has some free time in our office to lead an interview. We put attention to people we hire, but not ones that decide whether to hire them or not. It really matters to train your peers how to conduct during interview process or how to ask proper questions. You can have expert level engineer with poor recruitment skills – maybe it’s better to ask him to review recruitment tasks than lead interviews?
I’m a big fan of having specially trained hiring team – people having not only high level of expertise in their domain, but also being trained in interviewing and recruitment. If you have only one or few peers with such abilities, you can train new ones by for eg. acting as a shadow recruiter during interviews. Hiring best people starts with having great recruiters.
Second thing is hiring team being prepared. If you demand candidates to be prepared, you should repay with the same. Take effort not only to study their cv, but for eg. search for their web footprint – github, stackoverflow, blogs, etc.
Recruitment process
Usually hiring process consists of few different phases, like technical check, HR interview, etc. Think well the sequence of phases – if you prefer to review candidates knowledge and then agree or not to their salary demands, you should obviously do technical check first. If you have very strict salary ranges, maybe it’s better to agree on financial terms first.
Inviting every candidate for interview is sometimes impossible, and brief cv’s overview is often misleading, so you might want to conduct some kind of smoke-test. From personal experience, brief phone/skype talk with candidates can help you to schedule face-to-face interview only with most promising ones.
Technical check is the key part of the software engineers hiring process, hence there’s whole set of issues around it. Many companies are asking candidates for doing some kind of on-paper implementation of common algorithms. While I understand the aim of this activity, I don’t find it useful though. Programming isn’t meant to be group activity – programmers usually prefer to write code in environment where they can focus and be away of any distraction. If you failed great engineer, just because she couldn’t revert binary-tree on piece of paper while three strangers are watching – well, I don’t think it’s our goal here.
So how we can check their technical abilities? Of course face-to-face interview is always great, especially when we’re hiring for senior-level roles. Then it should be more of a talk between two experienced engineers than test. Although If you’re willing to check their code-writing style, good idea is to send homework tasks for your candidates, as a part of the recruiting process. It should be a small, yet not obvious task, like implementing some piece of functional test automation (Test Engineers) or simple microservice (Software Engineers). That code should be further reviewed by your senior engineers.
Some engineers have also a tendency to ask some special, puzzling technical questions. It’s better to adjust your questions to your real expectations – remember that candidate is also evaluating you and whole company and those corner-case questions can be misleading. If you want to hire engineers able to deal with real-life challenges – ask them real-life questions.
Lately I came across technical recruiters who are very close and vocal in various tech-communities. They have a tendency to ask about candidate’s community awareness, whether they know any blogs or participate in meetups. While I understand the learning and pro-active aspects of such attitude, I disagree about it’s explicitness. You can be a great engineer with hans-on experience and deep domain knowledge, without knowing whole set of blogs. Further more, having poor community knowledge doesn’t equals lack of self improvement desire – there’re many learning paths and sources available. With that being said, you can also participate in every community event and always keep your finger on the pulse whether any new posts came out, yet still don’t have well-grounded, practical knowledge. Bottom line is despite community-awareness is a plus, it does not implicate your technical knowledge and experience.
Last but not least, good practice is also to divide HR and technical parts of the process. Salary expectations should stay confident for future peers.
Feedback
As we already said at the beginning, IT industry is an employee market. There’s strong competition in acquiring best people available. The simplest strategy is to offer salary ranges greater than market average. Of course it’s effective, but up to some point – your resources would be limited. So what else you can do as a company to stand out from the crowd and attract candidates? One of the strongest factors here is company culture.
The term company culture is clearly overused and it’s definition exceeds range of this post. But how can you build image of your company in such limited timeframe like hiring process, and what’s even more important – how to leave good impression for ones that didn’t succeed in your recruitment?
One of the greatest tool here is giving feedback. Candidates invest time and effort in your recruitment process – If you failed them, it’s good to provide them information where they fell short and how they can improve. Many times, in various companies I’ve worked with I’ve seen similar scenarios where after failing from recruitment process, one was improving in certain areas (based on provided feedback) and then successfully reattempt to interview.
How to build a good feedback? It depends on the recruitment phase. If candidate was not hired because of his senior’s level salary expectation, you should give him detailed information what you expect from senior level employees in your company. When hiring software engineers or test automation engineers, common way of giving feedback is to do code review for his home task. You can provide detailed information for almost every single line. It’s the most valuable for candidates and can truly help them to grow as an engineers. You should also avoid giving feedback in a phone call – by sending e-mail you’re giving better way to focus on it.
Summary
Engineers recruitment is not an easy process – it’s more of continues learning experience. Not only you should constantly improve your procedure, but also catch up with latest trends and market’s demands. Important point here is exchanging thoughts with other recruiters and their experiences. By saying that – can you share some of your tips on hiring software engineers? If so, please leave a comment!
