Your first engineer will write the rules everyone after them follows
Your first engineer sets how things are built, decided and hired for. Hire for judgement, not a stack match.
By Macro Merge · · 5 min read
The short version
- 1Your first engineer sets the defaults: how decisions get made, what “done” means and who gets hired next.
- 2Hire for judgement about trade-offs. A stack match is the easiest gap to close later.
- 3Before you search, write down the decisions this person will make without you in their first six months.
Most first-engineer job descriptions are copied from a bigger company. Five years of experience. A list of frameworks. “Strong communication skills.” “Ownership mindset.”
None of it says what the job actually is. And the job of a first engineer is unusual, because they don't just build your product. They build the way your company builds things.
The first engineer sets the defaults
Whatever your first engineer does in their first six months becomes “how we do things here”. Nobody decides this. It just happens.
They'll choose the tools and the hosting. They'll decide how code gets reviewed, or whether it does. They'll decide what gets written down, how releases happen and what “done” means. When you hire the second engineer, they'll help interview them, and they'll be the person the newcomer learns from.
That's why this hire deserves more thought than a job title and a stack.
Six months in, their habits are your company's habits.
What you're really hiring for
Judgement about trade-offs
Early-stage engineering is a series of trade-offs made with too little time. Ship it now or make it solid. Build it or buy it. Fix the flaky thing, or build the feature your biggest customer wants. A first engineer makes dozens of these calls a week, mostly without you.
You want someone who can name the trade-off, make the call and tell you what they gave up. “Good enough for now, and here's when it won't be” is the sentence you're listening for.
Comfort without structure
There's no tech lead to ask, no product manager writing tickets and nobody reviewing their code. Some excellent engineers do their best work inside a well-run team and find this miserable. That isn't a flaw. It's a different job. What matters is whether they've done well without structure before, and whether they want to again.
Explaining decisions to non-engineers
Your first engineer will explain technical decisions to you, to customers and to investors doing diligence. They need to do it without jargon and without condescension. If you're a non-technical founder, this matters even more, because you'll make decisions based on their explanations.
Taste in tools
Not the newest tools. The boring, reliable ones a small team can run without being woken at night. Ask why they'd choose something, and listen for reasons about your situation rather than about what's popular.
An eye for the next hire
They'll shape who joins next. Someone who has helped hire before, or at least has a clear view of what a good colleague looks like, makes the second and third hires much easier.
What matters less than you think
- An exact stack match. A strong engineer gets productive in a new framework in weeks. Judgement takes years. If you have to choose, choose judgement.
- Famous company names. Engineers at large companies often do excellent work inside systems they didn't design, with a lot of support around them. Some thrive without that support and some don't want to. The logo on the CV won't tell you which.
- Years of experience. Five years maintaining one system and five years building three products from scratch are very different experiences with the same number.
- “Full-stack” as a label. It means something different to everyone. Ask what they've actually built end to end, and what they handed to someone else.
Write the role before you write the post
Before you search, answer three questions in writing. It takes an hour and can save weeks.
- What has to be true in six months? Outcomes, not tasks. “Customers stop reporting outages.” “We ship a feature a week without the founder reviewing every line.”
- Which decisions will they make without you? Architecture, tools, hosting, what to fix first, who to hire next. The longer the list, the more senior the role.
- What won't they do? No managing people for the first year. No mobile app until next year. Saying so up front attracts people who want this job, not a different one.
The seniority and the title follow from these answers, not the other way round. If the list of decisions is long and includes hiring, you're looking for someone who could grow into leading engineering. Describe that path honestly instead of offering a CTO title to win a candidate. Titles are hard to take back.
How to interview for judgement
Give them a real trade-off from your company. “We have two weeks. We can fix the payments flow that fails a few times a week, or build the integration our largest customer has asked for. What do you need to know before you choose?” Good candidates ask questions before they answer. Weaker ones pick an option straight away.
Ask what they wouldn't build. “Looking at our product, what would you leave alone for the first three months?” Restraint is a skill.
Ask about a decision they'd make differently now. Everyone has one. Listen for specifics and for honesty.
Have them explain something to a non-technical co-founder. Can they make a technical choice understandable without talking down?
Prefer a short, realistic task to a puzzle. If you set a take-home task, keep it to a few hours, make it look like your actual work, and consider paying for it. Strong candidates are usually employed, often serving notice. Respect their time.
If you aren't technical yourself, borrow technical judgement for one round. We've written about interviewing engineers when you're not technical.
Red flags worth taking seriously
- Wants to rewrite everything in week one, before understanding why it was built that way.
- Can't explain why they chose a tool, beyond popularity or familiarity.
- Asks nothing about your customers or the business. Your first engineer needs to care what the code is for.
- Has only ever worked where someone else made the calls. Not disqualifying on its own, but ask directly how they'd handle deciding alone.
Practical notes for Indian startups
Plan for notice periods. Experienced engineers in India commonly have notice periods of one to two months, sometimes longer. Build that into your plan from the start. See planning a hire around notice periods.
Explain equity clearly. For a first engineer, ESOPs are often part of the decision, and many candidates have never held them. Explain vesting, what happens if they leave and what the grant could realistically be worth, in plain words.
Be honest about the hard parts. Being the first engineer is hard: on call by default, few people to learn from, plenty of ambiguity. Candidates who hear that before the offer, and still say yes, tend to stay.