The good recruitment experience
In the era of the high demand for experienced engineers, your company can't afford a bad recruitment process
For about 18 months now, I have been running dozens of recruitments processes in my current company. As an engineer, my job was not only to run technical interviews but also to design a good process.
Recruitment isn't that easy - you need to know who you want to recruit first and what skillset you need. Do you need a senior engineer? If yes - why? What are the senior skills you look for?
For some companies, the senior engineer will be extremely good at software performance, for others - good social skills and the ability to understand business.
In your company, the recruitment process can be treated as an ongoing "project" itself. There are several people involved. There are HR managers, team leaders, technical interviewers, etc, who need to work together on daily basis and share knowledge about processes and candidates. That part also isn't easy, and if you don't make it right, it will be noticeable for candidates - they will see the mess...
Nowadays, recruitment can be a crucial part of the company's growth. Everyone needs programmers, almost everyone struggles to hire them. And not everyone is among FAAMG which for some reason are considered El Dorado for some people.
Recruitment is tightly coupled with employer branding.
✅A good process can start with slight attention, but end with a strong will to work with you - candidates might be intimidated by your professionalism, atmosphere, technical skills of people working at your company. It's a moment, where you can advertise your company among them.
❌The bad process will tell them, that you are desperate, your projects suck, your developers are poorly skilled and you waste their time.
Remember - as long as companies need programmers more than programmers need companies - the effort to make it right is on companies.
How about junior developers? In Poland, where I live, salaries and offers for senior engineers grow fast as hell. But for entry-level engineers - they don't. We receive a lot of resumes of people we can't and don't want to hire. Is it still an employee market here? In my opinion not - while we still need to be professional, there will be differences. Most of the effort in recruiting junior developers should be on a candidate - because we as a company have dozens (PHP) or hundreds (frontend) of resumes for each role.
I will not write step by step what I do - it's just too much for a single article. But let me give you some advice on what I consider good and bad practices - which works for me and my company.
The ugly - take-home tasks are evil
Take-home tasks are one of the most popular and one of the worst things companies ask to do. The more senior developer you are, the most likely you will hate it and resign from the process because of that.
It's quite simple - they try to give you a task, which requires you to spend from few hours to few days(!) doing some imaginary task which doesn't make sense. Why not? Because you can't write a working application in that amount of time! Of course, you can do a hackathon-like app which is a quick'n'dirty solution, but come on - you are recruiting yourself somewhere you want to work at, right?. So you want everything to be truly good. You want TDD, clear commits, elegant code, elegant abstractions... And you only know something like "Write app fetching beers from nearby stores and display them on the frontend, using pagination and filtering. Use React and Redux.". Why do I fetch these beers? Who is my client? How long app will be used? And why the hell do I need redux for that?!
There are hundreds of questions you should ask before you write a single line of code. If you are an experienced developer, you realize that coding is the last and possibly quickest thing you do. You need to analyze the domain, the business context, choose a stack, and do many, many things. And they ask you, to ignore all professional steps you will normally perform because you need to fit into several hours. Ridiculous!
What to do instead?
No task at all
Ask yourself do you need to check someone's skill by asking them to write code? Coding is based on thinking, so maybe you can just make people think?
Github and OSS
Ask candidates if they have any code they can share with you. Most likely it will be fine for you. My strategy as a candidate was to write some "classic coding task" for myself in my free time, later was sending it to several companies and no one rejected it. If they miss something, they can ask you during the interview how would you write it.
Design a solution instead of writing it
I like this one. Technically in a small amount of time you can write maybe some Katas - can be good for junior to check if they know the language itself. But complex solution (which company should be most interested in) can't be written - but maybe it can be designed.
Depending on what you want to check, you can ask several different topics, for example:
- Design Slack-like app. Consider communication between backend and frontend, deployment based on workspace creation, performance reading messages history
- Design an open-source library for the UI design system. Consider maintainability for few years, focus on API-first approach and interoperability with different styling solutions.
- Design CMS-like app with entities dynamically built by the user. Focus on storing data/designing database.
The output of such a task can be a document with some nice flowcharts, some abstract models, events flow, etc. Then you do follow-up and discuss it with the recruitment team and candidate, trying to validate this solution.
I like this solution, it can show real experience and reveals how candidates think, which is far more important than writing the code itself. The downside of this solution is that it fits senior+ engineers.
The code-review task
Coding takes time. And it's stressful. Live coding also sucks. But what about the old truth - that most of the programmer's time is not writing code, but reading it?
One of the solutions we did in Codibly was crafting a small app, which was later broken on purpose. It was working, but some traps were set. Of course, depending on technology, there is a different set of problems to be found.
During the interview candidate was meant to download the codebase, open it in his IDE and go through the codebase, pointing problems like it was a code review. The interviewer used this as a discussion starter, asking why this solution was bad, what should be done instead, etc.
If a candidate can spot wrong method naming, complex conditions, etc, most likely he will also know to write a good one - without asking him to do so. Instead, ask him "how would you name this method"?
The ugly - quiz interview
Many interviews have a nasty form of interrogation, where the bad-cop interviewer is asking questions, and after answer he nods or grunts, writing something down and going to the next question.
This is a serious step to daunt candidates from the company. No one wants to be put in so uneven position and be questioned, especially when there is no discussion or feedback later.
What to do instead?
Ensure that the interview is a discussion.
Just like a code review - it should be equal by definition.
The recruiter will indeed ask questions to the candidate, but the candidate has the right to disagree and to protect his own opinions. The interviewer can be wrong (but should be prepared well as hell!) and should accept it. Instead of "quizzing", start with open questions, which should lead to an interesting discussion about a real-life experience. This is also a time when a candidate can ask about the company itself.
Consider this short scenario:
- 👨🏽💻 Interviewer: Tell me something about TDD
- 👩🏻💻 Candidate: It's a technique, where you write tests before implementing the code.
- 👨🏽💻: Why do you do that?
- 👩🏻💻: _I have extra coverage, my code is better quality because it has to be testable. It's easier to spot tight coupling and use dependency injection.__
- 👨🏽💻: Right, it's also a great way to self-document a code, isn't it?
- 👩🏻💻: Yes, by reading a test I know for sure what function should do. Do you do TDD in your projects?
- 👨🏽💻: Yes, but not every time. We think on the front-end it doesn't work so well - it's hard to write valuable unit tests on UI components.
- 👩🏻💻: Cool, I agree, but...
Which a single question both interviewer and candidate know some real-life experience of each other.
Time for the candidate
Another proof of the equal conversation will be giving some time (e.g. last 15 minutes) for a candidate to ask general questions about working in the company. Remember, that some questions can't be asked to a non-technical person! If 15 minutes is not enough (I need about 2h to ask all my questions), ensure another meeting will be scheduled!
If a candidate doesn't know the answer, why keeping it from him? The interviewer doesn't have to teach candidate programming, but a one-sentence explanation what is the correct answer might be a great gesture. Candidates I interview give great feedback about their experience, pointing how much they have learned!
Final word - be respectful and honest
I, as a candidate, hate the most when my time isn't respected. When I spend time on the process and I receive no feedback. When I'm not talked to honestly, but being deceived by corporate policies. Or just being lied to.
Like Doctor House said, "Everybody lies".
Companies can think they will hire someone more likely. But after few weeks of work this person will leave, because the company lied and he feels insulted. And can find any other job in 5 minutes, au revoir.
If you want people to join your company, treat them with respect. Even if they don't join, they might be thinking well about you. Maybe they will tell their friends that you are a great place to work at. Maybe, when you skill up a little, they will try again and be great employees.
If you want me to help you with your recruitment process, you can contact me