Hiring Your First Developer When You Cannot Assess Developers
You cannot judge the code, so judge everything else — and build in the safeguards that make a wrong hire survivable.
Hiring someone whose work you cannot evaluate is genuinely uncomfortable, and the usual advice — 'do a technical interview' — is unhelpful when you are the one who cannot assess the answers. The situation is manageable, but not by pretending you can judge the code.
What you can assess
- Explanation. Ask them to explain a past project to you specifically, as a non-technical person. Someone who cannot is either unclear in their own thinking or uninterested in yours, and both will cost you.
- Questions asked. Strong engineers interrogate the problem before proposing solutions. Someone who starts designing before understanding will build the wrong thing efficiently.
- Trade-off reasoning. 'It depends, and here is what it depends on' is the answer you want. Certainty about a problem they have just heard is a warning sign.
- Honesty about limits. 'I have not done that, here is how I would find out' is a strong answer and a rare one.
Getting help with the part you cannot do
Bring in a trusted senior engineer for one technical conversation and one code review of the paid task. A few hours of an experienced person's time is the cheapest insurance available against a hire who writes plausible-looking code that becomes unmaintainable in six months. This is the standard we hold ourselves to; what well-built means spells it out.
Structural safeguards
- The repository is in your organisation's account from day one, with you as owner. Non-negotiable.
- Every access and account is in the company's name, not a personal one.
- Documentation is part of the definition of done, so knowledge does not live in one head.
- A second pair of eyes on the code, even part-time, from month one. A solo developer with no review is a single point of failure in every sense.
- 2-3 days of paid trial work
- 1 external technical reviewer
- day 1 repository ownership
Frequently asked questions
Should the first hire be senior or junior?
Senior, if you cannot evaluate the work. A junior developer needs guidance you cannot provide, and the gap shows up as technical debt that is expensive and invisible until it is not.
Contractor or employee?
A contractor is a reasonable start — faster, reversible, and often available at a seniority you could not hire full-time. Move to employment when the work is continuous and you need someone who accumulates context rather than delivering scoped pieces.
More on this topic: Growth & Strategy.
Keep reading
Want this built for your business? See what we do.