Blind Date: The Reality of Software Engineers Hiring Process

Can we get better at finding the right match?

I feel like we know each other for years

Have you ever been on a blind date? If you have, I am sure you remember the feeling of “what am I doing here?” during the date, followed by the “what was I thinking when I said yes” on the way home. I can hear you saying “some great love stories started with a blind date”. Yes, I know. But is blind dating an efficient way to find love?

Efficiency is a core concept in software engineering. We have sophisticated methods and fancy tools that helps us drive efficiently in almost every process. Hiring is an exception.

I assume we can agree that building a strong team is critical for our success and that hiring the right people is a core element in building a strong engineering team.

Somehow when it comes to our hiring process, analytical methods & efficiency are moved aside, and instincts & gut feeling based decisions kick in.

The situation doesn’t make more sense from the candidate's perspective. You are going to make a very important decision that will impact your career path. On a more immediate level, the decision you are about to take will define what you will be doing in the majority of the hours in which you are awake, and who are the people that you will be spending this quality time with.

Basically, both sides are looking for a good match. Each side has its own criteria for what a good match is, but the hiring process isn’t really tuned for providing confidence on the match criteria.

In this article, I will dive into this topic, based on ~20 years of experience I have both as a candidate as well as a hiring manager. We will begin by describing the desired match criteria, which is basically the signals that each side would want to get during the hiring process. I will then move to describe reality, meaning what usually happens and how far it is from satisfying the needs of both sides. Finally, I will try to imagine how a better world would look like, a world in which our first day on a new job won’t feel like a blind date.

Ruby on Rails?

What is the candidate looking for?

Meet David. David is a 32 years old software engineer. He has a computer science degree from a good university plus 6 years of pragmatic experience working as a developer. His first job was at a large enterprise, where he spent 4 years working on a B2B SaaS product. In his first job, David had a chance to work with experienced engineers and learn stuff he still considers as the foundation of building software the right way.

After 4 years, David felt its time to move on. He wanted to work for a smaller company where he believed he could make a bigger impact. He also felt his compensation was a bit low, and he was frustrated by it being driven by the company’s job leveling system, rather than by his actual performance (BTW: compensation of long-tenured engineers will be the topic of one of my next articles).

So David returned his badge, posted a nice goodbye message at LinkedIn, and moved on to his next challenge. He joined a small startup that was aiming to “change the world of eCommerce forever”. The CEO’s pitch made perfect sense (something with the word “democratize”) and David felt that onboarding a “rocketship” company as employee number 25 can’t be a bad decision. Especially considering the fact he was granted “10K stock options” of what will probably soon become a unicorn or even the next Amazon/Shopify/Some huge company with a typo in the name.

The reality of working at this small startup was very different than what David expected. He joined a team of 9 developers, all reporting directly to the CTO, who was also one of the founders. Everyone was too busy all the time, rushing to complete projects that David knew nothing about. Generally speaking, there was very little communication and cooperation in the team. Like his teammates, David was assigned to “lead” a project (he was also the only person working on this project). The context of the project and the business requirements were blurry, but he did get a very clear deadline of one month to “have this thing in production”.

The Architecture (Photo by Klara Kulikova on Unsplash)

David tried to get some context and learn the product by going into the source code, but this proved to be a bad idea because what he found there was a huge pile of spaghetti. Turns out that technology stack, architecture, and design patterns are not considered to be important here, or at least not as important as delivering features quickly. The one thing that the team was really good at was generating technical debt. These were just early signs for a much broader problem. It didn’t take too long until David understood that taking this job might have been a mistake. After almost 2 years of trying to make the best out of this situation, David finally decided that he must move on and find a new job.

This time, David decided to take a different approach to his job search. He created a list of the 12 aspects that are most important for him in the next job. For each position he will be interviewed, he will rate each of these aspects (on a scale of 1 to 10) based on signals collected during the hiring process. Here is David’s list:

1. Technology
2. Teammates
3. Direct Manager
4. Ability to Impact
5. Development Process
6. Learning Opportunities
7. Culture
8. Product
9. Company
10. Compensation
11. Work-Life Balance
12. Personal Growth Opportunities

Running away was easy; not knowing what to do next was the hard part

What is the hiring manager looking for?

Meet Sara. Sara is an R&D team leader in a successful SaaS company. Her team is responsible for building and operating an application for analyzing user behavior in web & mobile applications. This app is basically processing clickstream data of millions of users, transform this data into actionable insights, and offer those insights via a sexy web GUI as well as via a GraphQL API. Cloud-native, big data, AI-driven. As cool as it gets.

Like most teams in the engineering org, Sara’s team is structured as a feature team. The team she is leading contains 4 full-stack developers, 1 test automation developer, and 1 DevOps engineer. Based on next year’s strategic initiatives and budget plan, Sara got approval to increase the HC and add an additional full-stack developer to her team. Great news.

What would be a good hire? that’s a great question. Sara thinks about her current team. What kind of engineer would make us better? Of course, the dream is to bring in a 10x engineer that would boost the entire team, but that’s easier said than done. Like most team managers, Sara ended up building a match profile based on the people she currently has in the team. “It would be great if we can hire someone like Ben” she tells the recruiter. “He is a good coder, but more important, he is proactive and sincere”.

3 Types of Software Developers You Will Find in Every Team

Much like David’s list, Sara also has a list of 12 aspects that defines the developer that would be a good match for her team. For each candidate (Including our friend David), Sara is going to rate each of these aspects (on a scale of 1 to 10) based on signals collected during the hiring process. Here is Sara’s list:

1. Technical Skills
2. Team Player
3. Coachability
4. Passion to Make an Impact
5. Understanding of SDLC
6. Passion to Learn & Improve
7. Culture Fit
8. Communication Skills
9. Attention to Details
10. Responsibility & Ownership
11. Deal with Pressure
12. Potential to Grow

git clone? (Photo by Cleyton Ewerton on Unsplash)

What happens in reality?

The short answer is that reality sucks. Both David (the candidate) and Sara (the hiring manager) knows what they are looking for. They even have a rating system to measure each opportunity and find out whether it's a good match or not.

Amazingly, the two lists they created are almost a perfect reflection. So all we have to do is create a hiring process that will allow each of them to collect clear signals for each of the aspects in their lists. Sound trivial, right?

It turns out it's not trivial. In reality, most software engineers hiring processes that I have been part of (both as a candidate as well as a hiring manager) had at least 7 phases that involved at least 5 stakeholders from the hiring company:

1. Initial Screening: Done by a recruiter, based on the way she understood the match profile
2. Team Leader Interview: Technical interview done by the hiring manager
3. Technical Home Assignment: Explained and reviewed by the hiring manager & a senior developer/system architect.
4. Engineering Director Interview: Done by the hiring manager's manager
5. HR Interview: Done by the HR partner of the engineering org
6. Reference Calls: Done by HR & the hiring manager
7. Job Offer: Done by HR

This is the bare minimum. I have seen companies that had additional phases or that split the second phase (team leader interview) into multiple technical interviews. But the length of the process is not where the problem is.

The real problem is the lack of mapping between the different phases of the hiring process and the match criteria aspects each side wanted to validate.

On the hiring company side, it is not always clear on which phase, how, and by whom should each match criteria be evaluated. Most of the questions being asked during the different interviews aren’t crafted for getting strong signals on specific match criteria. I have also seen cases where the same question (“tell me more about that system you built in your previous role”) was asked by multiple people in multiple interviews, as well as cases in which the same questions are used for both junior and senior developers. At the end of the process, after these 7 long phases, the hiring manager hasn’t collected enough signals to evaluate the candidate on a significant number of the match criteria she has on her list.

The same problem exists on the candidate side. It’s often not clear on which phase of the hiring process should he get the data he needs for evaluating each of the different items on his match criteria list. In most cases, the expected outline of the hiring process isn’t clear. Many candidates (especially the less experienced) are trying to collect pieces of information being shared with them by the different interviewers along the process, plus stuff they read on apps like Glassdoor, and then try using those information fragments for building a complete picture of the job they are interviewing for.

Let me tell you a secret: this picture might not be a great representation of reality.

“A mistake repeated more than once is a decision” (Paulo Coelho)

What can we do to fix it?

That’s a tricky question. I mean, if there was a simple “one size fits all” answer, I guess we would all be adopting it already. Still, there are 8 common areas for improvement which I find both valuable and feasible:

1. Ownership: Having so many people involved in the hiring process creates an ownership problem. Specifically, there is a gray zone between engineering & HR. The way I see it, the hiring manager (the engineering team leader, who is going to be the direct manager) is the sole owner of the entire hiring process, from the minute the profile is defined, until the minute the contract is signed. All other stakeholders (recruiter, architect, engineering director, HR) should be synchronized by the hiring manager and provide their feedback to her. She owns the process and she is accountable for the outcome.
2. Planning: Each phase in the hiring process must have a well-defined objective. The objective of a phase should be defined by the set of match criteria (a subset of Sara’s 12 match criteria listed above) for which we need to get strong signals. The hiring process needs to be planned in a way that each of the match criteria will be covered in at least one of the phases. After each phase, the hiring manager must ensure that we indeed got strong enough signals for rating the candidate on the criteria that were planned to be covered.
3. Preparation: Come prepared for each phase in the process. This applies to both the hiring manager as well as to the candidate. On the hiring manager side: going through the candidate’s resume 10 minutes before an interview doesn’t count as coming prepared. The bare minimum is to check LinkedIn, Medium, and GitHub. You may find people you both worked with, as well as interesting projects that the candidate was involved in. That may drive some adaptation to the flow of the interview. The same is true for the candidate side: Spending 5 minutes on the company’s web site and 5 minutes on Glassdoor isn’t enough. Search for engineering blogs, public repos on GitHub, information about the tech stack on stackshare, and reviews about the product on G2.
4. Transparency: Be as transparent as possible. Create an environment in which the candidate gets as many details as possible as early as possible, and feels comfortable to ask for additional details in case you didn’t cover something that he considers as an important signal for one of his match criteria. It starts with sharing the outline of the hiring process itself: How many interviews? with whom? what is the purpose of each interview?. It then goes to sharing as many details as possible about the company, the team, and the specific position. In some cases, I would even offer a candidate to spend some time with a team member holding a position similar to the one we are hiring for. This is not an interview, but rather an informal conversation between people who may soon become teammates.
5. Personalization: Select the right questions for each candidate. I am not against having a fixed bank of questions and using them with multiple candidates, as long as the bank is wide enough and you can pick the right questions for the candidate you are interviewing. What do I consider “the right question”? typically I would go with questions that are either in a domain that the candidate was focused on in his past roles, or go to the extreme opposite and ask about domains he has no experience with.
6. Pairing: Interview paring is great. It’s not a 2 on 1 interview. I mean, there are 2 people from the hiring company in the room, but one of them is actually doing the interview and the other one is just an observer. The observer’s role is to carefully examine and document signals for the match criteria that were defined as the objective of that specific interview. Immediately after the interview is completed, the interviewer and the observer should discuss the signals that the observer documented, and rate the candidate accordingly. Pairing is also a good method for sharing interviewing knowledge and continuously tune & optimize the questions being asked.
7. Respect: Hiring involved a lot of pressure. For most people, a job interview is not a comfortable situation. This is especially true for software engineers. Treat candidates with great respect. They are professionals, and they are investing time and effort in this process. Respect mostly means efficient communication and direct feedback. Just as an example: after each phase, you must tell the candidate how long will it take for you to reach a decision, and make sure you (the interviewer) are calling him back to provide the decision. Not HR sending a cold email or something of that sort.
8. Measuring: It’s impossible to improve without measuring. Document every phase of the hiring process you perform. There are multiple systems for doing this (at WalkMe we are currently using Lever), but honestly, even a simple spreadsheet will be OK. Define a set of KPIs for what you consider a good hire. Usually, these KPIs should be related to the performance of the hired employee ~6 months into his new role. Doing this consistently will provide you with the data you need for analyzing and optimizing your hiring process.

“Now, I wanna dance, I wanna win. I want that trophy, so dance good” (Mia Wallace)

Conclusion

There is no other area in software engineering that has an impact to improvement ratio as hiring. The impact of good hiring is huge, the improvement over the last years is tiny. When it comes to hiring software engineers, we are still using almost the exact same methods that we used 20 years ago. It’s about time we start applying a professional state of mind for optimizing the hiring process, just as we do for optimizing our dev process, quality process, release process, etc.

The same applies to the candidates. You are investing so much time and effort in learning technologies and becoming a great engineer. How about investing some effort in improving the way you select your next job so that your first day won’t feel like a blind date?

We can all do it better, and the time to improve is now!