How do you measure what makes a great leader? How do you evaluate a development program when outcomes take years to materialize and clean experimental conditions are rarely available? How do you take a scientific methodology that a researcher validated carefully in one context and turn it into a system that any HR team across a company of over a million employees can run on their own? These are the kinds of questions the Senior Talent and Transformation Science team works on inside Amazon's People eXperience and Technology organization, and they are questions that matter: the systems this team builds shape how Amazon identifies, develops, and invests in its most senior leaders. As an Applied Scientist on this team you are the person who closes the gap between a validated scientific methodology and a system that runs in production without a scientist standing next to it. The architectural decisions about how scientific methods get encoded into software, the engineering quality bar for the code that implements them, and the reliability of the pipelines that other teams depend on are yours to own. You will work alongside Senior and Principal Research Scientists, an Amazon Scholar, Product Management, and a Senior Applied Scientist who bring deep expertise in behavioral science, psychometrics, and causal inference, and you will be the driving force behind turning that expertise into working, deployable systems for our Amazon executives. The problems you will be building for are genuinely hard and largely unsolved. Scoring a simulation-based leadership assessment with an LLM requires both measurement rigor and a production system that behaves consistently at scale. Estimating the effect of a talent program on leader outcomes requires both a defensible identification strategy and an analytical pipeline someone else can run and trust. Building a self-serve tool that lets a PXT team evaluate a new feature without calling a scientist requires both sound methodology and software that is robust enough to operate without expert supervision. If you want to do work that is technically demanding, scientifically cutting edge, and consequential for real leaders in a large organization, this is that role. Key job responsibilities • Own the production implementation of the team's scientific systems from end to end. When the team validates a new assessment methodology, evaluation framework, or causal identification strategy, you are the scientist who translates it into code that runs reliably, scales, and does not require a scientist standing next to it to operate. • Make the architectural and tooling decisions that determine how scientific methods get encoded into software on this team, choosing abstractions, data structures, and system designs that make the team's scientific components testable, maintainable, and extensible over time. • Define and hold the engineering quality bar for scientific code across the team, establishing and modeling best practices for testing, documentation, reproducibility, and peer review of code in a research team that does not have dedicated software development engineers. • Build the LLM-powered pipelines that operationalize the team's people science, including prompt orchestration, retrieval grounding, automated scoring, and LLM-as-judge evaluation harnesses, writing the implementation yourself and owning the quality and reliability of those systems once deployed. • Extend and adapt scientific techniques at the product level when established approaches fall short. When scoring a simulation-based assessment, estimating a program effect under unusual identification constraints, or evaluating a novel AI feature requires a methodological contribution that does not yet exist, you devise and implement that solution. • Partner with the Research Scientists during methodology design to surface implementation feasibility and trade-offs early, contributing your own scientific judgment on what can be built rigorously within real production constraints before design decisions become expensive to reverse. • Build reusable scientific components, services, and templates that encode methodology once and allow downstream teams to run it without scientist involvement, making the team's research operational infrastructure rather than a bespoke consulting engagement. • Contribute to the design and execution of quasi-experimental evaluations of people programs, owning the analytical implementation and the code pipelines that produce defensible causal evidence from observational and field data. • Mentor scientists on the team on software engineering practices and applied implementation, and participate actively in peer review of experiment designs, analytical approaches, and scientific code written by others. • Communicate implementation trade-offs and system design decisions clearly to product and HR partners in written documents that connect technical choices to business outcomes. A day in the life Your day is anchored in building and testing. You might spend the morning working through a thorny implementation problem, figuring out how to encode a psychometric scoring model into a pipeline that holds up under the messiness of real production data, debugging an LLM evaluation harness that is behaving inconsistently across assessment scenarios, or refactoring a causal estimation component so that another team can run it without calling you first. In the afternoon a Research Scientist might pull you into a methodology design conversation, and your job in that room is not just to follow along but to push back on approaches that would be difficult or brittle to implement, and to propose alternatives that preserve scientific rigor while actually being buildable. You might then shift to reviewing a colleague's code, writing documentation that makes a deployed pipeline understandable to someone who was not in the room when it was designed, or working through a data pipeline problem that is blocking the team's ability to evaluate a new product feature. At the end of most days something that was not working is now working, and the science the team does is a little more durable and a little more independent of any one person than it was in the morning.
