Software Engineer

Software engineers design, write, test and maintain the code behind applications, websites, internal business systems and the infrastructure that runs them. Most work in a team on an existing product rather than building something from scratch, and the "customer" might be the public, another business, or colleagues in the same organisation. The job is as much about reading and changing other people's code, fixing things that break and agreeing how something should work as it is about typing new code.

Approximate graduate salary

Typically somewhere around GBP 28,000-45,000 to start, but this varies very widely. The upper end is concentrated in London, in finance and in a small number of large technology employers; regional roles, smaller firms, charities and parts of the public sector commonly start lower. Treat any single figure with caution - the spread in this field is genuinely large.

What you'd actually do

Picking up a ticket (a small, defined unit of work) from the team's backlog - a bug fix, a new feature, a change to an existing screen or API - and working out what actually needs changing before writing anything
Writing code and accompanying automated tests, then opening a pull request so a colleague reviews your changes line by line before they are merged into the shared codebase
Reviewing other people's pull requests, which often means reading unfamiliar code and asking why something was done a particular way
A short daily stand-up meeting where the team says what they're working on and what's blocking them, plus periodic planning and retrospective sessions in teams that use agile ways of working
Debugging - reproducing a fault someone has reported, reading logs and error traces, and narrowing down which part of the system is misbehaving
Deploying changes to test and live environments, and sometimes watching dashboards afterwards to check nothing has degraded
Talking to non-engineers: product managers, designers, testers or business stakeholders, usually to pin down vague requirements into something buildable

How graduates get in

Structured graduate schemes, common at large banks, retailers, telecoms firms, consultancies, defence and engineering companies and the Civil Service. These usually recruit in autumn for the following September, often with rotations across teams and sometimes an initial training bootcamp.
Direct application to a junior or graduate developer vacancy at a smaller company or scale-up. This is very common and often happens year-round rather than in a fixed recruitment cycle - smaller employers tend to weight your portfolio and a technical conversation more heavily than your degree classification.
Converting from a summer internship or a placement year (the 'sandwich' year on a four-year degree). A placement year is one of the strongest routes in, because many employers make graduate offers to returning placement students.
Degree apprenticeships in software engineering or digital technology solutions - an alternative to the graduate route rather than a follow-on, where you work and study for a degree simultaneously. Worth knowing about if you are deciding between university and work.
Conversion routes for non-computing graduates: an MSc computer science conversion course, or a coding bootcamp. Bootcamp graduates do get hired, but more often by smaller firms and agencies than by competitive graduate schemes, and outcomes vary a lot by bootcamp and by how much you build on your own afterwards.
Moving sideways from an adjacent technical job - software testing, IT support, data analysis - having learned to code on the job. Less common as a first destination from university but a genuine route.

What employers ask for

A degree in computer science, software engineering or a closely related subject is the most common background, but it is not universally required. Maths, physics, engineering and other numerate degrees are widely accepted, and some employers accept any degree subject if you can demonstrate coding ability.
Many graduate schemes ask for a 2:1, some for a 2:2, and a growing number have dropped a formal grade requirement in favour of technical assessment. Some larger employers still filter on UCAS points or A-level grades; this varies enormously and is worth checking per advert.
Demonstrable coding ability in at least one language - commonly Python, Java, C#, JavaScript/TypeScript, C++ or Go. Employers care far more that you can program well in something than that you already know their exact stack.
Evidence you have built something: a dissertation project, personal projects on GitHub, hackathon work, open-source contributions, or a placement. For candidates without a computing degree this is usually the deciding factor.
No professional licence or exam is required to practise. Chartered Engineer (CEng) or Chartered IT Professional (CITP) status exists and is sometimes valued in defence, engineering and government contexts, but most commercial software engineers never pursue it.
Security clearance (BPSS, SC or higher) is required for defence, intelligence and some government and critical-infrastructure work, which usually means UK residency requirements and can rule out some candidates.

Skills that matter

Reading and understanding unfamiliar code

Almost all graduate work involves changing a large existing codebase you did not write, so comprehension matters more than raw writing speed.

Systematic debugging

A large share of the job is working out why something behaves unexpectedly, and the engineers who do this methodically rather than by guesswork are noticeably more productive.

Version control with Git

Branching, merging, resolving conflicts and writing clear commit histories is how teams collaborate daily, and it is assumed knowledge from day one.

Writing and maintaining automated tests

Most professional teams will not merge untested code, and testing is often where graduates make their first useful contributions.

Explaining technical trade-offs to non-technical people

You will regularly need to tell a product manager why a requested change is cheap, expensive or a bad idea, in language that doesn't rely on jargon.

Knowing when to ask for help

Teams expect graduates to be stuck sometimes, and spending a day silently blocked is treated far more negatively than asking a clear question after an hour.

Where it leads

Graduate or junior engineer, typically for the first year or two: you work on well-defined tickets with close review, and much of the job is learning the codebase, the tooling and the team's conventions.
Mid-level or 'software engineer' proper: you take on larger pieces of work, design small features yourself, review others' code and are trusted to work with less supervision. Reaching this point commonly takes a couple of years but varies widely by employer and by how much responsibility the team hands out.
Senior engineer: responsible for the design of substantial parts of a system, mentoring juniors, and often the main technical voice in conversations with product and business stakeholders. Timelines here vary a great deal - some reach it in a few years, others take considerably longer, and job titles are not consistent between companies.
The path then forks. The technical track leads to staff/principal engineer or software architect, where you influence design across multiple teams. The management track leads to engineering manager, then head of engineering or CTO at smaller organisations. Many engineers move between the two over a career.
Common sideways moves include product management, developer relations, site reliability or platform engineering, data engineering, security engineering, technical consultancy, and contracting or freelancing - the last of which can pay well but removes the stability of employment.

What people get wrong

“You spend most of the day writing new code.”

A substantial part of the week goes on reading existing code, reviewing colleagues' work, debugging, writing tests, in meetings and working out what the requirement actually is. Many engineers write relatively few lines of new code on a typical day.

“You need a computer science degree.”

It is the most common route and it helps, particularly for competitive graduate schemes, but plenty of working engineers came through maths, physics, engineering, conversion MScs or self-teaching. Demonstrable ability tends to override subject once you get to a technical interview.

“It is a solitary job suited to people who prefer not to deal with others.”

Software is built by teams, and the work is highly collaborative - pairing, code review, stand-ups and negotiating requirements with non-technical colleagues. Communication is a core technical skill, not an optional extra.

“You should learn whichever language is currently fashionable to get hired.”

Employers mostly test general programming ability and problem-solving, and expect you to pick up their stack on the job. Depth in one language is more useful than shallow familiarity with several.

Where this varies

The job differs a lot by employer type. At a large bank, insurer or government department you may work on long-lived internal systems, with heavy process, formal change control, regulatory constraints and older technology alongside modern work - the trade-off is structure, training and stability. At a startup or scale-up you are likely to touch more of the stack, ship faster, get responsibility sooner and face less supervision, with correspondingly less formal training. Consultancies and agencies place you on client projects, so you change domain and sometimes technology every few months and may travel or work on client sites. Defence and intelligence work requires security clearance and can involve restrictions on what you can discuss or where you can work. Specialisms also diverge early: front-end (what users see), back-end (servers, data, logic), full-stack, mobile, embedded or firmware (code running on physical devices), games, and platform or infrastructure engineering all feel like quite different jobs despite sharing a title. Remote and hybrid working is more common in this field than in most, but has tightened at some employers.

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.