What this subject covers
Course titles in this area include computer science, computing, applied computing, information technology, software science, computer applications, computer systems and high-performance computing. They overlap, but they do not ask for quite the same evidence. Read the module lists for the courses you are applying to, then pick the evidence that fits them. Do not try to show an interest in everything that involves a computer.
- Computer science and software science usually emphasise the theory behind computation. That includes algorithms, data structures, logic, discrete mathematics, complexity, programming language concepts and formal reasoning. The most useful evidence here shows that you have thought about why a method works or how efficient it is, not only that you got it running.
- Computing, applied computing and computer applications tend to place computational methods inside real problems. The most useful evidence shows that you understood a problem, chose a suitable tool, and judged whether the result actually helped.
- Information technology often looks at how systems are deployed, supported, secured and used in organisations. Evidence about reliability, users, maintenance and the trade-offs in running systems fits better than evidence of clever programming.
- Computer systems and high-performance computing focus on how hardware, operating systems, memory, concurrency and parallelism affect performance. Here the most useful evidence shows curiosity about what happens beneath the code. Examples include why one approach runs faster, where a bottleneck lies, or how work is split across processors.
Some subjects sit next to this one. If your main interest is interface design or graphics, networking and cloud, embedded devices, business information systems, or professional software development practice, those neighbouring subjects may suit you better. A statement for a general computer science course can mention these areas. It should still show interest in the core of the discipline rather than resting entirely on one specialism.
Choosing interests that carry weight
A strong interest in this subject usually means you have noticed a specific question and gone some way towards working through it. “I have loved computers since I was young” tells the reader nothing they can assess. The following kinds of interest give you something to explain:
- An efficiency problem. For example, you noticed that a program slowed sharply as the input grew. You then learned why a nested loop scales badly and what a different data structure changed. This connects directly to algorithms and complexity.
- A correctness problem. For example, you found a bug that only appeared in edge cases. It led you to think about testing, invariants, or how you could know a program is right rather than merely appearing right.
- A link with mathematics. Examples include recursion and proof by induction, graphs in a route-finding problem, modular arithmetic in hashing or cryptography, or Boolean logic in circuits. Discrete mathematics underpins much of computer science, so a link you have actually worked through is strong evidence. Only use one you understand.
- How a system works underneath. Examples include how memory is managed, what a compiler or interpreter does, how an operating system schedules tasks, or why parallel code is hard to get right. This suits systems and high-performance courses.
- A question about computing in society. Examples include bias in automated decisions, privacy, accessibility, or the energy cost of large computations. These work best when you connect them to the technical mechanism involved, not only to news coverage.
Artificial intelligence is a common interest. It is more convincing when you show what you understand of the underlying ideas. Suitable material includes the data, the optimisation, how models are evaluated, and their limitations. Admiration for a headline product is not enough. Be careful not to overstate your understanding of machine learning on the strength of using a chatbot or following one tutorial.
Preparation and activities worth considering
None of these is a requirement. Each is only useful if you can say what you learned from it.
- School subjects. Computing or computer science coursework, mathematics (especially proof, sequences, matrices, probability and further mathematics topics), physics (for systems and hardware interests) and electronics can all supply evidence. A non-exam assessment project often gives you real design decisions to discuss.
- Small, finished programs. A modest program you can explain thoroughly is worth more than a list of languages. Good examples are a solver for a puzzle, a simulation, a tool that automates a real task, or your own implementation of a sorting or search algorithm compared against an alternative.
- Programming and problem-solving challenges. Competitions and online problem sets build algorithmic thinking. Mention one problem whose solution taught you something. A score on its own says little.
- Reading. Introductory books or lecture materials on algorithms, the theory of computation or how computers work. Name one idea that changed how you approached something, and say how.
- Contributing to or studying existing code. Reading well-written open-source code or documentation, or fixing a small issue, shows that you can work within someone else’s design. Do not describe a minor contribution as maintaining a project.
- Hardware tinkering. Building or configuring a computer, or programming a microcontroller, suits systems-focused courses. Be clear about the limits. Assembling parts is not the same as understanding computer architecture, but it can be where that understanding started.
Using experience that is not obviously computing
Many applicants have no placement, no portfolio of apps and no access to specialist clubs. That is workable. The aim is to find moments where you met a computational idea, and to describe them honestly.
- Retail or hospitality work. Using a till, stock or booking system can lead you to think about how the system handled errors, queues or concurrent orders. It might also show you what happened when the system failed. Limit: you were a user, not a designer, so frame the experience as observation that raised a technical question.
- Spreadsheets in a job, club or family business. Building formulas, lookups or automation is real work in data handling and logic. It suits applied computing and information technology particularly well. Limit: it does not demonstrate programming in the wider sense or knowledge of algorithms unless you went further.
- Helping relatives or neighbours with technology. Fixing settings, setting up devices or explaining scams gives evidence for information technology interests in usability, security and support. Limit: helping people is not professional IT support, and the computing content may be thin. Focus on a specific problem you diagnosed and how you worked out the cause.
- Caring responsibilities. Managing medication schedules, appointments or assistive technology may have shown you how software fails or helps people with real constraints. This can lead naturally to interests in reliability or accessibility. Limit: keep the focus on the technical question it raised, not the caring itself.
- Games and modding. Writing scripts, adjusting game logic, or wondering how pathfinding or physics engines work can lead to genuine algorithmic interest. Limit: playing games is not evidence. What counts is analysing or changing how a game works.
- Music, puzzles, chess or crafts. Pattern, rules, search and optimisation appear in all of these. Examples are thinking about how a chess engine searches positions, or how a knitting pattern behaves like a program. Limit: the link must be one you have actually followed up, not a decorative comparison.
- Volunteering. Maintaining a charity’s records, website or mailing list provides evidence about data quality, users and maintenance. Limit: describe your actual responsibility precisely.
What useful reflection looks like
Reflection in this subject means explaining decisions and what they taught you about computing. Admissions readers cannot run your code, so your reasoning has to be visible on the page. Useful reflection tends to:
- Name the problem and the choice you made. For example: “I stored the results in a dictionary rather than a list because lookups were happening thousands of times.”
- Say how you knew whether it worked. This could be testing, timing, comparison with expected output, or feedback from the person who used it.
- Admit a limit or a mistake. Examples include code that did not scale, an assumption that turned out wrong, or a feature you removed. Honest analysis of a failure is often the strongest material you have.
- Connect it to the subject. Show how the experience led you to an idea you then studied more formally, such as recursion, complexity, concurrency or abstraction.
Compare a weak and a stronger version. A weak line is “I built a website, which improved my coding skills.” A stronger account explains what made the site difficult, such as handling user input safely. It then says what you learned about why input validation matters and what you would do differently next time.
Pitfalls specific to computing statements
- Lists of languages and tools. Naming many languages proves little. One language used thoughtfully is more convincing.
- Overclaiming expertise. Following a tutorial is not building an application. Using an AI tool is not doing AI research. Writing a scraper is not hacking. Readers can usually tell when claims and depth do not match.
- Treating the degree as job training. Computer science degrees teach theory as well as practice. A statement that only describes wanting to be a games developer or work at a large technology company says little about why you want to study the subject. Careers can be mentioned, but the focus should be the discipline.
- Ignoring mathematics. If the courses you are applying for are theory-heavy, avoid presenting mathematics as something you put up with. Show where it has helped you think.
- Too much on one specialism. A statement made up entirely of cybersecurity or graphics can suggest you would be happier on a specialist course. For general courses, place the specialism within a wider interest.
- Jargon without explanation. Using technical terms precisely, with a short account of why they mattered, shows understanding. Using them loosely shows the opposite.
- Hype about technology. Claims that a technology will change everything add nothing. A considered view of a technology’s limits is more persuasive.
Postgraduate and conversion applications
For a specialist master’s, show which area of computing you have already studied, the technical depth you reached (for example a dissertation or project), and how the course’s modules build on it. Conversion courses are designed for graduates from other subjects. For these, explain what computational problems you met in your previous field or work, what preparatory learning you have done independently, and how your earlier discipline will shape what you do with computing. Be accurate about your current level rather than presenting introductory study as advanced.
For general advice on planning, structure and editing, read our personal statement writing guide.