Little did I know going in that I was about to give my TED talk.
It all started innocently enough - a reference check for one of my mentees who’s been in my orbit for four years or more. I connected to the Google Meet thinking that a full 30 minutes would leave a lot of dead air after “if I were starting my own thing, I’d be taking them with me.”
On the other side of the screen was the terrifyingly young CTO of a local startup. But as I started talking to this “baby CTO,” two things immediately revealed themselves.
First, all of my excuses for not starting my own thing already, were just that - excuses.
Second -
Nobody teaches startup CTOs how to hire.
Sure, there’s plenty online from Big Tech types - senior engineers talking about the thousands of interview loops, LeetCode grinds, and whiteboard exercises they’ve sat through. But that’s recruiters feeding the pipeline, teaching grads how to get hired.
And on the other end of the spectrum, you’ve got retiring tech VPs giving sweeping, thousand-person-org career advice.
What I haven’t seen is anything that teaches founders how to pick their first 10 engineers.
What began as a simple reference check quickly devolved into the usual series of terrible, predictable interview questions with a reference twist. “How do they deal with conflict?” and other formulaic nonsense we all say without thinking. Every new interviewer starts here - echoing the bad questions they’ve endured and that one Business Insider listicle they Googled. We ask the questions we think we’re supposed to ask.
So after quickly addressing the reference - “They’re amazing” - I pivoted:
“If you’re hiring them, here’s the sort of profile I’d be looking for next to complement them.”
The conversation turned into an impromptu coaching session.
After nearly a decade of building and leading engineering teams - most of it in fast-moving, zero-safety-net environments - I’ve developed some strong opinions. Over time, they’ve settled into deceptively simple, battle-tested, and instantly actionable frameworks.
They were born out of startup chaos, but they’ve proven just as useful for any technical leader responsible for hiring - whether you’re a new CTO, a first-time engineering manager, or a big-corp team lead assembling your first real team.
And they all ladder up into three simple rubrics I’ve returned to again and again:
- The Three Questions keep you honest
- Hell Yeah or No keeps you decisive
- No Sevens holds everyone accountable
Rubric 1 - The Three Questions
All interview questions fundamentally boil down to three things.
If a candidate fails any one of them, it’s a hard no.
I’m not one to bury the lede, so here they are up front:
- Can they do this job?
- Do they want this job?
- Can I work with them?
1. Can they do this job?
This doesn’t mean “do they tick all the tech-stack boxes.” It means:
- Do they have foundational competence?
- Can they solve problems?
- Can they reason through ambiguity?
- And crucially: can they grow into what’s needed, not just what we remembered to put in the job description?
Think of this as the minimum viable bar: someone who can build things, not just talk about them. Startups need problem solvers. They need people who are already doing The Most Important Thing™, even when there isn’t a crafted quarterly roadmap and perfectly groomed backlog.
Over-indexing on tech stacks is a trap. Smart people learn fast, and your tech stack is going to change just as fast. At this stage you want T-shaped people - broad exposure across technologies with a proven track record of going deep on one or two when it matters.
What you’re really screening for are BS artists who’ve keyword-stuffed their résumé with whatever’s popular on Hacker News.
2. Do they want this job?
Capability ≠ motivation.
Just because someone technically can do the job doesn’t mean they want to. They might need a job. They might be fleeing a bad company. They might be running from a terrible boss. Or maybe they’ve sized you up as a future unicorn and want equity.
I don’t expect anyone to show up with a passionate love affair for B2B invoicing solutions. But I do expect pride in craftsmanship.
Pride matters more than domain knowledge.
Most new interviewers intuit this, and will try to probe with the classic:
“Why are you looking to leave your current position?”
Congratulations! You’ve just thrown them a no-win situation.
If they show candor, you’ll worry they’re negative.
If they dodge, you’ll worry they’re deceptive.
Instead, ask something that reveals desire - something that invites real reflection:
- “Tell me about a time you cared too much.”
- “What’s your biggest regret from your last job?”
- “How did you know it was time to leave?”
Bad answer:
“I can’t really think of anything, but I guess I just care too much and often find myself working weekends.”
Good answer:
“Well, there was this one time… we’d made a deadline commitment, and I spent three weekends rewriting the pipeline because I couldn’t let it ship with known issues.”
Gold.
Now you can dive into pros and cons, discussion of tradeoffs, communication strategies, what they’d do differently next time, and lessons learned.
Open questions like this feel awkward the first time you ask them - embrace it. Personal growth (on both sides of the table) happens when you sit in these awkward moments. Build rapport early, then let the silence do the work. Big questions take a moment to answer.
If you see a flash of emotion before they self-censor? Excellent.
Jump on it: “What was that? Tell me what that was!”
If someone chooses to share hard truths with you - especially ones that make them vulnerable - you’ve learned something valuable.
You want someone who’s choosing you, not someone escaping something else.
3. Can I work with them?
The final - and most important - question.
If they can do the job and they want the job, what remains is the interpersonal piece:
Can I actually work with you?
Startups run on high trust and low ego. They move fast. They break. They recover.
There’s no room for god-complexes or prima donnas.
Use the Airport Lounge Test:
“If we got stranded together for four hours because our flight was cancelled, would that be okay?”
Would you spend the time laughing?
Open your laptop and quietly coexist?
Or spend the entire time grinding your teeth waiting for merciful release?
You don’t need a twin or a soulmate.
You need safety, honesty, reliability - someone you’d trust at 3 AM during an outage.
TL;DR - The Three Questions
- Fail one → stop.
- Pass all → proceed.
- That’s it. This single framework prevents 90% of hiring mistakes.
Rubric 2 - Hell Yeah or No
I originally came across this one from Derek Sivers on the Tim Ferriss podcast. It was meant as a decision filter for life, but it absolutely shines in hiring.
If it’s not a HELL YEAH, it’s a no.
If it’s not a full-body, emphatic
“Hell yeah, I can’t wait to work with this person,”
then it’s a no.
Worse than a “no” is a deflection:
“I think they’d be good… just not for my team.”
If you wouldn’t take them today - not a year from now - in your own team, it’s a no.
Every time I’ve tried to override my gut with logic, it’s come back to bite me.
Every “they were fine” has been the one where I’m bringing in legal counsel.
During my time at Boeing - down the street from AWS and Microsoft - we interviewed a lot of engineers trying to escape the always-on-call life. From a résumé perspective, they were dream candidates. But I realised I was giving prestige résumés way too much leeway. If I tossed them a softball and they fumbled, I assumed I must’ve phrased it badly. If anyone else did that, it would’ve been an immediate hard pass.
My brain wanted their prestige by association.
My gut knew better.
Eventually I stopped reading résumés altogether.
My recruiters knew exactly what I wanted.
They sent me smart people - and I focused on fit.
Can you break this rule? Sure.
At a giant company with low urgency.
At a startup?
Never.
Rubric 3 - No Sevens
Once you’re past your first hires, you’ll inevitably end up with panel interviews. Panels invite groupthink. Groupthink is powered by politeness and fence-sitting. The whole point is to mask accountability.
You need a way to cut through the noise.
“On a scale of 1 to 10, how would you rate them?
You can’t use 7.”
Seven is the refuge of indecision.
Seven is the answer of someone who spent the last ten minutes checking email.
Seven is “meh,” “nice enough,” and “probably fine.”
Seven allows the illusion of acceptability while preserving plausible deniability. Neither committing nor offending.
My father used to say:
“The worst thing you can say about someone is that they’re nice.”
Nice means beige. Forgettable.
Nothing memorable at all.
If they’re a 6 → below average. Why are we hiring below average?
If they’re an 8 or 9 → a standout, obvious yes. What are we even debating?
I’ve used No Sevens to crystallize the thinking of entire leadership teams.
It cuts through the fog instantly.
Hiring is the most dangerous thing you can do
This is why these rubrics matter.
When a company feels growing pains, the temptation is to lower standards “just to get past this hump.”
Those standards never come back.
Worse: mediocre hires become the ones hiring the next generation - and suddenly those 6s start looking “not so bad.”
And this isn’t just a startup problem - big companies suffer from this too, just more quietly.
A mediocre hire is never “just for now.”
Once they’re comfortable, they’ll never leave.
And truly bad hires?
They destroy teams and take your star players with them.
Think I’m exaggerating? Here’s what I walked into when I returned from parental leave. I was asked to sit in on a new team lead’s meeting - “just observe and give a few tips.” What I found was a team on fire. Eight weeks into a twelve-week engagement, the codebase had been rewritten twice - both times over a weekend. The senior dev had been sidelined. The data scientists were dismissed as incompetent.
The entire team was quietly interviewing and days away from resigning.
One hire.
Total collapse.
That is the cost of getting it wrong.
Just gimme a checklist
- Use The Three Questions in the first interview: Can they? Do they? Can I?
- If it’s not a Hell Yeah, it’s a No - keep your standards high
- Use No Sevens for second opinions - force decision-making
- Never hire from panic or fear
- Slow hiring won’t kill you
- Bad hiring absolutely will
Wrapping it up
Hiring is hard. Really hard. You’re making decisions that can shape your company for years - based on impressions formed in minutes. It feels insane and disgustingly human.
These frameworks aren’t foolproof, but they give language and structure to what used to be gut feels. They’ll let you hire with conviction instead of fear. They help you push past politeness and force clarity - preventing the “maybes” that keep you up at night.
Future posts will cover team composition, the pros and cons of juniors versus seniors, and how to scale your org sustainably.
If you’ve made it this far and you’re a new CTO navigating your first hires, feel free to reach out - you don’t have to figure this out alone.
By
