Experienced hires

Data & AI

Data engineers, data scientists, machine learning engineers and model risk specialists who build models and pipelines that a bank examiner, a hospital’s clinical leaders or an agency’s inspector general can understand and trust.

The work

Models that have to be right, and able to show it

In our clients’ world a model is not finished when it performs well. It must be documented, validated, monitored and explainable to someone whose job is to doubt it. Our data and AI work sits in the AI Research Lab, Data Trust & Governance Labs and the industry divisions.

Data engineering

Data engineers in Yerevan and Melbourne build the pipelines behind our products and clients’ analytics: ingesting, cleaning and modelling data with tools such as Python, dbt, Snowflake, PostgreSQL and Kafka. Lineage, data quality tests and access controls are part of the job, because every number may be asked about later.

Data science

Data scientists build models for problems such as credit risk, loss forecasting under CECL and stress testing. You work with the client’s risk teams, and your documentation is read by validators and examiners as closely as your code.

Machine learning engineering

Machine learning engineers in San Francisco put models into production behind our products, including grounded AI that answers from a client’s own approved sources and says where an answer came from. You care about evaluation, latency, cost and failure modes as much as accuracy.

Model risk and governance

Model risk specialists apply the Federal Reserve and OCC’s model risk guidance (SR 11-7) and its equivalents elsewhere: inventories, independent validation, ongoing monitoring and the challenge process. Increasingly that includes AI models whose behaviour is harder to pin down.

Data governance

Data Trust & Governance Labs helps clients decide who may use which data for what, how long to keep it and how to prove it, across rules such as HIPAA, GDPR and banking regulations. The work joins law, policy and engineering.

Evaluation

Across all of these, we test models against what clients need them to do, including the cases where they should refuse, defer or flag uncertainty. Evaluation sets and their results are kept and versioned like code.

Open roles

Roles in this track

These roles were open when this page was written. Listings change, so check open roles for the current list. Every listing shows its pay range.

RoleLevelOfficeTeam
Model Risk & ML Governance Lead (SR 11-7)LeadNew YorkAI Research Lab
Senior Machine Learning Engineer, Grounded AISeniorSan FranciscoAI Research Lab
Senior Data Scientist, Credit Risk (CECL / Stress Testing)SeniorChicagoAI Research Lab
Data Engineer, Data Trust & Governance LabsMidYerevanData Trust & Governance Labs
Data Engineer, Healthcare AnalyticsMidMelbourneHealthcare Solutions

Each listing says whether the role is hybrid or on-site. In some countries you are employed through an Employer of Record partner while working on a Moraph team; the listing says when this applies.

What we look for

What each level looks like in this track

Our listings use Entry, Mid, Senior and Staff / Lead. The experienced hires page explains the levels across Moraph; this is what they mean in data and AI.

Mid

You build and run well-scoped pipelines or analyses end to end: you understand the source data, write tests that catch bad data before it reaches a report, document what you built, and explain your results in plain language. You notice when data is sensitive and handle it accordingly.

Senior

You own a model or a data product: you choose the approach, defend it to validators and clients, set up monitoring, and decide when it needs rebuilding. You lead small projects, review others’ work rigorously and teach them to document for an examiner.

Staff / Lead

You set the standard for a practice: how we validate models, how we evaluate AI, how we govern data across clients. You are the person others bring their hardest questions to, and you can say no to a model that is not ready, with evidence.

How we interview

The loop for this track

Usually two to three interviews after the recruiter screen. We tell you in advance who you will meet and what to prepare, and you choose the times on your application page.

  1. Recruiter screen

    Thirty minutes on your experience, what you are looking for, the role and its posted pay range.

  2. Hiring manager

    A conversation about models, pipelines or reviews you have done: the decisions behind them, how you checked they worked, and what you did when they stopped working.

  3. Practical exercise

    A realistic problem with data, done live or as a short take-home with a stated time limit: reviewing a model’s monitoring results, designing a pipeline with its quality checks, or critiquing a validation report. It is never production work, and the data is made up.

  4. The team

    A conversation with the people you would work with, often including someone from risk, engineering or the client side, about how you explain technical results to people who will act on them.

Interviewers score against the role’s competencies and write their feedback before seeing anyone else’s. Offers are always within the posted range. See How we hire.

Sample questions

Questions like the ones we ask

These are samples like the ones we use, written to help you prepare. Your interviewers will ask their own.

Hiring manager

Tell us about a model you built that did not work as well in production as in development. Why?

What a strong answer covers:

  • How you found out, and how long it took.
  • The cause: data drift, a change in the population, leakage in development, or a business change the model did not know about.
  • What you did, and what you changed in your development or monitoring process.
How would you explain a model’s decision to a customer who was declined, or to the examiner reviewing it?

What a strong answer covers:

  • The difference between the two audiences and what each is entitled to know.
  • Specific, accurate reasons rather than a list of features.
  • How the model was built to make this possible, not explanations added afterwards.
(Model risk) Describe a model you challenged as a validator. What happened?

What a strong answer covers:

  • The weakness you found and how you tested it.
  • How you raised it: severity, evidence and a proposed remedy.
  • How the disagreement was resolved, and whether the model changed.
When have you decided that a simpler model was the right choice?

What a strong answer covers:

  • The trade-off between performance, explainability, stability and cost.
  • Who needed to understand and maintain the model.
  • Evidence that the simpler model was good enough.

Practical

Design a pipeline that brings daily loan data from a bank’s core system into a credit risk model.

What a strong answer covers:

  • Ingestion and the checks that stop a bad file: row counts, schema, ranges, duplicates, late files.
  • Lineage: being able to say which source records produced a model input.
  • Access controls on personal data, and what the model actually needs.
  • What happens when a day’s file is missing or wrong.
A grounded AI assistant answers staff questions from a hospital’s policy documents. How would you evaluate it before release?

What a strong answer covers:

  • A test set built with the people who own the policies, including questions it should refuse or pass to a person.
  • Measures for correctness, citation accuracy and harmful answers, not just fluency.
  • How results are reviewed, versioned and repeated after every change.
  • What is monitored after release.
The population stability index for a model’s main input is low, but defaults are higher than predicted. What is going on?

What a strong answer covers:

  • Stable inputs do not mean a stable relationship between inputs and outcomes.
  • Possible causes: economic change, a product or policy change, a change in how defaults are recorded.
  • Checks you would run, and what you would tell the model owner now.
Write a data quality test for a table of hospital admissions. What would it check?

What a strong answer covers:

  • Structural checks: keys, nulls, valid codes and dates in order.
  • Business checks: discharges after admissions, plausible lengths of stay, counts in line with recent days.
  • What happens when a test fails, and who is told.

Team

How do you work with a client whose risk team distrusts machine learning?

What a strong answer covers:

  • Taking the concern seriously and finding out what it is based on.
  • Starting with what they already trust, and adding evidence step by step.
  • Being willing to recommend not using a model.
Tell us about a time your analysis was wrong. How did you find out and what did you do?

What a strong answer covers:

  • Owning the mistake and correcting it quickly with the people who used the result.
  • The check that would have caught it, and whether you added it.
How do you document a model so someone else can maintain it?

What a strong answer covers:

  • Purpose, data, assumptions, limitations and known failure modes.
  • How to rebuild it, test it and monitor it.
  • Writing for the next person, including an examiner, not for yourself.

A practical exercise to try

Read a model monitoring report

An exercise like the ones we use. Work through the numbers before you open ours.

Practice exercise · model monitoring · 45 minutes

A stable score and a rising default rate

The bank, the model and every number in this exercise are fictional, made up for practice.

Background

A regional bank uses a probability-of-default model for small business loans. The quarterly monitoring report compares the distribution of model scores this quarter with the distribution when the model was developed, and compares predicted with actual defaults on loans booked a year earlier.

Exhibit 1 · Share of loans by score band
Score bandAt developmentThis quarter
1 (lowest risk)10%8%
220%18%
340%38%
420%22%
5 (highest risk)10%14%
Exhibit 2 · Outcomes on loans booked a year earlier
ItemValue
Loans5,000
Average predicted 12-month probability of default3.0%
Loans that defaulted within 12 months210

Your task

  1. Calculate the population stability index (PSI) for the score distribution. Is the population stable by the common rule of thumb (below 0.1 stable, 0.1 to 0.25 a moderate shift, above 0.25 a significant shift)?
  2. Are defaults in line with the prediction? How confident are you?
  3. What would you tell the bank’s model owner, and what would you do next?
One way to approach it

PSI. For each band, (this quarter − development) × ln(this quarter ÷ development):

  • Band 1: (0.08 − 0.10) × ln(0.8) = −0.02 × −0.2231 = 0.0045
  • Band 2: (0.18 − 0.20) × ln(0.9) = −0.02 × −0.1054 = 0.0021
  • Band 3: (0.38 − 0.40) × ln(0.95) = −0.02 × −0.0513 = 0.0010
  • Band 4: (0.22 − 0.20) × ln(1.1) = 0.02 × 0.0953 = 0.0019
  • Band 5: (0.14 − 0.10) × ln(1.4) = 0.04 × 0.3365 = 0.0135

Total PSI ≈ 0.023: stable by the rule of thumb. The only notable movement is a shift into the highest-risk band, which contributes most of the total.

Defaults. The model predicted 3.0% × 5,000 = 150 defaults; there were 210, 40% more. Treating defaults as independent, the standard deviation of the count is √(5,000 × 0.03 × 0.97) = √145.5 ≈ 12.1, so 210 is about (210 − 150) ÷ 12.1 ≈ 5 standard deviations above the prediction. Even allowing for correlated defaults, which widen the range in practice, that is far outside normal variation.

What it means. The inputs look stable but the outcomes do not: the relationship between score and default has changed. A stable PSI was never evidence that the model still works; it only shows that the population looks similar. Likely causes to check: an economic change affecting small businesses, a change in the bank’s lending policy or product, or a change in how defaults are recorded. Break the comparison down by score band and by segment to see where the gap is.

What to tell the model owner. The model is underpredicting defaults materially; that should be escalated under the bank’s model risk policy now, not at the next annual review. Interim options include an overlay on predicted defaults while the cause is investigated, closer monitoring, and a decision on whether to recalibrate or redevelop. Under SR 11-7, ongoing monitoring and outcomes analysis exist for exactly this situation, and the report should record what was found and what was decided.

Your first 90 days

What the start usually looks like

Typical, not a script: your manager agrees your goals with you in the first week.

  1. Days 1–30

    Learn the data and the rules

    Onboarding on the regulations our clients work under and our data handling standards. Get access to the right environments, read the documentation and validation history of the models or pipelines you will own, and meet the people who use them.

  2. Days 31–60

    Own something

    Take over a pipeline, a model’s monitoring or a validation, and deliver a first piece of work through review. Sit in on a client conversation about results.

  3. Days 61–90

    Improve one thing

    Propose one improvement to a model, a test suite or a governance process, with evidence for why it matters. Your manager reviews the first 90 days with you in writing.

Where it leads

Paths from here

Deeper in a discipline

From Senior to Staff or Lead in data engineering, data science, machine learning or model risk, setting standards that other teams follow.

Into leadership

Leading a practice or a team in the AI Research Lab or Data Trust & Governance Labs. Management roles are posted when open, and moving into management is a change of job, not a promotion.

Across Moraph

Data and AI people move into product management, solutions architecture or client advisory work, where understanding how models fail is valuable.

Questions

Frequently asked questions

Do I need a PhD?

No. Some research-heavy roles may prefer one, and the listing will say so. Most roles care more about what you have built, validated or run, and how well you explain it.

Do you work with client data?

Often, under the client’s agreements and our data handling standards: least access, approved environments and audit logs. Many models are built in the client’s environment or ours with controls agreed with the client.

How do you use large language models?

Where they help and can be governed: answering from a client’s own approved sources with citations, drafting for a person to check, and supporting analysts. We evaluate them before release and monitor them after, like any other model.

Do I need to know SR 11-7 or GDPR?

For model risk and governance roles, yes, or equivalent experience. For other roles, onboarding covers what you need, and colleagues in Data Trust & Governance Labs are there to help.

Can I publish research?

Ask during your interviews. Anything that could expose client information, client data or how a client’s controls work stays private, and any outside talk or paper is reviewed first.