In 2023, a hiring manager at a Series B fintech told me her team had stopped using the title “full stack engineer” entirely, because it had become meaningless. Some people who claimed it could barely write a SQL query; others genuinely owned the entire product surface from database schema to animation. The title says less about someone’s actual capabilities than it did five years ago.
That’s the honest starting point for comparing these three roles. The categories are real, the differences in daily work are real, but the labels have blurred considerably, and anyone who tells you the boundaries are clean is probably selling a course.
What frontend developers actually do all day
The day-to-day for a frontend engineer is closer to product work than most people expect. You’re not just implementing designs; you’re making hundreds of micro-decisions about state, performance, and user experience that a designer didn’t spec out.
On a typical day: reviewing a design in Figma, building a component in React (or Vue, or Svelte, depending on the company), debugging a layout issue that only reproduces on mobile Safari, writing tests, and probably attending a meeting about an upcoming feature where you’re the only person in the room who can estimate how long the UI work will take.
The skills that actually differentiate strong frontend engineers are less about knowing the most framework tricks and more about: understanding how browsers work at a reasonable depth, caring about performance metrics like LCP and CLS (Google’s Core Web Vitals), and being able to communicate tradeoffs clearly to product managers and designers.
What backend developers actually do
Backend work is largely invisible to users, which is both a technical challenge and a career observation. When backend is working, nobody notices. When it breaks, everything breaks.
A backend engineer spends much of their time on: API design and evolution, database query optimization, authentication and authorization logic, and infrastructure decisions (how services communicate, how deployments work, how failures are handled). At larger companies there’s significant overlap with platform engineering and SRE. At smaller companies a backend engineer often owns production incidents end to end.
The cognitive mode is different from frontend. Frontend work has immediate visual feedback; you can see if something worked. Backend work is more like: write code, check logs, verify behavior through the consequences of actions rather than the actions themselves. Some people find that more satisfying; others find it frustrating.
Full stack: what it means in practice vs. what job postings say
Job postings for “full stack engineers” have proliferated, partly because companies want to hire fewer people to build more things. The Stack Overflow Developer Survey 2024 found that “full-stack developer” is the most common job title among respondents, at roughly 35% of all developers surveyed. That number probably reflects how many companies default to the title rather than how many people are genuinely operating across the full stack.
In practice, most people who call themselves full stack are stronger on one side. Someone with 6 years of React experience who also writes some Express endpoints is a frontend engineer who can do some backend. Someone who spent most of their career in Django and picked up React two years ago is a backend engineer who can do frontend. That’s fine; genuine depth-on-both-sides is rare and doesn’t necessarily correlate with being a better engineer.
The real full stack engineers I’ve seen at smaller startups are doing something specific: they own features end to end, from database migration to UI, which means they can ship faster without coordinating across team boundaries. That’s the actual value proposition, not that they’re twice as skilled.
Salaries: the gap is real but smaller than you might think
According to the Bureau of Labor Statistics, the median annual wage for software developers was $132,270 in 2023. The BLS doesn’t break this down cleanly by frontend/backend/full stack, but third-party compensation surveys generally show backend and full stack roles paying 8-12% more than frontend at mid-level, with the gap narrowing at senior and staff levels.
This probably reflects a few things: backend work often touches more business-critical systems (payment processing, data pipelines), and there’s historically been slightly higher demand for backend engineers relative to supply. Whether or not that gap persists as frontend engineering gets more complex is an open question. I’d argue frontend engineering at companies obsessed with performance and accessibility is as technically demanding as most backend work, but I acknowledge that’s a minority opinion.
How these roles interview differently
Frontend interviews heavily weight live coding in a browser environment. You’ll likely build or fix a React component, answer CSS/layout questions, and discuss performance optimization. At senior levels, there’s often a component architecture or “frontend system design” round.
Backend interviews lean toward data structures and algorithms (especially at larger companies), API design, database schema questions, and system design at scale. The Leetcode-heavy interview culture is more common on the backend side, though this varies significantly by company.
Full stack interviews are unpredictable. You might get a frontend-heavy loop, a backend-heavy loop, or genuine coverage of both. The best preparation is to identify which side of the stack the company’s product emphasis sits on and make sure you’re solid there first.
Which one should you pursue?
The honest answer is: whichever one you find more engaging when you’re actually doing it, not just thinking about it. Build something small in each direction. A React app with a real backend API and a real database is about a weekend of work and tells you far more about your preferences than any job description will.
Many people are not having the career they wanted because they picked a specialization based on salary projections instead of the kind of work they’ll spend 40 hours a week doing. This is, of course, not universal. Financial constraints are real. But if you’re earlier in your career and have flexibility, the skill that has the highest long-term value is genuine passion for the work itself.
Full stack is probably best arrived at, not started from. Learn one side well enough that you’d be hired for it, then expand. The engineers I know who operate most effectively across the full stack got there by spending years in one domain before deliberately broadening. Starting as “full stack” often means staying shallow on both sides for longer than is useful.