What this subject covers
Software engineering and development is about building software that works reliably for real users and can be maintained by other people over time. It overlaps with computer science but leans towards different questions. Computer science asks what can be computed and how efficiently. Software engineering asks how to specify, design, build, test, change and maintain a system without it falling apart. Courses in this family include software engineering, software development, web development, web technologies and mobile computing. Their emphasis varies, so read course descriptions carefully before deciding which evidence to put first.
A useful statement shows that you understand software as something made for someone, under constraints, and changed over time. It should not read as a list of languages you have touched.
How the course types differ and what evidence suits each
Software engineering
These courses usually emphasise process and quality. Typical topics are requirements, design, architecture, testing, version control, working in teams on shared code, and the long-term cost of decisions. The strongest evidence shows you thinking about a problem beyond the first version of the code. Examples include a bug that taught you why tests matter, a project you rewrote because the original structure made changes painful, or a clash between what a user wanted and what you had built.
Software development
These titles are often more applied and practical, focused on building working applications in common languages and tools. Here, completed artefacts and what you learned while finishing them carry weight. A small finished program that someone actually used says more than an ambitious one that stopped halfway, unless you can explain clearly why it stalled and what that taught you.
Web development and web technologies
These courses deal with how the web works: the client and server, HTTP, HTML and CSS, JavaScript, databases behind sites, accessibility, performance and security. Good evidence goes beyond appearance. For example, you might explain:
- why a page loaded slowly and what you changed;
- how you stored and retrieved data;
- what happened when you tested a form with unexpected input;
- how you made a page usable with a keyboard or screen reader.
If your interest is mainly visual layout and user experience, look at whether human-computer interaction or design-focused courses fit you better.
Mobile computing
Mobile courses add constraints such as small screens, touch input, battery life, intermittent connectivity, device sensors and app platform rules. Evidence is strongest when it engages with those constraints. Examples include an app that had to work offline, or noticing why an app drained a battery. If your interest is mostly hardware, sensors and low-level devices, embedded systems courses may suit you better.
Interests worth writing about
An interest is useful when you can say something specific about it. Areas that fit this subject well include:
- Why software fails. You might follow a widely reported outage or bug and think about what a better process could have caught. Do this cautiously, and only from what is publicly known.
- Maintainability. Reading someone else’s code, or your own code from months ago, and realising why naming, structure and comments matter.
- Testing. The difference between code that runs and code you have reason to trust.
- Collaboration on code. What changed when two people edited the same project, and how version control helped or caused confusion.
- Users with different needs. Accessibility, older devices, slow connections, or users who are not confident with technology.
- Security and data handling. Basic issues such as validating input or not storing passwords in plain text. Present this as awareness, not expertise.
- Trade-offs. Choosing a simple solution over a clever one, or a familiar tool over a fashionable one, and being able to justify the choice.
Naming a field such as artificial intelligence or games is not enough by itself. If those interest you, connect them to building and maintaining software. For example, you might describe the engineering problems you hit when training a small model or structuring game logic. If your real interest is the theory of algorithms, a computer science course may be the better match.
Preparation and activities that give you something to say
None of these is a requirement. They are ways to produce evidence you can reflect on.
- A small project you finish and someone else uses. Examples are a revision quiz for classmates, a rota tool for a club, a page for a local group, or a script that automates a tedious task. Having a real user forces you to deal with requirements and feedback.
- Adding a feature to something you already built. This shows you what poor early structure costs, which is the central concern of software engineering.
- Writing tests for your own code. Even a few simple tests give you something concrete to discuss about confidence and change.
- Using version control. Keeping a project in a repository, writing meaningful commit messages, and recovering from a mistake you made.
- Reading and modifying existing code. Fixing a small issue in an open-source project, or adapting a tutorial project in ways the tutorial did not cover. Be honest about how small your contribution was.
- School coursework. A Computer Science programming project, or an EPQ that involves building and evaluating software, is directly relevant. Write about the design decisions and the evaluation, not just the final product.
- Competitions, hackathons or coding clubs. These are useful mainly for what working fast with others taught you about planning, division of work, and what you would do differently.
- Reading about practice. Choose material on how software is designed, tested and maintained, and connect a specific idea to something you built or observed.
Making reflection useful
Admissions readers learn little from a statement that you built an app in a certain language. They learn more from what you decided, what went wrong and what you would change. When you describe a project, try to cover:
- who it was for and what they actually needed, which may differ from what you first assumed;
- one design decision and the alternative you rejected;
- a specific problem, how you found its cause, and how you knew it was fixed;
- what you would do differently if you started again;
- what you still do not understand and would expect to study.
For example, “I built a homework tracker in Python” is a fact. Compare: “When three friends used my homework tracker, two entered dates differently and it crashed; I added input validation, then realised I should have tested with other people before adding features.” That shows you learning about requirements and testing. Use your own real details. Do not borrow this example.
If you have no direct programming project or placement
You can still draw on experience, provided you are honest about what it shows. Each example below has a genuine connection to software, and a clear limit.
- A retail or hospitality job using tills, stock or booking systems. You saw software used under pressure by real staff, and perhaps noticed workarounds people invented for bad design or failures at busy times. This shows attention to users and requirements. It does not show you can build software, so say what you noticed, not that you understand how the system was built.
- Helping a relative or someone you care for use phones, apps or online services. This can give real insight into accessibility, confusing interfaces and assumptions designers make about users. It is evidence of perspective, not technical skill.
- Volunteering where records are kept on spreadsheets or shared documents. Organising data, reducing duplicated entries or creating a simple formula-based tool connects to data structure and automation. Keep the claim modest: it is a step towards programming, not equivalent to it.
- Maths and physics. Breaking problems into steps, checking edge cases and proving that something works relate to logic and testing. Mention a specific moment, such as finding an error by checking a boundary case, rather than claiming that maths makes you a good programmer.
- Design and Technology or engineering projects. Iterating on a design against a specification, and testing against requirements, mirrors the software lifecycle. Make the parallel explicit and brief.
- Hobbies such as modding games, building spreadsheets for a sports team, or customising website templates. These count if you can describe what you changed and why. Playing games or using apps a lot does not, on its own, show interest in building them.
- Writing structured instructions or rules. Writing instructions or rules for a game, or a process at work, connects to specifying behaviour precisely. This is a weak link unless you draw out the precision and ambiguity issues clearly.
If you have not programmed at all, consider starting something small before you write, using free introductory resources. Then describe it plainly as a beginning. A modest, honest start reflected on well is better than claimed familiarity with many languages.
Subject-specific pitfalls
- Listing languages, frameworks and tools. A list shows exposure, not understanding. Mention a tool only when you have something to say about using it.
- Overclaiming. Describing a tutorial project as an app you developed, or calling yourself a full-stack developer, invites doubt. Precise, modest descriptions read as more credible.
- Confusing using technology with making it. Owning devices, following technology news, or building a gaming PC are not in themselves evidence for software engineering.
- Treating the course as job training only. A degree is not the same as a particular developer role. Show interest in the principles behind building software, not just in a salary or a specific company.
- Ignoring the people involved. Software engineering involves users, teammates and future maintainers. A statement focused only on writing code alone misses most of the subject.
- Writing a computer science statement under a different title. If your evidence is all about algorithms and theory, either make the connection to building systems or consider whether computer science fits you better.
- Fixating on visual design for web or mobile courses. Appearance matters, but these courses also cover data, performance, security and behaviour across devices.
- Vague claims about passion for coding since childhood. Replace them with one specific thing you built, broke or improved, and what it taught you.
For general advice on planning, structure and editing, read our personal statement writing guide.
Software engineering and development personal statement examples