On Hiring Great Talent
By: Marco Sparagna, Director of Engineering Management at Fever.
In the past years there has been an increasing amount of people writing about our industry’s broken hiring processes and how it is a huge waste of time for both the company and the interviewee.
Most complaints are around the length of the process, as lately it is easy to have to face more than 7 interviews, even for junior roles. Other concerns are around the way technical skills are assessed, typically an algorithmic or system design challenge.
At Fever, we changed our process and focused on giving a better experience to the candidate which results in a higher quality of candidates hired and a shorter overall time to select them.
The Big Problem with the Hiring Process.
As much as we architect our systems trying to solve the same problems as big corporations have, without actually having the same problems (just search for “you are not x” where x is any of the FAANG) we try to solve hiring problems the same companies have, without actually having them.
Let’s start with a reality:
Google Gets 3 Million Resumes a Year.
your company, most likely, doesn’t. So why does your process look like Google’s?
I remember I once had to do 2 days of 6 interviews of 1 hour each for a junior frontend position. I passed the first-day of interviews, but I didn’t get the job in the end, and the feedback I got was that nine interviewers thought I knew enough but 3 didn’t. They were the last three interviewers of the second day.
For another Junior Engineer Interview, I had to write, on paper, an algorithm that would find all possible paths from a given point to another in a matrix, without hitting obstacles. I wrote an algorithm that could find one, but not all of them.
I didn’t get the job.
To this day, I still keep on wondering: what were the interviewers looking for?
The Interview
Most of the interviewers don’t really receive proper training and are asked to assess the technical knowledge, cultural fit, and psychological aspects of a person that is trying to answer hard questions in a 60 minutes interview while dealing with stress, imposter syndrome and a huge load of confusion on what the interviewer is looking for.
For example, I once received feedback for a candidate from two different interviewers involved in different stages of the process; they were both negative but one interviewer complained about the candidate mainly using “me” to talk about achievements, while the other complained about the opposite!!
Sure one can make the case that the candidate should have highlighted both the team and their personal impact to achieve the goal, but isn’t this just storytelling skills? Why not just directly ask the candidate to differentiate between their personal and the team’s effort if this is what we are looking for?
In a certain way, it seemed to me like the process is set up to highlight the candidates’ weaknesses and make them fail, instead of really understanding their actual knowledge and growth potential.
Embrace Imperfection
First of all, we have to accept that there’s no golden question you can ask in an hour that will give you a perfect picture of the applicants’ knowledge or their ability to fix a complex problem when in a real life scenario you normally have more than 1 hour and enough time to study, investigate or ask others.
This is why we should ask ourselves: “What are we trying to understand in this step?”. What will you do with the knowledge that someone can or cannot reverse a binary tree?
A better way
In my opinion, it is a lot better to ask the candidate questions about real problems they have faced, compromises they have made, challenges they have had during the development of the solution, and learnings.
Understanding the candidate’s ability to describe something they should know well sounds very simple, but it’s actually just a way to make them feel comfortable within an environment where they will be asked questions.
It is fair to ask the aspirant to brainstorm with you after changing some of the initial assumptions, for example asking: “How would you change the solution if the system you built had to handle a sudden huge spike of traffic?” or “How would you generalize this so it could be easily extended in the future?” but, without forgetting that we are asking an aspirant to solve a “hard question” in around 15/30 minutes (which is normally the time given to a single question in an interview). Odds are, the solution won’t be “optimal”.
What we really want to understand is the ability of the candidate to have developed a deep understanding of how and why they have built a system in the past as well as their capacity to have a technical discussion around such topics. How they reason about a certain problem, the questions they ask themselves and the interviewers, and how they accept feedback and act upon it.
This is one of the most realistic environments we can offer, as usually big work happens alternating between discussions, studies, and an iterative approach towards the solution, more than having the perfect answer on the first try.
Value potential over current knowledge
If you ask someone about the implementation details of a specific technology, you will only get a good answer if they have worked with it in the past.
Sometimes you need someone with expertise with a specific technology, but most of the time you hire people that can adapt to different environments.
So let’s say that the candidate has worked with JWT and you ask them to implement an auth solution; they’ll probably give you a correct answer. But does this tell you anything about their ability to implement any other solution?
And what if they have never had to build an auth solution from scratch? How much stress would this bring to them? Would this be a good assessment of their engineering skills?
By asking the candidates about problems they have actually faced, you can minimize the false positives/negatives that your process inevitably creates and put them in a less stressful environment to reason about engineering problems.
In the end, what you are looking for is passion, impact, curiosity, and depth of knowledge, not knowledge about a specific problem. As we always say: good engineers can prescind from specific technologies concepts.
The Technical Challenge
These days, it’s common knowledge that the algorithmic challenge doesn’t really work in most jobs but also giving a real- life problem can present some challenges, specifically related to boilerplate code and time.
It is frequent to have to deal with big projects at home to pass the technical step of the interview funnel, and this presents a huge disadvantage for people that have families or any other non-work related obligations/passions.
If we also consider the time spent for the initial setup of a project (from folder and file structure to external libraries and configurations etc) that is mostly useless to the outcomes of the test, this often becomes a huge effort for people that normally “underperform” by not spending enough time to deliver the project at the requested “production” level of quality.
Most companies completely miss the point of a coding challenge and expect the candidate to bring the same level of quality of a production environment while thinking about abstractions, decoupling,testing everything, implementing complex logic and thinking about scalability, all with a 5 line specifications document.
It is no surprise that lately, most senior engineers refuse to spend time doing coding challenges.
There are a couple solutions to this problem. You can simplify the coding challenge so the candidate can do it in a hour (but this doesn’t help with the more senior engineers or it still ends up being algorithmic centered) or, you can focus on simulating a more real- life task: starting with an existing solution and asking the candidate to improve it (refactoring or solving a technical limitation) or implementing/adding a functionality.
By starting with an existing codebase or a system, you avoid the blank page panic that can happen during the initial phase of the interview, you give hints on what you are looking for, create a task that really shows the candidate’s reasoning process and design pattern knowledge, and is the most realistic scenario you can provide to an engineer so they can show their skills.
Start a trust-based relationship
An important aspect to take into account in interviews is the candidate’s expectations about the position and the company. To ensure the success of a process, which includes the signature of the contract and the actual experience of the candidate once in the company, it’s also important to provide all the information about the environment, the responsibilities of the position, the phases of the selection process, and the salary conditions.
In this way, we ensure we provide the full information to the candidate, allowing them to decide if they want to continue with the process and avoid an unsatisfactory experience for both the candidate and everyone involved in the process if there’s a blocker that could have been identified early.
Another important point is to decide who is going to interview the candidate. It is important that the interviewers have different roles within the team, thus we’ll obtain a broader picture of the candidate, limiting the bias and presenting a more diverse understanding of the candidate skills, but also giving the chance to the candidate to understand the different parts of the organization they are going to join.
Conclusion
Ultimately the real secret ingredient to fix the hiring process is having empathy with the candidate and trying to provide a safe and comfortable environment for them to maximise their chances of showing their knowledge and potential.
My recommendation? Focus on growth potential. In the end, we hire people for who they are and for what they will become!
In Fever we care a lot about psychological safety and creating a good experience since day 1, starting with the interview process.
We have a lot of open positions (really, a lot) as we are growing in every department. Join us in our adventure, we can’t wait to get to know you!
