- Reading time: 3 minutes
- Price: Free download
- Published: 17th September 2026
- Word count: 618 words
- File format: Text
Personal statement example
My interest in high-performance computing began with a piece of code that worked perfectly and was uselessly slow. In my second year I wrote a two-dimensional heat diffusion solver in C for a numerical methods module. It produced sensible results on a small grid, but when I refined the mesh to see the boundary behaviour more clearly, a single run took most of an afternoon. My first instinct was to look for a cleverer algorithm. What actually helped was reading about memory layout and discovering that my nested loops were traversing the array in the wrong order, so almost every access missed the cache. Reordering two lines of code made the program several times faster. That gap between what I had been taught about complexity and what the machine actually rewarded is what I want to spend the next stage of my study on.
My final-year project built on that. I extended a fluid-flow simulation to run in parallel, first with OpenMP across the cores of a single node and then with MPI across four nodes of my department's teaching cluster. The shared-memory version was straightforward; the distributed version taught me far more. I spent weeks on halo exchange, and longer still on understanding why my strong scaling curve flattened at sixteen processes. Profiling showed that communication was not the main problem: load imbalance was, because my domain decomposition split the grid evenly by cells rather than by work, and the regions near the obstacle required more iterations to converge. Rebalancing the decomposition recovered a reasonable portion of the loss. I also learned the discipline of measuring properly, running each configuration several times and reporting variation rather than best-case figures, after my supervisor pointed out that my early numbers were suspiciously tidy. The project was marked well, and I was pleased that the write-up was judged mainly on the honesty of the analysis rather than the headline speed-up.
Alongside my degree I have worked weekends on the service desk of a garden centre, dealing with deliveries, refunds and stock queries. It is not technical work, but it has made me comfortable explaining something unwelcome clearly and calmly, and it has taught me to keep a queue moving without cutting corners. I have also helped run a weekly coding club at my local library for children aged around nine to thirteen. Preparing a session on sorting for that group forced me to strip an idea back to its essentials, and I now find that explaining a parallel algorithm to a peer follows a similar pattern: establish what each part is responsible for before worrying about the detail.
My strongest technical foundations are in C, Python and Linux, with coursework in operating systems, computer architecture and numerical computation. I am aware of the gaps. My linear algebra is adequate rather than fluent, and I have only read about GPU programming rather than written anything substantial in CUDA. I have been working through Hager and Wellein's Introduction to High Performance Computing for Scientists and Engineers in my own time, which has given me a much clearer mental model of bandwidth limits and why some of my earlier optimisation attempts were bound to fail. A taught postgraduate course would give me structured time on accelerators, parallel numerical methods and the tools for performance analysis, with access to hardware I cannot replicate at home.
In the longer term I would like to work as part of a team supporting research computing, helping scientists get more from the machines they already have. That work seems to sit exactly where I am happiest: close to the hardware, and in conversation with people whose problems are not primarily about computing at all.
Why this example works — strengths and ways to improve
This is a strong, coherent statement for a taught master's in high-performance computing. You trace a credible path from a cache-miss discovery to a parallel final-year project, with genuine technical reflection and honest acknowledgement of gaps. The main room for growth is sharpening quantitative detail and making the non-technical experience link more economically to your stated career aim.
Subject motivation
a piece of code that worked perfectly and was uselessly slow
Your opening works because the motivation comes from a concrete problem rather than a declared passion. The loop-ordering discovery shows why HPC interests you: the gap between theoretical complexity and real hardware behaviour. That framing is distinctive, accurate and plausible for a second-year undergraduate, and the final sentence of the paragraph ties it clearly to further study.
Academic preparation
coursework in operating systems, computer architecture and numerical computation
You list foundations relevant to HPC and support them with sustained independent reading of Hager and Wellein. You also name weaker linear algebra and no substantial CUDA work. That candour is credible and suits a taught course. You could briefly say how you are addressing the linear algebra gap, since parallel numerical methods depend on it.
Evidence and reflection
communication was not the main problem: load imbalance was
This is the statement's best moment. You form a hypothesis, test it by profiling, correct your assumption and explain the cause: decomposition by cells rather than by work. The note on reporting variation after your supervisor questioned tidy numbers shows methodological maturity. Phrases like 'a reasonable portion' are vague, though, and one approximate figure would strengthen the claim.
Relevant experience
helped run a weekly coding club at my local library
Your ordinary jobs are used well. The coding club link to explaining parallel algorithms is specific and believable, and it supports your aim of working with scientists. The garden centre paragraph is honest but its lessons are more generic. 'Keep a queue moving without cutting corners' could connect more directly to supporting research users.
Credibility and voice
My linear algebra is adequate rather than fluent
Your voice is measured and personal. The claims fit an undergraduate stage: a teaching cluster, four nodes and sixteen processes, with no exaggerated authority. Admitting weaknesses without apologising builds trust. The remark that the project was 'marked well' is fine, but the sentence about how the write-up was judged is slightly self-congratulatory and could be cut.
Structure and format
No single quotation captures structure. The sequence is logical: origin, project, wider experience, preparation and gaps, then aims. Paragraphs are focused and the prose is economical. The closing aim is realistic and connects back to the earlier themes. The leftover 'Personal statement example' heading should be removed before any real submission.
What you’ve done well
- The diagnosis of load imbalance near the obstacle shows real performance-analysis reasoning, not just a list of tools used.
- You acknowledge specific gaps (CUDA, linear algebra) and say how a taught course would address them, which makes your case for further study persuasive.
- Your career aim of research computing support is consistent with both your technical work and your teaching experience.
How this draft could improve
- Replace 'several times faster' and 'a reasonable portion of the loss' with approximate measured figures to reinforce your emphasis on honest measurement.
- Condense the garden centre paragraph and tie its lesson explicitly to handling researchers' requests or expectations.
- For a real application, tailor the second-to-last paragraph to the actual programme's stated content rather than generic course areas.