PERSONAL STATEMENT
EXAMPLES
My statements
Home » Subject areas » Civil, electrical and systems engineering » Electrical, electronic and computer engineering » Computer Engineering (Computer Systems), MS postgraduate personal statement example

Computer Engineering (Computer Systems), MS postgraduate personal statement example

PSE example
  • Reading time: 3 minutes
  • Price: Free download
  • Published: 5th October 2026
  • Word count: 638 words
  • File format: Text

Personal statement example

Every September, the college where I work as an IT support technician reimages around four hundred student PCs over two weekends. Last year I noticed that machines in one teaching block took nearly twice as long as identical models elsewhere. The cause turned out to be unglamorous: an older network switch was negotiating some links at a lower speed, and the deployment server was retrying stalled transfers rather than reporting them. Tracing it meant reading switch logs, timing transfers by hand and comparing settings line by line. I enjoyed it because it was a systems problem in the full sense, where hardware, firmware and software each behaved reasonably on their own but badly together. I want to study computer systems at postgraduate level because that is the kind of interaction I find most interesting, and I would like to understand it from the processor upwards rather than only from a help desk.

My undergraduate degree in Electronic Engineering gave me a sound base in digital design, embedded C and computer architecture. The architecture course was where the subject started to make sense to me. Working through Patterson and Hennessy's treatment of pipelining, I could see why a single instruction sequence might run quickly on one design and stall on another, and I began to see performance as something that could be explained rather than just measured.

My final-year project built on this. I implemented a small open-source RISC-V soft core on a mid-range FPGA development board and added a simple direct-mapped data cache, then compared two ways of ordering tasks in a basic cooperative scheduler I wrote in C. One ordering grouped tasks that shared data and the other did not. Using hardware counters I added to the design, I recorded cache misses and cycle counts across a set of small benchmark workloads. The grouped ordering reduced misses noticeably for workloads with shared buffers but made almost no difference elsewhere, which taught me to be careful about claiming general improvements from a narrow test set. The hardest part was timing closure after adding the counters; I learned to read the synthesis reports properly and to pipeline a comparison path I had written carelessly. The project received a first-class mark, and I left it with clear questions about multicore coherence and memory hierarchies that a single small core could not answer.

My job has developed skills a degree did not. I support teaching staff who need equipment working in ten minutes, so I have become good at explaining technical faults plainly and at writing documentation others actually use. I wrote a short guide for colleagues on diagnosing slow imaging, which is now part of our team's checklist. I also maintain a set of PowerShell scripts that collect hardware inventory data, which has made me more disciplined about testing changes before deploying them across hundreds of machines.

Outside work I play bass trombone in a community brass band. It has nothing to do with engineering, but rehearsing a difficult piece over months has given me patience with slow, cumulative improvement, and I help the band secretary keep our music library catalogued.

At postgraduate level I hope to study computer architecture, memory systems and hardware-software co-design in depth, and to gain experience with more rigorous simulation and evaluation methods than I used as an undergraduate. I am particularly interested in how scheduling and memory layout decisions in operating systems interact with cache and coherence behaviour on multicore processors. Longer term, I would like to work in processor or embedded systems design, where understanding the whole stack matters.

I bring a solid technical foundation, a completed hardware project I understand thoroughly, and two years of solving real problems for impatient users. I am ready for the more demanding theoretical and practical work that a master's degree requires.