Where you are. You have a track, the honest ROS 2 minimum, and tooling that records what your robot actually did. This lesson spends the next six to eight weeks of your calendar on one project, and it starts by deciding what that project is for.
Two links in a thread
Somebody forwards you two candidates and asks which one is worth an hour. You have nine minutes before your next call.
The first link is five repositories. A simulated pick-and-place, a fine-tuned policy, a small middleware package, an agent demo, a notebook. Each one works. Each one took a weekend, and you can tell.
The second link is one repository. One system, eight weeks of commits, a table of sixty trials broken out by lighting condition, and a section near the bottom headed “where this fails and why”.
Notice what you just did. You did not assess skill; both people can obviously write code. You worked out which one you would have something to ask about. The five-repository candidate leaves you one question, asked five times: did you write this yourself. The one-system candidate leaves you fifteen, and the first one is about that table.
A capstone is not proof that you can do robotics. It is the thing that gives a stranger something to ask you.
The idea in one paragraph
Design the capstone backwards from a sentence. Pick one claim about what kind of engineer you are, specific enough that it could turn out to be false. Build the smallest end-to-end system whose measured behaviour is evidence for that claim. Decide, before you write any code, which numbers would count as evidence and which would count as a failure. Then cut every feature that does not move the claim either way. The failure mode this prevents is the ordinary one: build an impressive demo, then reverse-engineer a claim out of whatever happened to work. That produces a project which is genuinely impressive and completely unaskable, because nothing in it was ever at risk of being wrong.
Start from the sentence
Write the claim first, in one sentence, before any architecture. The test is falsifiability: if there is no result that would make the sentence untrue, it is not a claim, it is a mood.
“I can build robots” fails the test. So does “I built an agentic robotics system”, which describes an artifact rather than asserting anything about it. These pass:
- An LLM planner can drive a real arm through multi-step tasks at a success rate I can state, and I know exactly which step fails and why.
- A learned policy trained on my own data holds up when I change the lighting, and I can show you how far it degrades before it breaks.
- A dataset pipeline can catch the bad episodes that quietly poison a training run, and I can measure how much it improved the resulting policy.
Each one names something measurable and admits a bad outcome. That admission is what makes it worth building.
The evidence has to be checkable without you
Wider than the screen; scroll it sideways.
Three kinds of evidence carry a claim, and a capstone needs all three.
Measured behaviour. A success rate, with the number of trials and the conditions attached. Not a demonstration that it can happen; a count of how often it does.
A durable artifact. Something a stranger can hold: a dataset in a standard schema, a recording they can scrub through, a checkpoint they can load. It survives being separated from you and from your laptop.
A failure account. Which cases break, what the root cause was, what you changed. This is the piece nearly everybody omits, and it is the piece that converts a demo into an engineering claim.
The spine, and everything that is not the spine
A capstone earns its length by going end to end. Sensor to decision to controller to a real actuator to a measurement of what happened. Five segments, and the reason it must be all five is that robotics does not break inside the segments. It breaks at the seams: the timestamp that was in a different clock, the frame convention that was flipped, the queue that silently dropped the message under load, the policy trained at one rate and deployed at another.
Wider than the screen; scroll it sideways.
Five weekend projects cover five segments and zero seams. That is the structural reason the one-system candidate is more interesting, and it has nothing to do with effort.
Everything outside the spine is shell: the web UI, the second embodiment, the deployment story, the config system, the second policy architecture you want to compare. Shell is not worthless. It is just not evidence, and every week spent on it is a week not spent on the seams.
Decide the numbers before you build
Write the evaluation protocol in week zero, on paper, and treat it as frozen. It needs four things: the task, the number of trials, the conditions you will vary, and the threshold that counts as success on a single trial.
Fixing the threshold in advance matters more than it sounds. “Success” is a definition, and a definition can be quietly moved. Did a grasp that lifted the object and then dropped it count? Does a task that finished in nine seconds instead of three count? If you decide after seeing the runs, you will decide generously, without noticing, every time.
The conditions matter as much as the count, because a single aggregate rate hides the interesting result. Twenty trials on one object under one light gives you a number about that afternoon. Sixty trials across three objects and two lighting conditions gives you a number about the system, plus the breakdown that tells you where it lives and where it dies.
Order the weeks by risk, not by comfort
The natural build order is easiest-first, because the easy parts produce visible progress. It reliably puts the one thing that can kill the project in week six, where finding out is useless.
Wider than the screen; scroll it sideways.
Invert it. Week one is a deliberately ugly probe at the single assumption that, if false, ends the project. Can the policy run fast enough on the hardware you own. Does the gripper actually close on that object. Does the planner produce a usable plan at all when the scene is not the one you imagined. Ugly is fine; the probe is a question, not a component, and you throw it away.
Week two is a thin end-to-end slice: every segment of the spine present, all of them bad. From there the project is an improvement loop rather than an integration gamble, and integration gambles are how eight-week projects become sixteen-week projects.
Build so that one hard story exists
Technical interviews in this field converge on the same move. Somebody asks which part consumed most of your time, then follows the answer down three levels. What did you try first. Why did that not work. How did you know it was that and not the other thing.
Padded work dies at the second follow-up. There is no way to fake the third level, because the answer is a specific afternoon.
This is a design constraint, not a lucky by-product. Choose a capstone with at least one genuinely hard sub-problem you expect to lose days to, and then keep a running log while you lose them: what you observed, what you hypothesised, what you measured, what it turned out to be. That log is where the write-up, the failure section and the interview answer all come from, and it cannot be reconstructed later.
Check yourself
1. Why does the claim have to come before the architecture?
Because the claim determines what is worth building. Design flows from the sentence: the system exists to produce evidence for it, the evaluation exists to test it, and the scope is whatever moves it. Reversing the order means writing the claim after seeing the results, which is guaranteed to produce a true statement and a worthless one, because it was never at risk of being false. If no result would make the sentence untrue, it is not a claim.
2. A friend shows you a two-minute video of their arm doing a task flawlessly, with no numbers. What does a robotics reviewer infer, and why is that not unfair?
That the work was probably evaluated and the results were not good enough to publish. It is not unfair because the field knows the cost structure: running twenty trials and building a results table is a day of work, so its absence is a choice rather than an oversight. A single clean take is also compatible with any number of failed attempts, and the reviewer cannot tell which. Silence about numbers is read as a number, and the number it is read as is low.
3. What is the deletion test, and what does it decide?
Remove a feature and ask whether the claim is still supported. If it is, the feature was shell rather than spine, and shell is what gets cut when the calendar tightens. It decides scope. The spine is the shortest path from a real sensor reading to a real physical action to a recorded measurement; the web interface, the second embodiment and the configuration system are all outside it, however much better they make the project look.
4. Why does the riskiest unknown belong in week one rather than where it naturally falls?
Because its only value is the information it gives you, and information arriving in week six of an eight-week project cannot change anything. Probing it first buys correction points: if the assumption is false, you still have seven weeks to change the design, pick a different task or scale down the claim. Easiest-first ordering feels productive because it produces visible progress, and it concentrates all the project risk in the part of the calendar with no slack left.
5. You get 14 successes out of 20 trials. What can you honestly say?
That the observed rate is 70%, and that the 95% interval runs from about 48% to 86%, which is wide enough to be compatible with a considerably worse system and a considerably better one. Honest phrasing quotes the count, the denominator and the conditions, and either widens to fifty or a hundred trials or states the interval. What you cannot honestly do is compare it against another 70% from a different condition set and call them equal, because at this sample size the difference between the two is invisible.
6. Why is “one hard sub-problem” a design requirement rather than bad luck?
Because the standard technical interview probes one topic three levels deep, and only genuinely debugged work has a third level. The answer at that depth is always a specific observation on a specific day, which cannot be reconstructed after the fact and cannot be invented. So you choose a capstone containing a problem you expect to lose days to, and you keep a log while losing them. The same log later becomes the failure section of the write-up and the most interesting ten minutes of any interview.
Do this
About two hours, and it produces the document that governs the next two months.
1. Write the claim. One sentence. Then write the sentence describing the result that would make it false. If you cannot write the second sentence, the first one is not a claim yet.
2. Draw the spine. Five boxes, sensor to measurement, with the actual technology in each. Then mark the four seams between them and write, for each seam, the specific thing that could go wrong there: clock, frame, rate, message loss, units.
3. Write the kill list. Everything you want to build that is not on the spine. Name each one and mark it cut. Keep the list; it becomes the “what I did not build and why” paragraph in the write-up, which is a stronger paragraph than most people expect.
4. Freeze the evaluation. Task, trial count, conditions varied, and the per-trial definition of success, precise enough that somebody else running your trials would score them the same way. Twenty trials per condition minimum. Date the file and do not edit it after the first run.
5. Order eight weeks by risk. Week one is the ugly probe of the assumption that could end the project, and write down in advance what result would make you change plan. Week two is the thin end-to-end slice. Week six is frozen evaluation; weeks seven and eight are shipping, which the next lesson treats as real engineering work rather than paperwork.
6. Run the depth probe on the brief. Give it to somebody technical and ask them to pick the hardest-sounding part and ask “why” three times. If you run out of answer at the second why, that part is not designed yet.
What you can now do
You can state a capstone as one falsifiable claim instead of a project description, name the three kinds of evidence that carry it, tell spine from shell with a deletion test, freeze an evaluation protocol before the results can influence it, quote a success rate with the honesty its sample size deserves, and order eight weeks so that the thing most likely to kill the project is discovered while there is still time to respond to it.