Robotics Software Engineer Jobs in 2026: Roles, Salaries, and How to Land One

Robotics Software Engineer Jobs in 2026: Roles, Salaries, and How to Land One

If you can already code in C++ or Python, robotics is one of the few engineering fields in 2026 still posting six-figure entry-level salaries — but most candidates lose months chasing the wrong roles, the wrong companies, and the wrong skills. Indeed shows over 4,000 active robotics software engineer jobs as of March 2026, and Glassdoor lists nearly 8,800 open robotics engineer roles across the US. The volume is real. The signal-to-noise problem is what kills most applications.

This guide breaks the field into the three role archetypes hiring teams actually fill, the robotics engineer salary bands visible in current postings, the skill stack that survives technical screens, and a realistic timeline by background. Salary data comes from active job postings on Indeed, BuiltIn, and Glassdoor (May 2026 snapshot). Timeline estimates reflect industry convention reported across hiring manager commentary and university career services anecdote — not rigorous labor research. Treat the numbers as planning anchors, not guarantees.

Table of Contents

• The Three Robotics Software Engineer Job Categories Hiring in 2026
• What Robotics Software Engineers Actually Earn in 2026: Verified Salary Bands
• Where the Robotics Software Engineer Jobs Actually Are: Sector and Geography Breakdown
• The Six Skills Hiring Teams Screen For — and How to Show Them Without Robotics Experience
• Three Portfolio Projects That Prove You Can Do the Job — Without Robotics Work History
• Where to Find Robotics Software Engineer Jobs and How to Pass the Technical Screen
• From Where You Are to Robotics Hire: Timeline and Contingency by Background

---

The Three Robotics Software Engineer Job Categories Hiring in 2026

Most candidates apply to robotics software engineer postings as if they're a single role. They aren't. Hiring teams are filling three distinct archetypes — and screening criteria, tech stacks, and salary brackets diverge sharply between them. Understanding which category fits your background determines whether you land interviews or get filtered out before a human reads your resume. The three archetypes below describe what hiring teams are actually building toward when they post these roles.

Embedded Systems Engineers write firmware and low-level control code that runs directly on robot hardware. The work sits closer to electrical engineering than web development. You're configuring peripherals, hitting deterministic timing budgets, and debugging with an oscilloscope as often as a software profiler. Common at industrial automation companies, surgical robotics programs (Johnson & Johnson OTTAVA), and edge computing platforms (ByteDance Edge).

Perception & Computer Vision Engineers build the systems that let robots interpret sensor data — cameras, LiDAR, depth sensors, sometimes radar. Heavy ML and deep learning component, with significant 3D geometry work underneath. Common at autonomous vehicle companies, agricultural CV firms like Blue River Technology (a John Deere subsidiary), and surgical robotics where intra-operative imaging matters.

Motion Planning & Controls Engineers translate high-level goals into actuator commands. The most math-heavy of the three categories. Often requires graduate-level coursework in control theory, optimization, and linear systems. Common at surgical robotics firms (J&J OTTAVA), aerospace and air traffic robotics (INDRA-type roles), and advanced manipulation startups working on dexterous grasping.

Role Category	Primary Tech Stack	Typical Hiring Companies	Salary Range Observed
Embedded Systems	C/C++, RTOS, Linux kernel	ByteDance, HarveStaff, J&J, Blue River	$93K–$218K
Perception / CV	Python, C++, ROS, OpenCV, PyTorch	Blue River, AV teams (BuiltIn SF), Coco	$140K–$285K
Motion Planning & Controls	C++, Python, ROS, MoveIt	J&J OTTAVA, INDRA, manipulation startups	$125K–$250K

Perception roles command the salary premium because autonomous vehicle capital is concentrated in a small number of well-funded teams, and Staff-level CV engineers pull $200K–$285K base per BuiltIn SF listings. Embedded skews lower at the entry band but offers the cleanest path for general software engineers — the math is less specialized, the systems skills transfer directly from kernel and distributed systems work, and the screen rewards depth in C and timing rather than years of robotics-specific exposure.

Controls roles require the deepest specialization. Linear systems theory, Lyapunov stability analysis, optimization under constraints — most candidates need 6+ months of focused study even with a strong CS background. The payoff is leverage: controls engineers are scarce, and the postings that require them tend to be at companies with deep funding (surgical robotics, aerospace, advanced manipulation).

One caveat on the volume figures: posting counts on Indeed and Glassdoor do not distinguish role type cleanly. The aggregate numbers conflate "robotics engineer," "software engineer (robotics)," and adjacent titles like "controls engineer" or "perception engineer." Treat the totals from Indeed's general robotics search as upper-bound directional, not exact.

---

What Robotics Software Engineers Actually Earn in 2026: Verified Salary Bands

Salary data here comes from active job postings on Indeed, BuiltIn, and Glassdoor as of May 2026. Ranges reflect base compensation only — equity, signing bonuses, and relocation are excluded. Geographic spread (San Jose vs. Seattle vs. remote) explains most of the within-band variance. The bullets below organize observed bands by seniority, then by company stage.

• New Grad / Entry-Level (BS or MS, 0–2 years): $93,480 – $259,200/year. ByteDance new-grad postings span the widest range — Edge Platform Engineer roles list $112,725–$177,840, while Cloud Native Infrastructure roles top out at $259,200 in San Jose, per Indeed new-grad listings. Test-focused roles sit at the lower end ($93,480–$142,800). The wide spread reflects geography and role specialization, not entry-level grade variation.
• Mid-Level Engineers (3–5 years experience): $91,000 – $200,000/year. Coco Robotics lists software engineer roles at $140K–$200K. Johnson & Johnson surgical robotics posts $91K–$129K for similar tenure on the March 2026 Indeed snapshot — medical device cadence and regulatory overhead historically suppress salaries versus pure tech employers. HarveStaff lists Linux robotics roles at $54.53–$62.53/hour, which annualizes to roughly $113K–$130K at full-time hours.
• Senior Engineers (5–8 years): $125,000 – $250,000/year. Blue River Technology lists Senior Robotics Engineer at $142K–$250K and Embedded Software Engineer at $125K–$218K. The ~$100K range within a single posting reflects level banding inside the title — a "Senior" req often covers what other companies would split into Senior I and Senior II.
• Staff & Principal (8+ years): $200,000 – $285,000/year base. BuiltIn SF lists Staff Software Engineer roles in autonomous vehicles at $200K–$285K. Add equity and signing bonuses for total comp; base alone exceeds most non-FAANG senior bands. These roles are rare in absolute count but consistently top the salary distribution across robotics-specific postings.
• Startup vs. Enterprise tradeoff: Startups (Coco, Sieve) compress base salary roughly 10–20% below enterprise comparables but offer larger equity grants. No verified data on equity outcomes — robotics startup survival rates are not publicly aggregated, so treat equity upside as speculative. Hardware-dependent businesses fail more often than pure SaaS, and unlike software companies, a failed robotics startup leaves engineers with specialized skills that don't always transfer cleanly to web roles.

Early-stage robotics companies compress base salary to fund equity, but unlike SaaS startups, hardware-dependent businesses fail more often and equity outcomes remain unverified.

---

Where the Robotics Software Engineer Jobs Actually Are: Sector and Geography Breakdown

Across Indeed and Glassdoor, May 2026 active listings sit between roughly 1,600 (Indeed all-time active for tightly filtered "software" titles) and 8,779 (Glassdoor US for the broader "robotics engineer" title). The wide range reflects how each platform defines the role — Glassdoor includes broader engineering titles, Indeed filters tighter on software. Treat both numbers as upper-bound directional. They tell you the field is hiring at meaningful volume; they don't tell you whether reqs are closing or sitting open for six months.

Five sectors dominate active postings. Industrial automation and manufacturing shows up through HarveStaff and similar staffing-driven listings — warehouse and factory floor robotics, dominant in Texas, Ohio, and Pennsylvania. Autonomous vehicles and mobility concentrates in San Francisco, Pittsburgh, and Phoenix, with BuiltIn SF Staff-level AV roles posting the highest base salaries observed in this dataset. Surgical and medical robotics clusters around Johnson & Johnson's OTTAVA program plus mid-stage startups in San Jose, Boston, and Raleigh-Durham. Agricultural robotics runs primarily through Blue River Technology, headquartered in Sunnyvale with distributed teams. Edge computing and infrastructure platforms — ByteDance leads here — hire robotics-adjacent platform engineers (3D graphics, edge inference) that surface in robotics search results without being pure robotics work. Posting volume by sector does not equal hiring momentum; making claims about which sectors are growing or cooling would require labor research not present in available sources.

Geographically, roles cluster heavily in five metros: San Francisco Bay Area, Pittsburgh (the Carnegie Mellon spinout corridor), Boston (MIT and the medical robotics cluster), Seattle (Amazon Robotics-adjacent and edge platform work), and Austin. Remote roles exist but are rarer than in pure SaaS — most robotics work requires hardware proximity for at least part of the development cycle. ByteDance postings show San Jose anchoring the West Coast presence; BuiltIn SF and BuiltIn NYC reflect heavy coastal weighting. A candidate unwilling to relocate to or near a robotics hub will face dramatically reduced volume — possibly an order of magnitude fewer viable openings than the headline numbers suggest.

Three company-stage buckets dominate active postings. Late-stage and enterprise (J&J, ByteDance, John Deere/Blue River) offer the cleanest hiring pipelines, structured interviews, and strongest base compensation, though the cycle from application to offer can run two to three months. Series B–D startups (Coco, Sieve) move fastest, screen less rigidly, and weight comp toward equity. Defense and aerospace (INDRA-type air traffic and aerospace robotics, plus life sciences R&D firms) run the slowest hiring cycles and often require security clearance, which adds cybersecurity screening on top of technical evaluation and can extend time-to-offer by months. With the geography and sector picture clear, the next question is what skills hiring teams actually screen for once you've targeted the right roles.

---

The Six Skills Hiring Teams Screen For — and How to Show Them Without Robotics Experience

These six competencies appear in nearly every robotics software engineer posting reviewed across Indeed, BuiltIn, and Glassdoor. Depth required varies by role category, but the floor is consistent. Each item below specifies what hiring teams expect and how to demonstrate it without paid robotics work history.

1. Production-grade C++ and Python. C++ for performance-critical paths (controls loops, perception pipelines), Python for tooling, ML, and ROS scripting. Hiring teams expect modern C++ — C++17 or C++20 with smart pointers, move semantics, and template fluency. Senior postings explicitly call for multi-threaded code and memory-safe patterns. Demonstrate with public repos showing both languages — a Python ML notebook and a C++ systems project. Mixed-language repos that show interop (pybind11, C++ extensions called from Python) signal real engineering judgment.
2. One robotics framework: ROS 2, Gazebo, or an embedded RTOS. Perception and motion planning roles require ROS 2 fluency — rclcpp, lifecycle nodes, DDS configuration, parameter management. Embedded roles want FreeRTOS, Zephyr, or similar real-time operating systems. Postings rarely list these as "preferred" — they list them as "required." Pick one and go deep. Surface-level ROS exposure (a single tutorial completed) gets filtered on the technical screen because hiring managers can spot it in five minutes of code review.
3. Real-time and concurrent systems thinking. Robots fail when control loops miss deadlines. You don't need a real-time OS background, but you must understand priority inversion, jitter, deterministic scheduling, and why a 100Hz control loop cannot tolerate a malloc() in the hot path. Read Jane Liu's Real-Time Systems fundamentals or equivalent. In interviews, the question "why is this code not real-time safe?" appears reliably in embedded and controls screens, and the answer separates candidates who've thought about it from those who haven't.
4. Linear algebra, transforms, and basic controls math. Coordinate frames (SE(3), quaternions), Jacobians, PID tuning, state-space basics. Perception roles add camera intrinsics and extrinsics, projective geometry, and bundle adjustment fundamentals. Controls roles add Lyapunov stability, optimal control, and convex optimization. Khan Academy linear algebra is the floor; Steve Brunton's controls lectures on YouTube are the practical ceiling for non-PhDs and cover most of what mid-level interviewers will ask.
5. Git workflow, CI/CD, and code review fluency. Screening signal more than a pure skill — sloppy commit history or uncommented public repos read as "doesn't work well on teams." Show meaningful commit messages (no fix stuff or wip 3), PR descriptions that explain trade-offs, GitHub Actions or similar CI configured, and unit tests that actually run. This applies to your portfolio repos as much as professional work; reviewers open your GitHub before they open your resume.
6. Simulation-first development. You don't need physical hardware to demonstrate robotics competence. Gazebo, NVIDIA Isaac Sim, MuJoCo, and Webots all let you build credible projects. Hiring teams know not every candidate has a robot at home — but they expect you to have used simulation to validate algorithms. A working sim demo with AI-based perception components beats a half-built physical prototype every time. Recorded video of the sim running, plus quantitative results, is the artifact that closes the screen.

These skills get you past the resume screen and through most technical conversations. Solid software development fundamentals are non-negotiable across every category — robotics employers don't lower the engineering bar to compensate for domain depth. The next section covers how to package the skills above into portfolio artifacts that hiring managers actually open and read.

---

Three Portfolio Projects That Prove You Can Do the Job — Without Robotics Work History

The chicken-and-egg problem in robotics hiring is real: companies want experience, but you can't get experience without a job. The workaround is a portfolio of simulation-based projects that demonstrate the same competencies as paid work. Hiring managers open GitHub. They look for three things: depth (does this go past tutorial level), documentation (can someone else understand it), and judgment (did the candidate report failures honestly or cherry-pick a single working demo). The three project templates below — one per role category — are practitioner conventions, not research-backed recipes, but each maps directly to what hiring managers in that vertical recognize on sight.

Project Template 1: Stereo Visual Odometry Pipeline in Simulation (Perception/CV)

• Stack: Python or C++, OpenCV, ROS 2, Gazebo
• What it shows: Camera calibration, feature extraction (ORB or SIFT), feature matching across frames, pose estimation, drift correction
• Time to build: 3–4 weeks of focused weekend work
• Why it works: Mirrors the first six months of work for any AV perception engineer. Hiring managers recognize the architecture immediately and can ask informed follow-up questions — which is what you want.
• Documentation requirement: README with system diagram, recorded video of pipeline running in Gazebo, evaluation plot (estimated trajectory vs. ground truth), explicit "limitations" section listing what fails and why
• Common failure mode that screams beginner: Submitting code without a video demo. If the reviewer can't run it in 60 seconds — or watch it run — they won't.

Project Template 2: 6-DOF Arm Pick-and-Place in MoveIt 2 (Motion Planning/Controls)

• Stack: C++, ROS 2, MoveIt 2, Gazebo or Isaac Sim
• What it shows: Inverse kinematics, motion planning (RRT* or similar sampling-based planner), collision avoidance, gripper control, simple state machine
• Time to build: 4–6 weeks
• Why it works: Surgical and manipulation startups screen on exactly this stack. MoveIt 2 is the industry standard for arm planning, and a working pick-and-place demonstrates you've touched every layer of the stack from URDF to controller.
• Documentation requirement: Architecture diagram, planner comparison (try at least two algorithms and explain the tradeoff), success rate metrics across 50+ trials with statistics
• Common failure mode: Tuning parameters until the demo works once, then not reporting the failure rate. Hiring managers assume you cherry-picked. Report the 73% success rate honestly; it's a stronger signal than a single perfect run.

Project Template 3: Real-Time Sensor Fusion on Microcontroller (Embedded Systems)

• Stack: C/C++, FreeRTOS or Zephyr, an STM32 or similar dev board (~$30), IMU + ultrasonic sensor
• What it shows: RTOS task scheduling, complementary or Kalman filter implementation, deterministic timing, hardware peripheral configuration (I²C, SPI, GPIO interrupts)
• Time to build: 2–3 weeks
• Why it works: Embedded screens are notoriously hard to fake. An actual microcontroller project signals you can read a datasheet, debug with an oscilloscope or logic analyzer, and reason about timing under real hardware constraints.
• Documentation requirement: Wiring diagram, oscilloscope or logic-analyzer trace showing timing, filter convergence plot, code organized with clear separation between HAL and application logic
• Common failure mode: Pure-software emulation when the role is hardware-facing. Spend the roughly $30 on a Nucleo or Blue Pill board. Hiring managers can tell.

How you present these projects matters as much as building them. Pin one repo per project to your GitHub profile — not buried in a sea of forks and abandoned experiments. The README is the resume; invest at least four hours minimum on writing it before you call the project done. Link projects directly from your application cover letter or LinkedIn featured section so reviewers don't have to hunt. A 60-second screen recording embedded in the README dramatically increases the chance a hiring manager engages past the first scroll. The same execution discipline that ships clean robotics code in production ships clean portfolio code on GitHub — reviewers read it as the same signal.

Hiring managers spend less than 90 seconds on a portfolio repo before deciding whether to read further — your README is the resume, not a footnote.

---

Where to Find Robotics Software Engineer Jobs and How to Pass the Technical Screen

Once your skills and portfolio are real, the application game becomes tactical. Most candidates lose months on bad job boards, generic cover letters, and unprepared technical screens. The five items below map the playbook from sourcing through final-round screen.

• Job board triage — where roles are actually posted. Indeed and Glassdoor have the highest volume but heaviest noise. BuiltIn (SF and NYC) is curated and shows salary ranges by default — particularly useful for filtering out reqs from companies that won't disclose pay. Startup Jobs and Wellfound (formerly AngelList) capture early-stage roles invisible elsewhere. Skip generic aggregators that scrape without verification; postings are often stale by the time you apply.
• Sourcing strategy — direct outreach beats applications. For startups, find the engineering lead or hiring manager on LinkedIn and message directly with a portfolio link. Reply rate is meaningfully higher than applying through the careers page. For enterprises (J&J, John Deere, ByteDance), use the formal application — but follow up with a recruiter on LinkedIn the same day with a one-paragraph note pointing at your repos. Cold-emailing CTOs at sub-50-person companies works surprisingly often; at 500+ headcount it doesn't, because the CTO isn't reading inbound.
• Application customization — what hiring teams actually scan for. Cover letters get skimmed in roughly 20 seconds. Lead with the role-specific signal: "I built a stereo VO pipeline in Gazebo and benchmarked it against ORB-SLAM3" beats three paragraphs about passion for robotics. Match resume vocabulary to the job description's exact phrasing — hiring teams use keyword filters before human review, and "ROS 2" parsed differently than "ROS2" can drop you from the queue. Quantify everything that can be quantified: control loop frequency in Hz, perception latency in milliseconds, pick success rate, repo stars, test coverage percentage.
• Technical interview structure by role type. Embedded screens cover bare-metal C, bit manipulation, RTOS scheduling questions, and sometimes a take-home with a microcontroller you flash and return. Perception screens lean on live coding (Python or C++), CV fundamentals (epipolar geometry, calibration math), and often a paper review of a recent CVPR or ICRA paper — they want to see how you reason about new research. Controls screens run pencil-and-paper math (Jacobians, stability proofs), ROS architecture design questions, and occasionally a take-home control problem in MATLAB or Python with a written analysis.
• Red flags in job descriptions that signal a broken team. "Wear many hats" at a Series B+ company means understaffed. JDs that list 15+ required technologies signal the team doesn't actually know what they need. No salary range in states where disclosure is required (CA, CO, WA, NY) signals lazy compliance and often correlates with poor pay. "Looking for a rockstar 10x engineer" usually means the team has retention issues and is looking for someone to absorb three jobs. Walk away — robotics is small enough that one bad two-year stint shows up in your reference calls forever.

---

From Where You Are to Robotics Hire: Timeline and Contingency by Background

Timelines below reflect industry convention reported across hiring manager commentary on LinkedIn, Reddit r/robotics, and university career services anecdote — not rigorous labor research. Treat them as planning anchors, not guarantees. A candidate's actual time-to-offer depends heavily on portfolio quality, market timing, and willingness to relocate. The matrix below pairs three target role categories against three common starting backgrounds.

Background → / Target ↓	General SWE (3+ yrs)	Junior SWE (0–2 yrs)	ML Engineer (Python)
Embedded Systems	4–6 months	8–12 months	9–14 months
Perception / CV	5–7 months	10–14 months	3–5 months
Motion Planning & Controls	8–12 months	12–18 months	8–12 months

General SWEs with systems backgrounds (kernel, distributed systems, performance work) transition fastest into embedded because the mental models overlap — interrupt handlers and scheduler primitives read as familiar territory rather than foreign concepts. ML engineers move fastest into perception because the deep learning stack is already in hand; they're learning ROS and 3D geometry, not Python and PyTorch from scratch. Junior SWEs face the longest timelines across the board because they're closing two gaps simultaneously: general engineering maturity and domain depth, and neither shortcut helps the other.

What "ready" actually means at each timeline mark is worth being explicit about. At month 3, a candidate should have one completed simulation project and ROS 2 fluency at the level of building custom nodes and launch files without reference material. At month 6, two projects with documentation, and the candidate should be able to whiteboard a perception or controls system end-to-end in an interview without freezing. At month 9, they should be interviewing actively and treating rejections as calibration data — every failed screen tells you which skill cluster is still weak.

If the target role doesn't land on schedule, pivot early. A candidate who has spent six months on embedded but isn't getting traction should pivot toward edge AI or platform engineering roles — ByteDance Edge Platform postings on the Indeed new-grad listings use overlapping skills with lower domain barriers and serve as a credible bridge into robotics later. A controls candidate stuck after nine months should consider robotics simulation engineer roles or robotics QA and test automation as adjacent entries that build resume credibility for a future controls move. The pivot is not a defeat; it's how most engineers actually arrive at their target role within the field.

When to call it: if 12+ months of focused study, three or more portfolio projects, and 50+ targeted applications produce zero offers, the bottleneck is rarely raw skill. It's almost always portfolio framing, geographic constraint, or interview performance under pressure. Hire a robotics-specialized career coach (they exist; hourly rates run roughly $150–$300) before assuming the field doesn't want you. A two-hour session focused on mock interviews and resume review often surfaces the gap that 200 self-directed applications won't.

A 12-month timeline with three real projects and 50 targeted applications outperforms a 6-month sprint with two half-built demos and 200 generic submissions, every time.