The Engineering Interview for Your First Senior Developer Hire: What to Test and Why
Your first senior developer hire is the interview you are least prepared to run. Founders and first-time engineering managers usually copy the process they went through themselves: LeetCode puzzles and system design rounds sized for companies with millions of users. A senior developer interview process for a 5 to 15 person SaaS company needs to test something else, because the job is something else. This post walks through what seniority means at your scale, a four stage process you can run in two weeks, the take-home format that reveals judgment without burning candidate goodwill, and the scorecard that keeps your decision honest.
What Seniority Means at a Company of 15 People
At a large company, a senior engineer owns a well-defined slice of a system and goes deep on it. The organization around them absorbs ambiguity: product managers write specs and staff engineers set the architecture. At a 5 to 15 person SaaS company none of that scaffolding exists. Seniority at your scale means problem framing. Someone hands the person a vague business problem, say "customers keep asking for exports," and they come back with a scoped plan, a list of what they deliberately left out, and a question that reshapes the request.
Code quality still matters, but it is the baseline, not the differentiator. Plenty of engineers write clean code and still need a spec handed to them. The expensive failure mode is hiring a strong implementer into a role that needed a decision maker. Whatever your first senior hire does also becomes the default: their coding patterns and their review tone turn into the house standard every later hire copies.
A Senior Developer Interview Process You Can Run in Two Weeks
Speed is part of the design. Senior candidates rarely stay on the market long, and a process that stretches past three weeks loses them to faster competitors. In Germany the stakes are higher still, because a three month notice period often sits between offer and start date anyway. Our post on hiring senior developers in Germany covers that market side in detail.
The process has four stages:
- A 45 minute screen with the founder or hiring manager, built around past decisions rather than trivia.
- A paid take-home, timeboxed to three or four hours.
- A 90 minute conversation that combines a take-home debrief with an architecture discussion.
- Reference checks, done properly.
That is the whole senior developer interview process. It contains no whiteboard algorithm round on purpose: reversing a linked list under observation predicts almost nothing about whether someone can scope a billing migration.
In the screen, ask for specifics. The last technical decision they regret. The incident they remember most. What they would change about the codebase they just left. If the role leans frontend, our post on React interview questions covers that screen in more depth.
The Take-Home: Small, Paid, and Shaped Like Your Real Work
An unpaid eight hour take-home filters for people with free weekends, and that is all it filters for. Pay a flat fee, timebox the exercise to three or four hours on the honor system, and build it from a sanitized slice of your actual product. A working but rough service with one planted bug and one missing feature works well. Ask them to add the feature and to write a short note on what they would change if they owned the code. Whether they notice the bug tells you something too.
The written note carries as much signal as the code. Seniors under a timebox cut scope and say so. Their README reads like a message to a colleague: here is what I did, here is what I skipped and why. Juniors polish one corner and go silent on the rest. Grade the reasoning as heavily as the implementation. An unexplained shortcut is a bigger warning than an explained one.
One practical problem remains: someone has to grade this, and at many small companies nobody has reviewed senior-level work before. Our worked example of what a senior code review catches shows the difference concretely, and an external reviewer through our code quality consulting can grade submissions until you have that seniority in house.
The Architecture Conversation: Trade-Offs Over Patterns
Skip invented scenarios. Bring a real decision your company faces, or one you recently made, and work through it together. The candidate has no context on your product, and watching them acquire that context is the test.
The strongest signal is what they ask before they answer. Seniors calibrated to small companies ask about constraints first: how many customers, how much traffic, how many engineers, what breaks if this ships two months late. Candidates arriving from larger companies often skip straight to the pattern they know, and you hear a proposal with a message broker and a Kubernetes cluster for a product with forty tenants.
Then ask the question that separates levels: what would have to change for your answer to change? A senior engineer can name the threshold where the simple version stops working and the heavier one earns its cost. Someone reciting a pattern cannot, because the pattern arrived without its reasoning.
Use the same session to debrief the take-home. Ask them to critique their own submission before you share your notes. Seniors volunteer their shortcuts unprompted and usually spot a problem you missed.
Red Flags a LeetCode Screen Never Shows
The failure modes that hurt at your scale are invisible in algorithm screens, and most of them cluster around explanation.
A candidate who cannot explain why a past decision was made, beyond "that was the standard at my last company," will import patterns into your codebase the same way: without reasoning you can interrogate later.
Defensiveness about old code is a second one. Every engineer with real experience has shipped things they now dislike. Ask what they would change about their last major project. A senior answers with a list and some regret. Evasion, or a claim that the design was right all along, tells you how code review will feel with this person on the other side of it.
Vague incident stories are a third. Ask about the worst production incident they were close to. You are listening for concrete mechanics: what broke, what they did in the first hour, what changed afterward. "There was a big outage once, the team handled it" from a supposed senior means they either watched from a distance or cannot reconstruct their own reasoning. Neither is what you are paying for.
And notice whether they ever say "I don't know." Across a 90 minute technical conversation the phrase should appear at least once. Its complete absence is its own answer.
Reference Checks That Surface What Candidates Will Not Say
Most reference calls collect rehearsed praise because the questions invite it. Change the questions. Ask a former manager what kind of work they eventually stopped giving the candidate. Ask a former peer what the candidate needed the most support with, and how the candidate reacted the last time someone pushed back on their design. End with a calibrated version of the hire-again question: "Would you hire them again as the first senior engineer at a ten person company?" The pause before the answer often says more than the answer.
Ask for one manager and one peer. A candidate who cannot produce a single former colleague willing to talk is information in itself.
The Scorecard
Decide dimensions and weights before the first interview, score independently before any debrief, and write one sentence of evidence per score. Group discussion happens after scoring, never before, which keeps the loudest voice in the room from becoming your de facto hiring bar.
| Dimension | Weight | What a 4 looks like |
|---|---|---|
| Problem framing | 30% | Asks about constraints before proposing anything; scopes the smallest version that solves the problem |
| Communication | 25% | Take-home note reads like a colleague's handoff; explains decisions a non-engineer can follow |
| Technical judgment | 25% | Ties every trade-off to your scale; can name what would change the answer |
| Code quality | 20% | Submission is readable, tested where it matters, honest about shortcuts |
Score each dimension 1 to 4. A hire needs a weighted average of 3.0 with no dimension below 2, and a problem framing score below 3 should stop the hire regardless of the total. The 20% weight on code quality is deliberate. It is the easiest dimension to improve after hiring and the one founders overweight most.
The Job Description Does the First Filtering
The scorecard fails if the wrong people fill the pipeline. A job description that filters well states the stack with versions, describes two real problems the person will own in their first six months, names the team size plainly, includes a salary range, and lays out this exact process with its time commitment. Engineers who want ambiguity absorbed for them read "you will own architecture decisions at a ten person company" and self-select out. The ones you want apply because of that sentence.
Where to Get Help Running It
Wolf-Tech helps founders run this senior developer interview process end to end: building the take-home from a sanitized slice of the real codebase, joining the architecture conversation as the technical interviewer, or grading submissions when nobody in house has senior review experience yet. And when the search plus a German notice period leaves a half year gap, our custom software development work covers the capacity until the hire starts.
If the first senior hire is on your roadmap this year, write to hello@wolf-tech.io or have a look at wolf-tech.io. A one hour conversation before you post the role is cheaper than three months of interviewing the wrong pipeline.