For founders

How to interview a founding engineer

The standard loop was built to filter hundreds of applicants down safely. You are hiring one person who will decide how the product gets built, and it tests almost nothing you need to know.

Zelcast

The interview loop most startups copy was designed by large companies to reject a lot of applicants without much risk, and it screens for the ability to solve clean problems under observation. A founding engineer’s job is to find the problem, decide what to build, and ship it while everything is ambiguous. Test that instead: give them a real problem you actually have, work on it together, and pay attention to the questions they ask before they write anything.

Why the standard loop misleads you

Four rounds of algorithm puzzles and a system design whiteboard were built for a company hiring a thousand engineers a year, where the cost of a bad hire is contained and the cost of a slow process is enormous. The Y Combinator library has been making the same argument to founders for years. Both of those are reversed at ten people.

It also tests the wrong axis. Every interviewer watches how a candidate handles a well specified problem, and your company will not have a well specified problem for a year. The person who is excellent at the puzzle and paralysed by ambiguity passes this loop comfortably, and at ten people that failure is the one you cannot survive.

Three conversations is usually enough

A working session. Take a real problem from your actual codebase or roadmap, give it to them in advance, and spend ninety minutes on it together. Not a take home you grade in silence. Sit in it with them and watch how they think when someone pushes back.

A history conversation. Walk through two things they built, in depth, until you hit the parts they got wrong. What did they choose, what did it cost, what would they do differently. People who have really owned something can go three levels deep without preparing. People who were nearby cannot.

A reality conversation. This one is yours to give. Describe the company honestly, including what is broken, what the money looks like, and what you need from them in the first six months. What to screen for is a longer conversation on its own. Then let them ask everything. The questions they ask here tell you more than any answer they gave earlier.

What you are actually testing

Judgment about what not to build. At this stage the most valuable engineering decision is usually a refusal. Ask what they cut on their last project and why, and listen for whether the reasoning was about users and time or about elegance.

Speed through ambiguity. Give them a problem with a missing requirement and see whether they notice, ask, or invent. All three are fine. Not noticing is not.

Whether they can hold the whole thing. A founding engineer needs to carry the product, the deploy, the data, and the customer in one head, a distinction we draw out in founding engineer versus early engineer. Ask what they owned end to end and how far the end went.

Whether other people get better around them. You are hiring your fourth engineer through this person whether you plan to or not. Ask who they have taught, and check it with someone who was there.

The signals that actually predict

They ask about users and constraints before they ask about the stack. The stack question is fine later. It is rarely the first one out of someone who has shipped under pressure.

They can describe a failure precisely and without a villain. Specific, technical, owned. Vagueness here or a story where everyone else was the problem is the strongest negative signal in the whole loop.

They disagree with you well during the working session. You want someone who will push back on a founder in year one, and the interview is the only place you get to see it before it matters.

They have shipped something all the way to a real user, with someone depending on it afterwards.

Two things founders get wrong

Outsourcing the decision. If a founder is not in the loop for an early hire, the loop takes longer and decides less, and the person who most needs to trust this hire has only read a scorecard.

Treating the interview as one directional. The candidate you want is evaluating you the entire time, and at this level they usually have options. A loop that wastes their evening on a puzzle tells them what working here will feel like. A conversation about a real problem tells them something better, and it measures more.