Start with the problem you want to solve
Robotics brings several disciplines together. Mechanical engineers work on structures, mechanisms, actuation, thermal constraints, and manufacturability. Electrical and embedded engineers work on power, electronics, interfaces, firmware, and the timing of signals that software depends on. Neither is simply a supporting role for AI: a capable model cannot compensate for an unreliable power system or an actuator that cannot deliver the required motion.
If your best work involves physical prototypes, measurements, CAD, circuits, or low-level debugging, begin with those disciplines. Look for evidence of what the team actually builds in-house. A company integrating purchased hardware may have a very different mechanical role from one designing its own joints.
Separate perception from controls and planning
Perception roles turn sensor observations into useful estimates about the world. Depending on the product, that can involve computer vision, calibration, localization, mapping, sensor fusion, or learned representations. Read the description closely: a role centered on model training differs from one centered on real-time sensor integration.
Controls and autonomy roles concern how a system behaves and moves. Work may include motion planning, trajectory generation, state estimation, feedback control, or testing behavior under uncertainty. These areas overlap with perception, but the deliverables and validation methods can be quite different. A shared C++ requirement does not make two roles interchangeable.
Consider the people who make the whole system work
Software infrastructure and simulation engineers build tools that help other teams develop, reproduce, and test behavior. Examples include logging, replay, build systems, simulation environments, deployment tooling, and data pipelines. Systems and integration engineers connect components, investigate failures across boundaries, and make a robot work reliably outside an isolated demonstration.
For these roles, ask what success looks like. Is the goal faster development, more reproducible tests, better fleet reliability, or fewer deployment failures? Strong integration work often requires reading logs, designing experiments, and communicating across several specialties.
Compare the job, not just the title
Job titles and seniority vary between employers. A useful shortlist records the responsibilities, technical stack, physical work environment, and evidence you would need to show in an interview. Treat missing information as a question to ask rather than a reason to assume the best or worst.
- What subsystem would I own, and what would I deliver in the first few months?
- How much time involves hardware, simulation, production code, or field support?
- Which skills are explicitly required, and which can be learned on the job?
- Who reviews the work, and how is performance measured?
- Are travel, on-site access, and work authorization explained?
Choose a direction without closing every other door
Pick a primary discipline and one adjacent area to explore. A controls engineer who can investigate sensor timing or a perception engineer who understands deployment constraints can collaborate more effectively. That does not mean every candidate needs to master the entire stack.
Use current job descriptions as evidence of what a particular employer needs. Our categories are browsing aids, not a universal professional taxonomy. The original employer listing remains the source of truth for responsibilities, qualifications, and working arrangements.