What Does a Flight Software Engineer Do?

There is ordinary software engineering. Then there is software engineering where the software sits inside a spacecraft that may be millions of kilometres away, running on a processor with a fraction of the resources available in a laptop. The second one is flight software, and it changes almost everything about how the work gets done.

A flight software engineer builds the software that allows a spacecraft, instrument, lander, rover or other vehicle to execute its mission. It is software engineering, but with physics, hardware, timing, reliability and mission operations sitting directly in the room with you.

What flight software actually covers

Flight software is the onboard software responsible for operating the vehicle and its payloads. Depending on the mission, it can handle command and telemetry, hardware interfaces, sensor processing, attitude and orbit control, fault detection and recovery, power and thermal management, payload operations, communications, data handling, autonomous decision making and mission sequencing. A CubeSat, a crewed spacecraft and a Mars rover do not share the same architecture, but the central principle holds across all of them: the software has to behave predictably when it matters, with no engineer standing next to it able to intervene.

Why it is a different discipline, not just harder

A consumer application can often be patched. A cloud service can be restarted. A mobile app can crash and relaunch. A spacecraft may have none of those options, which is why flight software places such weight on determinism, verification, fault handling, interfaces, configuration management and operational robustness. The hardware itself adds constraints of its own: processors chosen for radiation tolerance rather than raw performance, limited memory, limited power, scarce communications bandwidth, and real time deadlines that are hard requirements rather than targets. A flight software engineer has to understand both the software and the machine it is controlling.

Living close to the hardware

Flight software sits close to processors, memory, buses, sensors, actuators and electrical interfaces, which is exactly why embedded development experience is so valuable. What happens if a sensor stops responding? If a bus message arrives late? If memory becomes corrupted? If an interrupt lands at exactly the wrong moment, or the processor runs hotter than expected? These are not theoretical questions. They are engineering questions, and sometimes they become mission questions.

Real time systems: right answer, right time

Many flight systems run on real time operating systems or frameworks, and the specific technology matters less than the underlying fluency: scheduling, tasks and threads, interrupts, inter process communication, timing, memory, concurrency, fault handling and resource constraints. An engineer needs to know not just whether the code produces the right answer, but whether it produces that answer at the right moment. A command that arrives fifty milliseconds late can be just as wrong as a command carrying the wrong value.

Designing for things going wrong

FDIR, fault detection, isolation and recovery, is one of the defining characteristics of mission software. Sensors fail. Components reset. Temperatures move outside expected ranges. Communications disappear. Power conditions change. Software encounters states nobody predicted. A good flight software architecture does not assume these things will never happen. It assumes some of them will, and the real design question is how the spacecraft detects the problem, understands it, and responds safely, whether that means resetting a component, switching to a redundant sensor, changing operating mode, reducing power consumption, or entering a predefined safe mode while it waits for instructions from the ground. Flight software is not simply implementing the happy path. It is implementing the unhappy paths too.

Perseverance has to operate with a significant communications delay between Mars and Earth, so during critical phases the spacecraft cannot wait for a human operator to tell it what to do next. Its Terrain Relative Navigation system used onboard imagery to work out where it was relative to hazards and help select a safe landing site, autonomously.

The software was not operating in a clean laboratory environment. It was making decisions in real time, on imperfect sensor information, under severe computational and communications constraints, during one of the least forgiving phases of the mission.

Autonomy is changing the problem

Traditional operations often meant the ground sending a sequence of commands for the spacecraft to execute. Increasingly, spacecraft are expected to interpret sensor information, make decisions and adapt onboard, which changes the engineering problem underneath the software. It needs to be deterministic where determinism is required, but able to handle uncertainty too. It needs to know when it can decide autonomously and when it should defer to the ground. It needs robust state management, and it needs to fail safely. For a flight software engineer, that increasingly means working alongside GNC, systems engineering, autonomy, avionics and mission operations teams, with the boundaries between those disciplines becoming more interesting by the year.

Testing as part of the design, not the end of it

A serious flight software programme draws on unit testing, integration testing, software in the loop, hardware in the loop, processor in the loop testing, fault injection, static analysis, stress testing, end to end testing and operational scenario testing. NASA’s own systems engineering guidance treats verification as a structured activity running through the programme, not a final test phase bolted onto the end. A flight software engineer should be thinking about how the software will be proven correct while they are still designing it, not afterward.

Hardware in the loop testing is one of the most useful environments available. Instead of testing purely against a simulated spacecraft, parts of the actual hardware sit in the loop: the software believes it is operating the spacecraft, and the test environment supplies the simulated physical response. That lets engineers explore sensor failures, actuator failures, timing problems, unexpected states and communication losses safely, and it is often where the elegant whiteboard architecture turns out to need one more iteration.

NASA’s Jet Propulsion Laboratory built F Prime as an open source flight software framework, and it is not simply a demonstration project. NASA’s Mars Helicopter, Ingenuity, used F Prime as part of its flight software architecture and went on to complete 72 flights, far beyond its original technology demonstration goal of five. Ingenuity had to manage its own flight control, navigation and onboard decision making, because real time piloting from Earth was never an option. For a flight software engineer, that is embedded software where debugging the production system means talking to another planet.

Architecture is the job, not a side effect of it

Good flight software is not simply good code. It needs clear interfaces, components with well defined responsibilities, predictable state transitions, sensible separation between mission logic, hardware abstraction and platform services, controlled configuration, telemetry that makes the system observable, and failures that are handled deliberately rather than accidentally. This is why experienced flight software engineers can have such an outsized impact: they are not just writing functions, they are helping define how the spacecraft behaves as a software system.

Reliability comes from evidence, not intention

Reliability in flight software comes from architecture, discipline and proof: clear interfaces, defensive programming, deterministic behaviour where required, automated tests, code review, static analysis where appropriate, requirements traceability, configuration control, fault handling, repeatable builds and strong documentation. The exact assurance process depends on mission criticality and organisational standards, but the underlying question never changes: what does the software do, why does it do it, what happens when something goes wrong, and what is the evidence behind those answers?

There is also the space environment itself to account for. Radiation can cause single event upsets, where a particle interaction changes the state of an electronic device, so flight software often works alongside watchdogs, memory protection, error detection and correction, redundancy and other fault management mechanisms. The software is part of the spacecraft’s resilience strategy, not separate from it.

When the spacecraft is on the ground, almost everything can be fixed. When it is millions of kilometres away, the quality of engineering decisions made years earlier can be the difference between a mission that performs and one that does not.

What we actually screen for

We would be cautious about turning flight software hiring into another shopping list of C++, embedded systems, RTOS concepts, hardware interfaces, protocols, Git, automated testing and fault management, even though a strong candidate will usually touch several of those areas. We would rather find someone who understands why a real time system behaves the way it does, knows how to investigate a difficult failure, and can explain their architectural decisions, than someone who simply has five more technologies listed on a CV.

The single most revealing question we ask is not about programming languages. It is: tell me about something that went wrong. What happened? How did you know? What did you initially think was happening, and what did the evidence actually show? How did you isolate the problem, what did you change, and how did you prove the fix worked? What did you change in your process afterward? Those answers show whether someone can debug, whether they understand systems, whether they stay calm when the answer is not obvious, and whether they learn from failure.

Junior versus senior: different signal, different weight

For junior engineers, we weight fundamentals heavily. Can they write clear C or C++? Do they understand memory? Can they reason about concurrency, explain what an interrupt is, debug systematically, write useful tests, and stay genuinely curious about the hardware their software controls? A particular framework, coding standard or RTOS can be taught. Curiosity and engineering discipline are much harder to teach, which is why we look for them first.

For senior engineers, we look for ownership. What flight software architecture did they influence? What subsystem did they own? What was the hardest integration problem they worked through? Did they support commissioning, investigate an anomaly, or have to trade off elegance, performance, schedule and risk against each other? That is where real experience becomes visible.

What the best ones have in common

The strongest flight software engineers we place do not think of themselves purely as programmers. They think like systems engineers. They understand the processor, the operating system, the hardware interfaces and the mission. They understand what the GNC team is trying to achieve, and what the spacecraft can and cannot physically do. And they understand that their software is ultimately one part of a much larger machine, which is exactly why the quality of their decisions matters so much once the spacecraft leaves the ground.