- Reading time: 3 minutes
- Price: Free download
- Published: 5th October 2026
- Word count: 636 words
- File format: Text
Personal statement example
At four in the morning, in the frozen aisle of the supermarket where I work night shifts, my handheld scanner usually takes two or three seconds to confirm each pallet label. The warehouse Wi-Fi barely reaches that corner, so the device retries quietly until it gets through. Most colleagues simply wait. I started noticing which actions failed silently and which ones queued safely. That habit of asking what software does when the network disappears has shaped most of what I have built, and it is the main reason I want to pursue a taught master's degree in computer science.
My undergraduate degree combined mathematics and computer science. I gained a 2:1, with my strongest marks in algorithms, operating systems and a second-year distributed systems course. That course introduced me to the CAP theorem and logical clocks. I found it satisfying that a problem as vague as two people editing the same record could be stated precisely enough to prove what is and is not possible.
For my final-year project I built a stock-tracking app for the food bank where I had volunteered on Saturdays. Volunteers counted tins in a church hall basement with no signal, then re-entered everything on a laptop upstairs, so totals were often wrong or duplicated. My app stored changes locally and synchronised them later. I first tried last-write-wins, which lost counts when two volunteers updated the same shelf. I then modelled each count as an increment or decrement rather than a final value, an approach based on conflict-free replicated data types, so that merges no longer depended on order. I tested it by scripting simulated devices that went offline at random intervals and checking that totals converged. It was not elegant everywhere: the interface was plain, and I never solved deletions cleanly. Still, the coordinators used it for four months, and the number of corrections at month-end went down noticeably. I enjoyed explaining the trade-offs to them in plain terms, because they cared about why a figure changed, not about vector clocks.
Since graduating, I have kept working nights while building smaller projects in the mornings. I rewrote parts of my sync code in Rust to understand ownership and concurrency more carefully, and worked through Martin Kleppmann's Designing Data-Intensive Applications, whose chapters on replication and consistency gave me vocabulary for problems I had met by trial and error. I have also tried to be honest about gaps. My experience of large production systems is limited, and I have never worked within a professional engineering team on shared code. A structured postgraduate course, with substantial project work alongside others, is how I want to close that gap rather than guessing at industry practice alone.
The night job has taught me things that are less obvious than technical skill. Replenishment runs to a schedule, and when a delivery arrives late, the team has to reprioritise quickly and communicate clearly. I have become the person who trains new starters on the handhelds, mostly because I can explain the error messages. I also coach a junior chess club at my local library on Sunday afternoons. Teaching eleven-year-olds to calculate two moves ahead, and to check what their opponent threatens before getting excited about their own plan, is not so different from reasoning about failure cases in a system.
At postgraduate level I want to deepen my understanding of distributed systems, databases and security, and to work on a substantial team project where reliability under poor conditions matters. In the longer term I would like to work on software for places where connectivity cannot be assumed, such as logistics, field research or community services. I am a careful, persistent worker who learns well by building things and testing them against real use, and I am ready for the intensity of a demanding taught programme.