- Reading time: 3 minutes
- Price: Free download
- Published: 17th September 2026
- Word count: 873 words
- File format: Text
Why do you want to study this course or subject?
What draws me to information engineering is the idea that a measurement is only useful once you understand how it was corrupted on the way to you. I first noticed this with a damp patch in our hallway. My mum wanted to know whether it was worse in winter, so I bought a second-hand microcontroller board and a temperature and humidity sensor for a few pounds and logged readings every ten minutes to a memory card. The data was a mess: spikes when the front door opened, a slow drift I eventually traced to the board warming itself up, and a whole night missing because the power adapter was loose. Cleaning that up taught me more than the readings did. I learned to average over windows, to compare two sensors against each other rather than trusting one, and to write down what I changed so I could explain a jump three weeks later. Since then I have become interested in how signals are represented and recovered rather than just collected. Using a low-cost USB radio receiver I have looked at local broadcast and aircraft transponder transmissions, watching how a waveform in time becomes a shape in frequency, and how much of the work sits in filtering and decoding rather than in the aerial. In my A level Maths I met complex numbers and sinusoids as algebra; on the screen they became something I could tune. I want a degree that treats information as a quantity with its own limits, covering signal processing, control, communications and the software that ties them together, because those ideas seem to reappear in almost every system I find interesting, from hearing aids to the sensors managing a building.
How have your qualifications and studies helped you to prepare?
I am studying Maths, Physics and Computer Science at A level, having chosen them because they overlap in useful ways. In Maths I have found calculus and the mechanics work on differential equations the most directly relevant; modelling something that settles towards a steady value gave me the language for why my sensor readings lagged behind a change in the room. Trigonometric identities felt like arithmetic exercises until I needed them to understand how mixing two frequencies produces sums and differences. In Physics the practical endorsement has been the part I have valued most: measuring the speed of sound in a tube and estimating uncertainty properly made me much more careful about claiming a result. I now write down the resolution of an instrument before I write down its reading. Computer Science has given me Python and a grounding in how machines actually store numbers, which mattered when my own logging code produced negative humidity values because of an integer overflow. To fill gaps I have worked through introductory material on discrete signals in my own time, and I read Charles Petzold's Code, which built up from relays to a working computer and made the layers between hardware and software feel continuous rather than separate subjects. I also took a short online course on basic electronics to understand why a sensor needs a pull-up resistor instead of just copying a wiring diagram. My weakest point has been writing clearly about technical work, so I volunteered to produce the written report for a group physics investigation on resistivity and asked my teacher to mark it harshly.
What else have you done to prepare outside of education, and why are these experiences useful?
I work most Saturdays and two evenings a week on the checkouts and the self-service area of a supermarket. Helping customers whose payment has failed or whose barcode will not scan has made me patient at fault-finding under mild pressure, and I have got better at explaining something simply without sounding as though I am talking down to someone. It also means I plan my coursework around fixed shifts, which has forced me to be honest about how long tasks take. At home I get my two younger brothers out to school in the mornings while my mum is on an early shift, and I help the youngest with his times tables, which is where I first learned that repeating an explanation louder does not work. I play bass in a college band and have ended up as the person who sets up and troubleshoots the PA. Tracing a hum to a badly seated jack lead, or working out that feedback was coming from one monitor pointing at a microphone, felt like the same kind of thinking as debugging my sensor logger: isolate one variable, change it, listen again. I have also repaired two cheap Bluetooth speakers with a borrowed soldering iron, one successfully and one not. Outside that I run a few times a week and volunteer occasionally at a community repair session at our local library, where I mostly test fuses, label parts and watch the more experienced volunteers work. Listening there has shown me how much diagnostic skill comes from asking the owner good questions before opening anything up.
This example has 4,716 characters across the three answers. Use it for ideas and structure. Your own UCAS answers must fit within 4,000 characters in total, including spaces.
Why this example works — strengths and ways to improve
This is a specific, credible statement grounded in modest, well-reflected projects: the damp-patch logger, radio reception and PA troubleshooting show genuine engineering thinking. Each answer clearly exceeds 350 characters, but the total of about 4,716 characters is over the 4,000 limit, so you need selective cutting, especially in the third answer, while keeping the strongest reflective detail.
Subject motivation
a measurement is only useful once you understand how it was corrupted
Your opening frames a real idea at the heart of information engineering, then earns it through the sensor story. Moving from collecting data to how signals are represented and recovered shows developing curiosity rather than a generic passion claim. The closing list of topics is sensible but slightly broad.
Academic preparation
I now write down the resolution of an instrument before I write down its reading
You link A level content to your projects precisely: differential equations explain sensor lag, and trigonometric identities explain frequency mixing. The integer overflow example ties Computer Science to real debugging. Your reading of Code is reflected on rather than just listed, which keeps it credible.
Evidence and reflection
spikes when the front door opened, a slow drift I eventually traced
Concrete faults, and your methods for handling them, make this reflection convincing. Averaging, cross-checking two sensors and logging your changes are real lessons you learned. Your admission that writing is a weakness, and your response to it, adds honest self-assessment without false modesty.
Relevant experience
isolate one variable, change it, listen again
Supermarket work, caring duties and the band PA are ordinary experiences used well. The PA link to debugging is natural rather than forced. Running and the second speaker repair add little. Trimming them would save space without losing evidence.
Credibility and voice
I mostly test fuses, label parts and watch the more experienced volunteers
Your claims are pitched at a plausible school-student level, and modest phrasing like this avoids sounding professional. The voice is calm, exact and personal throughout. There is no inflated authority or ornate prose, and nothing here reads as overstated for your stage.
Structure and format
This example has 4,716 characters across the three answers.
Each answer clearly exceeds 350 characters, and the material sits logically, with little duplication across sections. However, the combined total exceeds the 4,000-character UCAS limit by roughly 700, so you must cut. The library's 3,500 minimum is comfortably met even after trimming.
What you’ve done well
- The damp-patch logger becomes a thread linking your motivation, A level content and troubleshooting, without repeating the same evidence.
- Your reflections name specific methods and errors, such as sensor drift, integer overflow and uncertainty, rather than generic skills.
How this draft could improve
- Cut about 700 characters: drop running and the speaker repairs, and shorten the caring and checkout reflections to one key lesson each.
- Tighten the closing sentence of your first answer, perhaps by keeping one example system rather than listing two, to save space.