Skip to content
Dana Lawson

Artwork: Micha Huigen

Hiring technical talent: An exercise in clarity, patience, and preparation

The two-way experience is as much about technical skills as it is about team fit.

Photo of Dana Lawson
Netlify logo

Dana Lawson // Senior Vice President, Engineering, Netlify

The ReadME Project amplifies the voices of the open source community: the maintainers, developers, and teams whose contributions move the world forward every day.

Hey there manager! So you just got your headcount approved and have a hiring goal. You want to ensure the candidate is successful when they join your organization, and that you can attract and retain the BEST talent. But how do you assess if the person shares your company values and has the level of technical acumen you need for the role? Where do you even begin?

It all starts before the first touch

Before you think about the manager screen, ensure your job posting and recruiting team understands your career level benchmarks. Your talent partners won’t be experts in engineering, and that’s OK! The interview loop should be robust enough to test those initial screenings—this is just step one. The same career rubric you use to assess your existing talent during your internal performance cycle should align with how you consider potential talent. Ensuring your talent team understands your levels and can generally speak to them makes for a better candidate experience and helps streamline the pipeline. 

Next, review your job postings to tell a “factual” story of the skills and values important to your organization. Don’t oversell or be overly specific. Too often you see a laundry list of “requirements.” Or worse, someone is “sold” a job that isn’t what they expected after they start, and you lose a lot of energy and money that you can’t get back. Consider whittling down the job description to the essentials, and keeping it wide open with no hard limits. 

Let’s take the hypothetical requirement of “eight years of Ruby.” Are eight years of Ruby that important? Maybe. However, you’ll have a wider pool of candidates if you use more neutral and open language. Instead of posting a hard requirement, consider something that allows for flexibility, such as “Experience developing production-level Ruby,” especially if you need to hire multiple people in the same role. This will give you flexibility when you screen and assess the candidate level (Senior vs. Staff engineer, etc.). It will also help you attract a wider range of applicants: Studies have shown that URM and Women candidates won’t apply if they don’t meet all the listed requirements.

The hiring process is more than you evaluating the talent; the talent also evaluates you. Joining a company and a team is a bi-directional relationship. In addition to reviewing the technical requirements for the job description, it’s also a best practice to focus on your company values and culture. People want to work in an inclusive and diverse environment where they can show up and be supported no matter how they walk through life, and your job posting should demonstrate those same values. Be mindful of the language you use in your job description and ensure it isn’t loaded with “bias” language. Many great tools are now available that will scan your job descriptions for inclusive and neutral language, such as textio, or free tools like idealrole.comdealrole.com/. 

Consider whittling down the job description to the essentials, and keeping it wide open with no hard limits. 

Interview time!

Great! The job descriptions are up, and you have a healthy screened pipeline. It’s time to take this interview to the next stage. In this day and age, most interviews have some remote elements. If your team only recently went digital, your interview process should be overhauled to reflect the nature of the remote working environment. 

Can you still do a whiteboard exercise? Yes, there are plenty of digital whiteboarding tools. But before you pick one out and implement it as a replacement, take the opportunity to ask yourself: “What value does this exercise bring?” “What important technical skills does the exercise assess?” “What soft skills should the candidate demonstrate during this exercise?” Write down what success looks like for the exercise. 

I’ve never been a fan of the pass/go technical exercise challenge. As a hiring manager, you should ensure you’re fair and balanced when assessing technical talent. Relying on a single test to evaluate all candidates isn’t necessarily fair. If you’re hiring someone just starting out in their career, you should tailor the technical interview to demonstrate what you would expect from their level. For instance, if they’re straight out of college, they might have not shipped code to “production,” but have delivered on other projects. As an effective engineering manager, you should be mindful of the composition of the team you have, or the team you are building, and fill the gaps accordingly. 

Once again, go back to your engineering levels rubric and use your benchmarks from the behaviors and skills for that assessed level. Also, ensure you mine for the skills and gaps that will positively contribute to the team’s needs. Maybe you already have a group of technically deep engineers in a specific area, and you need someone with more breadth. 

When you approach your technical interview, be human-centric and again think about what you’re looking for from this step, and how you can attract the candidates you want. Most people look for a new job while they have a current job, or have other life commitments, and the world is chaotic enough. Speaking as a working mother, there is no easy way to find time for a four-hour technical interview take-home test after a long day working and mom-ing! 

As an effective engineering manager, you should be mindful of the composition of the team you have, or the team you are building, and fill the gaps accordingly. 

Diversity and inclusion are essential, and should be reflected not only in the job posting but throughout this process. I encourage managers to use take-home exercises as a delta for talking points rather than a pass/fail test. Why? Because you can get deeply skilled engineers who can crush code, but it’s not the only thing that matters in most cases. How they communicate and work with others is equally as important. Again this isn’t to say that there’s no value in the technical exercise. Instead, it should be used as another tool in the interview process. If you do leverage take-home exercises, be mindful of what matters when reviewing the results, and time box the exercise.

You can also have an in-depth technical interview that’s just a conversation instead of a pass/go asynchronous take-home exercise. A technical discussion can tell so many things about the candidate and give them a view into the team they might join. If your candidate has a portfolio of projects or OSS contributions, this is a great way to curate a meaningful technical interview. For instance, if you’re hiring a Ruby engineer with public contributions, ask them about the project. Pick a section of the example they provided and go deep. This would cover what depth they have as a programmer. Then get into problem-solving—learn how they approached the problem, what role they played in solving it, and the steps they took in the development lifecycle. This will help you understand how they work with others, collaborate, and move past impediments. 

When interviewing, especially for a digital-first team, the other skills and behaviors I look for are excellent communication abilities, a growth mindset, and a strong desire to work with a team. After all, development is a team sport and the collective power of a team will always be stronger than any individual. Technical interviews should incorporate the opportunity to demonstrate collaboration, problem-solving, and cooperation.

After all, development is a team sport and the collective power of a team will always be stronger than any individual.

Tying it all together

This brings me to the last point: Invest in interview training. Most teams and companies have an interview process but don’t necessarily have interview training. Just as I suggested educating the talent team on the engineering levels, you should also ensure that your interview team understands what to look for holistically, and how to curate an experience for the interviewee. 

Try not to overutilize interview scripts or checklists to prepare the interviewer. Just as you might pair on code, consider pairing on interviews and ship to learn. Teams feel more engaged and connected when they have the opportunity to participate in hiring. It’s crucial to make sure that they’re prepared and have had the chance to shadow before you add them to the interview cycle. If you use a technical exercise, have the interviewer go through it, ask about their experience, and role-play and incorporate their feedback in the process. 

Hopefully, you can use these tips to find your next great teammate and, as a manager, create a curated and excellent candidate experience that sets everyone up for future success. As the world evolves and tech changes, keep going back, collecting feedback, and iterating. You’ll know when your technical assessment and interview cycle are humming along because you hired the right person for the right job, and they’re thriving!

Hey! I'm Dana. Over the past 20 years, I have been on both sides of the technical hiring fence as an engineer and a manager. As I have grown my career to manage managers and lead engineering organizations, I have seen what feels like a million different ways to analyze potential new technical talent. Spoiler alert: It’s not just about the tech skillz. Currently, I'm the Senior VP of Engineering at Netlify and I have built and managed engineering teams at GitHub, Heptio, InVision and others.

About The
ReadME Project

Coding is usually seen as a solitary activity, but it’s actually the world’s largest community effort led by open source maintainers, contributors, and teams. These unsung heroes put in long hours to build software, fix issues, field questions, and manage communities.

The ReadME Project is part of GitHub’s ongoing effort to amplify the voices of the developer community. It’s an evolving space to engage with the community and explore the stories, challenges, technology, and culture that surround the world of open source.

Follow us:

Nominate a developer

Nominate inspiring developers and projects you think we should feature in The ReadME Project.

Support the community

Recognize developers working behind the scenes and help open source projects get the resources they need.