Hands-on Exercises: Short, Focused Practice Tasks

Each exercise below takes between twenty minutes and two hours, teaches one specific thing, and is built around a trap that most first attempts fall into. The trap is the exercise. Getting a working answer without hitting it usually means the exercise was misread.

There is no submission and no marking. Each one tells you how to check your own work, which is a skill worth building in its own right.

Requirements and analysis#

E1 — Make a requirement testable. Take five requirements from a real document at work. Rewrite each so that you could prove it was met in one sentence. Then count how many of the originals contained the words support, handle, manage or user-friendly. Check: every rewrite names an actor, a trigger, and an observable result. See FRD.

E2 — Write the out-of-scope list. For a project you are on, write ten things it will explicitly not do. Trap: the first five are easy and useless ("it will not cure cancer"); the valuable ones are the things somebody actually expects. Check: show it to a stakeholder — if nobody objects to anything, you have not written the real list. See Project Charter.

E3 — Score a risk honestly. Take five risks from a live register and score likelihood and impact against definitions you write first. Trap: everything lands on medium. Check: if your five scores do not separate, your scale definitions are too vague. See Risk Register.

Engineering#

E4 — Find the deleted secret. Build an image that copies a file containing a fake credential, then deletes it in the next instruction. Now retrieve it from the image. Teaches: why layers are additive and why a leaked credential must be rotated rather than removed. See Docker.

E5 — Handle the signal. Take any service and send it a termination signal while a request is in flight. Observe the dropped request. Now handle the signal — finish in-flight work, stop accepting new work, exit. Check: repeat under a rolling restart with no failed requests.

E6 — Write a review comment that helps. Take a pull request you reviewed recently and rewrite your comments, labelling each as defect, question, or preference. Trap: you will discover how many preferences were phrased with the authority of defects. See software engineering.

E7 — Make a test fail first. Pick a test you wrote that has never failed. Break the code it covers and confirm it fails. Trap: a surprising number do not — they assert nothing meaningful, or they test a mock. See testing.

Data and AI#

E8 — Measure retrieval, not the model. On any retrieval system, write twenty questions with known answers and record the hit rate — whether the correct passage was retrieved at all, independent of the answer produced. Teaches: the ceiling is set here, and prompt work cannot raise it. See RAG.

E9 — Break the pipeline safely. Take a job that writes a data file and simulate the upstream source being unavailable. Trap: most write an empty file and exit zero. Fix it to fail closed and keep the last good output. See data engineering.

E10 — Give an agent a stopping condition. Build a minimal agent with one tool and no stopping condition, and watch it loop. Then add a step limit, a repeated-action check and a spend cap enforced outside the agent. Check: the cap actually stops it — test it rather than assuming. See AI agents.

E11 — Write the refusal. For any question-answering system, write the exact words it uses when the answer is not in its sources, then test it on ten unanswerable questions. Trap: it answers anyway. Measure how often.

Operations#

E12 — Find the space. Fill a disposable machine's disk with a log file held open by a running process, then delete the file. Find where the space went using only command-line tools. See Linux.

E13 — Time your own rollback. Deploy something, then roll it back, with a stopwatch. Check: compare the time to what your runbook claims. Most runbooks are optimistic by a factor of two. See DevOps.

E14 — Audit what is listening. On any server you own, list every listening port and justify each one in writing. Trap: there will be at least one you cannot explain. That is the exercise. See cyber security.

How to check your own work#

Without a marker, three questions do the job:

Did I hit the trap? Each exercise names it. Not hitting it usually means the exercise was not attempted as written.

Can I explain the result to someone who will push back? If your explanation is "it just works now", the diagnosis was skipped.

Would I do it the same way under pressure? The exercises are chosen because their lessons surface during incidents, not during development.

FAQ#

Are there solutions published?#

No, deliberately. Each exercise states the trap and how to verify your own answer, which is the skill that transfers. A published solution turns the exercise into reading.

How long should each take?#

Twenty minutes to two hours. If one takes a full day, you are learning the surrounding technology as well, which is fine but worth recognising — the exercise itself is small.

Do I need a cloud account?#

No. Everything here runs locally or against systems you already have at work.

Can I use these at work on real systems?#

Use judgement. Several are designed to be done on real artefacts — requirements, review comments, runbooks — and are more valuable that way. Anything that breaks something (E4, E9, E12, E13) needs a disposable environment.

What if I disagree with the framing of an exercise?#

Good — write down why. Several of these encode opinions, and the reasoning behind them is in the linked guides. Disagreeing with a reason is a better outcome than completing the task.

Are these suitable for interview preparation?#

Indirectly. They build the experience that lets you answer with specifics rather than definitions, which is what separates strong interview answers. See Interview Questions for the direct preparation.

What if I want something bigger?#

See Projects for end-to-end builds, and Labs for environments you set up and break deliberately.

Related Articles#

Follow the reading order in Courses, scale up with Projects, and test recall with Practice Tests.

What else is coming for Hands-on Exercises