What Does an Engineering Hiring Manager Look For?

So you're in the job hunt, or at least you've begun thinking about greener pastures elsewhere. Naturally you want to land an excellent gig at a worthy company, working with a great team, and so on. How to prep for the mating dance with these companies?

In this series of Ruff Guides from Underdog.io, we will analyze what engineering hiring managers are actually looking for.

It's mostly the tech, right?

Typical job titles and job descriptions make it look like hiring managers will mostly be interested in your experience with specific tech.

‍

We've all seen this sort of thing on job boards: a big bowl of tech keyword soup. But we can't conclude from this that hiring managers are most interested in your tech keywords. Here's the thing -- many applicants for a given role will list most or all of these same keywords. And they will do so even if they merely have passing familiarity from doing some tutorials or a short course. Or if it was someone else on the team who actually did the work and they were just along for the ride.

So there's a thorny verification problem. How to efficiently sift through a stream of candidates to find who's not BS-ing? To get at a working answer, let's think about what all that tech is for in the first place.

The lens of business problem solving

Ultimately, companies hire programmers to deliver software that solves more problems than it creates. The higher-impact the problems you can solve, the more valuable you are.

Conversely, knowing all the languages and tools in the world is pointless if you can't apply them to solve problems.

Hiring managers are looking for engineers who have a demonstrated track record of solving problems with tangible business value.

Offer clear, quantified summaries of how the tech you used related to delivering that value. It's harder to B.S. when numbers are involved, so it's reassuring.

Good and bad examples

Let's put this business problem-solving lens into practice on some sample resume snippets.

Sample #1

Original

Led the development of the tags feature by implementing the front end as well as working with designers and backend developers.

Better

Tech lead of 3 engineers on the item tagging feature to increase discoverability. I owned building the front-end in React/Redux. By 3 months after launch, tagged items were trading 20% more often than untagged items.

Sample #2

Original

Developed primarily on the backend for client facing sites by designing RESTful APIs for consumption by our sites.

Better

Built ReSTful APIs that powered client-facing sites for over $2M in accounts. Refactored one-off APIs into a common infrastructure, reducing time to delivery by ~20%.

Sample #3

Original

Wrote unit, integration, and acceptance tests for code.

Better

Increased test coverage from 22% to 85%. Introduced golden tests to reliably test complex API responses.

As you can see, the general pattern here is to be more specific about the nature of the problem being solved. This is especially effective when you can show quantified results. Here are the snippets again, this time with the problem highlighted:

‍

You can see how a hiring manager's imagination would be more stimulated by the improved versions. They can envision hiring you and getting similar results, for their business.

Your turn

Try taking another look at your own resume items, and see if they vividly convey the business problems that you've solved over the years. Keep in mind the problems you've solved and the hiring manager's point of view.