Hiring Your First Engineer: What to Look for Beyond Code

Every founder interviewing their first engineer asks the same things. What is your stack. Walk me through your last project. What is on your GitHub. These questions tell you whether the person can code. They tell you almost nothing about whether they will still be useful to you in year two.

I have been on the wrong side of this four times. Here is the checklist I wish I had the first time.

Non-code signals that actually matter

• Writing quality. Ask them to describe a bug they fixed in Slack-length paragraphs. Fuzzy writing is fuzzy thinking
• Ownership instincts. Ask "what did you ship that was not assigned to you?" If nothing comes up, you are hiring a ticket-closer
• Curiosity about your business. Do they ask why the company exists, or just what the tech is
• How they talk about past teams. Constant blame of previous managers is a pattern, not a coincidence
• Whether they can say "I do not know." People who cannot, will bluff in production too
• Tolerance for ambiguity. "What would you do if I gave you a one-line description and no spec?" — listen hard

Red flags that do not show up in the interview

The interview is too short to catch these. They appear in week three, and by week six you know. Name them to yourself now so you recognise them early.

• Cannot ship something small without a full spec
• Keeps finding reasons the codebase needs rewriting before they will work in it
• Does not read the existing code before adding new code
• Avoids public Slack channels — pulls everything to DMs
• Turns every technical decision into a discussion that never resolves
• Writes PRs that are technically correct and utterly unreviewable

Green flags most founders underweight

• Builds personal tools. People who solve their own annoyances solve yours too
• Has an opinion but updates it when shown a better one. Strong + flexible is rare
• Has done something in the past that was not glamorous and explains it without defensiveness
• Seems to like their craft for its own sake, not for the paycheck
• Asks good questions about your actual problems, not your tech stack

The trial that works

A one-week paid trial beats any interview I have ever run. They ship one small thing end-to-end on a real problem. You see how they write, how they ask questions, how they handle a surprise, how they write a PR, how they respond to review. You learn more in five days than in five rounds of interviews.

If they cannot do a one-week trial, be honest about what you are signing up for. You are hiring on vibes.

The uncomfortable truth

Your first engineer sets the engineering culture of your company for the next five years. If they write tests, everyone else will. If they do not, nobody will. If they ship on Fridays, you will still be shipping on Fridays in year three. If they ghost PRs, your codebase will ghost PRs.

Hire for the culture you want to still have when you are 40 people. Hire slow. Fire fast in the first month if the match is wrong. The compounding is more than you think.

Your first engineer picks the culture. Pick carefully.