What Do I Look For When Hiring an Engineer?

Hei maailma! (“Hello World!” in Finnish)

Mercer Island, WA, October 2024 – Photo by Kevin Goldsmith

The newsletter on when to stop coding as your day job as a manager inspired some lively discussion, which was great. Just a reminder that in addition to contacting me directly, you can also reply on Substack, especially if you have a comment or question you think other readers will be interested in.

If you are new to the newsletter, please check out the archives on Substack. Of course, you can always buy the book.

About this newsletter

If you are new to this newsletter, here’s what makes it unique. Every two weeks, I share a chapter from my book It Depends: Writing on Technology Leadership 2012-2022, which Unit Circle Press released in March. These chapters are not in sequential order, but each one is a standalone piece. In addition, a podcast serializes the audiobook in order, released in the alternate weeks from this newsletter.

The Latest Podcast

The latest episode of the podcast is “Writing Useful Performance Reviews: Delivering the Review.” This is the last in the four-part series about performance reviews. I also discuss how career development and performance management work at the more senior levels of management (they generally don’t) and how you can drive your own continuing development if your manager isn’t supporting you on it.

You can get the episode at Apple Podcasts, Spotify, YouTube, directly via the RSS Feed, or wherever you get your podcasts (see pod.link for a more extensive list).

Drop me a line

I’m always eager to hear from you. If you have questions, want a signed copy, or want to say ‘hi!’, please email me at contact@itdependsbook.net. You can also share your thoughts on Substack or the various podcast platforms. Your feedback is invaluable, and I look forward to hearing from you.

About this week’s chapter

When deciding which articles to include in the book, I was a bit nervous re-reading some of my older articles. Would they hold up? I’ve learned a lot over the years and approach many things differently now. This article still stands up for me 11 years later. If you read the interview briefs I create for candidates I’m hiring today, you’ll find me still asking people on the interview loop to evaluate for the five criteria I discuss in the chapter.

While I discuss the things I look for in candidates, the requirements are all reasonably broad. I’m not looking for a specific version of these characteristics; I’m looking for broad evidence. I often see hiring managers posting about their “red flags” that instantly disqualify a candidate for them. Even failing to send a “thank you” letter to the manager following an interview loop is an automatic disqualification for some managers. While I admit that I had some of these rules in the distant past, I learned the error of my ways. Context and situation are always important. The book is called “It Depends,” after all.

If you have specific answers or behaviors you expect from the candidates you interview for your roles, it might be worth stepping back and re-evaluating how you approach your interviews. Are your questions about finding the best candidate for your team and company, or could there be some similarity or affinity bias in your approach to evaluating candidates? You may have been successful with your process in the past, convincing you that your approach was correct, but could it have been possible that some of the people you passed up might have made your team even more successful by bringing in more diversity of thought and approaches?

This chapter was also shared in the podcast on July 7^th, 2024.

This is chapter 15 of It Depends.

---

What do I look for when hiring an engineer?

Originally published on November 2nd, 2013

I don’t spend much time on Quora, but I came across the question: “What qualities should a software engineer have?” Anyone who has worked with me can tell you that I am pretty opinionated about this subject. So since someone wasn’t already saying what I would have, I decided to post an answer. Here is that answer:

Over the last couple of decades, I’ve interviewed hundreds of software engineers for my teams at Microsoft, Adobe, Spotify, and other places.

Over the years, I’ve honed in on a few things that I consider vital for anyone joining my organization. These are the kinds of things that I value as a hiring manager, of course. Others will have their critical criteria.

These are in rough priority order.

1. Pragmatism I don’t bother with tricky or difficult programming questions designed to test a corner of your knowledge or some trivia. Instead, I ask a dead simple question—something anyone could do. Then I complicate it. And complicate it again. And again. I look for the point where you can no longer adapt your first answer. I want to know that you will throw away your first answer when it no longer makes sense. You’d be amazed how many engineers will hack on something that will never work when they could throw it away and do something much more straightforward in a quarter of the time.

2. Interest Do you actually like writing code every day? Do you read programming blogs for fun? Do you work on your own coding projects outside of work? If this will be your job, I want someone overjoyed that they get paid to write software, not someone who’d rather be doing something else.

3. Attitude/humility I’ve worked with brilliant people who are jerks. For every inch they moved the product forward with their innovation or genius, they moved the project back two inches by being impossible to work with. I want someone who will improve the team, not someone who feels everyone “needs to do as they are told.” (Yes, an actual quote from a candidate.)

4. Intelligence Yeah, you do need to be smart. Writing software is part art and requires creativity, but it is also a lot about problem-solving and just sheer brainpower to figure out why this thing is crashing, but only on Tuesday when the moon is full.

5. Programming languages/domain experience I have worked professionally with a dozen or more programming languages. Some I don’t even remember anymore. While I have a lot of depth in some of them through years of experience, I have learned others as I need to in order to suit the project. I would prefer to see someone proficient in more than one language because that shows some breadth and a willingness to learn, but if you can code and are clever (see #4), you can probably pick up whatever language we are working in reasonably fast. I hire for the long term. If you're a good fit, we can take a bit longer to get you up to speed, similarly with domain experience. If you have an aptitude, we can teach you.

I do have a couple of caveats to #5, though: If I’m hiring for a senior position that requires domain knowledge, yeah, that is in the job requirements, so you need to bring that. However, you would still need to handle 1-4, in any case.

On languages, there is a significant caveat. If we’re doing C++ or C, you’ll need some experience there. If you’ve only ever worked with high-level, garbage-collected languages, bringing you up to speed will take too long. I’ve tried this too many times and realized that it usually isn’t worth the effort.

---

Thanks again for reading! If you find it helpful, please share it with your friends.

Buy on Amazon | Buy on Bookshop.org | Buy on Audible | Other stores