Robotics and UAV hiring managers read past buzzwords quickly. A resume that lists "ROS, PX4, Gazebo, controls" tells them nothing about whether you integrated a stack, tuned a controller that flew, or clicked through a tutorial once. The job of your resume is to make your actual depth legible and checkable.
Show what you built, not what you touched
The single most useful distinction on a robotics resume is authorship. "Used ROS2" and "designed a ROS2 node graph for a multi-sensor perception pipeline" occupy different worlds. Anchor each bullet in a verb that implies ownership: implemented, tuned, integrated, debugged, characterized, deployed. Then name the concrete thing.
Some illustrative shapes worth borrowing:
- "Wrote a PX4 custom flight mode and offboard controller; validated in SITL before hardware flights."
- "Built a ROS2 (Humble) tf2 transform tree and time-synchronized IMU/GPS fusion for outdoor localization."
- "Ported a ground robot's navigation stack from ROS1 to ROS2, replacing actionlib with action servers."
Each names a system, a specific technology version, and a verifiable deliverable.
Be precise about the sub-disciplines
"Robotics" spans distinct skill areas, and a good posting usually signals which one it wants. Read for it and mirror the right vocabulary:
- Controls: PID vs. LQR vs. MPC, gain tuning, cascade loops, attitude vs. position control, actuator saturation handling.
- State estimation: EKF/UKF, sensor fusion, GPS-denied navigation, VIO, covariance tuning — say which filter and which sensors.
- Autonomy/planning: global vs. local planners, costmaps, behavior trees, A*/RRT variants.
- Flight stacks: PX4 vs. ArduPilot are not interchangeable; MAVLink, offboard control, and airframe config are their own competencies.
- Simulation: Gazebo (Classic vs. Ignition/Gz), SITL/HITL, and whether your sim results transferred to hardware.
If a posting emphasizes MPC and VIO, a resume that only says "controls" is leaving the alignment work undone. Match the specific terms you honestly own.
Make the work verifiable
Robotics is a field where artifacts carry weight. A public repo, a short demo video, a flight log, or a bench-test photo does more than any adjective. Link them. If your best work is under NDA, describe the class of problem and the stack without the proprietary details — reviewers understand that constraint.
When you keep a running record of your projects — the repo URLs, the sim-to-hardware notes, the controller you tuned and why — you can pull real evidence into each application instead of reconstructing it from memory. That is essentially what a Memory Board is for: a place to collect the concrete artifacts so the resume points at something real.
Be honest about depth
Robotics interviews expose shallow claims fast. If you ran a tutorial in Gazebo, do not imply you architected a simulation environment. If you flew in SITL but never on hardware, say so plainly — SITL experience is genuinely valuable and worth listing accurately. Distinguish coursework and personal projects from production or fielded systems; a labeled personal quadrotor project reads as credible, while an unlabeled one that collapses under questioning does not.
Aligning to the posting
Before you tailor, extract the posting's real requirements: the specific middleware version, the platform (aerial, ground, manipulator), the language (C++ vs. Python weighting), and the domain (research vs. safety-critical fielded systems). Where you have matching evidence, foreground it early. Where you have a genuine gap — say the role wants ArduPilot and you only know PX4 — decide whether to name the adjacent experience honestly or let it go, rather than papering over it with a keyword you can't defend in the interview.