Recruiters do not read portfolios looking for ideas. They look for evidence that you finish, measure and explain. Three documented projects beat fifteen half-built ones, every time.
This guide covers what to build, how to document it so a hiring manager can evaluate it in five minutes, and how to present student work honestly when the lab had one oscilloscope and no budget.
What a portfolio is actually proving
A portfolio answers four questions an interviewer cannot ask from a resume: can you build something that works, can you debug it when it does not, can you explain your decisions, and can you work within constraints. Every project you show should make at least one of those easier to answer.
| Signal | What proves it | What does not |
|---|---|---|
| You can build | Working hardware, wiring photos, measured results | A CAD render |
| You can debug | A failure you found and fixed, with the method | A list of features |
| You can design | Constraints, trade-offs, a rejected option | A block diagram with no reasons |
| You can measure | Numbers: accuracy, cycle time, current, temperature | “Works smoothly” |
| You can explain | A two-minute video and a clear README | Slides full of screenshots |
Three projects, three roles
Choose projects that map to the job you want, and make each one deep enough to discuss for twenty minutes. A useful structure is one control project, one perception or sensing project, and one integration project.
| Target role | Project one | Project two | Project three |
|---|---|---|---|
| Embedded / firmware | Closed-loop motor control with an encoder | Sensor driver on a real bus | Battery-powered robot with safe power path |
| Robot software | ROS 2 nodes with custom interfaces | SLAM or navigation in simulation | Hardware-in-loop with a real robot |
| Machine vision | Calibrated camera pipeline | Detector with measured accuracy | Vision-guided pick on a small arm |
| Industrial automation | PLC sequence with safety interlock | Robot cell handshake | Cycle-time improvement with numbers |
| Mechanical design | Mechanism with calculated loads | Manufactured part with tolerances | Full assembly with drawings |
If you already have ten projects, pick three and document them properly. Depth signals competence; a long list signals that you start things.
The document that makes a project credible
For each project, write a page that a busy engineer can skim. The order below works because it puts the problem and the result before the technology.
- Problem in one sentence, with who it is for.
- Constraints: budget, parts available, time, skill gaps.
- Design: what you chose and one option you rejected, with the reason.
- How it works: a short block diagram and the key calculation.
- Test: what you measured, with the instrument and the number.
- Failure: what broke, how you found it, what you changed.
- What you would do differently with three times the budget.
- Links: code, video, photos, schematic.
The failure section is the one candidates skip and interviewers value most. Anyone can describe a working robot; only someone who debugged one can describe the three days it did not work.
A README structure for GitHub
Most recruiters will open the repository before they watch a video. Give them a README that answers the same questions as the PDF.
# Project name
One sentence: what it does and for whom.
## Demo
Video: link with a 60 second cut.
## Hardware
Controller, drivers, sensors, power, approximate cost.
## How it works
Short explanation, one diagram, one key equation.
## Results
Measured accuracy, speed, current draw, and how each was measured.
## What did not work
Two honest failures and the fix.
## Build and run
Exact commands, versions, and known issues.Keep the repository buildable. A project that cannot run on a fresh machine is a screenshot collection, and reviewers notice missing build steps quickly.
When you have no hardware
College labs are often short of parts, and simulation is a legitimate way to show competence if you present it as simulation. A Gazebo or MuJoCo project with a tuned controller, logged results and a clear methodology is stronger than a hardware project that never ran.
- State clearly what was simulated and what was physical.
- Include the model, the parameters and the version of the simulator.
- Show a failure case and how the controller recovered.
- Add one cheap physical experiment, such as an IMU on a breadboard, to connect simulation to reality.
- Publish the launch commands so someone can reproduce the result.
Numbers you can honestly claim
Vague claims collapse under one follow-up question. If you say the robot is accurate, the next question is how accurate and how you measured it. Prepare the number, the instrument and the sample size.
| Claim | What to say instead |
|---|---|
| Very accurate | Repeated 20 picks, average error 1.8 mm, measured with vernier calipers |
| Fast | 3.4 s cycle time over 50 cycles, measured with a stopwatch and logged timestamps |
| Efficient | 2.1 A average during the cycle, measured with a shunt and an oscilloscope |
| Robust | Ran 6 hours without a reset; two faults found and fixed during that run |
Video and photos that help
- Sixty seconds, no music, showing the actual task from a useful angle.
- One wide shot of the whole setup, one close-up of the mechanism.
- A clip of the failure if it is instructive.
- Overlay the measurement on screen if it is not visible.
- Photograph the wiring before closing the enclosure; recruiters notice tidy work.
Common portfolio mistakes
| Mistake | Why it hurts | Fix |
|---|---|---|
| Team project with no role stated | Reviewer cannot judge your contribution | State exactly what you built and tested |
| Only renders and screenshots | Suggests nothing was built | Add photos, measurements and a demo |
| Copied tutorial project | No evidence of independent thinking | Extend it with a modification and a test |
| No code or unbuildable code | Cannot verify claims | Clean the repo and pin versions |
| Huge feature list, no results | Signals shallow work | Cut features, add measurements |
| Broken links | Suggests carelessness | Check every link before applying |
Using internships and freelance work
Paid or industrial work is the strongest portfolio material, provided you can describe it. If the work is confidential, describe the problem class and your contribution without naming the customer, and keep a private copy of the details for interviews.
- State the scale: number of machines, parts per shift, number of users.
- State your specific part in the delivery.
- State the result in the customer’s terms: downtime, cycle time, scrap.
- Keep a portfolio entry even when the code cannot be shared.
Related: robotics resume for freshers, robotics jobs for freshers in India, robotics internships in India, robotics project ideas, robotics skills roadmap.
How many projects should a fresher portfolio have?
Three well documented projects are enough, ideally covering control, sensing or perception, and integration. Ten shallow projects make a weaker impression than three you can discuss for twenty minutes.
Do recruiters accept simulation-only projects?
Yes, if you present them honestly as simulation and show methodology, failures and measured results. Add one small physical experiment to connect the simulation to real hardware.
What should a robotics GitHub repository include?
A README with the problem, a demo, hardware list, how it works, measured results, known failures and exact build commands. It should build on a fresh machine.
Can I include confidential industry work?
Yes, in a general form. Describe the problem, your role and the measured outcome without naming the customer or sharing proprietary details, and keep the specifics for the interview.
What if my project failed?
Include it if you can explain what you learned and what you would change. A documented failure with a clear diagnosis is stronger evidence of engineering skill than a claim that everything worked.
Pick projects you can finish and publish, and the club guide explains how to keep them on schedule.
Projects are what gets you shortlisted, and the internship guide shows how to present them to a small company.
Sources and further reading
- GitHub README documentation — structure and formatting guidance.
- ROS 2 documentation — project structure and tutorials worth referencing.
- IEEE Robotics and Automation Society — student activities and technical communities.
