In short
You cannot assess deep domain skill you do not have, so stop trying. Define the problem the hire must solve in terms you can defend, borrow a credible technical assessor for the depth check, and use your own interview time on reasoning, communication and how the person handles being wrong — all of which you can judge without the domain.
Key facts
- Do not fake
- Depth assessment in a field you do not know
- Do define
- The problem, the constraints and what good looks like
- Borrow
- One credible assessor for the technical deep-dive
- You judge
- Reasoning, communication, honesty about limits
The common failure
Founders hiring their first specialist outside their own field usually do one of two things: defer entirely to whoever sounds most confident, or run an interview that tests vocabulary rather than capability.
Both produce the same outcome — a decision made on presentation. The fix is to separate what you genuinely can assess from what you need someone else for.
A workable process without domain expertise
1. Write the problem, not the technology list
Describe what has to work, the constraints it must work within, and how you would know it was working. You can write this without knowing how it will be built.
2. Get the shape of the role checked
Ask an advisor, investor-network specialist or your recruiter whether the role as written is one person or three, and whether the seniority matches the problem.
3. Find one credible assessor
A technical advisor, a friendly senior practitioner or a fractional expert. One person who can hold a real conversation in the domain is enough.
4. Split the interview
They run the depth check against agreed criteria. You run reasoning, motivation, communication and how the person works with others.
5. Ask for the explanation twice
Once at their level, once as they would explain it to a non-specialist stakeholder. The gap between the two is genuinely informative and needs no domain knowledge to read.
6. Write down the criteria before you meet anyone
Without them you will compare candidates against each other rather than against the role, and confidence will win.
Questions that work without domain expertise
These test judgement and honesty rather than vocabulary.
- Walk me through the hardest technical decision you made on your last project, and what you traded away.
- What did you get wrong on it, and when did you realise?
- What would you need to understand about our system in the first month before proposing anything?
- Where does your expertise stop, and who would you want alongside you?
- How would you explain this problem to somebody funding it but not building it?
- What would make you tell us an approach was not going to work?
Who assesses what
| Assessment area | Who | How |
|---|---|---|
| Domain depth | Borrowed technical assessor | Structured deep-dive on real past work |
| Problem reasoning | Founder | Trade-off discussion on your actual constraints |
| Communication | Founder | Two-level explanation of the same problem |
| Working style | Founder plus a future colleague | Behavioural questions with evidence |
| Practical fit | Founder | Scope, autonomy, tooling and what the first six months hold |
Common questions
- Can we hire a senior specialist before we have anyone technical in that field?
- Yes, and many startups have to. The safeguard is a borrowed assessor for the depth check and written criteria set before interviews start.
- Is a take-home exercise a fair substitute for a domain assessor?
- Only if someone can evaluate it properly. An exercise nobody can grade tests the candidate's patience rather than their ability, and strong candidates with options often decline it.
- How do we avoid hiring the most confident person in the room?
- Write the criteria first, score against them independently before discussing, and give weight to candidates who describe their own mistakes precisely.
Turn this into a brief
Answer six short sections and you have a technical hiring brief you can share internally or send straight to us.
Open the hiring brief builderAny percentages or figures shown in this article are illustrative examples used to explain the model. They are not quoted rates, market benchmarks or salary data.