This week I realized that ever since my first full-time job as a frontend engineer, I was somewhat involved or responsible for hiring new people.
And I always found hiring... Strangely rewarding? I don't know. I have this weird predisposition to deal with work like it is some kind of strategy game. Hiring feels a lot like adding reinforcements to my XCOM squad.
That being said, this hiring game is far from an easy one, and after many screened candidates, many mistakes, and zero formal HR training, I learned a lot of stuff that I'd love to share.
Which brings us to this article, filled to the brim with advice for engineers (and team leads) that suddenly faced a need to add people to their team.
Just keep in mind that while some of my learnings are actionable, some others are straight-up opinions, and both are direct consequences of my professional experience. So grab (and share!) what resonates with you and feel free to skip what you don't find applicable.
Let us begin.
Treat candidates with the utmost respect and dignity #
Starting fast with rule freaking zero.
It makes me mad that this needs to be said, but it does. No candidate should ever be ignored; no candidate should ever be left waiting weeks for a status update. That's basic human decency and the absolute minimum you can do when hiring people.
Sorry for the rant, but I've seen friends being treated like crap far too many times. This kind of behaviour is unacceptable and I wonder why it happens so often.
One plausible theory I have is that recruiters (be it HR or engineers) usually fall into this hole where they can't noticing the enormous asymmetry of the hiring process and treat people like mere tickets on aboard.
See, as a recruiter, you go through dozens of profiles a day and disqualifying people is just part of the job. When you're finally done, you get a pat on the back, a "job well done", and move forward with other tasks.
Applicants, on the other hand, have much more at stake. Not only because applying for a new job usually takes a significant amount of time, but also because a new job might mean a critical and long-waited career change, more money and safety, a breath of fresh air, a self-realization boost, and fresh, exciting challenges.
Which does not mean you should hire people "because they want that job so badly!!! 😩", but keeping that asymmetry in mind will help you stay empathetic and treat candidates with respect.
Be super specific about what you want, what you can offer, and how you hire #
Hiring takes a lot of mental energy. Replying dozens of emails answering the same question about benefits and stipends over and over is not an intelligent use of that energy. So do yourself a favour and write a comprehensive job listing.
Start with a very detailed list of what does the company expects from the position. Think requirements, values, years of experience with XYZ, what the candidate can say or show to increase their chances, etc. Help them help you.
And be as detailed, if not more, about what the company can offer as compensation for the role. Salary is a piece of obvious information that should be up top, and you should try and be as specific as you can, a hard number is ideal, but a salary range that accounts for experience works well enough. Don't forget benefits, PTO and sick-days policies, home-office budget, etc.
Finally, do remember to add a section where you explain how the hiring process will be handled. A couple paragraphs describing each step and how long they usually take is enough to keep candidates informed. Being transparent is critical.
And just like good engineers write new test cases after a newfound bug, make sure to update the job listing with extra info after a candidate emails you with a new question.
Have some kind of system where you can keep track of everything #
Sometimes, when I'm feeling a little bit optimistic, I think that recruiters ignore candidates not because they don't care but because they're terribly disorganized.
I mean, that's somewhat understandable. It is easy to see how dealing with hundreds of candidates can be troublesome when you don't have a system to help you go through applications. However, trusting the task of keeping up with hundreds of people to your brain is hard to excuse.
So whenever I have to deal with more than a pair of candidates, I create a Trello board or something similar, like a Google Sheet, to keep control of the process. I'm a fan of creating super-comprehensive pipelines where I can move people through each step so, for a standard hiring process, I'd have columns for:
Application received > Application reviewed > First meeting invite sent > First meeting confirmed > Skill assessment sent > Skill assessment reviewed > Meeting with hiring manager invite sent > Meeting with hiring manager confirmed > Offer sent > Hired
Your mileage may vary depending on how your recruiting process works, of course, but having a clear picture about every single candidate and where they are in the pipeline brings some much-needed peace of mind.
Create a checklist to help you filter our candidates objectively #
Success! You've promoted your job listing very well, some industry influencers even shared it on Twitter, and now you have eighteen hundred applications to sift through. Hooray!
Ok, that number of applications is probably not realistic for the majority of job openings. But be it 1800 or 18, you might not have the time to book a 30-minute chat with everyone that sends you an application. So you need a way to filter these candidates in a fast, fair and objective manner.
That's where a checklist comes in handy, and if you wrote a detailed job listing, you're halfway there already.
Start by gathering everything you wrote on the "what we expect from this position" and turn it into a checklist. Does this candidate have 5 years of experience with Node? ✅ Do they have prior leadership experience? ✅ Their past experiences are good evidence of seniority? ✅. And so on.
Doing so provides an objective way to compare suitable applicants and gives you a fair (and quick) way to disqualify candidates that don't match the opening requirements. There is no problem with sending a "Thanks, but we expect more experience for candidates applying for this position" if you were transparent about what that amount of experience means.
Write down with a few canned, well-thought email templates #
Great hiring experiences happen when the people behind them are engaged and motivated to do it. So, as it happens in many situations in our industry, if you don't really feel like doing it, you'll do it half-assed.
But don't take that as discouragement. I firmly believe that engineers should be the protagonists of hiring, and "not feeling like it" should be expected from time to time. Hiring is a communication-intensive process that can leave the best, most extrovert engineers feeling drained after a few hours.
And what do we do when we don't want to work on a problem? We find a way to make that problem easier, more pleasurable to work with. And one thing that really helps is emails templates.
Let's go back to our hiring pipeline for a sec:
Application received > Application reviewed > First meeting invite sent > First meeting confirmed > Skill assessment sent > Skill assessment reviewed > Meeting with hiring manager invite sent > Meeting with hiring manager confirmed > Offer sent > Hired
Imagine that you need to update candidates every time their status changes, be it progress or disqualification. Typing down:
Hello candidate,
we are happy to invite you to the next step /
unfortunately, we decided to not move forward with your application
for each step, for each candidate, gets old real quick. So do yourself a favour and write that email only once and use it as a template.
Some pro HR tools like Recruitee gives you some fancy dynamic tags like [candidate_name] or [position_name], so you don't even need to worry about replacing strings. But even if you don't have those, simply copying and pasting a template (and remembering to change the candidate's name, for god's sake) will save you a lot of time.
As a rule of thumb, it is good to have a positive (we're moving you to the next step) and a negative (unfortunately, we're not going forward) template for each stage of your pipeline. Just remember rule zero and write those messages with extra care and respect.
Another good thing to keep in mind is that the longer you took to disqualify a candidate – say, they were dropped out on the last step before hiring – the more invested they were in the position. So take some extra time to write additional feedback for them.
And even if you create a dozen templates, you'll still likely have to write some original replies for edge cases. Just make sure to update your job opening page with the information if it makes sense.
Don't let the ball on your court for long #
Long recruiting processes suck. Candidates get more anxious (and uninterested) by the week, recruiters get demoralized by slow progress, and sometimes the process takes so long that the open position starts to get questioned.
"If you need that extra person on your team so badly, why you're taking so long to find them, huh?"
Poor hiring decisions, however, also suck tremendously. And sometimes, the only way to prevent that is investing a lot of time in assessing candidates.
This sounds a lot like a no-win scenario, drag the process for too long and risk losing great candidates to other companies, rush like hell and risk adding a Python backend engineer to your React frontend team. Pretty much an HR Kobayashi Maru.
You can do two things to deal with this impossible situation:
Question your leadership (or yourself) about how long the hiring process should be. It is essential to have a "baseline" process that works most of the time, but sometimes you can speed up one step or two to make things go faster without significant negative impact.
And if the process can't be made any faster, prevent it from going even slower.
If you need to communicate an update to a candidate, do so immediately. If a candidate is unresponsive, check if they're still interested. If other people in the company need to take action, keep bugging that until they do something.
No candidate should be left waiting because you're "like, super busy" with other tasks. An email takes like 2 minutes, even less if you already created some templates.
Be aware of hiring biases #
Human beings are fascinating animals.
We tend to look into the mirror and see clear-thinking, rational, fair individuals. But we are constant victims of cognitive biases that very much affect our decision-making without consent and, most of the time, without our awareness.
If we don't stay alert of these biases, we might favour candidates for unfair reasons, like them being surprisingly good looking person, or their life stories being similar to ours.
Another example, sometimes a friend or strong referral applies for the position. Instead of rationally assessing them and weighing pros and cons, we just search for information to confirm the initial assumption that they're a good candidate.
For the sake of brevity – and the already mentioned lack of formal psychology & HR education – this section won't feature a list of biases, only a strong recommendation for you to research more about it on reputable sources. Doing so will help you hire better and give you insights into some unconscious decisions you make every day.
Another thing to keep in mind, and this is a suggestion I'm comfortable with making, try and have at least one more person with you when evaluating CVs and during meetings with candidates.
It doesn't have to be the same colleague pairing with you every time. Just having one more person sharing their thoughts about a candidate is a powerful tool to help both of you recognize and counter biases.
Take action #
A few years ago, I found myself in this unusual scenario where three engineers, out of five, left my team in the same month. Each of them had good reasons to do so, and I was happy that they could find new challenges.
One thing I was not pleased about, though, is that my then team had some optimistic goals that were no longer attainable with two people instead of five. And to make things worse, the HR dept was notoriously slow and unresponsive. Some teams usually had to wait for months to meet with a promising candidate, things we're not looking good.
Thankfully (or, should I say, at least), the company had a strong ownership and autonomy culture, so I convinced myself that by jumping over HR and handling recruiting all by myself, I'd be 100% aligned to the company expectations.
And that's what I did. I still had a talk about compensation and benefits with HR – as a mere Team Lead, I didn't have that level of autonomy. Still, our agreement was that I would pick the candidates, and they would just work the final bureaucracy of hiring contracts, background checks and so on.
So for a couple of weeks, I didn't write a single console.log and devoted my time to writing job opening pages, headhunting, screening candidates, assessing tech skills, and doing all the communication.
During that period, I went through HR material like I was reading the docs of a fascinating new framework. Whenever I was conflicted with a decision or unsure about how to proceed, there was good advice on the internet. Hiring is not rocket science.
And things went surprisingly well! We hired three competent junior engineers with great cultural fit and still got to meet the quarter goals. I still catch myself wondering how we did it and feel content to have grabbed that bull but the horns.
So yeah, if there's a moral to this anecdote, it is that sometimes the only way you can put a fire down is by dropping the firehose and finding some more firefighters to team up with.
Remember that there's more to a good engineer than raw coding skills #
Filtering candidates is a big, if not the most significant, part of recruiting. You want people to help you on a mission, and you want to pick the best among all applicants.
What makes the "best" candidate varies a lot, though. Being super good with this week's stack is an obvious thing to notice, sure, but there are still many subtle and equally important skills to consider before deciding and who you'll hire.
For instance, try and picture a talented engineer that can't communicate their thoughts clearly, either written or verbally. Or a super fast designer that works fantastically under supervision but lacks the self-motivation to keep pushing when no one is watching.
Doing great work nowadays requires a diverse skill-set, especially if we consider the remote work boom. You need people that: can work under little to no supervision, self-organize over a clear mission, collaborate well while being precise with their words, manages their time efficiently, and display strong emotional intelligence.
Which can be... Hard to find, yeah, but just like a person can be a junior in tech skills, you can expect them to be inexperienced with these so-called "soft skills". This is fine, a good manager/team lead should develop soft skills as much as they promote tech expertise among the team.
Just keep in mind that values like integrity, honesty, and respect are not negotiable and should be expected from the greenest intern to the most seasoned veteran.
Wrapping it all up #
I'm quite confident that you'll go from unstructured, chaotic hiring to a pretty darn good process by following these tips. Most of it might sound like straight-up common sense to experienced people, but trust me, the "me from the past" would've love to be taught some of those things.
And with that in mind, I'm 100% sure that I still have a lot to learn about it. I mean, hiring is a complex process with a lot of variation and moving parts, and everything I know is "derived from" and "limited to" my career as a frontend engineer.
For future reference, I have this (very well recommended) book on my reading list called "Scaling Teams" from Alexander and David Loftesness. I should be going through it shortly, so you can expect either a quick revision of this article or a new "lesson learned" article about it.
Stay tuned and until next time. 👋