Ben Writing

Hiring Is a Craft: Here is How We Learned to Do It Better

We once rushed a hiring decision. The candidate looked sharp on paper, answered questions smoothly, and even tossed in a few buzzwords for good measure. A few months later, we realized something: they couldn’t break a problem down, they only danced around it.

That moment forced us to rethink how we hire. Here’s what we’ve learned since then, lessons that now shape every interview, every code review, every reference check.

Lesson One: The Screen Is Where It Begins

We now start every screening with a simple goal: find out how they think. A strong candidate doesn’t just know the answer, they deconstruct the question. When we ask them to explain something complex, we listen for clarity, not jargon.

We also pay attention to the small stuff. Typos in function name? Inattentiveness during a call? These signals often reflect deeper habits. Detail orientation is not optional, it’s predictive.

But there’s nuance. Some candidates overthink, spiraling into unnecessary complexity. Others lack the confidence to say “I don’t know.” We’ve learned to favor those who stay grounded, who speak plainly, and who don’t try to outshine the problem.

Lesson Two: Code Doesn’t Lie

When it comes to code samples, we don’t just read, we investigate. If a candidate claims to be up to date with new technologies, we check GitHub. Have they built something outside of work? Have they tried, failed, iterated?

We’ve also grown wary of the “cargo cult” programmer, the one who mimics good practices without understanding them. Their code might look fine, but it lacks intention. And software without intention is fragile.

Lesson Three: Interviewing Is a Two-Way Mirror

At the start of every interview, we neutralize our posture and tone. No smiles. No frowns. Just space. It’s surprising what people reveal when they aren’t trying to impress someone.

We ask a few key questions that have served us well:

  • “What would you change about your last project?”
  • “What’s the weirdest bug you’ve encountered?"
  • “What do you love or hate about AWS or GCP?”
  • “What’s been the highlight of your last five years?”

These aren’t just prompts, they’re reflections. The answers show us what matters to the candidate and how they frame success, failure, and learning.

Lesson Four: Always Check References (But Ask the Right Questions)

When we call a reference, we ask just one question:
“If this person wrote software to control an elevator, would you ride it?”

The answer is often less important than the pause. A delayed response, a cautious tone, it tells us volumes.

What We’ve Learned

Hiring well is not about spotting brilliance. It’s about seeing patterns, how someone thinks, how they explain, how they handle the unknown. Over time, we’ve built a system that works, not because it’s perfect, but because it’s intentional.

We write job descriptions like we write code: clearly. We run interviews like we run systems: observably. And above all, we hire the way we’d want to be hired, fairly, thoroughly, and with respect for the craft.