About the role
Software Engineer, Engine Telemetry & Observability Software Engineer, Engine Telemetry & Observability A jet engine on a test stand throws off data the way it throws off heat. Thousands of channels, tens of thousands of samples per second, every one of them telling you something about whether the engine is about to do what it's supposed to do or something a lot more interesting. The test team has to make decisions in real time, with that data on a screen in front of them, while the engine is running. The software that puts it there is not a dashboard. It is part of the test. At Boom we are building Symphony — the engine that will power our aircraft and gas turbines — in Denver, at a pace and cost point the industry says is impossible. We are building our telemetry and observability stack ourselves because the off-the-shelf aerospace test tools are slow-moving, expensive, hard to customize, and built for an era before AI was part of the stack. We need a platform that evolves at the speed our test cadence demands. We are hiring Software Engineers to own the tools the test team lives in. Telviz, our real-time visualization platform. Boombox, our post-event analysis suite. The ingest pipelines that move 200 kHz streams off the stand without dropping samples or losing time correlation. You will not ship UI over the wall. You will be on console during tests, watching engineers use what you built, fixing it between runs, and learning enough about the physics to know when a signal is lying.
What you'll do Own pieces of Telviz and Boombox end-to-end, from raw ingest through the visualization an engineer is staring at while the engine spins, with you on console during the test Ship real code in your first week. Ship a visualization or pipeline improvement the test team uses by the end of your first month. Reason about throughput, fidelity, and time correlation as first-class concerns. Work with high-density storage formats (Parquet, Avro, HDF5, netCDF) and in-transit formats (Arrow, Protobuf, Ethernet-based protocols). A dropped sample is not a UI bug. Help scale the platform from internal test infrastructure into the data backbone of a deployed product, as Superpower units ship to customers Write the boring observability, replay tooling, and runbooks that make the next test smoother You probably have Real software engineering experience in at least one of Go, Rust, C++, or production Python, with range across the stack Scar tissue from working with high-volume, real-time, or time-correlated data. Observability platforms, trading systems, motorsport telemetry, robotics, AV, hyperscale infrastructure — domain matters less than the instincts. Familiarity with the numerical computing toolchain engineers actually use (NumPy, SciPy, pandas) and an understanding of why time series databases exist Genuine curiosity about the physical systems behind the data, and comfort embedding with the engineers who run them You will thrive here if You believe the test stand is the most interesting room in the building You have strong opinions, held loosely, and you'd rather be proven wrong today than right in six months We are not the right place for engineers who want to wire up a charting library, get the ticket marked done, and let someone else worry about whether the chart is hiding something. We are exactly the right place for engineers who want to be on the headset when the engine lights, and who want to go home at night knowing the test ran because the tools held up.
