Flight Software Engineer Skills: What Makes an Engineer Mission-Ready

There is ordinary software engineering, and then there is software engineering where the code sits inside a spacecraft that may be hundreds of millions of kilometres away, running on hardware chosen as much for radiation tolerance and reliability as for raw processing power. The second one is flight software, and it asks something different of the people who write it.

A flight software engineer builds the software that lets a spacecraft, satellite, instrument, lander or rover carry out its mission. It is still software engineering, but with physics, hardware, timing, reliability, safety and mission operations sitting directly in the room. That changes the skill set we look for, and it is worth being precise about how.

What the job actually covers

Flight software is the onboard software responsible for operating a vehicle and its payload: command and telemetry, hardware interfaces, sensor processing, attitude and orbit control interfaces, fault detection and recovery, power and thermal management, payload operations, communications, data handling, mission sequencing and, increasingly, autonomous decision making. A CubeSat is not a crewed spacecraft, and a telecommunications satellite is not a Mars rover, but the underlying principle holds across all of them: the software has to behave predictably when it matters, on a vehicle that cannot be unplugged and debugged by an engineer standing next to it.

C and C++, but not just C and C++

When we are assessing someone for flight software, we want to know whether their understanding of software goes deeper than syntax. C and C++ remain central to many flight environments because they give engineers the control and predictability needed close to the hardware, but knowing C++ is not the same as understanding embedded C++. A mission ready engineer needs to be comfortable with memory, pointers and references, allocation, stack and heap behaviour, concurrency, interrupts, timing, hardware registers, serialisation and resource constraints. The question is rarely whether someone can write a class. It is whether they understand what that class does to the machine underneath it.

NASA’s F Prime is a useful reference point here. It is a component based flight software framework, built at the Jet Propulsion Laboratory, combining C++ infrastructure with message queues, threading, operating system abstraction and structured testing tools, and it has been deployed on several flight projects, including the Ingenuity Mars Helicopter.¹ That is a genuinely different environment from writing a web service, and candidates who have spent time in a framework like it tend to reason about software very differently.

Real time systems: right answer, right time

A flight computer rarely just needs the correct answer. It often needs the correct answer at the correct time, which is the heart of real time engineering: scheduling, task priorities, threads, interrupts, inter process communication, timing constraints, synchronisation, race conditions, watchdogs and deterministic behaviour. A command that produces the right output 500 milliseconds too late can be just as much a system failure as a command carrying the wrong value. Experience with a specific RTOS can help, but what we are really listening for is whether someone understands the underlying problem of scheduling, timing and concurrency well enough to move between environments, rather than having simply memorised one API.

Living at the hardware boundary

Flight software lives close to hardware: processors, memory, buses, sensors, actuators, power systems and electrical interfaces. The strongest engineers we place have some real appreciation for the physical system their code is controlling, and a healthy instinct for what happens when the two disagree. What happens if a sensor stops responding, a bus message arrives late, a watchdog fires, or the processor receives corrupted data? These are not unusual edge cases in this discipline. They are the job.

That boundary shows up concretely in the interfaces engineers work with, which can include UART, SPI, I2C, CAN, Ethernet, SpaceWire, MIL-STD-1553 or custom spacecraft buses. Nobody needs to be an electronics engineer, but they do need to understand enough of the hardware to know exactly what their software is asking the machine to do, because software that looks perfectly sensible on a development machine can behave very differently once it meets real flight hardware.

FDIR: designing for things going wrong

Fault Detection, Isolation and Recovery, FDIR, is one of the defining concepts in spacecraft engineering. Sensors fail. Components reset. Temperatures drift outside expected ranges. Power conditions change. Communications disappear. Software finds itself in a state nobody anticipated. A serious architecture does not assume this will never happen. It asks the more useful question: what happens when it does, and the answer is usually designed in advance, whether that means resetting a component, switching to a redundant sensor, disabling a payload, reducing power, entering a safe attitude or waiting for ground intervention. The important part is that the response is designed, not improvised. This is where flight software becomes deeply tied to systems engineering, implementing part of the spacecraft’s fault management strategy rather than sitting apart from it.

Testing starts with the architecture, not after it

One of the more common mistakes we see is treating testing as something bolted on at the end. In flight software, testing starts when the architecture starts. A serious programme can involve unit testing, integration testing, software in the loop, processor in the loop, hardware in the loop, fault injection, static analysis, stress testing, boundary condition testing and full operational scenario testing. NASA’s own systems engineering guidance treats verification as a structured activity threaded through the programme, with requirements verified through analysis, inspection, demonstration or test, the method chosen deliberately as part of the process.² Good engineers are not only asking how to implement something. They are asking how they are going to prove it works, from the outset.

Hardware in the loop testing is where this becomes particularly interesting, bringing real software and real hardware into an environment where the rest of the spacecraft can be simulated, so engineers can explore sensor failures, timing problems, lost communications, bad inputs and fault recovery safely. Occasionally the physical world wins an argument the whiteboard architecture thought it had settled. That is not a failure. Finding the problem on the ground is exactly what verification exists to do.

Perseverance’s Terrain Relative Navigation system used onboard imagery and a stored map of the Martian surface to identify safer landing locations, operating entirely autonomously because there was no possibility of an engineer on Earth manually steering the spacecraft away from a hazard in real time. NASA’s technical documentation reports an actual touchdown error of approximately 5 metres against a 60 metre requirement.³

That is not really a story about one clever algorithm. It is a story about an integrated system: cameras, computing, navigation, software, control, maps, requirements, verification and hardware, all meeting the physical environment at once. The software engineer is one part of that chain, but a critical one.

Ingenuity was designed as a technology demonstration for up to five flights over 30 days. It went on to complete 72 flights over almost three years, using F Prime as part of its flight software architecture and managing 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 a very different definition of embedded software: debugging the production system means talking to another planet.

The best flight software engineers we know do not think of themselves as programmers. They think of themselves as people helping operate a machine, one with hardware, physics, constraints and failure modes of its own.

Safety critical development, scaled to the mission

Not every spacecraft carries the same assurance requirements. A small technology demonstrator and a human rated spacecraft do not share a risk profile. But the closer software gets to mission critical or safety critical functions, the more weight disciplined engineering carries: requirements traceability, configuration management, coding standards, reviews, static analysis, independent verification, change control, reproducible builds and documented evidence. None of that is bureaucracy for its own sake. It exists so that someone can say, with evidence, what the software does, why it does it, and what happens when something goes wrong.

What we actually ask candidates

We are less interested in how many technologies someone can list than in whether they understand why those technologies matter in this environment.

Those answers reveal engineering maturity in a way a technology list never does. They tell us whether someone debugs systematically, or simply works from a ticket until the symptom disappears.

Junior versus senior, weighted differently

For a junior engineer, fundamentals matter enormously: can they write clear C or C++, do they understand memory, can they reason about concurrency and interrupts, can they debug and write meaningful tests, and are they genuinely curious about the hardware their software controls? Those fundamentals outlast any particular flight framework, which can always be taught. For a senior engineer, we look for ownership: what did they architect, what subsystem did they own, what was the hardest integration problem they carried, did they support commissioning or investigate an anomaly, and did they ever have to trade performance against reliability, schedule or complexity? That is where mission experience becomes visible rather than claimed.

What separates a mission ready engineer

In the end it comes down to mindset. A mission ready flight software engineer does not think “I write software.” They think “I am helping operate a machine,” one with hardware, physics, constraints, failure modes and operators, that eventually has to work when nobody can reach out and repair it. That is why the strongest flight software engineers we place are part programmer, part embedded engineer and part systems thinker. They understand the code, but they also understand the machine, and they understand the mission it serves.