A startup can need an exceptional engineer without needing a founding engineer. The useful distinction is the job you are asking someone to do: build within an existing direction, or help determine that direction while building.
Titles vary between companies. Before using either one in a search, write down what the person will own, which decisions remain open, and what support you can actually provide. A clear brief makes it easier for both sides to recognize a fit.
Start with the next six months of work
Describe three outcomes the hire should deliver. Use concrete language: launch the first customer workflow, improve a slow data pipeline, or take ownership of a production service. Then list what already exists: a product roadmap, technical leadership, working infrastructure, customer feedback, and other engineers.
Consider two hypothetical companies. One has a technical founder, a working product, and a defined backlog. Its next hire might be a senior engineer who owns a substantial product area. The other has early customer interest but no settled architecture or development process. It may need someone comfortable making those choices alongside the founders. Neither situation is inherently more prestigious; they demand different working conditions.
Separate experience from ownership
For this hiring decision, think of a founding engineer as an early technical partner with broad responsibility and significant ambiguity. That might include customer conversations, choosing tools, setting engineering practices, and explaining tradeoffs to nontechnical colleagues. It should still be clear who has final decision authority.
A senior engineer can also be highly independent, entrepreneurial, and influential. The difference is that the company may already provide a clearer technical environment and narrower area of ownership. Do not assume seniority means someone wants management responsibilities, or that a founding title means they should absorb every unresolved company problem.
Make the brief honest about the environment
Your job description should answer the questions a thoughtful candidate will ask:
What is built today, and what still needs to be discovered?
Who will they work with and report to?
Which product and architecture decisions can they make?
How much customer contact and operational work is expected?
What are the working location, schedule, and compensation expectations?
Explain the equity component separately from salary, and provide the actual terms when available. Avoid treating a title or an optimistic company narrative as a substitute for clear compensation information. If a decision is still open, say so and identify when it will be resolved.
Assess the work you will actually need
Choose an interview exercise that resembles the role without asking candidates to complete unpaid production work. For broad early ownership, discuss a small hypothetical product problem with incomplete requirements. Ask what they would clarify, what they would build first, and which risks they would postpone.
For a senior hire in an established system, explore a realistic design or debugging problem within that system's constraints. In either case, ask about a past decision they changed after new evidence appeared. Listen for the reasoning, their personal contribution, and how they worked with others. Agree on the assessment criteria before interviewing, then evaluate candidates against the same criteria.
Choose the title after defining the role
Write a one-page brief covering outcomes, ownership, support, and constraints. Have the founders and interviewers review it independently. If their descriptions of the job disagree, resolve that before starting the search.
The strongest match is someone who wants the actual work and environment you offer. A recognizable title helps people find the opportunity; a precise description helps the right person choose it.
