What this subject area covers
This area spans several distinct families of courses. Course titles overlap, so read module lists rather than relying on the name. A course called Computing may lean towards software development at one institution and towards theory at another. Your evidence should fit the emphasis of the courses you are applying to.
- Computer science and computing covers algorithms, data structures, computational theory, programming languages, operating systems and the mathematics underneath them.
- Software engineering and development, including web and mobile development, covers how software is specified, designed, tested, maintained and built by teams over time.
- Information systems and business informatics covers how organisations collect, store and use information. This includes databases, systems analysis, process modelling and the gap between what a system does and what its users need.
- Human-computer interaction and graphics covers how people perceive and use interfaces, usability evaluation, and the mathematics and programming of rendering, geometry and visual computing.
- Networks, cloud and embedded systems covers how machines communicate, distributed and cloud infrastructure, and software running on constrained hardware such as microcontrollers and Internet of Things devices.
Artificial intelligence, data science and cybersecurity are treated as a neighbouring area. If those are your main interest, focus your evidence there rather than presenting them as general computing. Games development and animation also sit closer to film and games unless the course is clearly about graphics programming.
How evidence differs between the branches
The same activity can support different courses, depending on what you draw out of it. Take a small app you built:
- Computer science: discuss the algorithm or data structure choice, why it was efficient or inefficient, and what you learned about complexity or correctness.
- Software engineering: discuss how you organised the code, used version control, tested it, fixed bugs that returned, or changed the design when requirements changed.
- Information systems: discuss who used it, what information problem it solved, how the data was structured, and what happened when real users did not behave as you expected.
- Human-computer interaction: discuss how you watched people use it, which tasks confused them, and what you changed as a result.
- Networks or embedded: discuss how it communicated with other devices, handled latency or dropped connections, or ran within memory and power limits.
You do not need evidence for every branch. A focused statement for one emphasis is usually clearer than an attempt to touch all five.
Interests worth writing about
Strong interests are specific enough that you can explain a problem, not just a product. Saying you love technology or have used computers since childhood tells the reader very little. More useful examples include:
- Why some sorting or search approaches scale badly, which you noticed when a program slowed down on larger inputs.
- How recursion, logic or proof in maths connected to something you programmed.
- Why a school or workplace system frustrates its users, and whether the cause is the interface, the data model or the business process.
- How a website stays available under load, or what actually happens between typing an address and seeing a page.
- How a microcontroller reads a sensor, and why timing and limited memory change how you write code.
- How 3D graphics turns geometry and matrices into pixels, if you are drawn to graphics rather than games as entertainment.
- Accessibility, such as how screen readers interact with badly structured web pages.
Reading can support an interest if you engage with an idea from it. Name the concept, say what you did with it, and say where your understanding ran out. A list of titles or famous figures adds little.
Preparation and activities
None of these is a prerequisite. They are ways to produce evidence you can reflect on.
- Programming projects. A modest finished project that you can explain in depth is worth more than a list of languages. Focus on one decision, one difficulty and what you would change.
- Computing or maths coursework. A coursework project, an algorithm you implemented in class, or a proof technique you enjoyed is valid evidence. It is especially useful if you went beyond what the task required.
- Online courses and programming challenges. These show initiative and practice. What they show is limited unless you explain which problems stretched you and what you understood afterwards.
- Competitions and hackathons. Describe your actual contribution and the technical or design problem you solved, not just the placing.
- Hardware tinkering with a Raspberry Pi, Arduino or similar boards. This is particularly relevant for embedded systems, Internet of Things and networking courses.
- Contributing to open-source projects, or maintaining a website for a club. Both show working with existing code or with real users. Be accurate about the scale of your role.
- Simple usability tests. Watching a few people try to complete a task on a website or app and noting where they struggle is accessible, relevant evidence for HCI and information systems.
Saying you know Python, Java and C++ only means something if you show what you did with them. Admissions readers on these courses will usually not be impressed by long lists of tools, frameworks or certifications without discussion.
Applicants without direct computing experience
Many applicants have not built software outside school. Ordinary experiences can be relevant if you connect them honestly. Each example below notes what it shows and what it does not.
- A retail or hospitality job. You may have used tills, stock systems or booking software and seen where they caused errors or delays.
- This connects well to information systems and HCI, because it is evidence about real users and processes.
- It does not show programming or technical design ability, so do not present it as systems analysis experience.
- Office or administrative work. Perhaps you organised records in spreadsheets, built formulas or noticed duplicated data.
- This is relevant to databases and information systems, especially if you made something more reliable.
- Spreadsheet use is not software engineering, but it can show you thinking about data structure and validation.
- Caring responsibilities, such as helping a relative use a phone, online banking or health apps.
- This can give genuine insight into accessibility and interface design: which steps confused them and why.
- It is an observation, not a usability study. Present it as what prompted your interest.
- Volunteering, such as handling sign-ups, rotas or a mailing list for a group.
- This shows a small information problem met with real constraints.
- It is relevant if you can say what you changed, and what you would do differently with technical skills.
- Hobbies. Several are relevant if you engage with how they work:
- Modding or configuring games, setting up a home network, or building a PC can lead into systems and networks.
- Puzzles, chess or logic problems relate to algorithmic thinking.
- Electronics kits relate to embedded systems.
Playing games, owning devices or being the person friends ask for tech help is incidental exposure. It becomes useful only when you show curiosity about how the thing works underneath.
- Mathematics, physics or other school subjects. Logic, functions, vectors, probability and modelling all connect to computing. Graphics relies on geometry and matrices, and networking involves rates and signals. Saying exactly which idea connects to what is stronger than claiming you are good at maths.
If you are applying for a conversion or foundation route, you can be open about coming from a different background. Show what has already moved you towards the subject, rather than implying more experience than you have.
What useful reflection looks like
Reflection in this subject usually means explaining a decision, a failure or a limit in your understanding. Compare:
- Weak: I built a website for my school club, which taught me a lot about web development.
- Stronger: When members could not find event dates, I realised the problem was the navigation structure rather than the content. Reorganising the pages around what members actually looked for made me interested in how interfaces are evaluated.
Useful questions to answer in your own words:
- What was hard, and how did you work out why?
- What would break if the project had ten times the data or users?
- What did you test, and what did you miss?
- What concept would you need to learn properly to do it better?
Being honest about limits is a strength. Saying you got a solution working but do not yet understand why one approach was faster suggests a natural next step in study.
Pitfalls specific to this subject
- Confusing using technology with studying computing. Heavy gaming or social media use is not evidence of interest in how systems work.
- Overclaiming. Calling a tutorial project an app, or calling yourself a full-stack developer after a short course, invites scepticism. Describe what you built at its real scale.
- Writing a CV of tools. Long lists of languages, frameworks and badges take space without showing understanding.
- Writing a career plan instead of a subject interest. Earning potential or a specific technology company is not a reason to study the subject. Courses teach principles that outlast particular jobs and tools.
- Ignoring the mathematical side. This matters for computer science and graphics courses in particular. You do not need to overstate ability, but avoid implying the subject is only coding.
- Mismatching branch and evidence. A statement entirely about business processes fits information systems better than theoretical computer science, and the reverse is also true.
- Drifting into AI or cybersecurity buzzwords without technical substance, when applying for a general computing course.
- Repeating generic tech-industry claims about how computers are changing the world, instead of a problem you have personally thought about.
For general advice on planning, structure and editing, read our personal statement writing guide.
Computing, software and information systems personal statement examples