By Nick Nathan in
LeadershipOf all the things that I have done in my professional career hiring engineers is easily the hardest.
A lot has been written about how to find a job, how to craft a great resume, how to interview effectively etc. and even though I'd been through the hiring process several times as a candidate much of this experience was completely useless when it came time for me to be the hiring manager. Recruiters, hiring software, candidate sourcing tools and screenings tests can all help but they can also increase the complexity of the process. It's easy to get overwhelmed, I definitely was.
When hiring there are a common set of hiring phases no matter what your company looks like and you'll have to make some important decisions at each step.
There is no right approach at each phase but instead you'll have to decide what's going to work best for your team given your needs, available resources and hiring constraints.
When sourcing candidates you are generally going to have four options available to you:
Each channel has pros and cons and most likely you'll use a combination of a few.
This approach is by far the cheapest and easiest way to source a large number of resumes and applications. If you have a limited budget and can spend the time sifting through resumes this can be a great option. It also has the benefit of ensuring that all candidates are actively looking for a new job.
The main disadvantage of this approach is that you have no control over the quality of applicants and will have to spend a lot of time reading through resumes.
When taking this approach it is critical you invest time up front in writing a great job description / listing. It is, after all, an advertisement. It may be obvious to you why a candidate would want to work at your company but you have to remember that unless you work for a brand name tech company your listing will be the ONLY information available to the candidate about the role. Otherwise all they'll have to go off of is your marketing website.
Reaching out directly to candidates is the cheapest way to find candidates that best fit the role you're looking to hire for.
Unfortunately it's also very time consuming and you will have to sell candidates on your team and company. Most engineers get tons of canned recruiter emails so like any sales outreach the more personalized your communication the better your chances. The best emails will talk specifically about how the role can benefit the candidate as opposed to just bragging about your company.
You also won't know if the people you're reaching out to are looking for a new job so you'll inevitably end up wasting a lot of time contacting uninterested people. There are also some services which aggregate interested candidates but still require that employers do the outreach. These are typically paid platforms but they can be useful to help speed up the search.
Many companies, especially for early hires or smaller organizations, will source exclusively from their own networks. This has obvious advantages since whoever is referring the person has a lot more information about that candidate and they are putting their reputation at risk by referring them.
Recruiters can be used either by hiring a full time employee to do a lot of the work described above on your behalf, or by hiring an outside service to refer you candidates. Generally this is the most expensive option but can save a lot of time. There is a lot of variation in the cost and quality of these services and so you'll just have to find the best given your constraints.
Assuming you now have a pile of resumes sourced from various channels you'll have to figure out who to contact. If you're lucky you'll have budget for a recruiter who can do this for you but if not then the question is who do you call for a phone screen?
Generally it's pretty easy to eliminate bad resumes e.g. resumes with tons of spelling errors, sloppy formatting, obviously exaggerated experience or completely irrelevant experience. Where things get tricky are the resumes on the margin. Here's what I recommend you look for:
The biggest mistake that hiring teams make when reviewing resumes is relying too much on finding candidates that have listed experience in your specific stack. Good engineers will understand technical concepts at multiple levels of abstraction and will be able to apply their knowledge to new contexts and domains.
For example, if you're limiting your search to Python developers you may miss out on someone with mostly Ruby experience who could be an amazing fit. Also it's important to note that your recruiter will have a much harder time making these connections given their limited technical experience.
Just because a candidate knows some technology your team happens to use doesn't mean they'll be a better hire. In my experience, candidates with strong general engineering knowledge and the ability to learn quickly will almost always outperform weaker candidates with more domain specific technical experience. This is especially true for younger or more junior engineers.
After reading through enough resumes you should have a good sense of who you want to screen. In my experience picking out good resumes isn't the hardest part and usually you're going to have only a handful that stand out to you. Things get a little bit tricker during the phone screen.
If your recruiter is doing phone screens they generally won't be able to help much in terms of a technical review however they can be very useful in confirming some critical information which would otherwise waste your time. For example:
If you do not have a recruiter you'll want to make sure to answer some of these questions upfront. There is nothing worse than wasting your entire team's time interviewing a great candidate only to find out their minimum acceptable salary is far above your price range.
In addition to covering the basics you'll want to validate that what they said on their resume is true by asking relatively easy questions specific to their experience. You'll want to ask another group of technical screening questions specific to whatever skill sets you are hiring for that approximate the minimum necessary knowledge. Finally, you're looking to verify the candidates verbal communication and language skills.
Common phone screen mistakes include:
You'll be able to get a lot of information from a phone screen if you shut up and listen. You generally don't have a lot of time so you'll want to try and get as much detail as you can while still being friendly and polite. The worst thing is to hang up and realize you don't actually know whether or not you want to interview the candidate.
A popular substitute for the phone screen is the automated technical screen. Usually this involves sending the candidate a timed online test or take home project which they must complete before moving on to an in-person interview.
These tests have the benefit of ensuring that candidates demonstrate strong baseline competency. Another advantage is that all your candidates will be asked the same questions so you can easily benchmark performance and compare them. It also involves very little effort on your end except to review the results and you may find candidates with weaker resumes that end up performing very well on the tests.
The downside to using this approach is that you may turn away more experienced or in-demand candidates who don't want to waste time completing coding challenges or take home projects. Therefore you may be limiting your applicant pool to more junior candidates who struggle to get noticed otherwise but are willing to invest the time.
Similarly, coding challenges are somewhat limited in their ability to accurately evaluate whether or not a candidate will be a good employee and generally only tests a specific type of engineering skill or ability. Therefore they really should only be used as a screening mechanism. Some companies offer more robust tests that try to evaluate for softer skills however these can also be pricier.
Interviewing is complex and nuanced. It's also very subjective and expensive in terms of your team's time. I've been fortunate to both lead and sit in on dozens of interviews over the years so I've seen a lot of good interviews and a lot of bad ones as well.
Before starting the process it's critical to assemble everyone who will be interviewing candidates to review what the role is and what you're looking for from each person. Everyone on the hiring team is busy and especially if they're not the hiring manager they may not have taken the time to read the job description. The better everyone on the hiring teams knows what they should be testing for the better that time will utilized.
You also want to make sure that everyone on the hiring team understands your expectations for the candidate. A common mistake is that individuals on the teams aren't aligned on how much experience the candidate should have and may end up rating a candidate far higher or lower than is appropriate. Remember, the success of a candidate always depends on your relative expectations for that candidate. No one is objectively good or bad.
Every hiring team is going to take a different approach but based on my experience hiring for engineers across a wide variety of roles here's the main things that I found help to ensure you're making the best use of your time.
The most important step which I find most hiring teams miss is spending a little time documenting what are the most important skills and attributes you want the candidate to have. This seems obvious but unless you clearly articulate what it is you need from the candidate and the role then you cannot design a good interview.
Once you're clear on both the technical and non-technical skills and attributes you can come up with a set of questions to evaluate those specific requirements. Most interviewers just ask random questions without having a clearly defined goal. This is important because every candidate will answer questions very differently and you need a way to compare their responses against a common rubric.
Have questions on a gradient of difficulty from easy to very hard. The goal is to find the edge of the candidates knowledge. For this reason you'll want to prioritize questions that allow for multiple solutions or approaches. Questions with binary answers give you less information because either the candidate knows the answer or they don't.
Focus on conceptual knowledge, problem solving, and mental flexibility. The best questions test a candidate's understanding of a particular concept as opposed their exposure to specific instances of that concept. Pick the most important concepts for your domain and team and find ways to tease out how the candidate has applied that concept in their own experience or via a test. Pick bigger, broadly applicable concepts where possible.
Finally, make sure to get your team's input. You are not the only person who will be working with this potential hire and therefore it's important to give others the opportunity to meet them. You won't always be paying attention to the same things as they will so the more perspectives you have the more likely you are to catch serious red flags.
Here are some common pitfalls which waste time or prevent you from getting the most accurate picture of the candidate.
Question design is more art than science and it's very difficult to come up with the right blend of easy and hard questions. The key here is that if your candidate answers all your questions correctly you haven't learned as much as you could. This will become a problem because that candidate cannot be compared against any other that also answered all your questions correctly. Similarly, if all your questions are too hard you won't really know anything about what the candidate does know.
Another common mistake is wasting too much time on any one question. If a candidate is struggling, you want to give them enough time and hints to work through a particular problem but you should also set time limits so that you can always change course and ask easier questions to get closer to the edge of their knowledge.
Many engineers tend to feel more comfortable asking technical questions however technical competency is not the only important attribute to test for. You need to identify what non-technical attributes really matter to you and your team and ask targeted questions to test for those attributes. Even if a candidate has the technical chops to be a great individual contributor you need to know if they'll be a good fit for your engineering team. This is not some canned abstract thing like "culture fit" which usually get's pawned off on some non-engineering interviewer. Every interviewer should be looking for things like drive, creativity, openness, ability to work in a team, communication skills, humility, confidence etc.
We are all guilty of assuming that what you know is "common knowledge" and if someone else doesn't know it they're stupid. It's very common pitfall for interviewers to get caught up in asking very specific technical questions which most candidates get wrong but provide little insight if the candidate gets them right. There is some merit to asking esoteric questions as a way of identifying highly knowledgeable candidates but the problem with this approach is that it's really inefficient. You may pass on great candidates who happened to forget some specific syntax they could just google in two seconds.
No candidate will be impressed by your questions. The point of an interview is not to make you feel smart, it's to test the candidate's knowledge.
After the team has completed the interview process I highly recommend you have everyone give the candidate a score on a four point scale in response to the statement:
"I would hire this candidate."
Note that there is no middle option because you want to force your team to provide a negative or positive review. Similarly, make everyone rate the candidate blindly. The last thing you want is for the team to try and evaluate the candidate based on what they think the boss wants or based on the general sentiment of the room.
After you have completed the hiring process take the time to document all the questions you asked so that other members of your team will have access. It's painful to have to re-create new questions every couple of months. More importantly, you should always be striving to improve your process and if nothing is recording you won't be able to build upon past experience.
Hiring is hard for a couple reasons:
Probably the biggest reason why hiring is so difficult is because the stakes are so high. Who is on your team plays a critical role in your success. Great people can take your team and your company to the next level and mediocre people will slow it down. The smaller the company the larger the impact of every additional hire.
Who you bring onto your team is a highly personal decision in the sense that you'll be spending a lot of time working with this person and the relationship you build together matters a lot. It matters both in terms of your ability to be productive together and to form a good working relationship and also because of the impact this person will have on the culture of the team. Are they going to contribute positively? Will they be open, supportive, thoughtful and kind to their peers? Or will they be negative, critical and stubborn?
Just because you're hiring a new team member doesn't mean that all your other responsibilities go away or the day to day operations of the business can be put on hold. It's also rare that you're continuously hiring meaning that hiring events are somewhat sporadic. As a result all the process and documentation around hiring, interview scripts and questions etc. have to be refreshed and the work required to complete the hire is stacked on top of everything else you have to do.
Hiring engineers is challenging because the things that make an engineer an effective contributor are not easy to test for in a short period of time. Not only do you have to evaluate for existing technical knowledge and competency but you're trying to test for valuable intangibles like their ability to learn and emotional maturity. Technical competency is expected but it is the bare minimum required to do the job.
Suppose you've found a great candidate who you want to either interview or you want to make an offer. Well they too may have competing offers and salary requirements etc. which does guarantee that you would be able to hire them. Given budget constraints, time constraints and your candidate pool you may end up in the position of having to decide between hiring a sub-optimal candidate and losing the budget or not having badly needed help.
Unlike other day to decisions you make hiring an engineer is a very expensive decision. Not only do they typically command high salaries but it often takes a couple weeks to a couple months to train a new hire to the point where they are creating real value. Firing a bad hire after the fact can be equally time consuming and requires then that you go through the hiring process all over again, which is expensive.
Finally, hiring is hard because, if you're reading this, you probably haven't done it too many times before. You simply don't get that many reps and even if you have hired a few people it sometimes takes a couple months before you know whether or not you've made a good choice.
Hiring is hard and takes practice but it's critical to the success of your team and your business. Too often hiring feels like a distraction from the real work of building software but it is the foundation of all good software teams.
People are highly complex and you don't have a lot of time to focus on hiring in general let alone any one particular candidate. The better you can take advantage of the time you do have the more likely you'll be able to find people that can transform your business instead of dragging it down.
If you liked this then you might enjoy my newsletter as well! I send out occasional emails covering interesting ideas I'm exploring, content I've enjoyed, and useful things I've discovered on my journey to become a better human.