How to hire a software engineer

Key takeaways

• "Software engineer" as a JD title produces a generic shortlist. Scope the surface and the system constraint before writing the role.
• Most software engineer engagements are closer to backend, fullstack, or frontend once the scope is clear. Use the more specific guide if you can.
• Evaluate for the quality of judgment on past system decisions, not for speed on novel algorithm problems.
• First 30 days: a first commit in week one, a first production feature or service by end of week three.
• Senior software engineers know what questions to ask before writing code. Hire for that instinct.

Why this question matters

"Software engineer" is a useful title on an org chart and a vague one in a hiring search. Teams that search for "a software engineer" without specifying the layer (frontend, backend, fullstack), the system (greenfield, existing product, infrastructure, data pipeline), and the constraint (performance, reliability, compliance, velocity) get shortlists that include people who'd be excellent for a different version of the role. The scoping work is the highest-leverage thing you can do before the search starts.

The decision frame: System layer first, seniority second

Three questions before writing the JD.

What layer of the system does this engineer primarily own? Frontend (UI, component systems, web performance), backend (APIs, services, data models, pipelines), fullstack (end-to-end ownership of a product surface), or infrastructure/platform (deployment, reliability, developer tooling)?

What's the primary constraint or challenge? Shipping a new surface fast, migrating a legacy system, improving reliability or performance, or integrating with an external system (AI API, data source, third-party service)?

What does the team look like? Does the engineer have peers to collaborate with, or are they the primary engineer on a surface? Solo engineers need stronger generalist judgment; team engineers can specialize more.

If you can answer those three questions in one sentence each, you have a scope that will produce a useful shortlist. If you can't, start with the more specific guides for frontend, backend, or fullstack engineers, one of those likely fits the actual need.

Scoping the role

Software engineer engagements break into four common shapes once scoped.

New product surface, greenfield. One engineer owning a new surface end-to-end from design spec to production deployment. This is where fullstack judgment matters most: the engineer makes decisions across layers that more specialized engineers would defer to others. The evaluation should focus on decision-making quality at ambiguous cross-layer moments.

Legacy system extension or migration. One engineer embedded in an existing codebase, extending it or incrementally migrating it. This requires production-debugging instincts and the maturity to read and understand a system before rewriting it. The evaluation should probe for how the candidate approaches unfamiliar code.

Reliability or performance improvement. One engineer focused on making an existing system faster, more reliable, or cheaper to operate. This is a diagnostic profile, identifying root causes, designing instrumented fixes, and measuring outcomes. The evaluation should probe for analytical rigor and measurement instincts.

AI or data system integration. One engineer building the software layer that integrates an AI model or data source into a product. This requires comfort with async APIs, streaming responses, partial failures, and the graceful degradation patterns that AI and data systems require. The evaluation should include a systems design question that involves an external API with variable latency and reliability.

Evaluating a senior software engineer

The wrong bar is algorithm speed. Timed algorithm problems measure a trait (fast recall under pressure) that has a weak relationship with production software quality. The right bar is judgment on past decisions.

Past codebase walkthrough. Ask the candidate to walk through a system or codebase they owned in production. Ask them to explain the two or three most important design decisions they made, what the alternatives were, and why they chose what they chose. The quality of the reasoning tells you more than the choices themselves.

Unfamiliar code diagnostic. Put the candidate in front of a small unfamiliar codebase (or a simplified version of yours) and ask them to identify a bug or a code smell without prior context. Watch the diagnostic process: what do they read first, what questions do they ask, how quickly do they form a hypothesis? This is closer to the actual day-to-day of senior engineering than any algorithm test.

Trade-off conversation. Give the candidate a real technical decision your team is currently facing, a technology choice, an architecture trade-off, a build-versus-buy decision. Ask them to walk through how they'd evaluate it. The goal is to see whether they ask for the right context before opining and whether their reasoning holds up under follow-up questions.

The first 30 days

Week one: first commit to production. Even something small. A bug fix, a configuration improvement, a test added to a flaky suite. The goal is to prove the path from work to production, not to prove the engineer is senior. If the path takes more than a week to navigate, the onboarding process has a problem.

Week two: systems orientation. A structured working session with the engineer who knows the codebase best. A hands-on tour, not a documentation dump: "let me show you where the hard parts are and why they're hard." Record it.

Week three: first production feature or service. Something with real scope and a test that proves it works. An API endpoint, a component, a pipeline stage, a new integration. The complexity should be calibrated to the engineer's familiarity with the system at this point, not to what you'd expect from a fully ramped engineer.

Week four: calibration. Is the scope still the right scope? Is the team integration working? Are there blockers that the team can remove? The 30-day check-in surfaces issues early enough to course-correct without losing the engagement.

Common failure patterns

Two patterns account for most software engineer mis-hires.

The scope was so broad the engineer couldn't close a decision. "Help us move faster" is a mandate, not a scope. A senior engineer handed a mandate with no defined surface will spend month one doing archaeology and month two proposing a roadmap nobody has approved. Scope tightly enough that the engineer can start making decisions in week one.

The evaluation filtered for a trait the work doesn't require. A team doing steady-state API maintenance hired an engineer who scored highest on a systems design marathon, a three-hour distributed systems design interview. Six months in, the engineer is bored with CRUD endpoints and the team wonders why their hire is disengaged. Match the evaluation to the work.

What to do next

Before writing the JD, write three sentences: the system layer, the primary constraint or challenge, and what the team looks like. If those three sentences feel like they're describing a frontend, backend, or fullstack engineer specifically, use the more specific guide for that role. The specific guide has a tighter evaluation rubric and a more useful shortlist profile. Use this guide only when the scope genuinely spans layers in a way the specialized guides don't cover.