Full-stack development is the discipline of owning a product slice end to end: the interface a user touches, the API in the middle, and the database underneath. The 2025 Stack Overflow survey confirms the title is the industry's default: full-stack developer is the single most common role, claimed by 27% of respondents, with the architect role entering the survey for the first time in fourth place. The environment those developers ship into is now near-universally cloud native; the CNCF's 2025 survey finds 98% of organisations using cloud native techniques and 82% of container users running Kubernetes in production. Three-quarters of developers build websites and business software, JetBrains reports, which makes web applications the centre of gravity for the discipline. What the title hides is where each candidate actually lives along the stack.
Challenges in Full-Stack Development Recruiting
Full-stack architecture where the seam is nobody's job
The most common full-stack failure is organisational, and it predates any line of code: nobody owns the seam. The browser side belongs to the frontend team's taste, the service side to the backend team's, and the contract between them is a JSON shape argued about in code review. A full-stack hire is often brought in precisely to be that owner, and the interview never asks whether they ever were one. The evidence question is simple: describe the last API contract you changed and how the client and the server adopted it together. Candidates who have held the seam talk about versioning, backwards compatibility and rollout order. Candidates who have only visited both sides of it talk about features. The deeper tell is language: owners of the seam say "contract", "payload shape" and "rollout order" without prompting. Visitors say "endpoint" and "component" and hope nobody asks how they meet. Full-stack architecture in a hiring brief should name which part of the seam the seat owns, because "both" is how the role died last time.
Cloud applications that moved the database out of the repo
The stack a full-stack developer claims to own is not the stack they operate anymore. Managed data layers have replaced the local database for a large share of new work: the survey records PostgreSQL at 58.2% among professional developers, but the fastest-moving parts of the ecosystem are managed and hosted offerings, with Supabase at 6.1% and rising. The hiring consequence is a split between two generations of full-stack development. The older generation models schemas, writes migrations and watches a local engine chew through a query. The newer generation calls a hosted API and has never once watched a slow query, because the platform will not show it to them. Both are legitimate hires; they are not interchangeable, and a brief that says "databases" selects for the older generation by accident while describing a newer-generation product.
Multi-tenancy is where cloud applications stop forgiving
One-tenant cloud applications teach almost nothing about many-tenant ones. A single-customer deployment hides the decisions that matter at scale: tenant isolation, per-tenant rate limits, shared pool exhaustion, cross-tenant query leakage. The CNCF survey describes the same gap from the platform side: 98% adoption is table stakes now, and the difficulty has moved from running the software to running it for many customers at once. Full-stack candidates who built a dashboard for one client have no evidence for the seat that serves ten thousand tenants, and the reverse false negative exists too: a candidate whose tenancy work happened on a managed platform may never have seen the isolation logic because the platform absorbed it. The interview fix is to make the scaling axis explicit: what changed when the second tenant arrived, what query started scanning the wrong rows, what cache key leaked between accounts. Silence on all three means the candidate's cloud applications have never been tenanted, which is fine to know before the offer.
Full-stack architecture without a schema owner
Data modelling is the quiet half of full-stack work, and it is the half most often missing from the CV. A developer can ship for two years in Next.js and never design a table: the median page ships 613 kilobytes of JavaScript on desktop, and the framework generation that dominates the survey is server-rendering-first, which pushes data access behind an ORM or an API client. The result is a population of full-stack engineers fluent in frontend development and fluent-adjacent in backend development, with the database in the blind spot. When the schema has no owner, the product accumulates JSON columns, duplicated state and the two-sources-of-truth bug that wakes someone at quarter past two. Verification is a single exercise: describe the tables behind your last feature, their indexes and what the migration did when it ran against production data. Strong candidates narrate it; the rest narrate around it. One more check pays for itself: ask what the indexes cost in write amplification, because the candidate who cannot discuss write paths never designed a hot table. Then test the operational half: what did the backup strategy look like, because a full-stack owner who has never restored one has never really owned the data.
Incidents expose which cloud applications a full-stack hire actually ran
Every full-stack CV lists the same stack: TypeScript, React or Next.js, Postgres, some cloud. The separation between candidates lives in operations, which the CV cannot photograph. Ask for the last production incident: who noticed, what the latency graph did, which layer absorbed the fix and what changed afterwards. Ask what they would monitor if they owned a service from the browser to the database tomorrow. JetBrains records that developers now rate non-technical factors like communication as highly as tooling for delivery, which shows up in incident behaviour: the best full-stack hires wrote the runbook before the incident, not after. A candidate whose incidents all happened on someone else's platform has consumed reliability rather than produced it, and the role you are filling is the one that produces it.
Full-stack architecture claims a load spike cannot carry
Verification for full-stack seats is hardest at the middle of the funnel, where the same nouns describe very different depths: APIs, databases, cloud applications, full-stack architecture. The probes that separate owners from visitors are end-to-end by definition. Reconstruct one feature across the whole seam, from the click to the commit. Give them a p99 graph that degrades at 3 p.m. and a schema that has just outgrown its third normal form, and ask what they would change first and what they would refuse to change. The refusal matters more than the plan, because it reveals the constraints they have internalised. The cost of skipping this is measured in compounding seams: a weak senior full-stack hire becomes the new owner of the contract nobody owned, and the seams get worse with every sprint instead of better.
References
- 2025 Stack Overflow Developer Survey: Developers — Stack Overflow. (accessed 2026-09-28)
- 2025 Stack Overflow Developer Survey: Technology — Stack Overflow. (accessed 2026-09-28)
- The CNCF Annual Cloud Native Survey: The Infrastructure of AI's Future — Cloud Native Computing Foundation. (accessed 2026-09-28)
- The State of Developer Ecosystem 2025: Coding in the Age of AI — JetBrains. (accessed 2026-09-28)
- Web Almanac 2024: JavaScript — HTTP Archive. (accessed 2026-09-28)