The first engineering hire: a generalist who ships

The short answerYour first engineer should be a generalist who can ship product, not a specialist who needs infrastructure. Look for someone who has built something end-to-end, even if it was a side project. Hire the generalist who has shipped something whole, and test for that in the interview.

The first engineering hire determines whether you ship or stall for the next year. Your first engineer should be a generalist who can ship product, not a specialist who needs infrastructure. Look for someone who has built something end-to-end, even if it was a side project. Hire the generalist who has shipped something whole, and test for that in the interview.

Culture is what you tolerate, not what you say

Every company has a culture. The question is whether it is intentional or accidental. Intentional culture comes from the behaviors you reward, the behaviors you tolerate, and the behaviors you punish. If you say you value transparency but punish people for sharing bad news, your actual culture is secrecy.

The test for your real culture: what behavior gets someone promoted, and what behavior gets someone fired? Those two answers define your culture more accurately than any values deck. If the person who hits their number but treats people badly gets promoted, your culture is results-at-any-cost. If the person who misses their number but helps the team gets a second chance, your culture is collaborative. Neither is wrong, but you should know which one you are building.

Your first five hires determine your company's DNA

Your first five hires determine your company's DNA more than any mission statement or values document. Hire for slope, not intercept. Someone who is learning fast will outperform someone who knows it all within eighteen months. The interview question that matters most is not what have you done but what would you do here in the first ninety days with what we have.

Reference checks are underrated. Not the ones the candidate gives you, but the ones you find yourself. Spend thirty minutes on the phone with someone who managed them and was not prepped. Ask one question: would you hire them again, and why? The pause before the answer tells you more than the answer itself. Trust the pause.

Design interviews to test the actual job

Most interviews test interviewing skill, not job skill. The candidate who is charming, well-prepared, and great at answering behavioral questions may be terrible at the actual work. Design interviews that simulate the job: a sales candidate should do a mock discovery call, an engineer should review actual code, a marketer should critique your actual content.

The working session interview is the most predictive format. Give the candidate a real problem from your business, thirty minutes of context, and sixty minutes to work through it with you. You learn how they think, how they handle ambiguity, and how they collaborate. They learn what the job actually involves. Both sides make a better decision.

Onboarding is a product, not an orientation

The first thirty days determine whether a hire succeeds. Not because the work is hard, but because the context is missing. The new hire does not know why decisions were made, who to ask for what, or what done looks like. Onboarding should transfer that context systematically, not leave it to osmosis.

The thirty-day plan: week one is context (product, customers, market, history). Week two is shadowing (watch the person they are replacing or the person they will work closest with). Week three is doing with support (start the actual work with a safety net). Week four is doing independently. At the end of thirty days, they should be able to do their core job without asking for help. If they cannot, the onboarding failed, not the hire.

Compensation should be simple, fair, and boring

Early-stage compensation should be simple enough to explain in one sentence. Base salary plus equity, with clear bands for each role. The moment you start negotiating custom packages, you create inequality that breeds resentment. Pay fairly from the start and you avoid the conversation entirely.

Equity should be meaningful enough to matter but not so large that it creates misaligned incentives. For the first ten employees, point-five to two percent depending on role and seniority is standard. Vesting over four years with a one-year cliff. No acceleration clauses for early employees. The equity conversation should take five minutes in the offer call. If it takes longer, the candidate is optimizing for the wrong thing.


Frequently asked questions

Who should be my first engineering hire?

A generalist who can ship product end to end: frontend, backend, deployment, and enough design sense to not embarrass you. A specialist who needs infrastructure will wait for tools you do not have.

How do I interview a first engineer?

Have them build a small feature in your actual stack over a paid week. Resumes and puzzles tell you about interviewing. Watching someone scope, ship, and explain a real feature tells you about the job.

What red flags should I watch for in early engineers?

Resumes full of scale work at big companies with nothing shipped solo, and candidates who ask about the platform team. You need someone energized by zero-to-one mess, not someone who misses the machine.

Should the first engineer be a co-founder-level hire?

In commitment, yes; in title, not necessarily. They need ownership of technical decisions and real equity. What they do not need is veto power over the product, which stays with whoever owns the customer.

How much should I pay a first engineer?

Fair market cash minus the startup discount, plus meaningful equity: one to two percent vesting over four years is common for hire one. Anyone who needs maximum cash will leave at the first rough quarter anyway.

Working through this right now?

This is the work we do with founders one-on-one. One email is enough. A partner reads every message.

Start a conversation