GNC Engineer Skills: What Employers Should Look For

There is a temptation, when hiring GNC engineers, to turn the job description into a shopping list. MATLAB. Simulink. C++. Kalman filters. Orbital mechanics. Six years’ experience. It looks reassuring. It is not especially useful.

The hard part of hiring for this discipline is telling the difference between someone who has encountered the terminology and someone who can actually reason through a flight problem. From where we sit, working GNC searches every week, that distinction matters more than almost anything else on the CV.

A strong GNC engineer sits at the intersection of mathematics, physics, software and hardware. They understand the theory, but they also understand what happens when that theory meets a real sensor, a real processor, a real actuator, and a spacecraft that is already in orbit. That intersection is what we screen for.

Mathematical foundations, tested by conversation not recall

Good GNC work starts with fluency in linear algebra, differential equations, probability, statistics, numerical methods, coordinate transformations and dynamical systems. An engineer does not need to be an applied mathematician, but they should move comfortably between a physical problem, a mathematical model, and an implementation.

The answers tell you far more than whether someone remembers the exact form of a particular equation.

Control systems: the reasoning matters more than the technique

Depending on the role, this could mean PID control, state space methods, LQR, nonlinear control, gain scheduling, robust control or optimisation based approaches. The specific technology matters less than whether the candidate can explain why they chose it, identify its limits, and reason clearly about saturation, delay, noise and uncertainty. Can they explain what happens when the actuator they designed around cannot deliver the command they expected? That is much harder to fake than a familiar acronym.

ESA describes GNC as a mission critical function spanning spacecraft pointing and position control through to rendezvous, formation flying and autonomous planetary landing, with required performance ranging from around 0.1 degrees for some communications spacecraft to levels thousands of times tighter for space telescopes. There is no single definition of a good controller. It has to be good for the mission in front of it.

State estimation and Kalman filtering

A spacecraft rarely knows its own state exactly, which makes estimation fundamental: process and measurement noise, covariance, observability, sensor bias, sensor fusion, extended and unscented Kalman filters, timing and synchronisation. Again, the value is not in reciting the equations. Ask what happens when the covariance is wrong. Ask what happens when a sensor drops out. Ask how they would diagnose an estimator that looks excellent in simulation and behaves badly on hardware, and what they would look at first.

Spacecraft estimation is increasingly a sensor fusion problem. ESA’s own GNC work draws on star trackers, gyroscopes, accelerometers, magnetometers, sun sensors and other specialist sensors, and its test facilities exist specifically to characterise those sensors and investigate anomalies before and after flight. The engineer needs to understand not just estimation theory, but the real behaviour of the sensors feeding it.

Flight dynamics, and reasoning through a scenario

The engineer needs a physical understanding of the system, whether that is orbital mechanics and attitude dynamics for spacecraft, or six degree of freedom flight dynamics, aerodynamics and propulsion interactions for launch and atmospheric vehicles. A useful scenario to give a candidate: the vehicle is oscillating, the controller is becoming more aggressive, the actuator is approaching saturation, the sensor has a delay. What happens next? You want someone who reasons through the chain of events, not someone who reaches straight for a familiar algorithm.

Simulation that tells you something useful

A serious GNC team runs simulations long before flight hardware exists: MATLAB and Simulink, Python, C and C++, Monte Carlo analysis, high fidelity dynamics, hardware and software in the loop, fault injection, sensitivity analysis. Almost everyone has built a simulation. The more useful question is whether they know how to build one that actually tells you something. What happens when the sensor bias is three times larger than expected? When measurements arrive late? When the actuator saturates, or the initial conditions are wrong, or two supposedly independent errors turn out to be correlated?

The team did not run the algorithm once on a laptop and call it done. They flew a helicopter campaign over Mars-like terrain, tested flight hardware, and ran high fidelity Monte Carlo simulations across thousands of possible landing conditions.

The mindset we look for is not “does it work.” It is “under what conditions does it stop working, and how do we know.”

Software skills, and the difference between correct and flight ready

Modern GNC is inseparable from software, even for engineers working primarily on algorithms: Python for analysis, MATLAB or Simulink for modelling, C or C++ for embedded implementation, Git, automated testing, numerical libraries, real time constraints, debugging and profiling. Writing code that produces the right answer is one thing. Writing flight software that behaves predictably under abnormal conditions, can be tested properly, and can be maintained by another engineer is another. It is the second one we look for.

Hardware matters too

One mistake in GNC hiring is treating the discipline as purely mathematical or software based. It is not. Sensors have noise and latency. Reaction wheels have torque and momentum limits. Thrusters have a minimum impulse bit. Computers have finite processing capacity. Interfaces carry timing constraints, and thermal and power limits shape what the system can actually do. ESA’s own GNC and AOCS laboratories exist to test sensors and actuators, investigate anomalies, and run spacecraft AOCS hardware in closed loop environments that reproduce aspects of on orbit behaviour. Candidates who have spent real time close to hardware tend to develop a healthy respect for the gap between a model and a machine.

Flight heritage, and what it actually teaches

There is a difference between having worked on a spacecraft and having been responsible for something that flew. Flight heritage teaches interfaces, configuration control, late changes, test campaigns, integration problems, commissioning, operations, anomaly investigation and the real consequences of small assumptions. Above all it teaches humility. The spacecraft does not care how elegant your design looked in the review. This is not a prerequisite for junior engineers, but for a senior hire we want to understand exactly what someone has owned, and what happened when their work met the real system.

The spacecraft does not care whether your design looked elegant in the review. A good GNC engineer learns to respect that.

Junior versus senior: what we weight differently

For junior engineers, we weight fundamentals and learning velocity far more heavily than toolchain familiarity. A graduate who understands dynamics, writes clean Python, can explain a control loop and shows genuine curiosity is often a better long term hire than someone who has memorised a particular framework. We also look at how they approach problems they do not know how to solve: do they make sensible assumptions, ask good questions, break a complicated problem into smaller pieces, test their own thinking?

For senior engineers, the emphasis shifts to ownership. What subsystem did they own? What decision did they make, and what failed? What did they change, and how did they verify it? What happened during commissioning? Did they ever disagree with the initial architecture, and what happened when the real system behaved differently from the model?

The people who cross boundaries

The strongest GNC engineers we have placed move comfortably between disciplines. They can sit with a controls engineer and discuss stability, with a software engineer and discuss implementation, with a systems engineer and discuss requirements, with a hardware engineer and discuss sensor behaviour, and then go back to their own simulation and know what needs to change. Spacecraft are systems, and the best GNC engineers understand that in practice, not just as a phrase.

The one question worth building a whole interview around

When we assess a senior technical candidate, one question tends to reveal more than any other: tell me about the hardest GNC problem you personally owned. Then keep asking. What did you initially believe? What turned out to be wrong? What data changed your mind? What did you implement, and how did you test it? What happened on hardware? What would you do differently today?

Hiring GNC engineers was never about finding someone who has seen every acronym. It is about finding someone who can take responsibility for a complex physical system, and keep asking the right questions until they understand how it will actually behave in the real world.