Fullstack Engineer

A fullstack engineer builds both the parts of a software product that users see and click on (the "frontend") and the parts that run on servers behind the scenes — the logic, the databases, the connections to other systems (the "backend"). In practice you take a feature from a rough description through to working, tested code that real people use, rather than handing your half over to someone else. Most work for software companies, banks, retailers, media firms, startups, consultancies or public sector digital teams, sitting in a small team alongside other engineers, a product manager and often a designer.

Approximate graduate salary

Roughly GBP 28,000-40,000 to start is a fair approximation, but this varies very widely. London and large technology or finance employers sit at or above the top of that range; smaller companies, agencies, charities and roles outside the major cities often sit below it. Public sector digital roles tend to pay less at entry but publish their pay bands openly.

What you'd actually do

Picking up a ticket (a described piece of work) from the team's backlog, writing the code for it, and running it locally to check it behaves as expected — this is where most of the week goes.
Writing automated tests so that the feature keeps working when someone else changes the code later, and fixing tests you've broken elsewhere.
Reviewing other engineers' code: reading a colleague's proposed change, leaving comments on it, and having your own changes picked apart in return. This is normal and not a criticism of you.
Attending a short daily stand-up (a quick team catch-up on what everyone is doing and what's stuck) and, on some teams, longer planning or retrospective sessions every week or two.
Debugging things that are already live — a page loading slowly, a form failing for certain users, an overnight job that didn't run. Tracing this often means reading logs and monitoring dashboards, not just reading code.
Talking to a product manager or designer to pin down what a vague requirement actually means before you build it, and pushing back when the technical cost is higher than they realise.
Deploying changes to production, usually through an automated pipeline, and watching to see nothing breaks afterwards.

How graduates get in

Structured graduate schemes at larger technology employers, banks, retailers, telecoms and consultancies — usually opening in autumn for the following summer, with online coding tests, a technical interview and often a longer 'assessment centre' style day. Common route, but competitive.
Direct application to a junior or graduate developer role at a small or mid-sized company or a startup. Very common, often advertised year-round rather than in an autumn cycle, and typically judged more on a practical coding exercise and a portfolio than on your university.
A summer internship or industrial placement year during your degree, converted into a graduate offer. This is one of the most reliable routes in, and worth targeting early in your degree.
Software or digital apprenticeship-style routes and degree apprenticeships — relevant if you're deciding before university, and some employers also run graduate-level apprenticeship programmes that combine work with a formal qualification.
Conversion from a non-computing degree, via an MSc computer science conversion course or an intensive coding bootcamp. This genuinely works but is more variable — bootcamp graduates often need a strong personal portfolio and some persistence, and some large graduate schemes screen on degree subject.
Self-taught entry with a substantial public portfolio (open source contributions, deployed side projects). Real but the hardest route; smaller companies are far more open to it than big graduate schemes.

What employers ask for

A degree is usually expected, but the subject matters less than people think. Computer science, software engineering, maths, physics and engineering are the most common; humanities graduates do get in, particularly through conversion MScs, bootcamps or a strong portfolio.
Some large graduate schemes still filter on a 2:1 and on UCAS points or A-level grades; many smaller employers and startups don't look at grades at all. This varies a lot — check the specific advert rather than assuming.
Demonstrable ability to write code in at least one language, evidenced through coursework, projects, a GitHub profile or a technical test. Almost every employer will test this directly rather than take your word for it.
Familiarity with version control (Git) and the basic workflow of branching, opening a pull request and merging — this is assumed knowledge on day one at most places.
No compulsory professional qualification exists for this role. Chartered status through BCS or the IET is available later in a career but is not a standard requirement, unlike accountancy or law.
Right to work in the UK matters practically — some employers sponsor visas for graduate engineering roles and many smaller ones do not, so check before investing time in an application.

Skills that matter

Reading unfamiliar code

You will spend far more time understanding a large existing codebase someone else wrote than writing new code from scratch.

Systematic debugging

Being able to narrow a fault down methodically — reproduce it, isolate it, test a hypothesis — is what separates engineers who fix things in an hour from those who flail for a day.

Working comfortably across the frontend/backend boundary

The role exists precisely because features cut across both, so you need to be willing to switch between browser-side layout and behaviour and server-side data and logic without treating either as someone else's problem.

Understanding data and databases

Most bugs and most performance problems trace back to how data is stored, queried or shaped, so knowing how to write and reason about queries is disproportionately useful.

Writing clearly in plain English

You'll write pull request descriptions, technical explanations for non-technical colleagues and incident write-ups; unclear writing slows the whole team down.

Estimating and scoping honestly

Being able to say 'that's two days, but only if we drop this part' is what makes you trusted by product managers and stops you being permanently behind.

Where it leads

Junior/graduate engineer: you work on well-defined tickets with close code review and a mentor or buddy. This phase commonly lasts somewhere between one and three years, but there's no fixed timetable and it depends heavily on the team.
Mid-level engineer: you take a whole feature from vague idea to shipped, make design decisions yourself, and start reviewing other people's work. Most graduates reach this within a few years, though titles and thresholds differ enormously between employers.
Senior engineer: you're trusted with ambiguous or risky work, you shape how systems are built rather than just building them, and you spend real time unblocking and mentoring others.
From senior, the path usually forks. One branch is technical — staff or principal engineer, architect, or specialising into an adjacent area such as platform/infrastructure, security, data engineering or machine learning engineering. The other is management — team lead, engineering manager, then head of engineering or CTO in smaller organisations.
Alternative exits are common and not a failure: moving into product management, developer relations, technical consultancy, freelancing or contracting, or founding a company. Fullstack experience is unusually portable because you've seen the whole system.

What people get wrong

“Fullstack means you're expected to be equally expert in everything, from CSS to database tuning to cloud infrastructure.”

In practice almost every fullstack engineer is stronger on one side and competent enough on the other to be useful. Employers are looking for someone who can work across the whole feature without getting stuck, not a specialist in every layer.

“The job is mostly typing code alone with headphones on.”

A large share of the week goes on reviewing others' code, clarifying requirements, discussing designs, and investigating problems. Teams routinely reject strong coders who can't explain their reasoning or work with a product manager.

“You need a computer science degree, and without one you're locked out.”

Plenty of fullstack engineers came in through maths, physics, other sciences, conversion MScs or bootcamps. What's non-negotiable is being able to demonstrate you can actually build things — the degree subject is a proxy that many employers, especially smaller ones, happily bypass.

“The specific programming language or framework you learn at university determines your career.”

Languages and frameworks come and go, and most engineers pick up new ones repeatedly. Employers generally care that you understand underlying concepts — how data flows, how the web works, how to structure a program — because they expect to retrain you on their particular stack anyway.

Where this varies

"Fullstack engineer" covers quite different jobs depending on where you land. At a startup it can mean genuinely doing everything — frontend, backend, deployment, sometimes talking to customers — with little supervision and fast-changing priorities. At a large bank, retailer or established software company, teams are bigger, there are dedicated specialists for infrastructure, testing and security, and there's more process, more code review and more compliance around what you're allowed to change. Consultancies add a further difference: you may move between client projects and technologies every few months, which builds breadth quickly but gives you less ownership of any one product. Job titles are also inconsistent across the market — "software engineer", "developer", "web developer" and "fullstack engineer" often describe overlapping work, so read the responsibilities and the technologies listed rather than the title.

General guidance about the role across the UK market, not about any specific employer. Entry routes and requirements vary — always check the individual job advert.