What this subject area covers
This family groups courses about how computing works beyond a single program on a single machine. Machines talk to each other over networks. Work is spread across many computers. Software runs on small devices that sense and control the physical world. Course titles include computer networks, network engineering, distributed systems, cloud computing, embedded systems and Internet of Things.
The branches share some ideas: communication, resource limits, failure and timing. The evidence that suits each one is different, though. Your statement is stronger if it shows which part of the area actually holds your interest, rather than listing every buzzword.
How the branches differ and what evidence suits each
Computer networks and network engineering
The core concerns are how data moves:
- addressing and routing
- protocols and layering
- congestion and reliability
- how networks are designed, configured and secured
Useful evidence shows you have looked below the level of “the internet works”. Examples include:
- setting up a home or school network and understanding why a particular configuration failed
- using a packet capture tool to see what a web request actually contains
- working out why a game lags on one connection and not another
Network engineering courses often lean towards design and operation. Computer networks courses may weight theory such as protocol behaviour and performance more heavily. Check which emphasis a course has before deciding what to stress.
Distributed systems
The interest here is coordinating many machines that can fail independently and may disagree about the order of events. Good topics to write about include:
- consistency and replication
- consensus
- fault tolerance
- the trade-offs between speed and correctness
A concrete observation can open a real discussion. For example, you might have noticed that a shared document briefly showed different versions on two devices, or that a messaging app delivered messages out of order. Show the reasoning, not just the anecdote: what problem the system was solving, and what it gave up to solve it.
Cloud computing
Cloud courses typically deal with:
- virtualisation and containers
- scaling services up and down
- storage
- automation of infrastructure
- cost and reliability
Evidence might be deploying a small application to a free-tier cloud service, running a service in a container, or comparing hosting choices for a project.
Be careful to separate using a cloud console from understanding cloud systems. Clicking through a setup wizard shows familiarity. Explaining why your service stopped responding under load, and what you changed, shows understanding.
Embedded systems
Embedded work combines software with hardware under tight limits on memory, power, timing and cost. Relevant evidence includes:
- programming a microcontroller board
- reading sensors
- dealing with electrical noise or timing problems
- debugging when there is no screen to print to
Applicants who enjoy electronics, physics or mechanical tinkering often fit here better than in cloud-focused courses. Mathematics and physics topics such as signals, circuits or rates of change can be relevant if you connect them to a real constraint you met.
Internet of Things
IoT sits between embedded systems and networks. It covers devices that collect data and communicate it, with the security, power and reliability problems that follow.
A strong IoT statement usually shows awareness of the whole chain: device, connection, data handling and the people affected. A project that sends temperature readings to a phone is a reasonable start. Reflecting on battery life, what happens when the connection drops, or who can access the data makes it more convincing.
Choosing interests worth writing about
Pick one or two specific questions that genuinely occupied you, and show how your understanding developed. Topics that work well include:
- why a protocol retransmits data
- how a service stays available when a data centre fails
- why a sensor reading drifted
- how devices with tiny memory handle updates
- why default passwords on connected devices are a security problem
Reading can support this if you engage with it. Accessible books, technical blogs, protocol documentation and write-ups of real outages all give you material. Naming a source is less useful than explaining one idea from it and how it changed what you did or thought. Engineering write-ups of real service outages are especially good for distributed systems and cloud applicants, because they show failure in practice.
Preparation and activities (all optional)
None of these is a requirement. They are ways to generate evidence you can reflect on.
- Small hardware projects: an inexpensive microcontroller or single-board computer with a sensor or motor. These suit embedded and IoT applicants.
- Packet inspection: capturing and reading your own network traffic to see protocols in action. This suits networks applicants.
- Self-hosting: running a small web service or game server, then observing what breaks when friends use it. This suits cloud and distributed systems applicants.
- Free online courses or vendor learning materials on networking or cloud fundamentals. Treat these as background, not as proof of competence.
- School subjects: computing coursework involving client–server programs or databases, physics electronics practicals, or mathematics such as binary arithmetic, probability or graph theory. These connect when you link them to a specific concept, for example graphs to routing.
- Competitions or clubs: robotics clubs, cyber security challenges or coding clubs, if you can describe a problem you personally worked through.
Applicants without direct experience
Plenty of applicants have no projects or placements. Ordinary experience can still be relevant if you state the connection honestly and do not overclaim.
- Being the family’s “IT person”: fixing home Wi-Fi, resetting routers or helping relatives connect devices.
- What it shows: practical contact with real networks and structured troubleshooting.
- What it does not show: network engineering knowledge.
- How to use it: describe one problem you diagnosed, such as an address conflict or poor signal through walls, and what you later learned explained it.
- Retail, hospitality or warehouse jobs: card terminals failing when the connection drops, stock systems updating late, or till systems queuing transactions offline.
- What it shows: first-hand observation of distributed systems problems such as availability, delayed consistency and offline operation.
- What it does not show: any inside knowledge of how those systems were built.
- How to use it: frame it as something you noticed and then investigated.
- Caring responsibilities: using medical alarms, monitors or smart home devices for someone you care for.
- What it shows: experience of where reliability, battery life and usability matter to a real person. This is directly relevant to embedded and IoT design concerns.
- What it does not show: technical expertise in medical devices. Do not imply any.
- Gaming: latency, server regions and connection quality.
- What it shows: a genuine route into networking questions.
- What it does not show: playing a lot is not evidence in itself.
- How to use it: it becomes useful once you have looked into why lag happens, for example distance, routing or how games predict movement.
- Mechanical or electrical hobbies: repairing bikes, cars or electronics, or model-making.
- What it shows: comfort with physical systems and fault-finding, which suits embedded courses.
- Its limit: connect it to computing explicitly, for example how a car’s control units communicate, rather than letting the reader infer it.
- Volunteering with technology: helping at a library digital skills session or setting up equipment for a community group.
- What it shows: setting up and supporting real systems for other people.
- What it does not show: teaching others to use email is not network expertise.
- How to use it: mention only the parts that involved setting up or troubleshooting systems.
What useful reflection looks like
Reflection in this subject usually follows a problem through to an explanation. A useful pattern is:
- what you expected
- what actually happened
- how you narrowed down the cause
- which concept explained it
- what you would design differently
For example, “I built a weather station” says little. Compare that with an account of how the readings stopped every few hours, how you traced it to the board resetting on low power, and what that taught you about power budgets. The second version shows thinking that embedded and IoT study builds on.
Trade-offs are particularly worth showing. Most problems in this area have no perfect answer, only choices between speed, cost, reliability, security and simplicity. Showing that you recognise a trade-off, even in a small project, signals readiness for the subject better than claiming a flawless result.
Pitfalls specific to this subject
- Listing tools and acronyms. A string of cloud services, protocols or programming languages without explanation reads as a keyword list. One tool you understand well is worth more than ten you have touched.
- Treating certificates as expertise. An introductory online certificate shows initiative. Present it as a starting point, not professional competence.
- Confusing the course with a job. A degree studies principles such as protocols, distributed algorithms and hardware–software interaction. It is not training for a single role such as network administrator or cloud engineer. Mention career interests if you like, but anchor the statement in the subject.
- Writing a general computer science statement. If most of your statement could be about any computing course, make clear why networks, distribution or embedded constraints specifically interest you.
- Writing about the wrong branch. A statement full of microcontroller projects fits an embedded or IoT course. It may sit awkwardly with a cloud computing course unless you draw the link, for example devices sending data to a cloud service.
- Overclaiming security knowledge. Avoid describing unauthorised access to networks or devices, even as curiosity. Discuss security through legitimate practice environments, your own equipment or published incidents.
- Vague enthusiasm for trends. Statements that the cloud or IoT is “the future” add nothing. A specific problem you want to understand is more persuasive.
Postgraduate applicants
For master’s courses in this area, the emphasis usually shifts towards depth and preparation.
- Relevant modules and projects. Name the modules that prepared you, such as operating systems, networking, computer architecture or concurrency. Describe a dissertation or project in terms of the technical decisions you made and why.
- Professional experience. If you have worked in IT support, operations or development, be precise about your own responsibilities. Explain what gaps in theory the course would fill.
- Changing field. If you come from electronics, physics or another engineering discipline, show which concepts carry over. Be honest about what you still need to build.
For general advice on planning, structure and editing, read our personal statement writing guide.
Networks, cloud and embedded systems personal statement examples