Hiring Software Engineers

As I launch my consulting practice, I feel the need to put on paper methodologies that will be useful for me and my clients. I figure I might as well experiment with turning choice topics into a blog post. I’m currently helping to hire for a martech/big data client, so here’s an outline that I’ve walked my client through.

Let’s (hopefully) state the obvious: people are the most important asset for a company, so it makes sense to invest a good deal of time and effort to get it right. I’ve interviewed hundreds of people: mostly software engineers, but also a mix of product managers, engineering managers/directors, data scientists, and various senior positions (VP and above) in marketing, sales, operations, and even finance. I love hiring people. I often think of myself as a coach, and whenever you get a chance to bring someone new into the team, it’s an opportunity improve. A well functioning team is different from a collection of individuals, an attribute commonly called emergence. A good team has the right balance of many different attributes: experience, skills, risk taking, leader vs supporter, introvert vs extrovert, EQ…. I want to outline a methodology to help you hire, but I often find reasons that I need to break from methodology to hire the right person. It’s hard to codify a process for complex judgements like trustworthiness, character, values, balance of skills, and what you’d pay for a unique candidate opportunity. We can barely scratch the surface on those complexities in our ever so brief period of judgement, so let’s make the most of it. Outlined below is a guide, not a rulebook for hiring software engineers. But it’s easy to see how you can modify it for hiring in general.

See yourself as a coach

1. What disposition do you need? You likely already have in mind what skills this person needs to have, but what kind of person would round out the team? Do you have a junior team that needs mentors/leaders? Or a senior team that needs people to mentor? Do you have lots of leaders and need more supporters? The value of a supporter on a team is so often overlooked in a traditional workplace that disproportionately rewards narcissism and a supporter can be the oil that keeps the team running. As you start interviewing this will change as you are presented with attributes you, or others in the interview process, didn’t think of. Less important that you get this right out of the gate, and more important that you start thinking about what your team really needs and evolve with the interview process.
2. Intro narrative. Tell me what the company and team does. I’m an engineer, get me excited about the position. If you can’t get excited about the position, you’ve got deeper problems than a person to hire. Hiring is a sales/marketing job. Know your product (company/team) and your customer (engineering candidates). You’re looking for people who are intrinsically motivated, so what’s going to drive a person to this job: the mission, opportunity to learn, work with a talented team, or career advancement. If a candidate isn’t interested in an intrinsic qualities of the opportunity early in the process (you’ve got to sell it first), it’s a good filter. Plenty of people just need a job or looking to get more salary, and you need to weed them out best you can before you get to the team. In addition to being a filter, you want to stand out from the other job recs candidates are reviewing so make it sizzle.
3. Needs vs wants. The needs list becomes key to the interview process. You are trying to validate that they: can write OOP/FP code in atleast one language, can collaborate in a team, know difference between pets and cattle, show a propensity for continual learning, or whatever it is. The needs section becomes your requirements for hiring. Do you really need someone that has experience with Go, or do you want to see they have experience with a procedural language. Do they have to have experience with Databricks, or do they just need to have experience w/formating and querying columnar data? Specific skills are too often the focus, and you risk ruling out a more qualified candidate (ie best person for the team). I love software engineers cause they are good at learning. Drop them into a domain and they’ll learn the business context, a new language, a different cloud platform… I always prefer a software engineer that has has a bent towards a specialization like infrastructure, data engineering, front end, or services development vs a Terraform, Snowflake, React focused developer. Don’t just put tech skills here, you want to hire for character too.
4. Iterate on on the job description. Be sure to ask individuals on the team what they think they need and to review the first draft of the job description. Ask your peers for feedback. This is where the process starts to involve the broader organization and you need them engaged and involved. Interviews are an organizational acceptance and recognition to modify their ranks, and this step 1 of that social construct. People are busy, and you need to respect their time, but sometimes they need a reminder of how consequential a good or bad hire can be. When others see how organized you are about your process and how much you care, it makes them care more.
5. Who needs to interview and how many interviews? Having a process for interviewing is key. An unstructured process turns into a bull session and invites unwarranted bias. Do I like this person vs is this the right person for the job. You should have your list of questions you want to ask in an interview, and you should ask that others have theirs. Bonus for interview collaboration on who’s asking what question. Again, be sure to make this a test of job needs first, wants second. The questions involved can be an art, but some of the technical questions are greatly aided with an upfront code test.
6. Take home code test. This should take roughly 2 hours and serves a few purposes. First, you need to know that someone can code. You’d be surprised (or maybe you wouldn’t!) how someone with a good resume and a grasp of buzzwords can fool even the most veteran. I like the code test to be really simple, ie no algorithm work and to be somewhat relevant to your domain. Second, you can use this test during the interview to delve into deeper topics like multithreading, distributed processing, CI/CD…
7. You should have a quick 30 minute phone screen. Many companies use HR or a recruiter to do this. As a hiring manager I like to do this myself for 3reasons: 1) hiring is super important and no one knows what you need more than the hiring manager 2) I need to decide if I should be in sell or screen mode quickly 3) I want to be as efficient with the interview’s team time as much as possible. Often you’ll get a candidate that is super qualified technically or someone with a great disposition and you need to turn on the sales charm. In a competitive hiring market, I want to be a highly involved, high touch hiring manager. This will require alot of your time and you may need to consider reprioritizing your current workload. Same goes for your team. Hiring takes time and you need to make room for it now, otherwise you’ll be forced to later on (because of a bad hire or inability to hire). During the phone screen you are giving your quick sales pitch on why this position and company are cool. You also, want to weed out things like salary, H-1B status, location, or any other basics before wasting the interview teams time.
8. (Nice to have) An application tracking system. I like this to stay organized with applications and to see where my traffic is coming from. Most job sites require that you pay to post. To optimize where you spend, it’s nice to see campaign metrics on applicants. This also helps to make sure you follow up quickly with candidates. It’s almost a rule that most companies are horrible at communicating with applicants which really sucks for candidates. And it gives you a bad reputation.
9. The actual interview. Group interviewers appropriately and don’t have too many people. Once I saw someone put an entire team of 10 people in a single interview. It was a disaster as you can imagine. I like no more than 4. When you set up the interview time, leave 10 minutes at the end for people to write down their feedback. Don’t skimp on this, it’s important. Make sure everyone writes down their impressions. Ideally they’ll send them to the hiring manager right away, but otherwise I tend to clean up notes after before meeting with the all involved in the interview. The process of written feedback can take a hiring process from ok to great.
10. Bring everyone together to review a recent round of interviews. Ask for their summary and candidate notes to be sent out before this meeting. This process is very insightful. The things that different people pick up on are invaluable and writing this down makes for a very productive meeting. (Again, you’re being respectful of people’s time). While all this seems like a lot of work, I find people are very engaged in this process and it helps to build/strengthen your company culture as you talk through values and needs. Speaking of values, if a company is clear on its values, I’ve really enjoyed interviews that ask questions to demonstrate those values. Ask everyone to put a candidate into one of 4 camps in addition to the feedback from the interview: strongly recommend to hire, recommend to hire, don’t recommend to hire, strongly don’t recommend to hire.

Expect this process to be iterative. I’ve taken mid level roles to senior roles in the process and vice versa. I’ve rewritten the job description and needs vs wants many times for a single position. The process is cathartic for you and the team. Because the process evolves, I like to start with candidates that may be less appealing on paper first. You don’t want to blow your shot on a rockstar because you weren’t ready. It might go without saying, but referrals should carry alot of weight. The interview process is just a pinhole view into whether a person is a good fit and good to work with. Someone that’s actually worked with a person holds alot of weight. So much weight, in fact, that at times that recommendation will supercede my ‘needs’ in the job req. This process is simply a guide and serves a tool to aid the most important thing of all: judgement and intuition of a hiring manager.