Hiring engineers is tough. Resumes all start to sound the same. Everyone “thrives in fast-paced environments.” And somehow every candidate is both a “team player” and a “self-starter.” Neat.
So how do you actually spot someone who will make your life easier—not harder—once they join?
I’ve hired a lot of engineers, and this is what I look for when talking to candidates. These aren’t vague vibes or buzzwords. This is the real stuff that makes someone great to work with—especially when the pressure’s on, systems are breaking, and the only thing more fragile than production is your sanity.
Let’s get into it.
Protip: Write a Job Description That Says Something
Before you even start talking to candidates, writing a great job description will make your life 1,000 times easier. I know it’s tempting to just reuse a template—but investing a little time up front will save you hours of frustration later.
If your job description sounds like it was spit out by a corporate jargon generator—
“fast-paced environment,” “dynamic team,” “rockstars only”—you’re not setting yourself up to win.
That kind of fluff attracts fluff. You’ll get a mountain of resumes with zero alignment to what you actually need.
Bad examples:
- “We’re looking for a passionate self-starter who thrives in a high-impact team.”
- “Must be a team player who’s also comfortable working independently.”
- “Familiarity with cloud platforms preferred.”
…Cool. So basically, everyone and no one qualifies.
Good examples:
- “We use Azure, Terraform, and GitHub Actions to manage infrastructure for our SaaS product. Experience with similar tools is ideal.”
- “Day-to-day you’ll be writing infrastructure as code, troubleshooting networking issues, and collaborating with devs during feature rollouts.”
- “We care more about ownership and communication than knowing every corner of our stack upfront.”
Be specific. What tech does your team use? What kind of problems will this person solve? What does success look like in 3 months?
Also—give your recruiter a short list of dealbreakers and screening questions:
- “Has the candidate worked in production environments?”
- “Have they owned a feature or system end-to-end?”
- “Can they explain CI/CD pipelines without getting lost?”
You don’t want to interview 18 people who think CI/CD is a seasonal Starbucks flavor. Set the bar clearly upfront and you’ll save everyone a ton of time.
What Real Experience Actually Means
Experience isn’t just “I used Kubernetes once” or “I dabbled in Terraform last year.” Real experience is doing something multiple times, in multiple ways—sometimes getting it right, sometimes screwing it up—and learning what works.
The best people bring a mix of scars and solutions. They’ve seen edge cases, made mistakes, fixed them, and remembered the lesson.
And while you probably want to avoid candidates who are job-hopping every six months, there’s huge value in someone who’s worked across multiple orgs. Why? Because they’ve seen different architectures, processes, and cultures. They’ve learned how other teams solve similar problems, and they bring that wisdom with them.
Think of it like a Dockerfile. Each job, each challenge, each screw-up and success—that’s a new layer added to the image. You want candidates who have depth. Who’ve built up layer after layer of real-world experience, not just someone who’s been stuck in one environment doing the same thing for ten years.
I’ll give you a personal example: I stayed at my first job for six years. Thought I had it all figured out. Then I joined a new company with a completely different stack and a totally new way of doing things—and I learned more in that first year than I had in the three years prior. That outside perspective was priceless.
So when you’re hiring, don’t just ask “What tools have you used?” Ask “What layers of experience have you built—and what did you learn from each one?”
Ownership Is the Real Superpower
Technical skills matter. Experience matters. But ownership? That’s the multiplier.
When you hire someone who takes true ownership of their work, your job as a leader becomes 10x easier. You don’t have to chase them down for updates. You don’t have to sit in every meeting or review every tiny decision. You give them context, a clear goal—and they run with it.
Ownership means:
- They ask the right questions up front
- They push through blockers (and escalate when needed)
- They don’t throw things over the wall
- They care—about quality, timelines, and outcomes
- They talk to the right people, ensure the code is tested, and double-check that it actually works
When someone truly owns their work, you can rest easy knowing they’ve got it handled. No guesswork. No micromanaging. Just progress.
This is so underrated.
I didn’t think it was a big deal—until I worked with someone who lacked it. Suddenly, I’m playing project manager, QA lead, and team babysitter just to get something across the line. It’s exhausting.
Ownership is the difference between “I did my part” and “I made sure the whole thing worked.”
Honestly, if I have two candidates—one with every skill but no initiative, and one who’s missing a few tools but clearly takes ownership—I’ll take the second one every time.
Because here’s the truth: Ownership scales. Babysitting doesn’t.
Use the Bank Account Test
Here’s how I think about experience and ownership (inspired by something Alex Hormozi said):
If I asked my 11-year-old daughter to go open a bank account—she’s smart, does well in school, and I don’t doubt she could figure it out eventually. But I’d have to explain every single step: what to bring, how to get there, who to talk to, what to say, what to sign, and what to do if something goes wrong.
Now if I politely asked my wife to do the same thing? She’d just nod, and the next day I’d have a bank account opened and a receipt on the kitchen counter. No drama. No reminders. It just got done. She is smart and has tons of life experience. This is no problem for her.
That’s the test I use when I’m hiring.
When I talk to a candidate, I’m trying to figure out: are they the kind of person who needs every step handed to them? Or are they the kind of person who can take a goal, ask a few smart questions, and make it happen?
If you’re hiring for a junior or mid-level role, of course you’ll need to do some teaching and hand-holding. That’s part of the job. But if you’re hiring for a senior or staff-level position, you shouldn’t have to handhold.
They should be able to:
- Ask a few smart clarifying questions
- Understand the context
- Own the work start to finish—without constant check-ins
The more experience someone has, the less you should have to tell them. Not because they know everything, but because they’ve done this enough times—in different orgs, under pressure, with different tools—that they’ve learned what actually works.
That’s the kind of experience that saves you time, lowers your stress, and raises the bar for your whole team.
Look for People Who Can Make Good Decisions (Not Just Follow Instructions)
A wise Jedi once said, “Only a Sith deals in absolutes.” Unfortunately, so do a lot of mediocre engineers.
But real software work? It lives in the gray areas. Trade-offs. Edge cases. Competing priorities. You need someone who can make good judgment calls—not just blindly follow a playbook.
Sure, we love documentation, runbooks, and clean requirements. But there will always be moments where something is unclear, or the right answer depends on weighing impact, risk, and timelines.
You want to hire someone who can say:
- “We could do it that way, but here’s the downside.”
- “This isn’t ideal, but it’ll unblock us today—and I’ll flag it for cleanup later.”
- “We’re seeing signs of load issues. Should we scale up now or investigate first?”
That kind of thinking only comes with experience and confidence.
Because look—anyone can follow Jira tickets like a robot. But the person who can see three steps ahead, make a smart call, and course-correct as needed? That’s the one who keeps projects moving and incidents small.
Good judgment is rare. If you find it, hire it fast.
And Yeah… They Should Probably Know Tech Too
If you find someone who takes ownership, communicates clearly, and makes smart decisions—you’re already in great shape. That’s the kind of person you can trust with big projects and sleep better at night.
But let’s not forget: they still need to know what they’re doing.
It’s not about memorizing every tool under the sun. The real skill is being able to think through problems, understand the trade-offs, and learn what’s needed to get the job done. Because no matter what, every project will involve something unfamiliar—new tech, new constraints, or new teams.
So yes, include a system design discussion or walk through some code together. Not to play “gotcha,” but to see how they approach problems, how they think, and how they explain their decisions.
That’s the real signal.
Because the best engineers aren’t just experts in today’s tools—they’re good thinkers who can adapt, learn, and still deliver solid results when the path isn’t clear.
Hire that, and everything else gets easier.
💡Liked this post?
Get real-world solutions like this in your inbox—join the newsletter.