What Makes a Flight-Software Engineer Mission-Ready
The competencies that separate strong software engineers from flight-critical ones
When software stops being just software
A software engineer can write a system that passes its tests. A flight-software engineer has to ask what happens when the sensor lies, the processor resets, the timing slips, the actuator doesn’t respond, or the system encounters something nobody put in the test plan.
The moment software controls a vehicle, software quality becomes a systems question. This picks up directly from the last mile: the journey from a technically sound idea to something that can be trusted on a mission. Flight software sits right in the middle of that journey. It translates algorithms and system requirements into behaviour on real hardware, and real hardware does not always behave the way the specification assumed it would.
On 4 June 1996, Ariane 5’s maiden flight was destroyed 37 seconds after launch. The root cause was a software module reused from Ariane 4, where a 64-bit velocity value overflowed a 16-bit integer field. The code itself was not “wrong”: it had flown successfully for years on a rocket with a slower ascent profile. It failed because nobody re-verified an inherited assumption against a new vehicle’s flight envelope.1
Flight software is not simply software developed in a different industry. The engineering constraints change the nature of the job.
The misleading way companies define the role
The typical job specification reads like a keyword checklist: C or C++, Python, RTOS, embedded systems, Linux, Git, testing, DO-178C, spacecraft experience, a set number of years.2
These are proxies for capability, not capability itself. Someone can have every keyword on the CV and still struggle with flight-critical engineering. Conversely, someone from robotics, automotive, defence, medical devices or another high-consequence embedded environment may already possess much of the underlying capability without ever having worked on a spacecraft. This is the same argument the first article made about recognising transferable depth rather than simply extending job descriptions.
The six competencies that actually matter
Rather than a long skills taxonomy, six dimensions capture most of what separates a strong software engineer from a mission-ready one.
Can they reason about software in relation to the processor and hardware it runs on? Look for real experience with memory and CPU constraints, timing, concurrency, interrupts, interfaces, buses, hardware dependencies and deterministic behaviour.
A conventional software engineer may ask: does the code produce the right output? A flight-software engineer also asks: when does it produce it, on what hardware, under what conditions, and what happens if the hardware doesn’t behave as expected?
Mission systems care about when something happens, not simply whether it happens. This covers scheduling, latency, jitter, task priorities, timing budgets, race conditions, watchdogs and fault recovery. The important distinction is between functional correctness and temporal correctness: a system can produce the right answer and still fail because it produced it too late.
A mission-ready flight-software engineer understands where their software sits in the larger vehicle, and can talk to GNC, avionics, systems engineering, electrical engineering, payload teams, test and verification, and mission operations, understanding why those interfaces matter. The best flight-software engineers aren’t necessarily generalists. They’re specialists with enough systems fluency to understand the consequences of their decisions.
This is where you distinguish someone who has built software from someone who has built mission software. The question is how the engineer convinces themselves, and everyone else, that this software will behave correctly, across the progression from unit test to integration test to simulation to hardware-in-the-loop to hardware testing to system verification to operational validation. Mission-ready engineers think about verification while designing the software, not as something that happens afterwards.
A mission-ready engineer doesn’t only design for the nominal case. What if the sensor data is wrong? What if a component stops responding? What if communications disappear? What if the software restarts mid-operation? What if two things happen simultaneously? What if an assumption made upstream turns out not to be true? This is engineering for the conditions that weren’t in the happy-path demo, and it is exactly what an autonomous vehicle has to do when it makes decisions with imperfect information and no operator standing by.
The engineer understands that their work doesn’t finish when the code is merged. This covers deployment, configuration, telemetry, commanding, logging, troubleshooting, anomaly response, software updates and mission operations. Someone who has sat in a room during a hardware test, or supported an anomaly in real time, develops a kind of judgement that is difficult to acquire from development work alone.
NASA’s Ingenuity helicopter made the first powered, controlled flight on another planet in April 2021, and went on to fly more than 70 times, all of it autonomous. Radio signals take up to 20 minutes to cross the distance between Earth and Mars, so real-time control was never an option: JPL’s team could only send a flight plan in advance and wait.3 The onboard software had to fuse a navigation camera, a laser altimeter and an inertial system to hold position over unfamiliar terrain, detect its own anomalies mid-flight, and land itself, with nobody able to intervene if something went wrong. It’s the positive mirror image of Ariane 5 and Mars Climate Orbiter below: the same failure thinking and verification discipline, applied successfully under conditions at least as unforgiving.
In September 1999, NASA’s Mars Climate Orbiter was lost during orbit insertion. The proximate cause was a units mismatch: one team’s software produced thruster impulse data in pound-force seconds, another team’s navigation software expected newton-seconds. The mishap board’s finding was broader than a single conversion error. It pointed to a lack of complete end-to-end verification of the navigation software as a system, and inconsistent communication between the teams either side of that interface.4
Both failures share a pattern. The code did roughly what its authors intended. What was missing was someone with enough systems awareness and verification discipline to check the assumption at the boundary between two pieces of trusted software.
An experience ladder, not a seniority ladder
Rather than junior, mid and senior, it’s more useful to frame progression around proximity to the mission. Years of experience don’t automatically equal mission readiness. Someone can spend ten years writing software without much exposure to the later stages below. Someone else can acquire unusually valuable systems experience much earlier.
| Stage | Typical experience | What they’re learning |
|---|---|---|
| Software development | Algorithms, architecture, implementation | How to build software |
| Embedded development | Hardware and software interaction | How software behaves on a device |
| Integrated systems | Interfaces, timing, verification | How components behave together |
| Hardware testing | Real-world failures and constraints | How assumptions survive contact with hardware |
| Flight and operations | Anomalies, commanding, mission constraints | How software behaves when it matters |
What hiring managers should actually ask
Instead of asking whether someone has worked on spacecraft before, better questions reveal considerably more about how someone actually thinks:
Tell me about a time software behaved differently once it met real hardware.
Tell me about a failure mode you didn’t anticipate initially. What changed?
How did you convince yourself that the system was safe or reliable enough to release?
Tell me about a software decision that had consequences outside the software team.
Have you ever had to diagnose or support something you had built while it was running?
Tell me about a technical assumption you changed your mind about.
The transferable-talent argument
Strong candidates increasingly come from outside traditional aerospace: robotics, autonomous vehicles, defence, avionics, automotive, medical devices and other safety or high-consequence embedded environments. The question isn’t whether they’ve worked in space. It’s whether they’ve already learned the engineering behaviours that space demands.
That comes with a qualification. Domain knowledge still matters, particularly around spacecraft architectures, mission operations and applicable standards such as DO-178C for airborne systems software.2 But the underlying engineering judgement, embedded thinking, verification discipline and failure thinking, is transferable. Public postings for embedded and flight-software roles in the US space sector currently span roughly $95,000 for early-career positions up to $250,000 or more for senior and staff engineers at leading manufacturers, reflecting how differently the market prices someone who has already built that judgement versus someone still acquiring it.5 Rocberg’s ongoing compensation coverage is tracking how that premium moves across regions and disciplines as demand for mission-ready engineers grows.6
The things that can’t easily be taught
Some technical skills can be acquired relatively quickly. Harder to manufacture are judgement, ownership, curiosity about failure, respect for interfaces, disciplined verification, comfort working across disciplines, the ability to stay calm when a system behaves unexpectedly, and the willingness to challenge an assumption.
This is the human version of mission readiness, and it connects back to the first article’s point that the industry needs to build pathways for engineers to acquire this experience, rather than simply demanding that it already exists on a CV.
Mission-ready isn’t a job title
The industry doesn’t have a shortage of software engineers. It has a shortage of engineers who have had enough exposure to hardware, systems, verification, failure and operations to make good decisions when those things collide. That experience is what turns software engineering into flight-software engineering, and it is why mission-ready is better understood as a set of competencies than a line on a CV.
If the first article asked where the talent gap really sits, this one asks what capability actually looks like underneath the title. The next piece in this series turns to what the market is currently willing to pay for it.
Space Systems Talent: specialist recruitment for GNC, autonomy and mission-critical engineering. Visit spacesystemstalent.com
1. NASA Safety and Mission Assurance, Ariane 5 Flight 501 launch vehicle history
2. RTCA, DO-178C, Software Considerations in Airborne Systems and Equipment Certification
3. NASA Jet Propulsion Laboratory, reporting on Ingenuity’s autonomous navigation and flight record, 2021 to 2024
4. NASA Safety and Mission Assurance, The Mars Climate Orbiter Mishap, safety message
5. Range compiled from publicly posted US flight-software and embedded-engineering roles at aerospace and space-systems companies, 2026
6. Rocberg, independent compensation and market intelligence coverage