Signals I look for when hiring: best practices explained

I've sat across from hundreds of engineers over the years—some brilliant on a whiteboard, others mediocre at algorithms but exceptional at building systems people rely on. The gap between "can they code" and "can they actually ship and grow with us" is where the real hiring happens. These are the signals I look for when hiring.

Clear communication of trade-offs

The first thing I listen for is how someone talks about decisions they've made. Not whether they chose PostgreSQL or MongoDB, but whether they can articulate why one mattered more than the other in their specific context.

A few years ago, I was interviewing an engineer who'd built a real-time trading system. Instead of jumping to "we used WebSockets for low-latency updates," he said: "We evaluated WebSockets, Server-Sent Events, and polling. WebSockets let us push data instantly, but they're stateful and harder to scale behind a load balancer. SSE was simpler but one-directional. For our use case—fast market updates but not bidirectional chat—we picked WebSockets with Redis pub/sub to share state across servers, accepting the operational complexity because latency directly impacted our traders' decisions."

That's the signal. He didn't just pick a tool; he weighed the trade-offs against the problem. He understood cost, complexity, and benefit.

When I ask "why did you choose X?" and someone says "it was the best," that's a yellow flag. When they say "it was the best for our constraints at that time," that's someone who thinks like a systems builder.

Look for this in conversations about:

• Consistency vs. availability in their data layer
• Monolith vs. microservices scaling decisions
• Caching strategies and their consistency implications
• Testing trade-offs (unit vs. integration vs. E2E)

Ask follow-ups: "What would you do differently now?" "What did you learn the hard way?" The engineers worth hiring will have changed their minds about something important.

Curiosity about the problem domain

I've noticed that the engineers who stay engaged and grow fastest aren't the ones who just implement tickets. They're the ones who ask about the business. Not in a resume-padding way, but genuinely.

I once hired someone for a ride-hailing platform. Three weeks in, they asked: "Why do we accept ride requests when the driver is already at capacity? Shouldn't we close the queue?" That question led to a two-hour conversation about surge pricing, driver earnings algorithms, and customer wait times. They weren't being asked to own that problem, but they cared enough to understand it.

This curiosity shows up in hiring conversations as questions about:

• Your biggest business problems, not technical ones
• Why you built things the way you did (product-wise)
• What metrics matter most to your company
• How their role connects to revenue or user experience

Someone asking "what are you trying to optimize for?" is already thinking like they own the outcome. That's someone you can trust with ambiguous problems.

Red flag: They never ask about the domain. They're just looking for a job, not a mission.

Ownership stories from past work

I don't care about individual contributions or impressive titles. I care about scope and how they handled it.

The signal I'm hunting for: "I owned X" followed by a real story about what broke, how they fixed it, and what they learned.

I asked a candidate about their proudest recent work. They said: "I refactored our authentication service from a custom JWT implementation to OAuth 2.0 with OIDC. We had a security audit flag our token refresh logic, and I spent a week understanding the OAuth spec, evaluating libraries, and planning the migration to avoid breaking mobile clients."

Notice what's in that story:

• A real problem (security audit finding)
• Ownership beyond just coding (understanding the spec, evaluating, planning)
• Handling downstream impact (mobile clients)
• Specificity (what exactly broke, how they solved it)

Compare that to: "I worked on our auth system." That's not an ownership story; that's a role.

In an interview, ask:

1. "Tell me about a time something you shipped broke in production."
2. "What was the scope of that?" (Did they own the fix? The communication? The prevention?)
3. "If you could go back, what would you do differently?"

Ownership candidates will have multiple stories where they took on something undefined and moved it to solved. They'll also be honest about what they'd do better.

Comfort saying 'I don't know'

This is the one that separates people who can grow from people who will plateau.

An engineer who says "I don't know, but here's how I'd figure it out" is someone I can unblock problems to immediately. An engineer who bluffs or stretches a tangential experience to cover a gap is someone who'll spend three weeks shipping something fragile.

During an interview with a senior engineer, I asked about his experience with Kafka. He'd used RabbitMQ but not Kafka. Instead of pretending, he said: "I haven't used Kafka, but I know message queues well—I'd need to understand your throughput, ordering requirements, and whether you're doing log replay. That shapes whether Kafka even makes sense here." He then asked clarifying questions about our use case.

That's not a weakness—that's a strength. He's self-aware about his actual knowledge and immediately thinking in the right frame.

People uncomfortable saying "I don't know" also tend to:

• Not ask for help until things are broken
• Avoid pairing or code review
• Blame external factors instead of taking ownership
• Make overconfident architectural decisions

Watch for this in interviews through questions like: "Tell me about something you realized you were wrong about" or "What's a technology you avoided learning and regret?"

The best answer includes humility, curiosity about what they missed, and a plan to fill the gap next time.

Common mistakes

Mistaking confidence for competence. Some people are just good talkers. I've learned to separate "sounds smart" from "has actually shipped." The signal is specificity: can they tell you the exact error message they saw, the exact line of code they changed, the exact meeting where they decided to pivot? Vague stories are a yellow flag.

Optimizing only for the resume line. A candidate who's been a "Senior Engineer" for three years but hasn't grown their technical depth or taken on harder problems is a yellow flag. I'd rather hire someone with a mid-level title who's been stretching.

Confusing technical knowledge with engineering judgment. Someone can know Go deeply but have poor judgment about distributed systems. Technical knowledge is learnable; judgment—knowing when to say "this is overengineered" or "we're not ready for this complexity"—is much rarer and takes time.

Not checking references thoughtfully. I don't ask "was this person good?" I ask: "Tell me about a time they surprised you with their judgment" or "When did they struggle, and how did they respond?" Former managers and peers will tell you the truth if you ask specifically enough.

Key takeaways

• Listen for trade-off thinking, not tool choices. Someone who can weigh costs and constraints is someone who will make good decisions under your constraints too.
• Curiosity about the domain predicts long-term engagement. Engineers who understand why problems matter stay longer and grow faster.
• Ownership stories matter more than titles. Scope, impact, and learning are the real metrics.
• Comfort with "I don't know" is a strength, not a weakness. It correlates with asking for help, learning quickly, and shipping carefully.
• Dig into specifics in interviews. Vague stories hide gaps in actual experience.
• Hire for judgment over knowledge. Knowledge is abundant; judgment takes years and experience to build.