Reflection, portfolio and career launch

The final lesson of the capstone, and of the robotics degree, looks back and forward. Looking back means reflecting on what happened in the project, what you contributed and what you learned, in a way that turns experience into lasting skill. Looking forward means presenting that experience to employers, graduate schools or funders through a portfolio, a résumé and interviews, and understanding the career paths open to robotics graduates, including professional licensure. This lesson also closes Team Tern's story and offers a final checklist for completing a capstone well.

Why reflection matters

Engineers learn as much from projects as from courses, but only if they stop to examine what happened. Without reflection, people tend to remember a project as a set of anecdotes, and to repeat the same mistakes in the next one. Reflection also matters for assessment: many programs grade an individual reflection because it shows insight that team deliverables cannot, such as how a student handled a conflict, what they would do differently and how their understanding changed.

A simple, widely used structure is "What? So what? Now what?". What happened: describe a specific event or decision factually. So what: analyse why it happened and what it meant, connecting it to engineering principles or team dynamics. Now what: state what you will do differently, as a concrete practice rather than a vague intention. Gibbs' reflective cycle adds explicit steps for feelings, evaluation of what went well and badly, and analysis before conclusions and an action plan. Either works; what matters is specificity and honesty.

The team retrospective

Alongside individual reflection, a final team retrospective captures lessons learned for the team's members, for future capstone students and for the partner. A useful format asks what went well and should be repeated, what went badly and should change, what surprised the team, and what recommendations it would give next year's team. Quantitative evidence makes the retrospective more useful than opinion alone: planned versus actual schedule, budget used, requirements met, test results, risks that materialized and those that did not.

Team Tern's retrospective identified three things to repeat: the early beach spike in week 3, which changed key requirements; the thread-based integration plan, which meant the robot was useful at every stage; and the decision to report results with confidence intervals, which the examiners praised. Three things to change: estimate integration time more generously, start the field-testing approvals earlier, and include combined-load electrical tests. One surprise: the most valuable output for the partner was the litter map, not the collection, which suggested that a future version might focus on mapping across the whole park with a cheaper robot. These lessons went into the final report and into a handover note for the next team.

Analysing your own contribution

A contribution log, kept from week 1 as lesson 1 recommended, lets you reflect on and evidence your role. It shows how your time was distributed across activities, what you produced and how your role changed over the term. It is also the raw material for résumé bullets and interview stories.

# Summarize a personal contribution log (illustrative entries for Dev)
from collections import defaultdict
log = [  # (week, category, hours, output)
    (2, "requirements", 6, "navigation requirements draft"), (3, "design", 8, "architecture diagram v1"),
    (3, "software", 5, "simulation world"), (4, "software", 12, "nav stack in simulation"),
    (5, "reviews", 6, "PDR slides: architecture and latency"), (6, "software", 11, "localization fusion"),
    (7, "integration", 14, "thread 1 and 2 integration"), (8, "integration", 9, "waypoint following on sand"),
    (8, "testing", 4, "route repeatability trials"), (9, "software", 8, "approach planner"),
    (10, "integration", 15, "thread 4 and 5, brown-out diagnosis"), (11, "testing", 9, "regression suite + field day"),
    (12, "documentation", 8, "report: design and integration chapters"), (13, "documentation", 6, "README, demo"),
]
by_cat = defaultdict(float)
for _, cat, h, _ in log:
    by_cat[cat] += h
total = sum(by_cat.values())
for cat, h in sorted(by_cat.items(), key=lambda kv: -kv[1]):
    print(f"{cat:14s} {h:5.1f} h  {h / total:5.1%}  {'#' * int(round(h / 2))}")
early = sum(h for w, _, h, _ in log if w <= 6); late = total - early
print(f"total {total:.0f} h; weeks 1-6: {early:.0f} h, weeks 7-13: {late:.0f} h")

integration     38.0 h  31.4%  ###################
software        36.0 h  29.8%  ##################
documentation   14.0 h  11.6%  #######
testing         13.0 h  10.7%  ######
design           8.0 h   6.6%  ####
requirements     6.0 h   5.0%  ###
reviews          6.0 h   5.0%  ###
total 121 h; weeks 1-6: 48 h, weeks 7-13: 73 h

The summary shows that Dev's work shifted from software development early in the term to integration, testing and documentation later, and that integration was his largest single category. That is a useful insight for reflection, since integration was the area where he learned the most, and for career planning, since systems integration is a distinct and valued role in robotics companies. It also supports the peer evaluation process with evidence rather than impressions.

Building a portfolio

A robotics portfolio shows what you can do in a form employers can check quickly. A strong portfolio typically includes a short project page for each major project with a one-paragraph summary, your specific role, a photo or short video, key results with numbers, the technical challenges you solved and links to code and reports where they can be shared; a public code repository with clean, documented work; and a résumé that links to both. Quality matters more than quantity: two well-documented projects with clear evidence of your contribution are more convincing than ten thin ones.

Before publishing, check what you are allowed to share. Sponsor confidentiality, the partner's data and the IP decisions discussed in lesson 11 may limit what goes online. Images of members of the public collected during testing should not appear in a portfolio without consent. When in doubt, describe the work and results in words, show the robot rather than the data, and link to the parts that are public. Credit teammates honestly: say "I led navigation and integration in a five-person team" rather than implying you built the whole robot. Employers notice, and teammates will be your professional network for decades.

Interviews

Robotics interviews often combine technical questions, coding or design exercises, and behavioural questions about past projects. The capstone is your best source of answers to behavioural questions such as "Tell me about a time you solved a hard technical problem" or "Describe a conflict on a team". The STAR structure, situation, task, action and result, keeps answers focused: briefly set the scene, state your responsibility, describe what you specifically did, and give the result, ideally with a number and a lesson learned. Prepare four or five capstone stories covering a technical problem, a failure, a conflict, a decision under uncertainty and a time you led or helped others.

Technical interviewers often probe deeply into one project: why did you choose that sensor, what were the alternatives, what would you do differently, how did you know it worked? The trade studies, decision records and verification results from this course are the best preparation. Being able to say "we chose a 2D safety-rated scanner over a depth camera for the protective stop because it is certified for safety functions and works in sunlight; here is the trade study" demonstrates engineering judgment far better than a list of tools.

Career paths in robotics

Robotics graduates work in a wide range of roles. Robotics software engineers build perception, planning, control and infrastructure software. Controls engineers design and tune control systems for robots and automated machines. Perception and machine learning engineers develop vision and learning systems. Mechanical and mechatronics engineers design robot hardware. Systems and integration engineers, like Dev's emerging role, connect subsystems and own requirements, interfaces and testing. Test and validation engineers design and run verification programs. Field and applications engineers deploy robots at customer sites. Automation engineers design robot cells in manufacturing, as in ROB-440. Industries include manufacturing, logistics, agriculture, mining, health care, space, defence, consumer products and research.

Graduate school is another path, particularly for research-focused roles in perception, learning, manipulation or human-robot interaction. A capstone with a strong technical core, a clear report and possibly a workshop paper is good preparation for a research-based master's or doctoral program. Many students also continue their capstone through a summer research position or an internship-based project, using the funding sources in lesson 11.

Professional licensure

Licensure gives engineers the legal right to practise professional engineering and to take responsibility for engineering work affecting public safety. Requirements differ significantly between Canada and the United States, and robotics work spans areas that are regulated differently, so graduates should understand the route in their jurisdiction early.

In Canada, engineering is regulated provincially and territorially, and the title "engineer" and the practice of engineering are protected by law. Licensure as a Professional Engineer (P.Eng., or ing. in Quebec) generally requires an accredited degree or equivalent, a period of supervised engineering experience (for example, 48 months in Ontario, assessed through a competency-based approach), and passing the National Professional Practice Exam on law and ethics or an equivalent; graduates usually register as engineers-in-training or similar where that status is offered. Professional Engineers Ontario removed its requirement for Canadian experience in 2023, and other regulators have changed their requirements too, so check your regulator's current rules. Many robotics roles involve safety-related machinery work, such as Ontario's pre-start health and safety reviews covered in ROB-450, that must be done or supervised by licensed engineers.

Whatever the jurisdiction, the ethical obligations introduced in lesson 1 and practised throughout the capstone, holding public safety paramount, practising within competence and acting honestly, are what licensure formalizes. The capstone's safety review, honest test reporting and transparent re-scoping are early evidence of the professional judgment that licensing bodies and employers look for.

Closing Team Tern's story

Team Tern finished the term with a robot that met all of its must-have requirements, some with confidence intervals that did not yet prove the target, and missed one should-have. Its full patrol at the beach collected cans and mapped all litter types, and parks staff said the litter map alone had changed where they planned to place new bins. The team's recommendations, a mapping-focused version covering the whole park and a suction end effector for cigarette butts and wrappers, were taken up by the next year's capstone team, who received Tern, its documentation and the handover note. Ana went on to a mechanical design role at an agricultural robotics company, Ben to a controls position in automation, Chloé to a master's program in robot perception, Dev to a systems integration role at a logistics robotics firm, and Ema to a test and validation role at an autonomous vehicle company. Each of them used Tern in their interviews.

Your capstone will have its own story, with its own surprises and setbacks. The practices in this course, defining the problem before the solution, writing measurable requirements, comparing alternatives honestly, managing interfaces and margins, integrating incrementally, testing with statistical honesty, taking safety and ethics seriously, documenting as you go and reflecting on what you learned, are the same practices that professional robotics engineers use on projects a thousand times larger. The degree ends here; the engineering continues.