Hiring outside your expertise: a founder's guide.
You're a marketer. You're hiring a developer. Every CV lists the same frameworks, you can't read the code that would settle it, and your interview questions aren't fooling anyone. Here's the way out.
Founders hire role-by-role, which means almost every hire is someone's first hire in that discipline. The developer hiring their first marketer, the designer hiring their first sales rep, the operator hiring their first engineer — at a small company, hiring outside your expertise isn't the exception. It's the default.
And it fails in a predictable way. Not because founders are bad judges of people — because they're asked to judge the wrong thing. You cannot evaluate Kubernetes experience you don't have. What you can evaluate — with no domain knowledge at all — is whether a specific claim survives specific questions. That shift, from judging expertise to verifying claims, is the whole method.
Why the usual approaches fail
Keyword matching
When you can't evaluate substance, you fall back on surface: does the CV say React? Does it say "led"? Every candidate knows this, which is why every CV in your inbox says exactly those words. Keyword filters rank writing ability, not ability — and the polished CV that clears your filter was often polished precisely because it had to be.
Borrowed question lists
The "top 20 developer interview questions" you googled have been googled by your candidates too. Generic questions get rehearsed answers; you end up grading preparation and confidence, two things that correlate with interview skill, not job skill.
Gut feel
With nothing testable to hold on to, the decision drifts to rapport — who you enjoyed talking to. That's how confident generalists beat quiet specialists, and how bias gets laundered into "culture fit". It's also indefensible the day someone asks you why a candidate was cut.
The principle: verify claims, don't judge expertise
A CV is a set of claims. "Led the migration to Kubernetes." "Cut p99 latency from 800ms to 120ms." "Grew organic traffic 10×." You cannot judge whether those were done well — but you don't need to. You need to find out whether they were done by this person, and three kinds of questions do that in plain English:
- Mechanism — "What did you actually change, and how did you measure the improvement?" People who did the work describe the messy middle; people who watched it describe the outcome.
- Ownership — "Which part of that project did someone else own?" The fastest honest-answer generator in interviewing. Real owners answer instantly and specifically.
- Decisions — "What was the rollback plan if it failed halfway?" Anyone can recite what happened; only the person who carried the risk can tell you what would have happened instead.
Notice that none of these require you to know Kubernetes. You're not grading the technical content of the answer — you're grading whether a concrete, coherent, first-person account exists at all. Vague claims survive keyword filters; they do not survive three specific questions in a row.
A worked example: marketer, hiring a developer
Sara's CV says she led a Kubernetes migration. The interview prep of a founder outside their depth looks like this — it's the note we've all written:
1. Tell me about your Kubernetes experience? (too generic)
2. Why did you migrate? (she'll just say "scale")
3. Something about pods???
Anchored to her own claims instead, the same interview becomes:
1. Walk me through how you scoped the migration and what your rollback plan was if pods failed.
2. Which workloads did you migrate first, and what was the reason for that order?
3. The CV says the Staff engineer was involved — what was your actual ownership?
You still can't evaluate her Kubernetes choices. You can absolutely evaluate whether she scoped it, sequenced it, and owned it — or whether the story dissolves under the second follow-up. That's the judgment you were always qualified to make.
The part that stays yours
Claim verification doesn't outsource the decision — it clears the noise so your actual judgment has something real to work on. Whether this person communicates clearly, wants the problems you have, and works the way your company works: those are things a founder is better placed to judge than any specialist interviewer. The failure mode was never that founders have bad judgment. It's that their judgment was being spent on unverified claims.
Doing this for two hundred applicants
The method is free and works by hand — for a dozen applicants. The catch is that claim-based questions must be written per candidate, from their specific CV; that is the point of them. At real posting volume it becomes a week of work, which is why it usually doesn't happen and gut feel wins again.
That's the part BestHire automates: every fit applicant takes a 5-minute AI interview whose questions are generated in real time from your JD and their own CV claims. Every answer is scored against the claim it probed, with the transcript quote cited — and you get a ranked shortlist where you read the evidence and decide. It's the same method, run at scale: how it works.
Go deeper
- Role-by-role playbooks — what to test and ask when hiring a developer, marketer, designer, or sales rep
- Interview questions that test claims — the method in depth, with example sets
- A JD template that filters for you — because verification starts with testable requirements