Choose one project and make your contribution unmistakable
Start with a project relevant to the role you want. For controls, that might be a feedback experiment or a motion-planning comparison. For perception, it might be a calibrated sensor pipeline with a clear evaluation setup. For mechanical or embedded work, drawings, measurements, design decisions, and test procedures can be more informative than an elaborate website.
Explain whether the project was individual, a course assignment, or a team effort. Name the components you owned and credit the libraries, designs, datasets, and collaborators you relied on. Respect employer confidentiality and licensing restrictions. A public portfolio is not a reason to publish proprietary code or private data.
Write a short project brief before adding more features
Give the reader the problem, constraints, and result up front. Someone should be able to understand the purpose without first installing your software or watching a long video. Follow that summary with enough technical detail to support a deeper conversation.
- Problem: what should the system do, and for whom?
- Constraints: what hardware, compute, time, cost, or safety limits shaped the work?
- Contribution: which decisions and implementation were yours?
- Evidence: what measurements or tests support the result?
- Limits: where does it fail, and what did you not test?
Make the result reproducible where practical
Document dependencies, relevant versions, configuration, and the steps needed to run a representative example. If hardware is required, describe it clearly and explain which parts can be inspected or replayed without access to the machine. A small sample log or simulation example may help, provided you have permission to share it.
Separate expected behavior from observed behavior. State the conditions of a test, such as the environment, sensor setup, task, or number of trials. A successful run in one environment does not establish reliability in every environment. Avoid turning an isolated demonstration into an unsupported claim.
Explain one failure in detail
Pick a problem you actually investigated. It could involve mechanical tolerance, timing, calibration, noisy measurements, unreliable communication, or an assumption that did not hold. Describe the symptom, the hypotheses you considered, the evidence you collected, and the change you made.
An honest explanation of uncertainty can be more informative than a success-only presentation. If a fix improved one condition while making another worse, describe the tradeoff. If you could not resolve the issue, explain what you would measure next rather than inventing a confident conclusion.
Adapt the presentation to the vacancy
Lead with the project and evidence most relevant to the employer’s stated responsibilities. Keep links working and make the README easy to scan. Include diagrams or video where they explain motion, interfaces, or physical construction; add captions so the reader knows what to observe.
Public projects are one way to demonstrate skills, not a universal requirement. If you cannot share previous work, consider an appropriately scoped personal example or discuss non-confidential engineering decisions. Do not imply that all employers require unpaid take-home projects or a public GitHub history.
Before sending an application, check that you can explain your choices in your own words. The point of the portfolio is to make a useful technical conversation possible, not to hide uncertainty behind presentation.