How to get hired as an applied scientist in 2026-27

What an applied scientist actually does, and the titles people confuse it with

An applied scientist is accountable for a modelling result inside a product or an operation. The work starts before any model exists, with a problem stated in business language that cannot yet be measured: sellers complain that search misses obvious items, a warehouse network over-stocks one region and runs dry in another, fraud losses have moved to a new pattern, customers abandon a flow at a step nobody can explain. Your first contribution is turning that into something with a label, a metric, a baseline and a unit. The model comes third or fourth.

The day-to-day is less exotic than the title suggests. Most applied scientists spend more time on data than on modelling: finding out whether the label they want exists, discovering it was logged inconsistently for eight months, building a holdout that respects time, and arguing about what counts as success. Then modelling, then offline evaluation, then an online experiment with a real readout, then a written document that persuades people to act on it. At the large employers who hire the most applied scientists, a substantial part of the job is writing: a design document the team reviews, an experiment plan, a post-readout memo that says plainly whether it worked.

The confusion that costs candidates the most interviews is between a handful of adjacent titles, and the difference is not seniority or intelligence. It is what you are measured on at review time.

• Applied scientist: measured on a modelling result that ships and holds up. Novelty is welcome, not required. You write code most days, read papers selectively, defend your methodology to people who will poke at it, and own the number. The loop includes a research depth round on work you did yourself.
• Research scientist: measured on a method or a finding, usually with publication as an expected output. Concentrated in labs and in the research arms of large companies. A PhD is effectively the norm, a first-author record at top venues is close to required, and the loop weights the job talk heavily.
• Machine learning engineer: measured on whether a model-powered system works in production and keeps working. Owns serving, latency, cost, retraining and on-call, and will happily use a model somebody else built. No PhD expected, and the loop is a software loop with machine learning rounds added.
• Research engineer: measured on making other people's research run at scale, for example training infrastructure, distributed jobs, kernels, evaluation harnesses and experiment tooling. The strongest route into research organisations for people with excellent engineering and no PhD, and at some labs the band overlaps the research ladder.
• Data scientist: measured on a decision or a measurement rather than a shipped model. Experiment design, causal inference, metric definition, forecasting for planning. Overlaps heavily with applied science in statistics-first teams and barely at all in deep-learning teams, which is why the same title means two different jobs at two companies.
• Economist and operations research scientist: separate ladders at a few large employers, Amazon's economist ladder being the largest of them, hiring PhD economists and OR specialists for pricing, causal measurement, auctions, inventory and network optimisation. If your background is econometrics or stochastic optimisation rather than deep learning, these postings are often a better fit and a shorter queue than the generic applied scientist one.
• AI engineer and member of technical staff: titles that in 2026 frequently cover work an applied scientist would recognise, especially post-training, retrieval and evaluation. Filtering your search on the words 'applied scientist' alone will hide a meaningful share of the roles you want. Search on the responsibilities instead.
• One practical consequence: a posting's title tells you less than its first three responsibilities. If they name a metric, a baseline, an experiment or a publication, you are reading an applied science job. If they name uptime, deployment, pipelines and on-call with no metric anywhere, it is engineering with a science label on it.

Who actually hires applied scientists, and the five flavours of the job

The title is not evenly distributed. Amazon uses it as a standard job family at a scale no other company matches, with a ladder running from entry level through principal and its own internal science community, and it is the single biggest reason the term is now generic. Microsoft uses it widely too. Beyond those two, the title appears across large software companies, marketplaces, travel and booking platforms, delivery and logistics companies, streaming services, advertising technology, banks and insurers, hardware and robotics companies, and the applied arms of health and biotech firms. Frontier model labs mostly do not use it; they post research scientist, research engineer and member of technical staff, pay above the general market and hire a small fraction of the volume.

This matters because the five flavours of applied science want different evidence, run different depth rounds, and are not interchangeable on a resume. A candidate with a vision PhD applying to a demand-forecasting team is not weak, but will be out-argued by someone who can talk about intermittent demand, hierarchical reconciliation and the cost asymmetry between a stockout and a markdown.

Decide which flavour you are, then read the posting to decide which flavour it is. Where they differ, your cover note and your first two resume bullets are the only place to make the bridge, and the bridge has to be a transferable method, not enthusiasm.

• Ranking, search relevance, recommendation and ads: the largest single pool. Wants retrieval and reranking, learning to rank, counterfactual and off-policy evaluation, position bias, exploration, nDCG and recall at k, and a credible story about an online experiment where offline gains survived contact with users. Advertising adds auctions, pacing and budget constraints.
• Forecasting, supply chain, pricing and operations research: wants time series at scale, intermittent and hierarchical demand, quantile and probabilistic forecasts, the cost asymmetry of over and under prediction, and optimisation under constraints. Often more statistics and OR than deep learning, and often the shorter queue.
• Risk, fraud, abuse and trust: wants extreme class imbalance, label delay and label noise, adversarial drift, cost-sensitive thresholds, graph features, and the discipline to talk about precision at a fixed review capacity rather than accuracy.
• Language, speech and the LLM-adjacent teams: wants post-training rather than pretraining in almost every case. Supervised fine-tuning, preference optimisation, reward modelling, distillation, retrieval quality, synthetic data generation, and benchmark and evaluation design for a specific domain. This is the fastest-growing flavour and the one where job titles are least stable.
• Perception, robotics and scientific or clinical modelling: wants domain physics or biology alongside machine learning, hard constraints, small and expensive labelled data, simulation-to-reality gaps, and in regulated domains an understanding of validation that will stand up to an auditor or a regulator.
• A test worth running before you apply: can you name the metric this team is judged on and roughly where its baseline sits? If the posting, the team's engineering blog, their published papers and a fifteen-minute call with the recruiter do not let you guess within a factor of two, you are not yet ready to interview there.

Does the PhD still gate it in 2026-27, and the routes that work without one

The honest answer has three parts. First, the PhD remains the modal credential, and at research-screening employers a recruiter holding hundreds of applications uses it as a cheap filter whatever the posting says. Second, the posting language has genuinely softened: 'PhD in a quantitative field, or a master's degree and several years of relevant experience' is now common wording at large employers, and people are hired on the second clause every month. Third, the thing the PhD is a proxy for is what actually gets tested, which is whether you can take an ill-posed problem, choose a method, be wrong for three months, and still arrive at a defensible result. If you can evidence that without the degree, the filter can be bypassed. If you cannot evidence it with the degree, the degree will not save you in the depth round.

What the PhD buys that is hard to replace is the depth round itself. For an hour, someone will ask why you chose that estimator, what the assumption buys you, what breaks when it fails, what you tried first and why it failed, and what you would do with twice the data or a tenth of the compute. That conversation is comfortable for someone who has defended a thesis and brutal for someone who has only ever shipped. The non-PhD routes that work all substitute an equivalent body of work you can be cross-examined on.

Three routes convert in practice. None is fast, and two of them involve being inside a company already.

• Internal transfer: by far the highest-probability route. Move into an engineering, analytics or data role on or beside a science team, take the modelling work nobody has capacity for, get a scientist to co-own and review it, ship a measured result, then apply internally where your depth round is a conversation with people who already watched you do it. At several large employers this is a documented path with its own bar for the transfer, so ask your manager what that bar is in writing.
• Master's plus an applied research record: a master's in machine learning, statistics, OR or a quantitative field, then three to five years where you were the person who owned a model's quality rather than its deployment. One or two external artefacts make it legible: a workshop or conference paper with industry co-authors, a published reproduction, a technical write-up of a result with real numbers, or a talk at an applied venue.
• Research engineer first: join a research organisation on your engineering strength, owning training infrastructure or evaluation harnesses, and convert by co-authoring. This is the common route for strong engineers into labs, and in 2026 the evaluation and post-training tooling side of research has more open headcount than the method side.
• Routes that mostly do not convert, said plainly: certificate stacks, Kaggle rank on its own, a bootcamp, an unfinished PhD presented as research experience with no result attached, and a long list of reimplementations of famous papers with no measurement. They are not worthless; they are simply not evidence of the thing being screened for.
• If you are currently in a PhD: the internship is the pipeline. At the employers who hire the most new PhDs, the return offer from a summer internship is the main new-graduate channel, and applications open roughly in the autumn and close in the winter for the following summer. One internship inside your programme changes your odds more than one additional paper, and two is better than two more papers.
• If you are a postdoc or on a faculty track and switching: the thing to add is not more publications. It is one piece of evidence that you can work to somebody else's metric and deadline, for example a funded collaboration with measurable deliverables, or a sustained open-source contribution to a tool a company actually runs in production.
• Ask the recruiter directly whether the req has a hard PhD requirement or a preference. They will tell you, and it saves you four weeks of hoping.

The loop, round by round, and how level is decided

Applied science loops are longer than software loops and are usually decided by a committee rather than by the hiring manager alone, because the committee decides level and compensation as well as hire or no hire. Four to ten weeks is normal, and a slow week in the middle is usually a scheduling problem rather than a signal. The sequence below is the common shape at large employers. Startups compress it to two or three conversations plus a take-home, and frontier labs replace the fundamentals round with a harder research screen and often a multi-hour paired research exercise.

The rounds are not equally weighted, and the weighting is not what candidates assume. The research deep dive decides whether you are a scientist. The modelling design round decides whether you are a scientist they can use. The coding round rarely wins you anything and regularly loses it. The behavioural round is a genuine filter at employers with a strong written culture, and treating it as small talk has sunk candidates who passed every technical round.

Ask the recruiter for the loop composition in writing: whether a job talk is required and how long it should be, whether coding is in a shared editor or on a whiteboard, whether an AI assistant is allowed in the coding round, whether any round is a non-technical values interview, and who is in the room. Recruiters answer this readily, and the answer changes how you prepare.

• Recruiter screen, 20 to 30 minutes: confirms credential, work authorisation and location, and asks you to describe your research in plain language to someone non-technical. Many candidates fail here by reciting a thesis abstract. Have a 90-second version with no jargon that ends in what changed because of the work.
• Hiring manager or science screen, 45 to 60 minutes: the real first filter. Your work in 10 to 15 minutes, then questions about your choices, then their problem space and whether you have anything to say about it. Come with two specific questions about their metric and their current baseline.
• Technical phone screen, 45 to 60 minutes: usually coding plus machine learning questions in the same hour. Python or the language of your choice, a problem at the easier end of the standard interview range, and five to ten minutes of fundamentals. Being slow here is the most common reason a strong researcher never reaches the onsite.
• Coding round at the onsite, 45 to 60 minutes: either data structures and algorithms at medium difficulty, or a focused implementation such as k-means, a gradient step, an evaluation metric, batched inference or a sampling routine written from scratch without libraries. Both forms appear; ask which. Write runnable code, state complexity, test it yourself before being asked.
• Machine learning and statistics fundamentals, 45 to 60 minutes: rapid, broad and unforgiving of vagueness. Bias and variance, regularisation and the prior it corresponds to, maximum likelihood against maximum a posteriori, when cross-validation leaks, calibration, the metric to use under imbalance, confidence intervals and power, what a p-value does and does not say, confounding and the identification strategy you would use, how attention works and what it costs in sequence length. Expect at least one derivation on a board.
• Research deep dive or job talk, 45 to 60 minutes, sometimes 30 to 45 minutes of prepared talk plus questions: one piece of your own work in depth. At senior levels a formal talk to the wider team is often mandatory and is the round the offer turns on.
• Applied modelling design, 45 to 60 minutes: an open business problem from their domain, graded on framing, metric and baseline before method. Covered in its own section below.
• Behavioural round, 45 to 60 minutes: at employers with a published set of leadership principles or values, this round is scored against them explicitly and a vague answer is a failing answer. Amazon's Bar Raiser is the best-known example of a trained cross-team interviewer who can veto a hire. Prepare six to eight specific stories with your own actions, the data you used, the disagreement you had and the outcome, and be ready for follow-up questions that dig three levels into one of them.
• References: for a new PhD the advisor's reference is a real part of the decision at some employers, and for experienced hires the informal backchannel to a former colleague is common. Tell your referees which result you led with so their story matches yours.
• Debrief and level: the committee sets level from the depth and design rounds and from the scope of what you have owned. To influence it, give the panel evidence of scope rather than seniority: how many people or how much volume was affected by the decision your model drove, who else had to agree, and what you owned when it went wrong.

The research deep dive and the job talk: what is actually being graded

This is the round that separates applied science hiring from everything else, and the mental model most candidates bring to it is wrong. A conference talk is designed to make the work look inevitable: here is the problem, here is our clean method, here are the wins. The deep dive is designed to find out whether you can be cross-examined. The interviewers are looking for the decision log underneath the result, including the parts a paper hides.

Pick the work by what you can defend, not by prestige. A smaller project where you made every choice and know every number beats a high-profile collaboration where you owned one component and will have to say 'my collaborator handled that' four times. If your best work is your thesis, pick one chapter, not the whole thing. If your best work is under NDA, say what the problem class was, the shape of the data, the method and the relative improvement, and be explicit about what you cannot share. Interviewers are used to this and respect it; vagueness about which part is confidential is what reads badly.

The structure that survives questioning is the same every time: the problem and why it was hard, the baseline and why it was the right baseline, the decision you made and the two alternatives you rejected, how you knew it worked, what broke, and what it changed. Fifteen minutes of that, then let them interrupt. The best signal in this round is a candidate who, asked why they did not use the obvious alternative, says 'we tried it, here is the number, here is why it lost'.

• Know your own numbers cold: dataset size, split strategy, the baseline's score, your score, the variance across seeds or folds, and whether your gap is larger than that variance. Not knowing whether your improvement sat inside the noise band is a disqualifying answer in this round.
• Name the baseline and why it was fair. A result against a weak baseline is the single thing interviewers probe for hardest. Volunteering 'the honest comparison is against this stronger baseline, and here is what happens then' earns more than defending the flattering one.
• Have the ablation. Which component carried the gain. If you never ran it, say so and say what you would run first.
• Be ready for the question that goes outside your work: what would you do if the data were ten times smaller, if the latency budget were 50 milliseconds, if a third of the labels were wrong, or if you could not use a neural network at all. They are testing whether you hold a principle or only a method.
• Be ready for 'what was wrong with it'. A candidate who names a limitation they found themselves, before it is pointed out, reads as a researcher. A candidate whose work has no limitations reads as someone who did not look.
• If you give a prepared talk: slides a panel can read in a bright room, no animation, one claim per slide, a method slide that would let a competent person reimplement it, and explicit numbers on every claim. Finish inside your time. Running over into the questions is read as poor judgement about other people's time, and it is remembered in the debrief.
• Rehearse against someone hostile and senior, twice, and record it. The failure mode is not nervousness. It is the eight minutes you spend on setup before anyone hears what you did.
• For industry work, close with the consequence: shipped to what volume, what the online readout was, whether it is still running. Research that never left the notebook is a weaker artefact in this loop than research that shipped at half the quality.

The applied modelling design round, and the fundamentals round people under-prepare

The design round hands you something open and from their world: forecast demand for every item in a catalogue, decide which of ten million listings to show for a vague query, detect a new abuse pattern with two weeks of noisy labels, choose which support conversations an assistant should attempt. Candidates who prepared for a software system design interview start drawing boxes. Candidates who prepared for a machine learning interview start naming architectures. Both are losing the round in the first three minutes.

What is graded, in order, is the formulation, the metric, the baseline, the data and labels, the evaluation, and only then the method. Specifically: what decision does this model drive, what does each kind of error cost in the business's units, what is the simplest thing that would already work, where do labels come from and how delayed or biased are they, how would you evaluate offline in a way that predicts online behaviour, and how would you run the online experiment including what you would do about interference between units. If you reach a model class with ten minutes left and defend the choice on cost and constraint grounds, you have done well.

The fundamentals round is the other under-prepared one, and the reason is uncomfortable: deep specialists have forgotten the breadth. Someone three years into diffusion models may not have thought about heteroscedasticity, the derivative of logistic loss, or how to set a decision threshold since their qualifying exam. These questions are asked because the job involves reaching for the right tool, and at most employers most of the money is still made by the simple tools.

• Open with the decision, not the data: 'before I model anything, what action does the output trigger, and what does a false positive cost compared with a false negative'. Ask it even if you have to assume the answer, and say which assumption you are making.
• Name the dumb baseline out loud and cost it: last week's value, the global average, a popularity ranking, a hand-written rule, the current production system. Teams hire people who know when not to build a model.
• State the metric and defend it against the obvious alternative. Precision at the review capacity you actually have, recall at a fixed alert budget, quantile loss where over-forecasting and under-forecasting cost different amounts, nDCG where position matters, calibration where the number feeds an optimiser downstream.
• Be explicit about time: a split that respects it, features computed as of the decision moment, and the training and serving skew that appears when they are not. Leakage through a future-derived feature is the most frequently planted trap in these rounds.
• Design the online experiment, not just the offline score: unit of randomisation, what interferes between units, how long to run it, what power you need to detect a change you would actually act on, and the guardrail metric that stops it.
• Say what you would ship first and what you would defer. A phased answer, for instance a rule and a logging change in week one so that labels exist at all and a model in month two, is a senior answer.
• For the fundamentals round, drill these until they are fast: regularisation and its Bayesian reading, the derivative of logistic loss, why accuracy fails under imbalance and what replaces it, probability calibration and how to check it, confidence intervals and power, the difference between correlation and an identification strategy, what cross-validation does when groups or time are present, how attention scales with sequence length, and what a learning curve tells you about whether to buy data or buy capacity.
• Expect one question that invites you to be honest about not knowing. 'I have not worked with that; here is the closest thing I have done and how I would approach it' scores well. Bluffing a derivation in front of someone who publishes on it is the fastest no-hire in the loop.

Pay, location and work authorisation

Resist quoting yourself a number from a forum. The honest statement is that applied scientist compensation varies more by employer, level and location than any adjacent title. Frontier research labs pay above the general market for a small number of seats. At several large technology employers the science ladder and the software ladder are close enough at the nominally equivalent level that the comparison depends on the specific company and level, and levels.fyi is where you check that rather than guessing. An applied scientist at a bank, an insurer, a retailer or a hospital system may be paid on a quantitative-analyst or data-science band instead. Which of those you are talking about moves the number more than the title does.

Use sources you can check. The US Bureau of Labor Statistics has no code for this title, so bracket it with the Occupational Employment and Wage Statistics series: 15-1221 for computer and information research scientists, 15-2051 for data scientists, 15-2041 for statisticians and 15-2031 for operations research analysts. Read the metropolitan-area tables rather than the national median, because the role concentrates in a small number of metros where the figures run substantially higher. Then read the bands employers are now obliged to publish under state pay-transparency laws, and the per-level ladders on levels.fyi. For an academic comparison, public universities publish their salary scales, which gives you the counterfactual you are actually weighing.

Two mechanics matter more than the base number. First, level: the committee decides it from your evidence of scope, and one level at a large employer is usually worth more than any negotiation you will win inside a level. Second, equity structure: the vesting schedule, whether the grant is refreshed annually, and whether the offer is quoted at a share price that may not hold. Ask for the grant in shares and the vesting shape, not just the headline total.

Work authorisation is a real gate in this role in a way it is not in many others, because a large share of the candidate pool are international PhD students. In the United States that usually means F-1 with OPT and then the 24-month STEM OPT extension, an H-1B registration that runs through a capped March lottery for an October start, and O-1A as a genuine alternative for people with a publication and citation record, which many applied scientists have. Universities and some non-profit research institutions are cap-exempt. Ask the recruiter two questions before you invest four weeks: is this req open to sponsorship, and has this team sponsored at this level before. Canada and the UK have non-lottery routes, which is why some candidates take a first industry role outside the United States and transfer later.

• What raises an offer: a competing offer at a named company with a date on it, evidence of scope rather than years, a scarce domain match with the team's problem, and a published or shippable record in exactly their area.
• What raises it less than candidates expect: additional publications beyond a credible first-author record, the prestige of your institution once you are past the screen, and total years when the recent years were not spent owning a result.
• Equivalence to watch: an applied scientist offer and a senior machine learning engineer offer can land within noise of each other, and the engineering one may come with faster progression and more portable skills. The science ladder's advantage is the work, not automatically the money.
• Remote applied science roles are rarer than remote engineering roles, and the depth-round culture is part of the reason. If you need remote, filter for it early and expect a smaller pool rather than discovering it at the offer stage.
• Contract and staff-augmentation applied science exists, mostly in pharma, defence and consultancies. It pays a day rate that can look excellent and comes with no equity and a weaker research record. Take it as a bridge, with a named artefact you will be allowed to publish or show.
• If you are weighing academia against industry, cost it honestly: the industry offer is usually larger in cash and equity, the academic post usually carries more control over the question. The intermediate options, industry research residencies and part-time affiliations, are real and worth asking about by name.

The resume, the publication record, and running the search in 2026-27

Submit a resume, not a CV. One page if you are a new PhD with a focused record, two if you have industry years, and a separate publications page or a scholar profile link for the rest. The screen you are passing is a hiring manager spending under a minute looking for three things: a problem class that matches their team, a result with a number, and evidence you can be cross-examined. Teaching, service, reviewing, posters and departmental talks do not survive that minute, and including them pushes out the things that would.

Order the content by what is being screened for. A short line naming the problem class you work on in plain language, then two to four results each written as problem, baseline, what you did, measured outcome, then publications with authorship position and venue, then internships and industry collaborations, then education, then a thin tools line. Write the results in business units wherever you can: a ranking metric and the engagement or revenue readout, a forecast error reduction and the inventory consequence, fraud recall at a fixed review budget and the losses avoided. If the number is confidential, keep the unit and give the shape, for instance 'cut forecast error by a mid single-digit percentage on a product line doing nine figures of annual revenue', and never drop the outcome entirely. One small mechanical point: most postings and most parsers are American, so write 'modeling', 'optimization' and 'A/B testing' the way the posting spells them, whatever your own house style is.

On publications, write them so a non-specialist can see the signal. Mark first and co-first authorship explicitly, name the venue by its real name and year, and give each important paper one clause saying what it showed rather than repeating the title. Do not pad: workshop papers listed as if they were main-conference papers, preprints listed as 'under review' for two years, and third-to-eighth authorships stacked to make a long list all read as padding to anyone in the field, and the panel is in the field. Three papers you can defend beat fifteen you cannot.

The search itself runs on different rails from a software job search. Volume applications through job boards convert poorly for this title because the screen is a research judgement, not a keyword match. What converts is being known: an internship that turns into a return offer, a referral from someone who has seen your work, the author of a paper you built on who answers a short specific email, a reviewer who remembers you, a conference where the recruiting happens in the hallway and at the sponsor booths. Build a list of teams whose published work you can speak to, and apply to teams rather than to companies.

• What gets ignored on the resume: coursework, a research-interests paragraph, h-index, GPA beyond a new graduate's first job, a tools list longer than one line, 'proficient in' anything, and the word 'cutting-edge'.
• What lands and is routinely missing: one line naming the baseline you beat; the online readout, not only the offline one; the thing you tried that failed and what it taught you; a link to code someone else has run; and the scope of the decision your model drove.
• Have a one-page research summary ready as a separate document: three results, a figure each, the numbers, and what shipped. Send it with a referral or attach it where the application form allows. It is also the thing you rehearse the deep dive from.
• Portfolio artefacts that work for this title, in descending order: a shipped result you can describe with numbers, a reproduction that found something the paper did not say, a domain benchmark or evaluation set you built and released with its labelling protocol, a tool other researchers use, a careful negative result written up honestly. Yet another reimplementation of a well-known model is near the bottom.
• Cold outreach that works: three sentences to the person whose paper or engineering blog post you built on, naming the specific result, saying what you did with it or found when you reproduced it, and asking one question. No attachments on the first email. This has a far higher hit rate than any application form, and a surprising share of these hires start that way.
• Where the postings actually are: company career sites filtered by team, the conference job boards and recruiting events at the venues in your field, the hiring threads of research groups you follow, and internal referrals. Aggregators are the worst channel for this title and the one candidates spend the most time in.
• Timing: for new PhDs the controlling calendar is internship applications in the autumn and winter for the following summer, with conference season acting as a recruiting venue. For experienced hires there is no season, but headcount tends to be clearer early in a company's fiscal year, which is when a manager will actually talk about level.
• Keep a rejection log with the stage you reached. Rejections before the depth round mean a credential or framing problem, fixed by the resume, the research summary and referrals. Rejections at the depth round mean a defensibility problem, fixed by rehearsal against a hostile reviewer. Rejections at the coding round mean exactly what they say, and two weeks of drilling fixes them. Treating all three the same is why people apply for nine months without changing anything.

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.

• Applied scientist
• Machine learning
• Python
• PyTorch
• scikit-learn
• SQL
• Spark
• PySpark
• NumPy
• Statistical modeling
• Experimental design
• A/B testing
• Online experimentation
• Causal inference
• Uplift modeling
• Multi-armed bandits
• Thompson sampling
• Bayesian inference
• Hypothesis testing
• Statistical power
• Probability calibration
• Gradient boosting
• XGBoost
• LightGBM
• Feature engineering
• Learning to rank
• Recommendation systems
• Search relevance
• Two-tower retrieval
• Cross-encoder reranking
• nDCG
• Recall@k
• Off-policy evaluation
• Counterfactual evaluation
• Position bias
• Time-series forecasting
• Hierarchical forecasting
• Quantile regression
• Demand forecasting
• Operations research
• Convex optimization
• Mixed-integer programming
• Pricing models
• Fraud detection
• Class imbalance
• Cost-sensitive learning
• Label noise
• Large language models
• Supervised fine-tuning
• Preference optimization (DPO)
• Reinforcement learning from human feedback
• Reward modeling
• LoRA
• Parameter-efficient fine-tuning
• Model distillation
• Retrieval-augmented generation (RAG)
• Embeddings
• Vector search
• Agents and tool use
• Evaluation harness
• Benchmark design
• LLM-as-judge
• Inter-annotator agreement
• Error analysis
• Synthetic data generation
• Deep learning
• Transformers
• Computer vision
• Natural language processing
• Speech recognition
• Model serving
• Inference cost optimization
• p95 latency
• Quantization
• vLLM
• Ray
• Airflow
• MLflow
• Weights & Biases
• AWS SageMaker
• Google Vertex AI
• Azure Machine Learning
• Docker
• Git
• Peer-reviewed publications
• First-author publication
• NeurIPS
• ICML
• ICLR
• KDD
• ACL
• CVPR
• RecSys
• SIGIR
• Research internship
• Technical writing
• Design documents
• Model documentation
• Model risk management
• EU AI Act
• PhD
• Master's degree

Mistakes that cost people this job

Questions people ask