The most common mistake non-technical founders make when interviewing full stack developers is asking broad questions and accepting broad answers. "Do you know React?" "Yes." "Have you built Django APIs?" "Yes." None of this reveals capability. The three questions below require specific mechanisms and produce answers that are either credible or not — without needing technical judgment to evaluate.
Why T-Shaped Depth Is What You're Looking For
"Full stack" describes a spectrum. At one end: a developer with deep backend knowledge and genuine frontend competence. At the other end: a developer who has touched both sides but masters neither — what senior engineers call a "shallow generalist." The two look identical on a resume. Their output over six months is very different.
T-shaped developers have a primary depth axis (usually backend or frontend) and sufficient breadth in the other area to build and maintain features without asking for help. A backend-heavy full stack developer can implement a React form with state and validation; they may not be the person to build a custom animation system. A frontend-heavy full stack developer can design a sensible database schema and write a REST API; they may not be the person to optimise a complex background processing pipeline. Both are valuable. The shallow generalist can approximate both areas on small problems and falls short on anything non-trivial.
The test for T-shape is simple: ask a detailed question in what the developer claims is their strength. If the depth is there, the answer includes mechanisms, specific experiences, and tradeoffs. If it's not, the answer stays general.
Three Questions That Reveal the Whole Picture
Question 1: "Tell me about a feature you built end to end. What was the hardest backend decision and the hardest frontend decision?"
This question forces the candidate to demonstrate both domains in a single answer, which removes the ability to hide weakness in one area by pivoting to the other.
What to listen for: The backend decision should involve a specific constraint — "I had to decide whether to store this as a denormalised column or do a JOIN at query time, and I chose denormalisation because the query ran 8,000 times per day and the JOIN was causing 200ms latency." The frontend decision should involve a specific problem — "I had to decide whether to use TanStack Query or local state for this, and I used TanStack Query because three components needed the same data and I didn't want to prop-drill three levels." Both answers name the tradeoff and explain the reasoning.
Red flag: "The backend was an API and the frontend was a React component." This describes what they built, not the decisions they made. Every full stack feature has an API and a React component. The absence of a specific decision means there was no deliberate choice — they just built the obvious path.
Question 2: "A user clicks 'submit payment' and the request takes 8 seconds. Walk me through how you'd diagnose that."
This is a debugging question that tests understanding of the full request-response cycle. A correct answer touches every layer: client, network, server, database.
What a T-shaped developer says: "First I'd check the browser network tab to see where the 8 seconds is. If the request itself shows 8 seconds server-side time, the problem is on the backend. Then I'd check the server logs for which database queries ran during that request and how long each took. If there's a slow query, I'd run EXPLAIN ANALYZE on it in PostgreSQL to see whether it's doing a sequential scan that needs an index. If there's no slow query and the time is in application code, I'd profile the endpoint to find where it's spending the time — sometimes it's a loop calling an external API, which should be in a background task instead."
Red flag: "I'd add a loading spinner." This is a user experience answer to a performance question. The developer has not thought about the diagnostic process — only the user-visible symptom.
Question 3: "How do you ensure that the API you built doesn't break the frontend when you change it?"
This tests whether the developer thinks about the contract between backend and frontend — the joint responsibility of a full stack role.
What a good answer includes: API versioning (changes go to /v2/ rather than breaking /v1/), TypeScript types shared between frontend and backend (a change to the API response type produces a compile error in the frontend immediately), and communication conventions for breaking changes. Developers who have been the sole full stack developer may describe informal practices — "I update the frontend and backend in the same commit." That is acceptable for solo work. Developers who have worked in teams should describe explicit versioning or shared type contracts.
Red flag: "I'd just update both sides." This works when both sides are owned by the same developer. It is a complete non-answer for understanding API contract discipline, and it reveals that the developer has not thought about what happens when someone else consumes the API.
How to Evaluate the Answers Without Technical Knowledge
Specificity is the signal. Candidates who have done the thing give specific answers: specific table names, specific error messages, specific tools used. Candidates who have read about the thing give general answers. You do not need to know whether their specific answer is technically correct — you need to notice whether the answer is specific at all.
Constraints are the signal. Real engineering decisions have constraints: time, traffic, team size, data volume. A developer who describes decisions without constraints — "I used PostgreSQL because it's good" — has not had to justify a technical decision under pressure. A developer who says "I used PostgreSQL over MongoDB because I needed transactions across three tables and MongoDB's multi-document transactions added operational complexity we couldn't afford at that stage" is describing a real trade-off.
Mistakes are the signal. Ask what they'd do differently on any project they describe. The best developers describe a specific mistake and what they learned. "I used Redis for rate limiting and the implementation was correct, but I didn't account for Redis failover — when Redis went down, the rate limiting failed open and we had a brief period with no rate limiting on the API. I've since added a circuit breaker." This is a developer who has run production systems under real conditions.
The Paid Trial Project: the Most Reliable Signal
For any full stack developer hire that will last more than a month, a paid 6–8 hour trial project is more reliable than any interview. The task: implement a small feature with both a backend API endpoint and a frontend component — a user profile update flow, a simple search with filtering, a paginated list with a create form.
What to evaluate: Does the backend endpoint handle the error cases (missing fields, invalid data, not found)? Does the migration run correctly? Does the frontend handle the loading and error states, not just the success state? Is the code structured consistently with how a team project would be? Are there any tests?
A developer who produces clean, correct output on a trial project across both layers with no guidance needed is the hire. A developer who produces correct output on only one layer and approximate output on the other has shown you their real T-shape.
Frequently Asked Questions
How long should a full stack developer interview take? 45 minutes: 10 minutes on background (what they've built, at what scale), 25 minutes on the three questions above, 10 minutes for the candidate's questions. The candidate's questions reveal as much as their answers — someone asking about deployment practices, code review culture, and technical debt is thinking about quality. Someone asking only about salary and remote policy is not.
Should I ask to see code during the interview?
If the candidate has public GitHub repositories, review them before the interview and ask about specific choices in their code. "I see you used select_related here — when would you use prefetch_related instead?" is a much more revealing question than a generic interview question, and it's not possible to prepare a memorised answer to it.
What if the candidate answers all three questions well but the trial project is weak? Trust the trial project. Interview answers can be prepared; a 6-hour trial project under a specific scope cannot. The reverse — weak interview, strong trial — is also informative and usually favours the trial output.