- Reading time: 3 minutes
- Price: Free download
- Published: 4th October 2026
- Word count: 657 words
- File format: Text
Personal statement example
Last winter the library service where I work found that a search for one popular children's author returned forty-one records, most of them duplicates created when two branch catalogues were merged years ago. My manager asked whether I could tidy them before the spring reading scheme. I wrote a short Python script that normalised titles, stripped punctuation and compared ISBNs. Where ISBNs were missing, it scored pairs of records by edit distance on title and author. It flagged about three hundred likely duplicates across the catalogue, and a colleague and I checked them by hand before merging. The hand check taught me as much as the script did. A few pairs looked identical but were different editions, and the script could not tell them apart. I would like to understand that kind of problem properly rather than patch it, and this is why I am applying for a taught Masters in computer science.
My undergraduate degree was in mathematics, with a minor in computing taken in my second and third years. I enjoyed the computing modules more than I expected, particularly algorithms and data structures, where the proofs of correctness felt like a natural extension of the analysis I was doing elsewhere. My final-year project grew from a question I had as a cyclist. Ride-tracking apps store a GPS point every second, and most of those points add little information. I implemented the Ramer–Douglas–Peucker algorithm for simplifying polylines and compared it with a simpler method that keeps every nth point, using my own ride logs and a set of public traces. I measured how far each simplified route strayed from the original and how much storage it saved. The more interesting part was the edge cases. On slow, twisting climbs the fixed-interval method did surprisingly well, while the standard algorithm with a single tolerance sometimes cut corners that mattered. I tried varying the tolerance according to speed. The results were modest, but writing up why they were modest was the most careful technical writing I had done.
Since graduating I have worked as a library systems assistant. Much of the job is ordinary: resetting patron accounts, running overdue reports, fielding questions when the self-service machines freeze. It has given me a practical sense of how software behaves when it is used by people with no interest in how it works, and of how much depends on data that was entered inconsistently a decade ago. I have also learnt to write SQL queries against a database I did not design and to document what I change so that the next person can follow it.
Outside work I coach a junior chess group on Saturday mornings, mostly players aged eight to twelve. I do not use engines much with them. Instead I try to get them to explain a move aloud before they play it, which is harder for them than finding the move. I also sing tenor in a community choir. Neither activity is computing, but both have made me more patient about explaining things in steps.
I am aware of the gaps in my preparation. My degree gave me less systems programming and less exposure to operating systems and networks than a single-honours computing graduate would have. Over the past year I have worked through Kernighan and Ritchie's The C Programming Language, doing most of the exercises. I have also started reading about record linkage, including the Fellegi–Sunter model, which formalises the problem I met with the catalogue far better than my improvised scoring did.
At Masters level I want to strengthen my foundations in systems and to study algorithms and data management in more depth, with a view to working on the kind of messy, real-world data problems I have started to meet. I bring mathematical training, a finished independent project and the habit of checking whether a clever solution actually works on the data in front of me.