How to hire a fullstack engineer

Key takeaways

• Scope the engagement against an outcome you can point at on a calendar, not a generic job description.
• Four engagement shapes cover most fullstack hires: greenfield, migration, scale or performance work, and team augmentation.
• Evaluate for judgment across the stack (past work review, paired work session, judgment-focused reference check). Skip timed algorithm screens.
• Ship a first production commit in week one and a first visible milestone by end of week three.
• Two common failure patterns: hiring for breadth when the work is depth, and letting scope expand without re-contracting.

Why this question matters

Most teams don't hire "a fullstack engineer." They hire a specific person to own a specific surface end-to-end in a specific window. That shift changes the whole process. Scoping, evaluation, and onboarding should all sit under that frame, and the hires that go wrong usually do so because the team was recruiting against a generic job description while the actual need was something narrower and more defined.

The decision frame: Outcome first, profile second

Before writing a JD or opening a search, get clear on three questions.

What is the surface? One product area, one system, one feature flow. "Our checkout stack" is a surface. "Our iOS app's subscription management" is a surface. "Full-stack engineering" is not a surface.

What is the outcome in three months? Something you can point at on a calendar. "Migrate the payment service from Stripe Classic to Stripe Payment Intents and shut off the legacy integration by July 31" is an outcome. "Help the team move faster" is not.

What's the surface's current state? Is this a greenfield build, a rewrite, a migration, or a steady-state maintenance situation? Each one selects for a different kind of fullstack engineer.

When you can answer the three questions in one sentence each, you have enough to write the scope. The profile follows from the scope, which is the opposite order most teams use.

Scoping the role

A senior fullstack engagement typically falls into one of four shapes.

Greenfield surface, three-to-six-month scope. Single engineer, end-to-end ownership, shipping something new. The hire here should have a track record of launching surfaces from zero and past experience making judgment calls about what's worth building versus what's worth cutting.

Migration or rewrite, three-to-six-month scope. Single engineer, working alongside an internal team, often on a system that has non-obvious history. The hire needs production-debugging instincts and the maturity to sit with legacy code before rewriting it.

Scale or performance work, two-to-four-month scope. Single engineer, specialized. This is where stack-specialized fullstack engineers (Go, Elixir, Rust) earn their rate. The scope is tightly bounded by a performance target.

Team augmentation on an in-flight project. Fullstack engineer plus a specialist counterpart (backend or frontend) plus a product manager, for six to nine months. This is less a single hire and more a team shape.

The shape of the engagement tells you how senior the hire needs to be, how long the engagement should run, and what the team composition looks like. Get this right up front and the rest of the process follows.

Evaluating a senior fullstack engineer

The wrong bar is "can they write React and Node." The right bar is "can they hold the whole system in their head and make the right call at every layer." That's harder to test. The evaluation pattern that works:

Past work review. Spend 30 minutes walking through a past production system the candidate owned. Ask them to sketch the architecture on a shared digital whiteboard or over screenshare and walk through three judgment calls they made: one on the data model, one on the API, one on the UI. The quality of their answers tells you more than any take-home.

Paired work session. One to two hours. A real problem from your codebase, loaded into a branch. Watch how the candidate approaches it. You're looking for how they diagnose rather than how fast they type. Senior fullstack engineers ask four or five structural questions before writing a single line of code.

Reference-check on judgment. Call two people who've worked with the candidate and ask a single question: "What's the hardest call you saw them make, and what did they decide?" Anything less specific than a concrete example is a signal the candidate hasn't operated at the level the role demands.

Skip coding tests that don't reflect the actual work. A timed algorithm screen selects for a trait (fast algorithm recall) that has little to do with shipping fullstack work at a senior level. It filters out good candidates and lets in people who study for interviews.

The first 30 days

The best hires ship something measurable in the first month. Set up the engagement so that's possible.

Week one: systems access and a first commit. The candidate should have laptop, repo access, staging environment, and monitoring logins on day one. A first commit to a small surface should land by end of week one. If the first commit takes two weeks, something is wrong with onboarding, not the hire.

Week two: scope confirmation. Sit with the engineer and walk through the scope you wrote during hiring. Ask them what they'd change. A senior engineer will flag things the scope missed and make trade-off suggestions you hadn't considered. Listen to those.

Week three: first milestone ship. Something small, visible, and in production. A bug fix, a feature flag rollout, an API endpoint. The goal is to prove out the full path from work to production.

Week four: one-on-one calibration. Check in on the engagement itself. Is the scope still the right one? Is the engineer unblocked? Is the team integration working? A 30-day check-in here catches issues early enough to correct course.

Common failure patterns

Two patterns show up repeatedly.

The team hires for breadth when they needed depth. Fullstack is a convenient label; sometimes the actual need is a backend specialist with enough frontend fluency to collaborate cleanly. If the surface is 80% backend, hire a backend engineer and make peace with needing a bit of frontend pairing. Forcing a fullstack hire onto a backend-shaped scope is how you end up with an engineer who's decent at both ends and great at neither.

The scope expands mid-engagement and nobody re-contracts. An engineer hired to migrate a payment service gets pulled into a separate refactor, then a third project. By month two, nobody can tell you what the engagement is shipping. Write the scope, post it somewhere visible, and protect it. If the scope needs to change, do it formally.

What to do next

If you're hiring a fullstack engineer in the next 90 days, write the scope first. Three sentences answering the three questions in the decision frame. If you can't fit the answer in three sentences, the scope isn't clear enough yet. Once the scope is written, the profile, the rate, and the evaluation process all flow from it.