UCAS · THREE-QUESTION SUBMISSION DRAFT
Personal Statement Response Set
| Entry cycle | 2027 entry | Subject | BSc Computer Science |
|---|---|---|---|
| Qualification context | Chinese senior secondary curriculum with Mathematics, Physics and Information Technology | ||
Character budget · spaces included
| Question 1 | Question 2 | Question 3 | Total |
|---|---|---|---|
1,257 characters | 1,274 characters | 1,384 characters | 3,915 characters |
UCAS currently requires at least 350 characters for each response and allows 4,000 characters across all three responses. The questions themselves are not included in the total.
Motivation · subject curiosity · direction Q1
Why do you want to study this course or subject?
Building a route finder for our school library changed my idea of what programming could do. I began with a simple goal: help new students locate books without walking through every aisle. My first version returned a route, but not always the shortest one. Comparing it with Dijkstra's algorithm made me curious about the reasoning that turns a plausible answer into a dependable one. I started to see computer science as the study of such reasoning: how data is represented, how an algorithm's cost grows, and how a system behaves when its assumptions meet untidy reality. I then read selected chapters of Grokking Algorithms and recreated the examples in Python, changing graph sizes and edge weights to observe when different approaches became inefficient. What interested me most was not making the code look sophisticated, but explaining why one method was appropriate and where it might fail. At university I want to deepen this habit through discrete mathematics, algorithms and software engineering, then explore how reliable data-intensive systems can support public services. Computer science appeals to me because it combines proof, experimentation and responsibility: an elegant model matters only when people can trust the system built from it.
Formal study · evidence · reflection Q2
How have your qualifications and studies helped you to prepare for this course or subject?
Mathematics has trained me to move between a general rule and a testable case. While studying sequences and probability, I learned to state assumptions before calculating and to check whether a result remained sensible at an extreme. I applied the same discipline in Information Technology when I compared breadth-first search with Dijkstra's algorithm on a weighted map of our campus. I designed small test graphs by hand, wrote Python tests for unreachable nodes and duplicate paths, and recorded run times as the graph grew. An early conclusion was wrong because I had compared results generated from different input sizes; correcting the experiment taught me that reliable evidence depends on controlled data as much as on correct code. Physics strengthened this approach through modelling. In a motion investigation, the gap between predicted and observed values required me to consider measurement error rather than force the data to fit the equation. Across these subjects I have learned to break a large question into explicit steps, document revisions and explain uncertainty. These habits will help me engage with proofs, laboratory work and collaborative programming, where a solution must be understandable and reproducible, not merely functional on one machine.
Beyond school · contribution · usefulness Q3
What else have you done to prepare outside of education, and why are these experiences useful?
Outside school, I volunteer twice a month at a community science centre, helping younger visitors complete short coding activities with microcontrollers. At first I solved errors for them, which kept the sessions moving but left them dependent on me. I changed my approach by creating a set of debugging cards that asked learners to check power, inputs and one line of code at a time. Watching them use the cards to find faults independently showed me that a technical explanation is successful only when another person can act on it. I also maintain a small reading log for open-source project documentation. Comparing issue reports with the changes that resolved them has taught me to describe a problem with reproducible steps and to treat feedback as part of development rather than criticism. During a local weekend coding challenge, I used those habits to coordinate three teammates building a bus-arrival display: I separated the data parser from the interface, kept a shared task list and proposed a simpler fallback when the live feed became unreliable. We delivered a working demonstration, but the more valuable result was learning to adjust scope without losing the purpose of the product. These experiences have prepared me to contribute patiently to group projects, communicate across different levels of confidence and keep users in view while studying complex systems.
