How to Hire a Full-Stack Developer

Why this role matters

In small teams a full-stack developer often owns entire features, so their gaps become product gaps. A weak data model slows every later feature, an unvalidated API becomes a security problem, and a careless front end hurts conversion and accessibility. A strong full-stack hire reduces handoffs, spots where a front-end request will strain the back end, and makes sensible trade-offs about where logic should live.

Where to find candidates

• GitHub, searching for contributors to projects in your exact stack (for example Next.js, Django, Rails or Laravel) with commits on both client and server code
• Hacker News monthly "Who is hiring?" threads, which reach developers who read about engineering trade-offs
• Wellfound (formerly AngelList Talent) for developers who want early-stage, broad-ownership roles
• Local and online meetups for your framework, where speakers and organisers have shown they can explain their work
• Bootcamp and university hiring channels for junior hires, paired with a work sample rather than a credential filter
• Referrals from your own engineers, asking specifically for people who shipped features alone

Skills to look for

Red flags

• Portfolio projects that are tutorials with the same schema and features as the course they came from
• Cannot explain how data flows from a form submission to the database and back to the UI in their own project
• Puts business rules and permission checks only in the front end
• Treats database migrations, backups or rollback as someone else's job
• Every answer is about one layer, which suggests a specialist using the full-stack title
• No tests anywhere, or tests that only assert that components render

The interview process

1. 1

   Portfolio and code review

   Ask for one project they built end to end and walk through the repository together. Ask why the schema looks the way it does, where validation happens and what they would change now. Shortlist people whose explanations match the code.

2. 2

   Technical screen

   A conversation about real situations: how they would add a field that touches the database, API and UI; how they debug a slow page; how they handle a failed migration in production. Listen for ownership of the whole path.

3. 3

   Feature work sample

   Give a small starter app in your stack and a ticket such as adding a comments feature with permissions, pagination and a basic test. Ask for a short README on trade-offs. A job simulation of the real feature work is one option for running this consistently. Review the schema change, API design, UI states (loading, empty, error) and tests.

4. 4

   Review and system discussion

   Go through their submission with them, then extend it: what changes if comments need real-time updates, or if one post gets far more traffic than the rest. Judge whether they reason about the data and the user experience together.

5. 5

   Team interview and references

   Have a product manager or designer they would work with join one session. Ask references about features they owned alone and how they handled production incidents.

How to evaluate

• A data model that fits the feature and leaves room for obvious next requirements
• APIs that validate input on the server and return useful errors
• UI that handles loading, empty and error states and works with a keyboard
• Permission checks enforced on the back end
• Tests placed where bugs would be costly
• Clear written explanation of trade-offs and what they left out

Onboarding

• 1Have a one-command local setup with seeded data ready before their first day
• 2Ship a small change through the full pipeline in the first week so they see review, CI and deployment
• 3Give them a map of where business logic lives and which services own which data
• 4Pair them with the on-call engineer for an incident review so they learn how production is monitored
• 5Agree which layer they should go deepest in first, based on where the team is thinnest

Common questions