How to Interview a Software Engineer: A Founder's Guide

Run the same structured interview with every candidate, score it against a written list of the skills the job needs, and judge a sample of real work rather than a conversation. That is how to interview a software engineer without being one yourself. You are not testing whether someone sounds impressive. You are checking whether their work matches the job.

This guide is for founders and hiring managers running a technical hire without a CTO in the building. It covers what to test, how to build a scorecard, which assessment formats are worth a candidate's time, the questions that work when you cannot read code, what to do about AI-assisted candidates, and where to borrow technical judgment. If you are still deciding whether to hire at all, our comparison of hiring models and what each one costs covers that choice first.

Key takeaways

• Decide what good looks like before you meet anyone. A one-page scorecard of four or five competencies turns opinions into evidence.
• Ask every candidate the same questions in the same order. That is what makes an interview structured, and it is the only way two candidates become comparable.
• A work sample beats a quiz. In Schmidt and Hunter's meta-analysis of 85 years of selection research, general mental ability plus a work-sample test reached a mean validity of .63 for predicting job performance, level with a structured interview.
• Assume AI is in the room. 84% of developers in the 2025 Stack Overflow survey use or plan to use AI tools, so test how a candidate reviews generated code instead of pretending it does not exist.
• Borrow the judgment you lack. One hour of a senior engineer's time in the technical round costs less than a wrong hire you keep for six months.

What are you actually testing?

Four things, in this order: whether they can do the job's daily work, how they think when they are stuck, how clearly they explain themselves, and whether they finish. Frameworks listed on a CV, years of experience and the logo of a previous employer are proxies for those four, and weak ones.

Write the scorecard before you write the job ad

A scorecard is a one-page list of the competencies the role needs, each with a sentence describing what a weak, acceptable and strong answer sounds like. Write it before you meet anyone, because once you have met a likeable candidate the bar quietly moves to fit them.

For a first backend hire at a small product company, something like this is enough:

• Data modelling. Can they design the tables behind a feature you describe out loud, and explain the trade-offs they chose?
• API design. Do they think about who calls this, what happens on a retry, and what the error looks like to the caller?
• Debugging. Given a bug report, do they form a hypothesis and test it, or guess and change things?
• Testing and release. How does their work get to users, and how do they find out when it breaks?
• Communication. Can they explain a technical trade-off to you, the non-engineer, well enough that you could repeat it to an investor?

Four or five lines is plenty. Ten turns the interview into a survey and nobody scores it honestly.

Seniority is about scope, not years

A mid-level engineer delivers well-defined work on their own and knows when to ask. A senior engineer owns a feature or system end to end and copes with an unclear brief. A lead sets direction across several systems and other people. Titles mean different things at different companies, so ask what the person decided and what they were accountable for, never what the title said.

How to interview a software engineer, step by step

Five stages, roughly four hours of candidate time in total. Run them in the same order for everyone, including the person who was referred by a friend.

1. Screen for the basics (20 minutes). Motivation, notice period, salary expectations, location and the two or three technologies the role genuinely requires. Do this before anyone spends an evening on a task.
2. Run a structured technical interview (60 minutes). Real work, not trivia: a design problem, a piece of code to reason about, an incident they owned. Same questions, same order, scored against the scorecard.
3. Set a work sample (two to three hours, capped). A small task that resembles the job, with a written brief and a stated time limit.
4. Review the work together (45 minutes). Ask why they chose what they chose, what they would change with another day, and what they deliberately left out. The conversation is worth more than the code.
5. Check references, then decide quickly. Two short calls with people who worked beside them. Make the offer within a week of the final round.

Stage two is the one founders improvise, and it is the one that most needs a script. The US Office of Personnel Management's definition of a structured interview is blunt about what makes it structured: all candidates are asked the same predetermined questions in the same order, and all responses are evaluated using the same rating scale. Skip that and you end up comparing memories rather than candidates.

Which assessment format should you use?

A work sample, almost always, followed by a conversation about it. In Schmidt and Hunter's review of 85 years of personnel selection research in Psychological Bulletin, general mental ability combined with a work-sample test reached a mean validity of .63 for predicting job performance, the same figure as general mental ability combined with a structured interview. Out of nineteen methods they examined, an unscripted chat was not one of the winners.

How long should a take-home task be?

Two to three hours, with the cap written into the brief and respected when you review the result. A task that swallows a weekend selects for people with free weekends. If you need more than three hours of someone's effort, pay their day rate and call it a trial rather than a test.

Make the task resemble the job. If the role is billing, ask for a small endpoint that records a payment and survives the same webhook arriving twice. If it is data work, hand over a messy CSV and a question to answer from it.

What should you ask when you cannot read code?

Ask about work they have actually done, then keep asking why. You do not need to read the code to judge the reasoning, and reasoning is most of what separates a senior engineer from a competent one.

• "Walk me through something you built end to end. What did you get wrong?" Strong answers name a specific decision and its consequence. Weak answers describe the product rather than their part in it.
• "The last time production broke, what happened?" You want a timeline: how they found out, how they narrowed it down, and what they changed so it could not happen the same way twice.
• "What would you need in your first two weeks to be useful here?" Senior people ask about access, environments, who owns what, and where the risk sits. Juniors ask for tickets.
• "Tell me about something you argued against building." Engineers who only ever say yes will build whatever you ask for, including the wrong thing.
• "Explain this line on your CV as if I am the person paying for it." If you cannot follow the explanation after two attempts, that is information about them, not about you.

Score each answer straight after the interview, before the next candidate, while the detail is still fresh. Stack Overflow's summary of the research behind developer interviews puts the alternative plainly: an unscripted conversation is closer to speed dating than to assessment.

Several of these questions overlap with the technical review investors run before they fund you, which doubles as a list of what an experienced engineer is expected to have in place.

How do you interview when every candidate uses AI?

Assume the tools are in the room and test what the candidate does with the output. In the 2025 Stack Overflow Developer Survey, 84% of respondents said they use or plan to use AI tools in their development process, up from 76% a year earlier, while 46% said they distrust the accuracy of what those tools produce against 33% who trust it. Reviewing generated code is part of the job now, so make it part of the interview.

A short review exercise does this well. Hand over a snippet an assistant could plausibly have written and ask what they would change before it ships:

app.get('/api/orders/:id', async (req, res) => {
  const order = await db.query(
    `SELECT * FROM orders WHERE id = ${req.params.id}`
  );
  res.json(order);
});

Two problems should surface within a minute. The order ID is pasted straight into the SQL string, which is an injection waiting to happen, and nothing checks that the signed-in user owns that order. A candidate who names both, describes the fix and mentions the test they would write has told you more than any puzzle would.

Who should run the technical round?

Someone who has done the job recently. If that is not you, borrow them, because an hour of a senior engineer's attention is the cheapest insurance in the whole process.

Whoever runs it should write a page afterwards: what was tested, where the candidate was strong, where the gaps are, and the level you would hire them at. That page is what lets a second person form a view without repeating the interview. It is the format behind our own engineer-led interview process, where an engineer interviews every candidate before any profile reaches the client.

If the first version of the product does not exist yet, hiring may not be the first move at all. Our guide to getting a product built without a technical co-founder covers the alternatives.

Common mistakes

• Interviewing without a scorecard. Six opinions and no criteria produce a committee, not a decision.
• Asking for a weekend of unpaid work. The engineers you most want have other offers and will simply decline.
• Testing trivia. Syntax questions measure recall. Anyone can look up syntax; nobody can look up judgment.
• Hiring only for today's stack. Someone who has used one framework for eight years may struggle the first time the ground moves.
• Skipping references. Two short calls with people who sat beside them catch more than another interview round.
• Letting the process drift. Good candidates hold offers for days, not weeks. Every extra week doubles the chance you lose them.

Frequently asked questions

Can I hire a software engineer if I cannot code?

Yes, provided you do not run the technical round yourself. Your job is to define the role, judge communication and ownership, and check references. Bring in an engineer for the part that needs code, and insist on a written report you can actually read.

Should I pay candidates for a take-home test?

Not for a clearly scoped two-hour task that every candidate receives. Pay for anything longer, and pay for anything that produces work you could ship. Paying also keeps you honest about length.

How many interview rounds does a startup need?

Three or four, including the work sample. Each extra round adds less information than the one before it and raises the chance the candidate accepts elsewhere. Decide what a round is for before you add it.

Are coding puzzles like LeetCode useful for a startup?

Rarely. They measure practice at a specific genre of problem, which tracks free time to drill more than it tracks building and maintaining a product. A small, realistic task tells you more in the same hour.

How long should hiring an engineer take?

Four to six weeks from brief to accepted offer is realistic, plus the notice period. Our own process puts first profiles in front of clients within days, client rounds usually take about two weeks, and if a hire leaves or is let go for performance within 90 days we find a replacement once at no charge.

Hire for the work, not the conversation

Write down what good looks like, ask every candidate the same questions in the same order, put a small piece of real work in front of them, and keep someone technical in the room for the part you cannot judge. The method is the same whether this is your first engineering hire or your fifth, and it is the part of hiring that compounds.

If assembling a panel for a single role is not practical, our engineers can run the technical interview and write you the report before you ever meet the candidate.