Mid Software Engineer
A mid-level (or "mid-weight") software engineer writes, tests and maintains the code behind an employer's products or internal systems - web applications, mobile apps, back-end services, data pipelines or embedded software, depending on the company. Unlike a junior, they are expected to pick up a feature or bug and take it through to production largely on their own, and to help review and unblock more junior colleagues. They work inside a team of engineers alongside product managers, designers, testers and sometimes data or operations staff.
- Starting salary
- £28k–£40k
- Live graduate jobs
- 4 open now
- Main way in
- This is normally not a direct-entry graduate role
- They usually ask for
- Commercial experience is the real requirement
Approximate graduate salary
Entry-level graduate software engineer roles typically start somewhere around £28,000–£40,000, and mid-level roles commonly sit meaningfully above that - but this is only a rough approximation. It varies a great deal by region (London and some tech hubs pay more), by sector (finance, trading and large tech tend to pay above public sector, charities and agencies) and by employer size, and some roles add bonuses or share options on top.
1What you'd actually do
- Writing and changing code against tickets in a tracking tool (such as a Jira or Linear board) - typically a mix of new features, bug fixes and small improvements to existing code rather than building things from scratch.
- Reviewing other people's pull requests - reading a colleague's proposed code change, leaving comments on correctness, readability and edge cases, and approving or asking for changes. Most teams require at least one review before code is merged.
- Writing automated tests (unit tests, integration tests) and fixing the ones that break when the build pipeline runs.
- Attending a short daily stand-up and periodic planning or refinement sessions where upcoming work is sized and clarified with the product manager.
Show 3 moreShow fewer
- Debugging production problems - reading logs and monitoring dashboards to work out why something is slow or failing, sometimes under time pressure if customers are affected.
- Writing or updating small design documents and technical notes before building anything non-trivial, and discussing the approach with a senior engineer or the wider team.
- Helping newer joiners: pairing on a tricky bug, explaining how a service fits together, or answering questions about the codebase.
2How graduates get in
- This is normally not a direct-entry graduate role. The usual path is to join as a graduate or junior software engineer and be promoted to mid level after roughly two to four years, though this varies a lot by employer and some people move faster.
- Structured graduate schemes at large employers (banks, insurers, telecoms, retailers, defence and engineering firms, consultancies, the Civil Service and some tech companies) - these usually involve online coding assessments, a technical interview and sometimes an assessment centre.
- Direct junior/entry-level engineer applications at smaller companies, start-ups and agencies, where there is no formal scheme and you interview straight into a team. Very common, and often faster-moving.
- Degree apprenticeships in software engineering or digital technology solutions - an increasingly common route that means some people reach mid level earlier than graduates, because they have been working throughout.
Show 2 moreShow fewer
- Coding bootcamps or self-taught routes with a strong portfolio - realistic but harder, and usually requires demonstrable projects or open-source contributions. Some employers specifically run bootcamp-to-hire pipelines; others filter on degree.
- Occasionally a graduate with substantial prior experience - a strong placement year, significant freelance or open-source work, or a postgraduate research background - is hired straight into a mid-level posting. This happens but is the exception, and the title still implies you can work with limited supervision from day one.
3What employers ask for
- Commercial experience is the real requirement. A mid-level advert normally expects a couple of years of professional development, or demonstrably equivalent experience - this is the main thing separating it from a graduate advert.
- A degree in computer science, software engineering, maths, physics or a related subject is the most common background, but the subject matters less than it does in many fields - plenty of mid-level engineers came from unrelated degrees, apprenticeships or bootcamps. Some large graduate schemes still filter on a 2:1 or on UCAS points; many smaller employers do not look at grades at all.
- Working knowledge of at least one mainstream language and its ecosystem - for example Java, C#, Python, JavaScript/TypeScript, Go, or C++ in embedded and games work. Employers usually care more that you can learn their stack than that you already know it.
- Familiarity with version control (Git), testing, and the basics of how code gets deployed - continuous integration pipelines, containers, cloud platforms such as AWS or Azure. Depth expected here varies hugely.
Show 2 moreShow fewer
- No mandatory professional qualification exists. Cloud certifications and security clearance (for defence, government and some finance work) can matter in specific sectors; chartered status through BCS or IET exists but is uncommon and rarely required.
- Interviews almost always include a practical element - a live coding exercise, a take-home task, a system design discussion, or walking through code you have written before. The format varies enormously between employers.
4Skills that matter
Reading and changing unfamiliar code
Most mid-level work is modifying a large existing codebase someone else wrote, not greenfield building, so the ability to orient yourself quickly matters more than raw coding speed.
Systematic debugging
Working out why something fails in production - forming a hypothesis, checking logs and data, narrowing it down - is a large slice of the job and the skill that most visibly separates mid from junior.
Breaking work into small, shippable pieces
You are expected to take a vague ticket and decide the order to build things in so that progress is visible and risk stays low, rather than disappearing for three weeks.
Writing clearly in short form
Pull request descriptions, design notes, incident write-ups and Slack explanations are how decisions get made in distributed teams, and poorly explained work gets blocked.
Giving and taking code review
You will review juniors' work daily, and being able to flag a problem without being discouraging - and to accept criticism of your own code without defensiveness - keeps a team functioning.
Knowing when to ask
Mid-level engineers are trusted to work alone but judged on knowing the point at which struggling privately for another day is wasteful, which is a genuine judgement call.
Putting these on a CV? We counted which skills 12,914 live graduate adverts ask for, and what to do with the answer — part of our application advice.
5Where it leads
Graduate or junior engineer - closely supervised, small well-defined tickets, lots of pairing and review. Typically the first one to three years.
Mid-level engineer - owns features end to end, reviews others' code, contributes to technical decisions. Many people stay here for several years and that is entirely normal.
Senior engineer - leads larger pieces of work, makes design decisions, mentors formally, and is often the person stakeholders come to. The step up is usually about scope and influence rather than coding ability. Timeframes vary widely; some reach it in a few years, others take much longer or deliberately don't chase it.
From senior, the path usually forks: a technical track (staff/principal engineer, architect) or a people-management track (team lead, engineering manager, head of engineering). Both are well-established and neither is considered a demotion from the other.
Sidesteps are common and well paid: moving into platform or site reliability engineering, data engineering, security engineering, developer relations, technical product management, solutions architecture, consultancy, or contracting/freelance work.
What people get wrong
“"Mid-level" is a formal, standardised rank you are awarded.”
There is no industry-wide definition. Some companies have explicit levelling frameworks with published criteria; many smaller ones just call everyone "software engineer" and decide seniority informally. A "mid" at one employer may be doing what another calls senior, so job titles are a poor guide to the actual work - read the advert's responsibilities instead.
“The job is mostly writing new code.”
A large share of the week goes on reading existing code, reviewing colleagues' changes, debugging, writing tests, and discussing what to build. Many mid-level engineers find their actual typing-new-code time is a minority of the day, and the hard part is usually understanding the problem rather than expressing the solution.
“You need to be brilliant at maths or at competitive-programming-style puzzles.”
Some interview processes still test algorithm puzzles, so practice helps for getting hired, but the day job rarely needs them. Far more valuable is patience with messy legacy systems, clear communication and good judgement about trade-offs.
“Progression means becoming a manager.”
Most UK software employers of any size now run a parallel technical track, so you can keep going up in pay and influence as a staff or principal engineer without ever managing anyone. Moving into management is a change of job, not a promotion in kind.
6Where this varies
The day-to-day differs sharply by sector. At a start-up or small agency you may touch everything - front end, back end, infrastructure, even talking to customers - with little process and fast release cycles. In a bank, insurer, government department or defence contractor, you are more likely to work on a narrow part of a very large system, with formal change approval, compliance requirements, longer release cycles and sometimes security clearance. Consultancies place you on client projects that rotate every few months, which means variety but less long-term ownership. Remote and hybrid patterns also vary a lot: some employers are fully remote, others expect several days a week in an office, and this is worth checking before applying.
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.