Love is a losing game
Love is a losing game
and what is hiring if not love at first sight?
The absurdities encountered during the hiring processes of well-known technology giants has become a meme on social media. Everyone loves it, everyone loves to dunk on it, and everyone thinks that they are stupid. And someone everyone still wants to be hired by those companies.
When I interview candidates, I ask them about what could be improved in their current company.
Regardless of their specific answer, some people are very open but others fear that it’s a trick question, I always follow up with “Let’s assume that people are not stupid, if your company does things this way there must be a reason. So why is that?”
Side note: If you are interviewing with me, this follow-up question is the actual question.
So, let’s answer that question ourselves before we can maybe propose an alternative.
Hypothesis 1. The signal-to-noise ratio is really bad for popular companies
In my experience as hiring manager in a big company, I had to face the fact that we just had a lot of applicants and it was incredibly difficult for our recruitment team to call all of them and/or screen CVs 1.
So we reverted to the easy way out: use HackerRank to screen direct applicants (not referrals or sourced) with a super-duper-easy test.
Even after that step, we had a ton of applicants to be feasible for the hiring manager to interview everyone that passed the recruitment phone screen. So we had another technical interview step before the person was allowed to get to the 3-4 step final interview.
I swore after this experience that I was never going to use automated interview tests ever again as they are terrible for candidate experience and filter out candidates that just don’t like to do exercises under pressure or just reject this model of interviewing (and maybe those are the ones I need).
Hypothesis 2. Exclusivity
Big popular companies offer very high salaries and great benefits and their former employees find another job very easily. Is like being admitted to an exclusive club.
Therefore those companies feel that they have to be rigorous and have a very high bar (or a bar raiser) to make sure that the people that join are “worthy” of the status of ex-Amazon/Google/Apple regardless of the actual job performed by the person.
I am wary of this explanation because it seems too easy: it would explain why those companies keep struggling with inclusivity for example, but I am not fully convinced that this is a conscious choice.
Hypothesis 3. Cargo culting
In the 90s, when most of those famous companies were founded (if not earlier), being a software engineer was a specialist role. The technology stack was not as abstract as it is today and most of the work was low-level.
At that time the supply of engineers was low, and was also hard to find people that had the right technical skills.
Fast forward to 2022, the technology stack has completely changed, most of the software engineers in these companies write CRUD applications using libraries and tools that are widely available and rarely have to deal with complex theoretical problems that cannot be solved by googling harder2.
But the hiring practices have not changed, they are still geared toward selecting the unicorn engineer that can single handendly rewrite the Unix kernel without asking “Which problem is this person going to work on?”
Hypothesis 4. Broken internal processes
Companies have broken internal processes and require senior people that can work around that broken onboarding process and figure things out by themselves instead of hiring more junior/medior folks that will need (gosh!) to be onboarded and learn the internal stack before being productive.
Which hypothesis is correct?
While obviously, I can’t be sure, and maybe not even those companies know exactly, I think that all of the above are relevant but mostly point one and three drive the current state of affairs.
Fixing point one is hard, but in my opinion, if you have so many applicants to require people to go through Hackerrank, then you are better off not accepting direct applications and going only through referrals and sourcing.
An alternative
When I joined Aidence it was finally my responsibility to change things, to shape the hiring process exactly as I wanted. So, high on power, I decided to burn my past, read a lot and try something I haven’t tried before.
Rules I gave to myself
No automated tests or automated rejections, there is always a human on the other side
No trivia (for example “please describe the even bubbling in javascript” but also “please write on this piece of paper the Dijkstra algorithm”)
Adhere to the SOARA style in technical interviews
Try to make the process as stress-free as possible, and as inclusive as possible
Drive a consistent hiring bar across different teams using objective measurement
The cornerstone of the process: The playbook
One thing I had clearly in mind from the beginning was that each position published should be for a specific team, that the hiring manager for that position must be the future manager of the person hired, and that the people interviewing should be the future teammates.
This has several advantages in terms of engagement and ownership of the team but also for the candidate that gets the opportunity to reverse interview the people they will work with, for example, to learn what kind of work they do.
The biggest disadvantage is that you might end up having an inconsistent process, a different hiring bar, and so forth.
So I decided that to drive consistency we will have a shared playbook for each role: i.e. all the Backend Engineer interviews must use the same playbook.
The biggest inspiration came from a famous (but otherwise mediocre) book on hiring called “Who - The A-method for hiring”.
In that book, the authors propose a scorecard method to use to grade candidates and drive objectivity and consistency. As illustrated below.
And this scorecard is the first part of my playbook. Each role must have a mission, 3 SMART goals, and 5 competencies.
Those goals and competencies are what is graded by interviewers: there is no such thing as “passing the interview” or “I like their code”. Whichever question we ask candidates must be used to evaluate the SMART goals and competencies, nothing else.
The second part of the playbook defines the interview process, the steps, and which interviewers are involved in those steps.
So let’s dive into it.
The first steps
We want to be very quick, and as I said before, we don’t want to use automated tests. So we rely heavily on sourcing and referrals.
The first step is obviously with our recruiter or recruitment agency, so nothing different from the usual.
The next step is always a 45 minutes call with the Hiring Manager to go through the candidate's experience and essentially assess if the person has a fair chance to pass the interview.
I have heard multiple times that this could be too heavy on the hiring manager and I should rethink this approach but, at least for now, I am 100% convinced that this is the right thing to do.
It creates a feedback loop for the hiring manager, that puts a limit on how much they can grow their team without being fully absorbed by hiring. If hiring is critical for them, they should be 100% focused on it.
Finally, it creates the right incentives, as they have to balance the need to hire with the need to not overburden their team.
It also creates a great candidate experience, as they get to know immediately their future manager and ask questions directly to them. No middleman, no smoke screen.
The two above steps are completely skipped if the candidate is a referral from inside the company.
The technical interview
Depending on the role this might vary, but let’s use Backend Engineer as an example.
The technical interview is made of 3 steps:
Take home test
Pair programming
System Design
Important to note: Step 1/2 can be skipped altogether if the candidate has enough open-source code to share. Fewer steps are always better if that doesn’t compromise quality.
Here what I wanted was to create an experience that made sense, that was as close as possible to the real work that people do in our company, and that didn’t induce too much stress.
During my research, I figured that take-home tests followed by a pair programming session appeared to be the favorite combo of people with anxiety. It also adapts very well to our remote policy as it just requires the candidate to share their code first, and their screen during the session.
Sidenote: There are no limitations on which tools to use or if you can google stuff. In real life, you have an IDE and Google, and everything else. We don’t care about adding fake obstacles in the interview.
Much of this was inspired by this blog post and I advise you to give it a read as well.
System Design as a SOARA interview
While for the coding interview, I had to dig and research, for the System Design interview it was much easier as I had already experience with a method to make those interviews better.
The idea is that you must never ask “Please design this” because that is the “coding on paper” version of system design.
Instead you ask “Can you please draw and describe the architecture of a complex system you worked on in the past”. And then ask questions to clarify the design, and to understand if the candidate truly understands the system, failure modes, operations, scaling, etc…
The typical counterargument is “What if the candidate doesn’t have a system to describe” Then maybe their level of experience isn’t what you need right now and that is a straightforward signal.
The job posting
A few words need to be spent on the job posting, while the majority of it is pretty standard, we took the step of being 100% transparent on our website and describing clearly:
All interview steps
Our salary range
Our remote policy
This was important to me because it creates a more inclusive environment, as we know minority groups and women tend to ask for less money, but this way they already know the pay and we don’t lowball them.
It’s also good for recruitment if there isn’t a match of expectations that is well-known from the beginning.
Rolling out this method needs a mindset shift
The biggest hurdle in rolling out this method wasn’t to get people to like or accept it. Everyone understood and liked the idea.
But when the time came for the first technical interviews, people struggled with a few topics:
Why can’t I ask trivia? I think those topics are important to know
How do I fill out the scorecard without grading the code?
How do I ask SOARA questions on technical topics?
Those are just a few examples, but don’t be afraid of tackling those questions. Your people are smart and will catch up.
Actions lead to a culture shift
While I can’t say we are always successful, I think those changes injected in the organization a healthy culture around recruitment with some heartwarming successes like this one
In a LinkedIn post, I summed up our culture as follows:
Interviewing is not about "gotchas" or pressuring people, is about getting to know each other, what are our mutual strengths and if that is a match. We hire for strengths not lack of weaknesses.
Our interview process is "outcome based" and is all about giving people the ability to shine in real world problems that we face as a company, not theoretical exercises that mean nothing.
If we don't hire someone is not because "they are not good enough for us" but because their strengths do not match what we need right now at this stage of growth.
And I stand by those words
Closing thoughts
While in this post I went all out against the common hiring practices used in big companies, I don’t think I can be fair to those companies without mentioning that engineers also have their fair share of guilt in the current state of affairs.
I have seen pushback on basically anything: people do not want to do live coding but also don’t want to do take-home tests, but also do not have the time to have a GitHub repository, but also…
I have even seen pushback against SOARA interviews people want to be hired with no process at all.
While this would be great, and I am sure that in some cases this is possible, it’s also unreasonable. And if one party is unreasonable then the outcome can never be satisfying no matter how hard you try.
As I said at the beginning, Love is a losing game
the first person that figures out how to replace CVs with something useful will win a Nobel prize
If you are in BigTech and feel differently, you are probably the exception