Amazon LEO is an initiative to increase global broadband access through a constellation of 3,236 satellites in low Earth orbit (LEO). Its mission is to bring fast, affordable broadband to unserved and underserved communities around the world. Amazon Leo will help close the digital divide by delivering fast, affordable broadband to a wide range of customers, including consumers, businesses, government agencies, and other organizations operating in places without reliable connectivity. About this role We're looking for a Data Scientist to turn data from our satellite fleet into engineering decisions. Every satellite in orbit sends back a steady stream of telemetry. Every unit was also tested heavily on the ground before launch, and the ground segment watches the satellite every day while it operates. Your job is to connect these sources. You'll find out which in-orbit behaviors trace back to what we measured in the factory, which events repeat across the fleet, and which patterns point to weaknesses in the hardware design. Your findings will directly shape how we design, build, test, and operate the next generation of satellites. A typical problem starts small: a handful of satellites show a drifting temperature, an occasional link dropout, or a counter that creeps up faster than expected. You'll work out whether it's a real effect or noise, whether it's spreading, and what the affected units have in common. They might share a manufacturing lot, a configuration, an orbital environment, or a signature in their factory test history. From there you'll form a hypothesis about the physical cause and argue it in front of hardware, firmware, and reliability engineers who will push back hard. You'll also have to say plainly when the data rules your own idea out. Telemetry alone rarely settles the question, so your first stop is the ground test data we already have. Every unit in orbit has a detailed record from manufacturing and environmental testing, and the fleet as a whole is backed by an even larger population of units still on the ground. You'll dig through that history for the same behavior: did the affected units show early signs on the ground, did they sit near a test limit, does the effect appear across many units under certain conditions? Often the answer is already in data no one has looked at in this light. When it isn't, you'll design the ground experiments that can provide it. That means deciding which units to test and under what conditions, how many runs you need before the result means anything, and what outcome would confirm or refute the theory. You'll work with the engineers who run those tests, analyze the results, and close the question with a clear answer and a recommended action. Beyond individual investigations, you'll build the fleet-level view: baselines for healthy behavior, early warning indicators that catch emerging issues before they cause outages, and reliability estimates that tell us how the population is aging. You'll decide which recurring analyses should become automated monitoring and work with software engineers to make that happen. You'll be the person the team turns to when someone asks "is this normal?" about the fleet. The ideal candidate is curious about how hardware fails and comfortable with messy data from many sources. They can turn "we're seeing something odd on a few satellites" into a rigorous analysis and a clear recommendation. What you'll bring: - Master's degree or above in a quantitative field such as statistics, mathematics, data science, physics, electrical or aerospace engineering, or computer science, or PhD - 3/5+ years of hands-on experience in an applied or industry setting using Python and SQL to analyze large datasets such as time series, telemetry, sensor, or test data - Experience applying statistical methods (hypothesis testing, regression, time-series analysis, anomaly detection) to noisy, incomplete real-world data - Experience building visualizations and dashboards that communicate findings to engineers and decision makers - Experience framing and solving loosely defined problems, from the first question to a recommendation people act on - Ability to work with hardware and software engineers and turn their questions into analyses you can actually run Nice to have: - Experience analyzing telemetry from satellites, spacecraft, aircraft, vehicles, or other fleets of deployed hardware - Experience with reliability and failure analysis methods such as survival analysis, Weibull modeling, failure-mode analysis, and root-cause investigation - Familiarity with electronics or RF hardware, manufacturing test, environmental stress screening (thermal cycling, burn-in, HASS/HALT), or yield analysis - Experience with pattern-discovery techniques such as clustering, change-point detection, and unsupervised anomaly detection - Experience with large-scale data tools (Spark, Athena/Presto, Redshift) and AWS - Experience with visualization tools such as QuickSight, Tableau, Grafana, or Plotly/Dash - Experience working with software engineers on data pipelines: data requirements, schema design, data quality checks, and automating recurring analyses - Experience using AI-assisted tools to speed up analysis and automate repetitive work - A track record of changing engineering design or test decisions with data Export Control Requirement Due to applicable export control laws and regulations, candidates must be a U.S. citizen or national, U.S. permanent resident (i.e., current Green Card holder), or lawfully admitted into the U.S. as a refugee or granted asylum. Key job responsibilities As a Data Scientist, you will… - Analyze in-orbit telemetry to measure the health and performance of satellite subsystems, and detect anomalies and slow degradation early - Correlate in-orbit behavior with pre-launch data, including manufacturing, production test, and environmental test results, to find which ground measurements predict on-orbit performance. Feed those insights back into test limits and screening strategy - Correlate in-orbit data with what the ground segment sees (gateways, customer terminals) and with failure analysis of lab and returned units - Connect events across the fleet by build lot, component, configuration, firmware version, orbit, and operating conditions, so we can tell systemic issues apart from one-off events - Find patterns that point to hardware design weaknesses, measure their impact on the fleet, and present the evidence to hardware engineering teams with clear recommendations - Build visualizations and dashboards that support decisions in fleet health reviews, anomaly investigations, and design reviews - Work with software engineers to improve the data pipeline: define data requirements, improve data quality, link ground and in-orbit datasets, and automate recurring analyses - Own ambiguous investigations end to end, from forming the hypothesis to reporting the outcome to senior engineering leaders About the team Phased Array Antenna System Validation is the team that decides whether a satellite's phased array antennas (PAAs) are ready to fly. These are the electronically steered transmit and receive panels that form the link between the satellite and the ground. We're part of Amazon Leo, Amazon's low Earth orbit satellite constellation, and we own the test strategy, the automation, and the data pipeline that every PAA goes through on its way to orbit. That path runs from early component-level screening through full-panel functional testing and extended environmental stress testing across temperature, vacuum, and vibration. Our responsibility doesn't end at launch. We also own the analysis of telemetry from PAAs in orbit, and we use what the constellation tells us to improve how we test on the ground. We are a hardware-facing software and test team, and we sit where several disciplines meet. Our test automation directs firmware provisioning, self-tests, and environmental profiles on test stations at manufacturing sites. Over a single run it exercises thousands of measurement points: high-speed serial links, clocking, digital beamformer firmware, RF chains, power, and thermal behavior. Every result is tied to a specific serial-numbered part. That builds a detailed, part-level history of how each panel and component behaved under stress, from the factory floor to launch. A large part of our work is investigation. When something fails, we work out whether the cause is the hardware, the firmware, the test equipment, or our own automation, and we decide what should happen next. Over time we have built a growing catalog of failure signatures and their root causes, internal tools for analyzing long-duration tests, and AI-assisted agents that help turn raw logs into conclusions. We care about evidence over assumption. A label on a result isn't the result itself, and a search that finds nothing doesn't prove the problem has no history. Theories get tested against the data before they're accepted. We support multiple hardware generations at once, so the architecture, the questions, and the tooling keep changing. You'll work closely with antenna hardware, firmware, manufacturing, and reliability engineers who are glad to dig into a hard problem with you. Because we own both ends, from the first ground test to behavior in orbit, the loop is closed within the team. What we learn from the constellation goes straight back into our screens, thresholds, and test sequences, so that the next panel we validate is more likely to keep working in orbit.