- Reading time: 3 minutes
- Price: Free download
- Published: 4th October 2026
- Word count: 651 words
- File format: Text
Personal statement example
Every Monday morning at the further education college where I work, I unlock a trolley of thirty laptops and check which ones failed to update over the weekend. Usually it is two or three, and usually the reason is dull: a machine went to sleep halfway through, lost its network connection and never retried. Fixing that properly, rather than restarting each laptop by hand, meant reading the update logs, writing a small PowerShell script to flag stalled machines and agreeing a new power schedule with my manager. It is modest work, but it is the kind of problem I keep returning to: systems that behave well when everything is connected and badly when it is not.
That interest began with my final-year project for my BSc in Computer Science. I built an offline-first catalogue and loans app for a volunteer-run community library that had patchy Wi-Fi and one shared tablet at the desk. Volunteers needed to record loans when the connection dropped, then have those records merge cleanly once it returned. My first approach used simple timestamps and a last-write-wins rule, which worked until two volunteers edited the same member record on different devices. Researching alternatives led me to conflict-free replicated data types, and I implemented a basic observed-remove set for the loans list. I did not solve every edge case, and my report was honest about where the design would struggle at scale, but the library used the app through a summer reading scheme and the volunteers' feedback shaped my final changes to the interface. The project earned a first-class mark and left me wanting a deeper grounding in the theory I had only skimmed.
Since graduating I have worked as an IT support technician for two years. The role is broad rather than glamorous: imaging machines, managing user accounts, answering tickets from staff who simply need a projector to work. Some of it has been more technical than I expected. I helped migrate the college's helpdesk from a shared inbox to a ticketing system, which involved cleaning several years of exported emails with Python and learning how much data quality determines whether a tool is actually useful. I have also become more patient at explaining technical problems to people who have no reason to care about them, which I think is an underrated part of building software that others rely on.
Alongside work, I have been reading Martin Kleppmann's Designing Data-Intensive Applications, slowly and with notes. His treatment of replication and consistency models gave me a vocabulary for things I had stumbled into during my project, and his discussion of the trade-offs between availability and consistency made me realise how much of distributed systems design is about choosing which failures to tolerate. I have also worked through an online course in algorithms to strengthen areas where my undergraduate knowledge felt thin, particularly graph algorithms and complexity.
Outside computing, I coach a junior badminton session on Thursday evenings at a local leisure centre. I took my Level 1 coaching qualification last year. Planning drills for twelve children of very different abilities has taught me to break skills into small, testable steps and to notice quickly when an explanation is not landing. It is also simply the best part of my week.
I want to undertake a master's degree to move from fixing the edges of systems to understanding and designing them properly. I am particularly drawn to distributed systems, networking and data management, and I would welcome the chance to study the formal foundations behind tools I currently use mostly by experiment. I expect the step up in mathematical rigour to be demanding, and I am ready for it. My aim afterwards is to work on infrastructure or backend engineering, ideally on systems that have to cope with unreliable conditions, whether that is a rural clinic's records or a library tablet that loses its signal.