NWEA® is a division of HMH that supports students and educators through research, assessment solutions, policy and advocacy services, professional learning and school improvement services that fight for equity, drive classroom impact and push for systemic change in our educational communities. For nearly 50 years, NWEA has developed innovative pre-K–12 assessments, including their flagship interim assessment, MAP® Growth™ and their reading fluency and comprehension assessment, MAP® Reading Fluency™. For more information, visit NWEA.org to learn more.
HMH is a learning technology company committed to delivering connected solutions that engage learners, empower educators and improve student outcomes. As a leading provider of K–12 core curriculum, supplemental and intervention solutions, and professional learning services, HMH partners with educators and school districts to uncover solutions that unlock students’ potential and extend teachers’ capabilities. HMH serves more than 50 million students and 4 million educators in 150 countries. For more information, visit www.hmhco.com
We build the models inside HMH Pulse. They take assessment results as their input and turn them into what a teacher can act on: where a student stands against what they are expected to learn, what they are ready for next, and how much growth to expect. Every model is white-box: you can read every number it produces and explain it to the person it affects. The data covers millions of students, and the output lands in classrooms.
You would work across the full model lifecycle on AWS SageMaker, in Python: data, training, validation, release, serving, monitoring, and the next version. Engineering quality is the floor, whichever side you come from. We are hiring either a strong modeller who wants to run their models in production, or a strong ML engineer who wants to work on hard inference problems.
What you will do
An ML engineer here works a model through its whole life, not one slice of a pipeline. You will sit on a stream-aligned team, working with a senior or staff engineer, and you will be the person who knows your models best.
• Explore and check. Look hard at the data before you fit anything, and again after. A model earns its keep by surviving data it has not seen and by what it teaches you. You will write that up for people who will challenge it.
• Train and validate. SageMaker training jobs and pipelines in Python, experiments tracked in MLflow, validation against held-out cohorts before anything is promoted. You should be able to defend every parameter.
• Release. Register, promote and deploy model versions with a lineage you can defend: which data, which code, which weights, served where. Releases go through code review and CI like any other change.
• Serve. Real-time endpoints and batch scoring, fed from a feature store and backed by Snowflake. Latency, cost and capacity are yours to understand and tune.
• Watch. Dashboards and alerts on prediction quality, failure rates and drift. A monthly production-health review. A blameless postmortem when something breaks, and the fix that follows.
• Improve. Use what production tells you to propose the next version, and bring the analysis and evidence that shape the team's design docs (RFCs).
• Support. Help analysts, product and data teams understand what the models say and how to use them well.
The kind of problems you will work on
These are the shapes of work on the team today, so you can judge whether the job is what you want.
• Take a model that works for one subject or one curriculum and make it work for several, without forking the code.
• Re-score a very large student population against a new model version while the live service keeps serving.
• Run several model versions side by side and retire one without anyone noticing.
• Catch data and model drift before a user does.
• Make training and serving more efficient without changing what a model says.
Who we are looking for
You are strong on one of these two sides and curious about the other. Both write code that passes review on its merits.
• The modeller. At home with ML and statistical models that can be explained: Bayesian and hierarchical models, growth modelling, or measurement models from psychometrics. Writes clean, typed, tested Python and is comfortable with CI/CD and infrastructure as code. Has fitted models that other people relied on and wants to see them running in production. We will teach SageMaker and our platform.
• The engineer. Builds ML systems that are fast and resilient. Fluent in production Python, testing, packaging, GitHub Actions and Terraform. Has run SageMaker or an equivalent in anger. Wants to work close to the statistics and will learn the modelling.
Psychometricians: if you have built or evaluated measurement models, write good code already, and want to move into engineering, this role is a deliberate path. Bring the modelling and the habit of explaining it; we will grow the production craft with you, deliberately and with review.
What you will need
• A track record of shipping models or ML systems that others depended on. For IC4. that typically means three or more years of hands-on work, or a doctorate combined with relevant practical experience. A Masters or PhD in a quantitative field, psychometrics included, is expected.
• Engineering excellence as the floor, not a bonus: idiomatic, typed, tested Python that passes review the first time; comfort with CI/CD (we use GitHub Actions) and Terraform-managed infrastructure; solid SQL. Python is our language.
• A statistics foundation you can use, not just cite: you can explain a posterior, a likelihood and a calibration plot to a colleague without notes.
• Exploratory data analysis as a discipline, not a warm-up. You look at the data before you model it, you notice what is odd, and you can show why it matters.
• Excellent writing. A model is only worth building if its reasoning can be read. You can state an analysis, a design, a result or an incident in a page that someone else can act on, and you do it as a matter of course.
• Working knowledge of AWS, ideally SageMaker, and of an experiment tracker such as MLflow.
• The confidence to say "this is not good enough to ship" and the evidence to back it up.
It helps if you have: psychometrics or education measurement; cognitive diagnostic models or Bayesian networks; probabilistic programming (Stan, PyMC and friends); R; Snowflake and dbt; Terraform; GitHub Actions; knowledge graphs or ontologies; experience with K-12 assessment data.
How we work
• Evidence first. State the hypothesis, run the cheapest test that could prove it wrong, then decide. Nobody ships on a hunch, and nobody is blamed for a hunch that failed its test.
• We write things down, and write well. Analysis write-ups for every model, RFCs for design decisions, runbooks for operations, postmortems for incidents, data contracts between producers and consumers.
• Model code is production code. Typed Python, tests, review and CI on every change, for training pipelines as much as for endpoints. Infrastructure is code too, and you read and change it.
• Every model has one accountable owner. A named senior engineer is directly responsible for each model. You work with them, and you are expected to know the model's behaviour in production better than anyone.
• Agent-assisted engineering is how we work. Coding agents sit in every workflow. We write the playbooks they follow, point them at our runbooks, and review their output as hard as a colleague's.
• A growing team. We are adding people and models, and our practice is evolving with them.
What we use: AWS SageMaker (training jobs, pipelines, real-time endpoints, Model Registry, Feature Store), MLflow, Snowflake and dbt, Python, GitHub Actions, Terraform, Datadog, and knowledge graphs.
Practicals
• Level: IC4, an experienced individual contributor on a stream-aligned team, working alongside a senior or staff engineer.
• Location: remote (may be performed from any state in the US)
• How to apply: if you include a cover note, tell us about one thing you built and ran, what went wrong, and what you did about it. We will ask about it anyway.
Benefits and Salary Range
Salary Range – $110,000 to $115,000. Our salary ranges are based on national averages. We have wide ranges so we can be flexible and determine compensation based on a number of factors including the candidate’s skills, experience, education, and location.
Our Culture and Benefits - careers.hmhco.com
Application Deadline
The application window for this position is anticipated to close on October 23, 2026. We encourage you to apply as soon as possible. The posting may be available past this date but is not guaranteed.
#LI-DNI
HMH is fully committed to Equal Employment Opportunity and to attracting, retaining, developing and promoting the most qualified employees without regard to race, gender, color, religion, sexual orientation, family status, marital status, pregnancy, gender identity, ethnic/national origin, ancestry, age, disability, military status, genetic predisposition, citizenship status, status as a disabled veteran, recently separated veteran, Armed Forces service medal veteran, other covered veteran, or any other characteristic protected by federal, state or local law. We are dedicated to providing a work environment free from discrimination and harassment, and where employees are treated with respect and dignity. We actively participate in E-Verify.
Requirements
Must-haves
Train and validate. SageMaker training jobs and pipelines in Python, experiments tracked in MLflow, validation against held-out cohorts before anything is promoted. You should be able to defend every parameter.
Release. Register, promote and deploy model versions with a lineage you can defend: which data, which code, which weights, served where. Releases go through code review and CI like any other change.
Serve. Real-time endpoints and batch scoring, fed from a feature store and backed by Snowflake. Latency, cost and capacity are yours to understand and tune.
Watch. Dashboards and alerts on prediction quality, failure rates and drift. A monthly production-health review. A blameless postmortem when something breaks, and the fix that follows.
Improve. Use what production tells you to propose the next version, and bring the analysis and evidence that shape the team's design docs (RFCs).
Support. Help analysts, product and data teams understand what the models say and how to use them well.
The kind of problems you will work on
These are the shapes of work on the team today, so you can judge whether the job is what you want.
Take a model that works for one subject or one curriculum and make it work for several, without forking the code.
Re-score a very large student population against a new model version while the live service keeps serving.
Run several model versions side by side and retire one without anyone noticing.
Catch data and model drift before a user does.
Make training and serving more efficient without changing what a model says.
Who we are looking for
You are strong on one of these two sides and curious about the other. Both write code that passes review on its merits.
What you will need
A statistics foundation you can use, not just cite: you can explain a posterior, a likelihood and a calibration plot to a colleague without notes.
Exploratory data analysis as a discipline, not a warm-up. You look at the data before you model it, you notice what is odd, and you can show why it matters.
Excellent writing. A model is only worth building if its reasoning can be read. You can state an analysis, a design, a result or an incident in a page that someone else can act on, and you do it as a matter of course.
Working knowledge of AWS, ideally SageMaker, and of an experiment tracker such as MLflow.
The confidence to say "this is not good enough to ship" and the evidence to back it up.
Evidence first. State the hypothesis, run the cheapest test that could prove it wrong, then decide. Nobody ships on a hunch, and nobody is blamed for a hunch that failed its test.
We write things down, and write well. Analysis write-ups for every model, RFCs for design decisions, runbooks for operations, postmortems for incidents, data contracts between producers and consumers.
Model code is production code. Typed Python, tests, review and CI on every change, for training pipelines as much as for endpoints. Infrastructure is code too, and you read and change it.
Nice-to-haves
None flagged.
Application prep
Use the role’s language and application details while tailoring your materials.