Hiring When You Aren't the Expert

Dev Leader Weekly 129

Mar 01, 2026

TL; DR:

Start with the problem, not the solution
Define success in the role before writing questions
Hiring is imperfect -- iterate and build the skill
Join me for the live stream (or watch the recording) on Monday, March 2nd at 7:00 PM Pacific!

How Do You Hire When You Aren’t Even the Expert?

I came across two Reddit posts recently that both circled around hiring. Different scenarios, totally different contexts -- but my instinct for tackling both was the same. And I figured it was worth sharing, because I think a lot of people jump straight to “how do I interview for this?” when they should actually slow down and answer a different question first.

You can check out my full thoughts on this in the video below:

The Two Scenarios

The first post was from a CTO with six engineers who was trying to hire their first engineering manager. The comments were... not kind. A lot of people were like, “you only have six people, why do you need an EM?” Which, fair point on the surface -- but we don’t have enough context to know if that’s actually true. Maybe they’re growing fast. Maybe the CTO has other responsibilities pulling their attention away. Maybe they’re just trying to get ahead of the scaling pain before they’re drowning in it.

The second post was someone asking: “How do you hire or interview for a role that you don’t have experience in?” Someone on their team had left, and now they’re responsible for backfilling that gap -- even though they don’t have the skill set themselves.

On the surface, these look completely different. But the framework I’d use to approach both of them is identical.

Step Back and Ask: What Are You Actually Trying to Solve?

Before you even think about interview questions or job postings, I want you to pause and ask yourself -- what problem am I actually trying to solve here?

In the EM scenario, the person is presenting a solution (”I need to hire an EM”) without fully articulating the problem. And that matters, because the right solution depends heavily on what the actual gap is.

Are your direct reports not getting enough time and attention from you? Is coordination of deliverables falling apart? Is there not enough time being spent with customers and stakeholders? Each of those problems might point to a different hire. An EM, a project manager, or even a product manager could all be the right answer depending on what’s actually broken.

If you don’t know what’s broken, you’re optimizing for a job title, not a solution. And that’s a recipe for a hire that doesn’t move the needle.

Actionable Tip: Before writing a job description, write a problem description. One paragraph -- what is not working right now that this role is supposed to fix? If you can’t write that paragraph, you’re not ready to hire yet.

Defining What the Role Actually Looks Like

Okay, let’s say you’ve done that work and you’ve confirmed: yes, what you need is an engineering manager. Now what?

You need to figure out what you actually expect from this person in this role. Because “engineering manager” means wildly different things at different companies, different team sizes, different growth stages. The classic debate everyone loves to have: should EMs code?

My take: if you have a small team, absolutely -- find ways to contribute hands-on. When you’ve got six engineers, there’s a real case for the EM being in the code with the team. It doesn’t scale as the team grows, but at that size it often makes sense. The point isn’t whether they’re technical -- it’s whether the team benefits more from their hands-on contribution or their coordination and people work at that specific moment in time.

So you need to ask yourself: what are the core responsibilities I’m hiring for in the short, medium, and long term? And then structure your interviews around those things.

For example, if you’re hiring an EM at a small startup where you know they’ll be expected to code alongside the team, you’d better have a technical component in the interview. You need to know they can build software -- not just manage the people building it.

If you’re hiring an EM because you’re about to scale from 6 to 12 engineers and you know they’ll be spending a lot of their time recruiting and onboarding, the emphasis shifts. You’re probably less focused on their coding chops and more focused on their ability to build and grow teams, run hiring processes, and develop people over time.

The role definition drives the interview design. If you skip the role definition, you end up asking generic questions and hoping for the best.

When You Don’t Have the Expertise Yourself

The second scenario is a little more raw -- you literally don’t have the skill set being hired for. So how do you gauge a candidate when you can’t evaluate their technical answers?

Same starting point: what does success look like in this role?

Let’s say you need to hire an Android developer. Your team has never built an Android app. You don’t know Kotlin, you don’t know the Google Play ecosystem, none of it. How do you know if someone’s answer to your question is actually good?

Here’s the reframe I’d offer: are you going to know if their answers are good after you hire them? Probably not immediately either. You’re not going to suddenly become an Android expert the moment they sign the offer letter. So the goal isn’t to design interview questions that prove to you in the moment that this person is an expert -- you can’t do that if you’re not an expert yourself.

What you can do is think through what success in this role looks like, and then ask questions that surface the traits and behaviors that point toward that success.

In the Android example, if success means:

Going from zero to a published app
Actively sharing knowledge with the rest of the team
Owning Android security for the platform

...then your interview questions should probe for those things. Can they talk through how they’ve taught others on previous teams? Can they give examples of how they approached security decisions on a platform they owned? Do they have examples of leading a greenfield platform from scratch?

Actionable Tip: Write out three to five things that would make this person clearly successful in their role six months in. Now ask yourself -- do my planned interview questions actually tell me anything about those things? If the answer is no, redesign the questions.

This Is an Imperfect Process -- And That’s Okay

I want to be honest with you: this framework doesn’t magically solve the problem. Hiring is messy and imperfect, no matter how well you prepare.

What defining the role and the success criteria does is make sure you’re asking questions in the right direction. You might not nail the evaluation of every answer. You might misjudge a candidate. You might make a bad hire even after doing this work. But at least you’re not going in completely blind, asking generic questions and hoping someone impressive shows up.

And honestly -- hiring is a skill. It gets better with reps. The first time I had to hire for a role I wasn’t deeply familiar with, I made a lot of mistakes. But each time you do it, you get a better sense of what signals actually matter and what questions actually surface them.

The minimum viable step is knowing what you’re trying to accomplish. Everything else -- the specific questions, the interview structure, how you score responses -- you iterate on over time.

So if you’re in one of these situations right now: don’t panic. Step back, define the problem, define success, and then build the interview around that. It won’t be perfect. But you’ll be heading in the right direction.

Dev Leader Weekly

Discussion about this post

Ready for more?