How to get hired as a machine learning engineer in 2026-27

What a machine learning engineer actually does in 2026, and the adjacent titles people apply to by mistake

A machine learning engineer owns a model's behaviour in production and the system that makes that behaviour useful. That means the data that goes in, the features or the retrieval, the choice of model, the evaluation that says whether it works, the serving path it runs on, the guardrails around its failures, and the latency and cost it runs at. The unit of work is a system that users or another service depend on, not a notebook result.

The title moved hard between 2022 and 2026, and the market has not finished relabelling. The old centre of gravity, design an architecture, train it on your own data, tune it, publish or ship it, is now a minority of postings, concentrated in a small number of labs and in domains where no general model exists. The new centre of gravity is building around models somebody else trained: retrieval over your own corpus, an evaluation harness you can trust, serving that holds a latency budget, fine-tuning only where the case for it is made, agents that call tools without looping forever, and an inference bill that does not grow faster than usage.

That shift matters for applications because the same posting title now covers two quite different jobs, and because several adjacent titles sit close enough that candidates routinely apply to the wrong one, get rejected, and learn nothing from it. The distinction between them is not seniority. It is what you are measured on.

• AI engineer: measured on a shipped product feature powered by a model nobody on the team trained. Prompting, retrieval, tool use, streaming, guardrails, latency, cost. Little or no training. If a posting never mentions training data, labels or offline metrics, it is this job regardless of what the title says.
• Applied scientist and research engineer: measured on a modelling result: a better loss, a better ranking metric, a method that works where the previous one did not. A PhD is the norm for research scientist and usually preferred for applied scientist, though several large employers run an applied scientist ladder that hires at master's level with a strong applied record. The loop includes a research-depth round on your own work, and it is more competitive than ML engineer at the same level.
• Data scientist: measured on an answer, a decision or a measurement. Experiment design, causal inference, forecasting, metric definition. May build models, but is not usually on call for one. The tell is the posting's emphasis on stakeholders, experiments and recommendations rather than services and service levels.
• MLOps and ML platform engineer: measured on whether other people's models can be trained, deployed and observed. Serving infrastructure, GPU scheduling, feature store, CI for models, drift monitoring, cost controls. Owns the paved road, not what drives on it.
• Machine learning engineer: measured on whether a specific model-powered system works in production and keeps working. Owns the model's quality and the engineering that delivers it. Writes production code most days, reads papers selectively, and is on call for something.
• One tactic worth knowing before you read any further: 'software engineer, machine learning' is a real and growing posting at large employers, where a strong software engineer is embedded in an ML team and hired on a standard engineering loop with one ML-flavoured round. If you are strong at engineering and medium at modelling, it is often the easier door into the same work.

The five kinds of ML engineer job: read the posting's nouns

Before you tailor a single bullet, decide which of five jobs the posting describes. They want different evidence, interview differently, and pay differently. The nouns in the first three responsibilities tell you which one it is.

Most candidates have genuine experience in one and a reading knowledge of the others. The failure mode is a single generic resume that leads with whichever project is most recent, so a recommendations team reads a RAG chatbot and a platform team reads a Kaggle notebook. The same career supports more than one of these resumes. It does not support the same document.

• Classical and tabular ML in a product. Fraud, credit risk, churn, pricing, demand forecasting, propensity, lead scoring, insurance, ad targeting, supply chain. Gradient-boosted trees still win most of these. Postings say feature store, label leakage, point-in-time correctness, calibration, drift, AUC or PR-AUC, model monitoring. Probably the largest category of ML jobs outside technology companies, and the one candidates chasing LLM work overlook. Interviews probe data leakage, class imbalance, threshold choice against a cost ratio, and the gap between offline metrics and online results.
• Ranking, recommendation and search. Marketplaces, media, commerce, ads, feeds. Two-stage retrieval-then-rank architectures, embeddings, candidate generation, features computed at request time, counterfactual evaluation, position bias, interleaving and online tests. Postings say nDCG, recall@k, click-through rate, engagement, two-tower, re-ranker, real-time features. The hard parts are evaluation under feedback loops and serving a ranker inside tens of milliseconds.
• LLM systems. Retrieval over internal documents, assistants, extraction and classification pipelines, agents that call tools, summarisation at scale. Postings say RAG, vector database, embeddings, evals, prompt engineering, function or tool calling, guardrails, token cost, time to first token. Overlaps heavily with AI engineer; the ML engineer version usually also owns fine-tuning or distillation, offline eval infrastructure, and the inference stack.
• Post-training and reinforcement learning. Supervised fine-tuning at scale, preference optimisation (DPO and the GRPO-style policy methods), reward modelling, reinforcement learning on tasks with a verifiable answer, and the company's own eval suite used as the reward surface rather than as a report. Postings say SFT, preference data, reward model, rollouts, RLHF or RLVR, annotation pipeline, training infrastructure. It is at the labs, at a handful of model-serving companies, and increasingly at product companies with enough proprietary data to tune on. The most competitive of the five: it usually wants prior experience training at scale, and the interview goes deep on the pipeline that collected the preference data and on why your eval is not gameable.
• Domain and edge ML. Computer vision for manufacturing inspection, robotics and autonomy, medical imaging, speech, defence, geospatial, embedded and on-device inference. Postings say ONNX, TensorRT, quantisation, latency on a named device, data collection rigs, annotation pipelines, sensor calibration, regulatory validation. Here training from scratch or heavy fine-tuning is still routine, because general models do not cover the data distribution. These teams care about your data pipeline as much as your model.

How the hiring loop works in 2026-27, round by round

The structure stabilised after the 2023-24 churn, and it is now fairly predictable across company sizes. What changed is the weighting: two rounds, ML system design and evaluation depth, became where the offer is won or lost. The coding round did not get easier. It stopped being where the decision is made while remaining the place most candidates are eliminated.

Expect four to eight weeks end to end. Large employers run more rounds and schedule them further apart; startups compress to one or two days and lean harder on a take-home or a working session. Where a company uses a hiring committee, the written feedback from the system design and project deep-dive rounds is what the committee actually reads.

Round by round, and what each one is really testing:

• Recruiter screen (20 to 30 minutes). A vocabulary and level match. Have a 90-second answer to 'what have you put in production' with one number in it, and a direct answer on which of the five job types you are strongest in. Ask here whether the role trains models or consumes them, because the answer rewrites your preparation.
• Hiring-manager call (45 minutes). Scope and judgement. What you owned versus what your team owned, why a project was worth doing, what you would do differently. This is also your best chance to find out what the team is actually struggling with, which tells you which stories to lead with for the rest of the loop.
• Coding round (45 to 60 minutes), and the difficulty depends on the employer. At large technology companies and quantitative trading firms this is a standard software-engineering coding round at medium to medium-hard difficulty, graded on whether you reach the optimal complexity inside roughly 35 to 40 minutes of actual coding. It is a filter rather than a decider, but it is the filter that fails more ML candidates than any other round, and preparing for it as though it were easy is the most expensive mistake in this article. At startups and non-technology employers it is more often data manipulation in Python and SQL, or an ML-flavoured implementation: write a training loop, implement k-means or a k-NN search, write an evaluation loop over a dataset, implement attention, debug a dataloader that silently shuffles labels. Some employers now let you use an AI assistant and grade how you direct it and whether you catch what it got wrong; others still ban it. Ask which, and practise the mode you will face.
• ML system design (45 to 60 minutes). 'Design a system that flags fraudulent transactions.' 'Design support-ticket deflection over our help centre.' 'Design the ranking for a two-sided marketplace's search.' The highest-weighted round for mid-level and above. Details below.
• Evaluation and modelling depth (45 to 60 minutes). How you would know the system works, offline and online. This is the round most candidates have not prepared for, and the one that most reliably separates people who have operated a model from people who have only built one. Details below.
• Project deep dive (45 to 60 minutes). One project, pushed until it breaks. Expect: why that model, what the baseline was, what the data looked like, what went wrong in production, what you measured, what you rejected. Prepare two projects to this depth, covering architecture, numbers, failures and alternatives, rather than six to a shallow depth.
• Take-home (four to eight hours, when used). Most common at startups and mid-size companies. Typically a messy dataset with a loose goal, or a small retrieval or extraction task with a held-out set. The scoring rarely rewards the best score; it rewards a clear baseline, an honest error analysis, a stated metric with a reason, and a README that says what you would do next and what you did not have time for. Ask whether it is paid and what the time cap is, and respect the cap visibly.
• Behavioural and cross-functional round. Usually a product manager or a partner engineer. The real question is whether you can explain a model's limits to someone who will have to sell or support it, and whether you will say 'this will not work' early rather than late.

The ML system design round: what is actually being graded

This round is not a trivia test and it is not a software system design interview with a model bolted on. It is a test of whether you reason from the problem to the system, in the order a practitioner does: what decision is being made, what the cost of each kind of mistake is, what data exists, what the simplest thing that could work is, how you would evaluate it, then how you would serve it and what it would cost.

The single most common failure is starting at the architecture. A candidate hears 'design fraud detection' and begins with a model family and a feature store diagram, never having asked what happens when the system is wrong, whether a false positive blocks a customer's rent payment or merely queues a review. Written feedback on this round is overwhelmingly about framing rather than diagram quality: a candidate who spends the first five minutes on the decision usually outscores one who draws a better architecture.

A workable shape for 45 minutes, which also works as the structure of an answer in a take-home write-up:

• Frame the decision (5 minutes). Who or what consumes the output, and what action follows. Is this a ranked list, a binary block, a score a human reviews, or generated text a user reads? What are the costs of a false positive versus a false negative, in the business's own units? What is the latency budget, and is it an online request path or a batch job? What volume?
• Name the baseline you would have to beat. Rules a domain expert could write, last week's value, a popularity ranking, a keyword search, a single prompt with no retrieval. Saying out loud that the baseline might be good enough is a strong signal, not a weak one. A candidate who proposes a transformer before mentioning a baseline reads as someone who has not had to justify a quarter of work.
• Data before model. Where the labels come from and how delayed they are: fraud labels arrive weeks later via chargebacks, and that single fact reshapes the whole design. Whether the label is actually the thing you care about or a proxy. How you avoid leakage and training-serving skew, through point-in-time correctness, the same feature code in training and serving, and no feature that is only knowable after the event you are predicting.
• Then the model, with a reason. Gradient-boosted trees for tabular, a two-tower retriever plus a re-ranker for recommendations, hybrid lexical-plus-dense retrieval with a cross-encoder re-ranker for document search, a hosted general model with retrieval for open-ended text, a small fine-tuned or distilled model where latency or unit cost rules the hosted one out. Say what you are giving up with each.
• Evaluation, offline and online, before you draw the serving diagram. The offline set and where it comes from; the metric and why it matches the cost asymmetry you named; the online test and its guardrail metrics; what you would ship behind a flag and at what traffic share.
• Serving and the numbers. Online or batch; where features come from at request time and how stale they may be; caching; what you do when the model or a dependency times out; the fallback that keeps the product usable. Give a rough latency breakdown and a rough cost per thousand requests, and say which number you are least sure of.
• Failure and monitoring. What drift looks like for this system and how you would detect it before a user does; what you log so a bad output can be reproduced; the retraining cadence and what triggers it; the kill switch and who is allowed to pull it.
• Say what you rejected. Name one alternative you considered and the condition under which it would have been the right call. This is the single cheapest way to read as senior, and most candidates never do it.
• What to practise from, since 'practise system design' is useless advice on its own. Chip Huyen's Designing Machine Learning Systems and AI Engineering (both O'Reilly) give you the system-level frame and the LLM-era vocabulary. Ali Aminian and Alex Xu's Machine Learning System Design Interview is organised the way the round is run, which makes it good for pacing. Then read the engineering blog of two companies whose job type matches your target, because a worked write-up of a real ranking or retrieval system teaches trade-offs no book can abbreviate. Rehearse out loud and on a timer; the round rewards verbal order, not knowledge.

The evaluation round, the one most candidates are unprepared for

Evaluation moved from a chapter at the end of the project to the centre of the job, and hiring followed. Many loops now dedicate a full round to it, and even where they do not, the evaluation questions inside the system design round carry disproportionate weight. The reason is practical: when the model is a commodity someone else trained, your only durable advantage is knowing, faster and more precisely than a competitor, whether a change made things better.

Questions in this round are concrete and they punish vagueness. 'Your summariser sometimes invents a policy number. How do you measure that, and how do you know your fix worked?' 'Accuracy went from 0.91 to 0.93 and complaints went up. Explain.' 'You have 200 labelled examples and no budget for more. What do you do?' 'Your LLM judge agrees with your preferred answer almost every time. Why is that not reassuring?'

What a strong answer has in it, regardless of the model type:

• A dataset with provenance. Where the examples came from, how many there are, how they were split, and why the split is honest: grouped by user or document so near-duplicates cannot straddle it, and time-ordered when the real task is predicting the future. 'I held out 20%' with no further detail is a weak answer; 'I split by customer and by week because the same ticket appears in several forms' is a strong one.
• A metric tied to the cost of being wrong. PR-AUC and a chosen operating threshold rather than accuracy on an imbalanced problem; recall at a fixed precision when a human reviews every flag; nDCG or recall@k for ranking; for generated text, a decomposed set, asking whether it is grounded in the retrieved source, whether it answers the question asked, and whether it follows the required format, rather than one fuzzy quality score.
• Error analysis by hand. Say that you read failures, grouped them into a taxonomy, counted the groups, and fixed the largest one first. Interviewers notice this immediately because it is the habit that separates people who improve systems from people who tune them. Bring a real taxonomy from real work if you have one: 'of 150 failures, 60 were retrieval misses on acronyms, 40 were the model answering a question the user did not ask, 30 were formatting, 20 were genuinely ambiguous.'
• Honest handling of LLM-as-judge. It is the standard tool for grading generated text at volume, and it is only as good as its calibration: a human-labelled subset, measured agreement between judge and humans, position and verbosity bias controlled, pairwise comparison rather than absolute scoring where possible, and a different model as judge than as generator. A candidate who uses a judge without a calibration set, or who cannot name a bias it introduces, is a candidate who has not been burned yet.
• Evals wired into CI. A regression suite that runs on every prompt, retrieval or model change and blocks a merge on a named threshold. This is the artefact most likely to make an interviewer lean forward, because most teams want it and fewer have it.
• Online and offline connected. A shadow deployment or canary, an A/B test with a pre-registered primary metric and guardrails, and a story about a time the offline number improved and the online number did not, with the reason you found. The offline-to-online gap is the real craft, and naming yours is credibility.
• Cheap-label strategies when data is scarce. Weak supervision and heuristic labelling, active learning on the model's uncertain cases, synthetic examples for format and edge cases with a human check, a small gold set you defend fiercely rather than a large noisy one you half-trust.

What machine learning engineers are paid, and what moves it

Be sceptical of any single number for this title, including the ones on salary aggregators, because the title spans a fraud-model engineer at an insurer and a frontier-lab infrastructure engineer, and because a large share of total compensation at the top end is equity whose value is not a salary at all.

Where to get numbers you can defend. The US Bureau of Labor Statistics has no SOC code for machine learning engineer; the honest approach is to bracket it with the two OES codes that absorb most of these jobs, 15-2051 (data scientists) and 15-1252 (software developers), and to read the metropolitan-area tables rather than the national median, because geography moves this more than almost anything else. For the large-technology ladder, levels.fyi has the most useful level-by-level breakdown, and the published level names let you ask a recruiter precisely which band a role sits in. For a specific employer, the ranges posted under state pay-transparency laws, which now cover Colorado, California, Washington, New York, Illinois and a growing list of other states, are the most reliable public figures available, because they are what that company is legally representing about that role.

What actually moves the number, in rough order of effect:

• Employer type, not title. A frontier lab, a large technology company, a quantitative trading firm, a well-funded AI startup, a bank, a retailer, a hospital system and a defence contractor can differ by more than a factor of two for the same nominal job, mostly through equity rather than base. Compare offers on the equity terms, not the headline.
• Which of the five job types you are in. Post-training, LLM infrastructure and ranking at scale pay above internal tabular ML at a non-technology employer, for the same years of experience.
• Demonstrated production ownership. Candidates who can show a system they ran, with latency and cost numbers and an on-call history, negotiate from a different position than candidates whose evidence is projects and papers.
• Level, which is negotiable in a way salary often is not. The level decision is made from the system design and deep-dive rounds. Pushing on level before the offer stage, with scope evidence, is usually worth more than haggling over base afterwards.
• Geography and remote policy. Many employers now band remote pay by location. Ask which band applies before the offer conversation, not during it.
• Scarce domain depth. Hardware-constrained inference, speech, medical imaging under regulatory validation, autonomy, or a specific regulated data environment command premiums because the hiring pool is genuinely small.

The resume: what lands, line by line

ML resumes fail in a specific and consistent way: they describe technique and omit consequence. 'Built a customer churn model using XGBoost and SHAP' tells a reader nothing about whether anything happened. Compare an illustrative rewrite of the same work: 'Replaced a rules-based churn list with a gradient-boosted model; retention worked the top 2% of scores; 1.8 percentage point retention lift against a holdout over two quarters.' Same project, and now the reader can tell you have been in the room where a model was judged. Use your own numbers, not these.

If the real number is confidential, keep the unit and give the shape: 'cut manual review volume by roughly a third at fixed precision', or 'moved top-of-funnel conversion by low single-digit percentage points'. Vagueness about magnitude is survivable. Absence of any outcome is not.

Four kinds of evidence do most of the work. If your resume has all four, it will clear nearly every screen for the job type you are targeting; if it has none, no amount of tool listing will substitute. Write bullets in this shape: what the system does, what it replaced, the measured outcome with units, and the constraint it ran under. One line per system, not three.

• A model in production with a measured outcome. The non-negotiable item. Name the decision it affected, the baseline it beat, and the number: revenue, loss avoided, tickets deflected, conversion, review hours saved, defects caught.
• An evaluation harness. 'Built the offline eval suite for the extraction service: 1,200 human-labelled documents, per-field precision and recall, run on every prompt and model change in CI, blocking merges below a set threshold.' This line is rarer than it should be and it reads as senior immediately.
• Latency and cost numbers. p50 and p95 for the serving path, and unit economics: cost per thousand requests, cost per resolved ticket, GPU-hours per training run, or the before-and-after of an optimisation with the lever named, whether that was quantisation, batching, caching, a smaller distilled model, a reasoning-effort cap, or a cheaper retrieval stage in front of a dearer generator.
• Data work, stated as engineering. Volume and shape, where labels came from, the annotation process you ran or designed, the leakage you found, the pipeline you built and its cadence. Data work is often the majority of the job, and candidates under-report it because it feels unglamorous. It is the most transferable evidence you have.
• Keep a short, honest tools block at the bottom, for the keyword screen only. Python, PyTorch, scikit-learn, SQL, XGBoost or LightGBM, a serving stack you have actually used, an orchestrator, a cloud, a tracking or eval tool. A block that lists everything you have ever touched reads as a list of things read about; keep it to what you could be questioned on for ten minutes.
• Cut the Kaggle rank and the coursework unless you are a new graduate, in which case lead with one deployed thing instead. A leaderboard position answers a question no interviewer asked: it says you can optimise a fixed metric on a clean dataset, which is the part of the job that no longer exists.
• Name the model family, not just 'machine learning'. Screens, human and automated, match on specifics: gradient boosting, two-tower retrieval, cross-encoder re-ranking, LoRA fine-tune, distillation, sequence labelling, time-series forecasting, preference optimisation. Generic phrasing matches nothing.
• Mirror the posting's job type in your first two bullets. The same underlying experience can lead with a ranking system for a marketplace and with an eval harness for an LLM team. Reorder; do not reinvent.

Portfolios that work, and the paths that convert

The portfolio question is asked in almost every loop, in one form or another: show me something you built. The answer that works is one deployed system with a public write-up, not five notebooks. Depth is the signal, because depth is what a notebook cannot fake. You only hit retrieval failures on acronyms, a cache that returns stale features, or a token bill that triples at 10% more traffic by running something past real inputs.

A portfolio project that gets interviews looks like this: a real dataset or a real corpus, a baseline you beat, an eval harness with a held-out set and a metric you argue for, a deployed endpoint with measured p95 latency and a cost-per-thousand figure, a README with an error taxonomy counted from actual failures, and one paragraph on what you would do with another month. Write the failures down. Interviewers trust a project that admits where it is weak far more than one that claims to work.

On the paths in. Four converge on this role, and each has a specific thing to fix:

• From software engineering. The strongest path and the most underrated. You already have the half most candidates lack: production code, testing, on call, systems thinking. Fix: one end-to-end model with offline and online evaluation, and enough statistical literacy to defend a metric choice. Target 'software engineer, machine learning' and the platform-adjacent postings first; they screen on your existing strengths.
• From data science or analytics. You have the modelling and the metric judgement. Fix: ship something that serves live traffic. Take the model you built that sat in a notebook, put it behind an endpoint, write the eval suite, add monitoring, and describe it as a service with latency and cost. Learn enough engineering discipline, meaning version control, tests, containers and CI, that a reviewer does not have to wonder.
• From research or a PhD. You can read and reproduce anything. Fix: show that you can hold a constraint. One project where the limit was 50 milliseconds or a cent a request, and where you chose a worse model on purpose for a stated reason. Also decide honestly whether you want applied scientist instead; that loop rewards your depth more directly.
• From MLOps or platform. You own the road. Fix: own one model's quality, not just its deployment. Build the eval suite and the error taxonomy for a system your platform hosts, and be able to argue about a threshold in business units.
• Where the jobs are. Go to company boards directly. Greenhouse, Lever and Ashby pages are where postings appear first and where descriptions are complete, and they are indexable. Then the hiring pages of labs and AI startups, the monthly 'Who is hiring' threads, specialist ML job boards, and the engineering blogs of companies whose problems you find interesting, because a referenced blog post in a cover note gets read. Avoid the aggregator reposts; the descriptions are truncated exactly where the job type is specified.
• On certifications. There is no licence and no credential that gates this work. Cloud ML certifications occasionally help a resume clear a procurement-minded screen at a consultancy or an enterprise, and they help nobody in the system design round. Spend the same weeks on a deployed system with an eval report instead.

Running the search in 2026-27, including the no-production-experience trap

Everything above assumes you get read. In 2026 that is the binding constraint for most readers of this page. A posting at a recognisable employer collects applicants in the hundreds within days, most screens reject on title and keyword match before a human reads a line, and the single most common blocker is circular: the job wants a model you shipped to production, and your current employer will not let you ship one. Treat those as two separate problems, because they have two different fixes.

On channels, the honest shape rather than a made-up conversion rate: cold applications convert badly enough that the only way to make them work is volume and precise targeting, while a referral or a direct note to the hiring manager converts well enough to be worth most of your effort. Do not quote yourself a percentage from anywhere. Just allocate your week accordingly: a few hours on applications, most of it on the five companies you actually want and the people inside them.

A referral request that works is short, names the requisition, and does the referrer's work for them. Two sentences on the one system you shipped that matches that posting, a line on why that company specifically, and a paste-ready paragraph they can forward. 'Let me know if you hear of anything' asks a stranger to do your thinking and reliably gets nothing.

On the production-experience trap, in order of cost:

• Find the model inside your current job. The cheapest production experience available is the decision at your employer that is currently made by a rule, a spreadsheet or a queue nobody has looked at in two years. Scope the smallest useful version, define the metric with whoever owns the decision, build the eval before the model, ship it behind a flag at a small traffic share, and write down what it changed. This is the same artefact the interview asks for, and it does not require a title change.
• Take the ML-adjacent work your team is avoiding. The label pipeline, the drift monitoring, the eval harness for a feature someone else prompt-engineered, the cost reduction on an inference bill. It is all legible as ML engineering evidence, and it is usually unowned.
• Internal transfer beats an external move when you lack production evidence. You are competing against a smaller field, the hiring manager can verify your engineering directly, and six months on an ML team internally makes the external search a different search. Ask for a rotation or a loan before you ask for a transfer.
• If none of that is available, build the portfolio system described above and put it in front of real users, even two. A side project with ten real users and a logged failure taxonomy beats a benchmark result with none, because the failures are what the interview is about.
• Open source is the other verifiable route: a merged contribution to an eval, serving or data-tooling project is public, dated and reviewable by a stranger, which a private side project is not.
• Fix the title mismatch on your own documents. If your title is 'Data Scientist' and you are targeting ML engineer, the headline under your name should say what you do (for example, 'Data Scientist, production ML systems'), your first two bullets should be the service you shipped, and the skills block should use the posting's nouns. Do not invent a title you never held; reframe the one you did.
• Track where you lose, not just whether you lost. Losing at the recruiter screen is a documents and targeting problem. Losing at the coding round is a drilling problem. Losing at system design is a framing and rehearsal problem. Losing at the deep dive means your two projects are not prepared to depth. Candidates who do not record the stage repeat the same fix for months. Expect the search to run in months rather than weeks, and keep several processes alive at once so no single loop carries your timeline.

What a screen is looking for

These are the terms that a resume screen, human or automated, is matching against for this role. Use the ones that are true of you, in the words the posting uses.

• Python
• PyTorch
• scikit-learn
• SQL
• XGBoost
• LightGBM
• Gradient boosting
• Feature engineering
• Feature store
• Point-in-time correctness
• Training-serving skew
• Label leakage
• Class imbalance
• PR-AUC
• Probability calibration
• Recommendation systems
• Learning to rank
• Two-tower retrieval
• Cross-encoder reranking
• nDCG
• Recall@k
• A/B testing
• Shadow deployment
• Canary release
• Model monitoring
• Data drift
• Model retraining
• MLflow
• Weights & Biases
• Airflow
• Docker
• Kubernetes
• CI/CD
• AWS SageMaker
• Google Vertex AI
• Azure Machine Learning
• Model serving
• vLLM
• Triton Inference Server
• TensorRT
• ONNX
• p95 latency
• Time to first token
• Quantisation
• Model distillation
• Inference cost optimisation
• Large language models
• Retrieval-augmented generation (RAG)
• Embeddings
• Vector database
• Hybrid search
• BM25
• Chunking strategy
• Prompt engineering
• Tool calling
• Agents
• Guardrails
• Fine-tuning
• LoRA
• Supervised fine-tuning
• Direct preference optimisation (DPO)
• Reward modelling
• Eval harness
• LLM-as-judge
• Golden dataset
• Error analysis
• Groundedness
• Observability
• Tracing
• EU AI Act
• SR 11-7 model risk management
• Time-series forecasting

Mistakes that cost people this job

Questions people ask