Tech Job Resources
Eleven roles that sit close enough together to be confused constantly — in job ads, in interviews, and by candidates deciding which one they actually want. For each: what you own, the skills that matter, the soft skills nobody lists but everybody screens for, the tools, and a small project worth building.
The strip on every card shows the same pipeline with that role's territory lit up — solid for what you own, pale for what you touch. Overlaps between roles are real, not sloppy labelling.
At a glance Product & platform AI Engineer Lead AI Engineer ML Engineer Data Scientist Data Analyst Data Engineer System Development Engineer Forward Deployed Engineer Technical Program Manager Research Research Scientist Applied Scientist Research Engineer One system, seven roles Choosing
At a glance
| Role | Core question | Primary output | Interview weighted toward | Most confused with |
|---|---|---|---|---|
| AI Engineer | Can I build a reliable feature on a model I didn't train? | A shipped LLM/VLM feature + its eval harness | Applied coding, LLM system design, evals | ML Engineer |
| Lead AI Engineer | Is the team building the right thing, in the right order? | Technical direction others can execute against | Ambiguous system design, leadership scenarios | Eng Manager / Staff Engineer |
| ML Engineer | Can I train, serve, and keep this model healthy? | A model in production with monitoring | ML system design, fundamentals, coding | AI Engineer / Data Scientist |
| Data Scientist | What is true here, and what should we do? | A decision, with quantified uncertainty | Stats, SQL, product case | Data Analyst / ML Engineer |
| Data Analyst | What happened, and what should people see? | Trusted metrics and dashboards | SQL (heaviest), business case | Data Scientist |
| Data Engineer | Is the data correct, fresh, and available? | Reliable pipelines and models of the data | SQL, modelling, pipeline design | Backend / Analytics Engineer |
| System Development Eng. | Can this run reliably at scale without a human holding it up? | Automated, observable infrastructure and a shorter on-call | Linux/networking troubleshooting, coding, ops scenarios | DevOps Engineer / SRE / SDE |
| Forward Deployed Eng. | What does this customer need, working, this week? | A working deployment in someone else's environment | Practical coding, customer scenarios | Solutions Architect / SWE |
| Technical PM | What's blocking the ship, and who needs to know? | Shipped programs across teams | Execution cases, technical depth screen | Product Manager |
| Research roles | ||||
| Research Scientist | What don't we know, and can I move it? | A method and a result others can build on | Research talk, your own papers, fundamentals | Research Engineer |
| Applied Scientist | Does a known method solve our problem? | A method adapted, shipped, and measured | Applied ML case, depth, coding | ML Engineer / Research Scientist |
| Research Engineer | Can I make this experiment run correctly, at scale, fast? | Training infrastructure and experiment velocity | Systems + ML coding, distributed training | ML Engineer |
Titles lie, scope doesn't. The same title spans wildly different jobs by company size — at a 20-person startup one person is often three of these; at a large company the boundaries are sharp and enforced. Read the responsibilities in the job description, not the title, and in interviews ask "what did the last person in this role actually spend their week doing?"
Product & platform roles
Roles measured by something shipping. The clock is quarterly, the output is a working system, and success is someone using it.
AI Engineer
"Can I build a reliable product feature on top of a model I didn't train?"
What you own
- The application layer around a model: prompts, retrieval, tool calling, agent control flow, and output handling.
- Quality as a measurable property — building the eval set and harness that says whether a change helped.
- The three production numbers: latency, cost per request, and failure behaviour under load.
- Guardrails: grounding, citation, abstention paths, and what happens when the model refuses or returns nonsense.
Technical skills
- Strong applied Python and comfort living inside someone else's API — streaming, retries, rate limits, token budgets.
- RAG end to end: chunking strategy, embeddings, hybrid retrieval, reranking, and knowing that most "model problems" are retrieval problems.
- Agent patterns — tool calling, planner/executor, reflection — and when a plain chain is the better answer.
- Evaluation design: golden sets, LLM-as-judge and its failure modes, regression gates in CI.
- Cost and latency engineering: caching, prompt-prefix stability, model routing by difficulty.
Soft skills that actually get screened
- Calibrated honesty about non-determinism. Stakeholders want "does it work?"; your job is to answer with a number and a confidence interval without hiding behind either.
- Knowing when it's good enough. This role has no natural stopping point — the discipline is deciding the quality bar with the business before you start tuning.
- Writing precise specifications. Most prompt failures are underspecified requirements wearing a costume.
Tools
PythonOpenAI / Anthropic / Bedrock APIsLangGraphLlamaIndexMCPpgvector / PineconeLangfuse / LangSmithRagasFastAPIDocker
Small project worth building
A documentation assistant with an evaluation harness. Index a public documentation set, serve answers with hybrid retrieval and a reranker, and cite sources. The differentiator is not the chatbot — everyone has one. It is the 50-question golden set with expected answers, the faithfulness and retrieval-precision scores, and a CI job that fails the build when a prompt change regresses quality. Publish the eval numbers before and after one deliberate improvement.
Lead AI Engineer
"Is the team building the right thing, in the right order, well enough to keep?"
What actually changes from AI Engineer
This is a seniority tier rather than a different discipline, so the useful question is not what the skills are — you already have them — but what the job becomes. Four things change, and they are the whole difficulty:
- You are measured on the team's output, not your own. A quarter where you wrote almost no code and three engineers shipped well is a good quarter. This takes most people a year to genuinely believe.
- The hardest problems stop being technical. They become "these two teams disagree and both are partly right", and no amount of engineering skill resolves them.
- You decide without enough information, publicly. Waiting for certainty is itself a decision, and usually the expensive one.
- Your leverage moves to review and design. A good design review changes the direction of six weeks of work; a good pull-request comment changes how someone builds for years.
What you own
- Technical direction for the AI surface — including which problems should not get a model, which is the more valuable half of that judgment.
- The expensive-to-reverse decisions: provider and model strategy, evaluation infrastructure, build versus buy, and where lock-in is acceptable.
- The quality bar and its enforcement — what the eval gates are, and holding the line when a deadline argues otherwise.
- Engineers growing: scoping work so it stretches people, reviewing in a way that teaches, and giving the hard feedback early.
- Translation upward — converting leadership's expectations into something achievable, and the reverse, without either side feeling managed.
Technical skills
Everything in the AI Engineer card remains assumed. What gets added:
- System design across a portfolio rather than a feature — shared eval infrastructure, shared retrieval, and cost modelled at the level of the whole product.
- Enough breadth into data, infrastructure, and security to spot the risk that sits between teams and has no owner.
- Reading the research and vendor landscape well enough to know what is about to get cheap, so you don't build what you could buy in six months.
- Writing that carries a decision: design documents and decision records that let someone act without you in the room.
Soft skills that actually get screened
- Restraint. Not fixing it yourself when fixing it yourself would be faster. This is the single hardest transition, and interviewers probe it deliberately.
- Saying no upward with a smaller yes attached. "Not that, but here is what we can have by then" keeps credibility that a flat refusal spends.
- Feedback that changes behaviour without costing trust — specific, early, and about the work rather than the person.
- Making your reasoning legible. A decision nobody can reconstruct gets relitigated every quarter.
- Absorbing uncertainty on behalf of the team so they can keep building while you carry the ambiguity.
Tools
Everything in the AI Engineer cardDesign docs / ADRsEval platformsCost dashboardsRoadmappingIncident review
What to show instead of a project
Evidence of judgment, not another repository. By this level a portfolio project proves little — everyone assumes you can build. Bring a decision record instead: one architecture or build-versus-buy call you made, the options you rejected and why, what you were uncertain about, and what actually happened afterwards — including if it went badly. Pair it with evidence someone else built on your work: a tool your team adopted, an engineer who grew under your review, a direction change you argued for and won.
Check whether it is actually a management job. "Lead" usually means a technical track where you still build — but if the description mentions headcount, performance reviews, hiring plans, or budget ownership, it is an engineering manager role wearing an engineering title. That is a genuinely different career, not a harder version of this one. Ask directly in the interview: "how much of this role is expected to be hands-on in six months?" — and treat a vague answer as an answer.
ML Engineer
"Can I train this model, serve it, and keep it healthy at 3am?"
What you own
- Training pipelines that are reproducible — same data and config, same model, months later.
- Serving: throughput, p99 latency, autoscaling, and the memory arithmetic that decides how many requests fit on a node.
- Monitoring for drift and degradation, and the retraining trigger that responds to it.
- The handoff boundary with research — turning a notebook that worked once into a system that works continuously.
Technical skills
- PyTorch and the training loop in depth: data loading, mixed precision, distributed strategies, checkpointing.
- Optimisation for deployment — quantization, distillation, pruning, ONNX/TensorRT export, batching strategy.
- Software engineering that survives review: testing, packaging, CI/CD, dependency and CUDA hygiene.
- Infrastructure: containers, Kubernetes, GPU scheduling, cost awareness per training run and per 1K inferences.
- Debugging skill specific to ML — telling a data bug from a training bug from a serving skew.
Soft skills that actually get screened
- Experimental discipline. The willingness to distrust a result that looks great, and to go find the leakage before shipping it.
- Ownership past launch. Models decay quietly. The role rewards people who instrument first and get paged rarely.
- Translating with research. Being the person who can read the paper and explain why its assumptions don't hold in your serving environment.
Tools
PyTorchMLflow / W&BAirflow / KubeflowKubernetesDockervLLM / TritonSageMaker / Vertex AIONNXPrometheus + GrafanaSpark
Small project worth building
A closed training-to-retraining loop. Fine-tune a small model, serve it behind an autoscaling endpoint, and log every prediction. The differentiator is the loop closing itself: a drift detector on the input distribution, an alert, and an automated retraining job that promotes a new version only if it beats the incumbent on a held-out set. Report p99 latency and cost per 1K requests before and after one optimisation.
Data Scientist
"What is actually true here, and what should we do about it?"
What you own
- Turning a vague business question into one that data can actually answer — or establishing that it can't.
- Experiment design: hypotheses, power analysis, guardrail metrics, and the analysis plan written before the data is seen.
- Inference and modelling where the goal is understanding, not just prediction — effect sizes, confounders, uncertainty.
- The recommendation, delivered so a decision-maker can act on it and knows how confident to be.
Technical skills
- Statistics with real depth: hypothesis testing, confidence intervals, multiple comparisons, power — and the traps in each.
- Experimentation: A/B design, sample sizing, novelty and network effects, when a test is invalid.
- Causal inference beyond correlation — diff-in-diff, propensity scores, instrumental variables, and their assumptions.
- Modelling with scikit-learn and friends; feature engineering; validation splits that respect time and grouping.
- SQL good enough to get your own data without waiting on anyone.
Soft skills that actually get screened
- Saying "the data can't answer that." The hardest and most valued sentence in the role. Everything downstream depends on someone being willing to say it early.
- Communicating uncertainty without losing the room. A result nobody understands has the same business value as no result.
- Resistance to the desired answer. You will often be handed a conclusion and asked to support it. How you handle that is the whole job.
Tools
Python (pandas, scikit-learn, statsmodels, SciPy)SQLRJupytermatplotlib / seaborndbtTableau / LookerGit
Small project worth building
An analysis that was allowed to fail. Pick a public dataset, state a hypothesis and success criteria up front in the README, then run it. The differentiator is pre-registration and an honest write-up — including a null or inconvenient result, the assumptions you checked, and what would change your mind. Almost every portfolio has a model with 0.94 accuracy; almost none demonstrates intellectual honesty, which is the thing the role is actually hiring for.
Data Analyst
"What happened, and what does the business actually need to see?"
What you own
- Metric definitions — including the edge cases, exclusions, and timezone decisions that everyone forgets and then argues about.
- Dashboards and reporting that people trust enough to act on, and that don't quietly break.
- Ad-hoc investigation: the "why did this drop on Tuesday" question, answered fast and correctly.
- Enabling self-serve, so the same five questions stop arriving in your inbox.
Technical skills
- SQL, deeply — window functions, CTEs, careful joins, and understanding why a query is slow.
- Data modelling for analytics: how facts and dimensions should be shaped so questions are cheap to answer.
- Visualisation judgment — chart type, axis honesty, and cutting everything that doesn't inform a decision.
- Enough statistics to avoid the common traps: Simpson's paradox, survivorship bias, reading noise as trend.
- Spreadsheet fluency, unglamorous and genuinely load-bearing in most organisations.
Soft skills that actually get screened
- Finding the question behind the question. "Can you pull last month's signups?" usually means something else, and the good analyst asks what decision it feeds.
- Pushing back on vanity metrics — diplomatically, with an alternative in hand rather than just an objection.
- Narrative discipline. Leading with the finding, not the methodology, and knowing which three numbers matter out of the thirty you have.
Tools
SQLdbtTableau / Power BI / LookerQuickSightExcel / SheetsPython (pandas, light)GitBigQuery / Snowflake
Small project worth building
One metric, defined properly. Take a public dataset and pick a single business metric — retention, say. Write the definition document: what counts, what's excluded, which timezone, how late-arriving data is handled, and how a naive version of the same metric misleads. Then build the dashboard on top of it. The definition document is the portfolio piece; the dashboard is the easy half, and hiring managers know it.
Data Engineer
"Is the data correct, fresh, and where it needs to be — and how do I know?"
What you own
- Pipelines that run on schedule, recover from failure, and produce the same result when re-run.
- The warehouse or lakehouse model: schemas, partitioning, and the contracts other teams build against.
- Data quality as an enforced property — tests, quarantine, alerting — rather than something discovered downstream.
- Cost, which in this role is a first-class design constraint rather than an afterthought.
Technical skills
- SQL and at least one of Python or Scala at production quality.
- Distributed processing with Spark: partitioning, shuffles, skew, and why a job that worked at 1GB dies at 1TB.
- Orchestration and the semantics that matter — idempotency, backfills, late-arriving data, exactly-once vs at-least-once.
- Dimensional modelling, slowly changing dimensions, and schema evolution without breaking consumers.
- Streaming fundamentals (Kafka), plus infrastructure-as-code and enough cloud to own your footprint.
Soft skills that actually get screened
- Productive paranoia. Assuming upstream will change the schema without telling you — and building so that it's caught rather than silently absorbed.
- Calm during incidents. When the pipeline fails at 6am and eight dashboards are wrong, the useful person triages instead of narrating.
- Negotiating contracts with upstream teams who have no incentive to care about your pipeline, which is a diplomatic problem more than a technical one.
Tools
SQLPython / ScalaSparkAirflow / DagsterdbtKafkaSnowflake / BigQuery / RedshiftTerraformDockerGreat Expectations
Small project worth building
A pipeline that survives bad input. Ingest a messy public feed on a schedule into a modelled warehouse table. The differentiator is everything after the happy path: data-quality tests that quarantine bad rows instead of failing the run, an alert that says which check failed and why, backfills that are safe to re-run twice, and a documented schema contract. Then deliberately feed it a malformed batch and show what happened.
System Development Engineer
"Can this run reliably at scale without a human holding it up — and if it breaks at 3am, how fast do we know and recover?"
Primarily an Amazon and AWS title, and the source of most of the confusion around it. A Software Development Engineer (SDE) builds the product; a System Development Engineer (SysDE) builds and automates the systems the product runs on. It is a genuine engineering role with a real coding bar — not an operations role with a coding screen bolted on — but the code you write is automation, tooling, and infrastructure rather than product features. Elsewhere the same job is usually advertised as Infrastructure Engineer, Platform Engineer, or SRE.
What you own
- The path from a merged commit to running software: build, deployment pipelines, rollout strategy, and rollback.
- Fleet and infrastructure lifecycle — provisioning, patching, scaling, and retiring hosts or containers without downtime.
- Observability as a product: the metrics, alarms, dashboards, and logs that other engineers depend on during an incident.
- Operational load itself. Reducing pages, automating the manual runbook step, and eliminating the class of failure rather than the instance.
- Capacity and cost, which in this role are engineering constraints you are measured on rather than someone else's spreadsheet.
- On-call for the systems you own, and the follow-up that stops the same incident happening twice.
Technical skills
- Linux, genuinely. Processes, file descriptors, memory and the OOM killer, systemd, and the ability to work out why a box is unhealthy from the shell rather than from a dashboard.
- Networking. DNS, TCP handshakes and timeouts, TLS, load balancers, VPCs, routing, and NAT — most cross-service mysteries turn out to live here.
- Coding at production quality, usually Python or Go, occasionally Java. The bar is real: expect data structures and algorithms, but weighted toward parsing, automating, and systems glue rather than competitive puzzles.
- Infrastructure as code — Terraform or CDK/CloudFormation — plus configuration management, and the discipline that nothing is changed by hand.
- Containers and orchestration: images, registries, and Kubernetes or ECS, including what to do when a pod is stuck rather than only how to deploy one.
- CI/CD pipelines end to end, with the deployment safety mechanisms — canaries, staged rollouts, automatic rollback on alarm.
- Cloud depth over cloud breadth. IAM, VPC, EC2, S3, and the operational behaviour of a handful of services beats a passing familiarity with fifty.
- Observability and troubleshooting method: reading a distributed trace, bisecting to isolate a fault, and distinguishing saturation from a hard limit.
Soft skills that actually get screened
- Composure and structure under an active incident. The person who mitigates first and diagnoses second, and who says what they are doing while doing it, is the one this interview is trying to find.
- Blameless analysis. Being able to describe an outage you caused, what the system allowed, and what you changed afterwards — without either defensiveness or performative self-blame.
- Refusing to normalise toil. Treating a recurring manual step as a defect to be engineered away is the attitude that separates this role from ticket-driven operations.
- Working with teams whose deadline your safeguards inconvenience, and making the case for the guardrail in their terms rather than yours.
Tools
LinuxPython / GoBashTerraformDockerKubernetes / ECSAWSCI/CDPrometheus / GrafanaCloudWatchAnsibleGit
How the interview differs
Expect a Linux and networking troubleshooting round — a described broken system, and you ask questions to narrow it down. Bisecting to eliminate the most possibilities beats guessing the most likely cause, and saying so explicitly is part of the score. Expect a systems design round weighted toward deployment, failure modes, and blast radius rather than product features. Expect coding, at a real but not algorithm-tournament level. At Amazon specifically, expect Leadership Principles behavioural questions in every round, with Ownership, Dive Deep, and Bias for Action the ones this role leans on, answered in STAR form with your own metrics.
Small project worth building
A service that deploys and heals itself. Take any small application, then build everything around it: infrastructure defined in Terraform, a CI/CD pipeline that builds an image and deploys on merge, a health check, and autoscaling. The differentiator is what happens when it breaks: an alarm that fires on a symptom users would feel, an automatic rollback triggered by that alarm, and a short written runbook. Then kill an instance on purpose, let it recover, and write up what the graphs showed — that write-up is the artefact worth talking about.
Forward Deployed Engineer
"What does this customer actually need, and can I make it work in their environment this week?"
What you own
- Getting the product working against real customer data, in a stack you did not choose and cannot fully control.
- Rapid prototyping in front of people — building the thing that proves value before the contract renewal.
- Integration reality: their auth, their formats, their network restrictions, their compliance review.
- The feedback loop home — being the person who tells product why the beautiful abstraction doesn't survive contact with customers.
Technical skills
- Broad rather than deep: enough backend, data, and infrastructure to be dangerous across an unfamiliar stack.
- Integration work — APIs, auth flows (OAuth, SAML), file formats, and legacy systems with no documentation.
- Debugging in environments you can't reproduce, often with limited logs and no ability to install what you'd like.
- Data wrangling against genuinely messy real-world inputs, not a curated dataset.
- Security and compliance literacy — enough to answer their review without stalling the deployment.
Soft skills that actually get screened
For this role the soft skills are the qualification. Everything above is table stakes.
- Reading the room mid-demo. The stated blocker is often not the real one; the real one is usually political and unstated.
- Expectation management without over-promising. Saying "not this quarter" to a customer's face, keeping the relationship, and being believed next time.
- Composure when it breaks live. It will break live. What you do in the next ninety seconds is the job interview and the job.
- Bilingualism. Translating customer frustration into an actionable engineering ticket, and engineering constraints into something a customer accepts as reasonable.
Tools
PythonSQLDockerPostman / curlCloud consoles (AWS / GCP / Azure)Kubernetes (enough)GitObservability toolingWhatever the customer runs
Small project worth building
A deployment under deliberately awkward constraints. Take an open-source tool and stand it up in an environment designed to be inconvenient — no outbound internet, an unusual auth scheme, data arriving in a legacy format. The differentiator is the runbook: a document another engineer could follow to repeat the deployment without you, including the three things that went wrong and how you diagnosed them. This role is hired on evidence that you operate well in other people's mess.
Technical Program Manager
"What is blocking this from shipping, and who needs to know right now?"
What you own
- Execution across teams that don't report to you — sequencing, dependencies, and the critical path.
- Risk: naming it early, quantifying it, and driving mitigation before it becomes an incident.
- The communication layer — status that is honest and short, escalations that are timed rather than panicked.
- Scope discipline, which mostly means being the person who asks what gets cut when the date won't move.
Technical skills
- Enough depth to evaluate an estimate and notice when "two weeks" is optimistic — you don't write the code, you have to understand it.
- Systems thinking: seeing that the model can't launch until the backfill lands, three sprints before anyone else does.
- Planning craft — milestones that mean something, dependency mapping, and buffers placed where risk actually is.
- Metrics and instrumentation for the program itself: are we ahead, behind, or guessing?
- Writing. The single highest-leverage TPM skill: a document that makes a hard tradeoff legible to twelve people.
Soft skills that actually get screened
- Influence without authority. The entire role. You get outcomes by being useful, prepared, and trusted — not by escalating.
- Escalation judgment. Too early and you burn credibility; too late and you own the failure. Calibrating this is what separates senior from junior.
- Absorbing chaos. Taking ambiguity in and emitting clarity, so engineers can keep their context intact.
- Saying the uncomfortable thing early, in the room, when the date is clearly not going to hold.
Tools
Jira / LinearConfluence / NotionSlackSheetsSQL (for your own metrics)Dashboards (Looker / Tableau)MiroIncident tooling
Small project worth building
Run something real and keep the artifacts. This role can't be demonstrated with a repository, so coordinate an actual multi-party effort — an open-source release, a migration, a hackathon, a student org's launch. The artifacts are the portfolio: a one-page program brief, a risk register with what you did about each item, the status update format you used, and a retrospective naming what you'd do differently. Bring those to the interview; almost no candidate does.
Research roles
Roles measured by what becomes known or possible. The clock runs in years rather than quarters, the output is a method or a capability, and the thing you build may be handed to a product team long after you finish. Three roles sit here, and the confusion between them is the sharpest on this page.
| Research Scientist | Applied Scientist | Research Engineer | |
|---|---|---|---|
| Asks | What question is worth answering? | Does a known method solve our problem? | Can we run the experiment at all? |
| Output | Knowledge others build on | A working solution that moves a metric | Capability and experiment velocity |
| Judged by | Novelty and rigour | Business impact | Throughput and reliability |
| Publishing | The point | A welcome side effect | Occasional, usually systems work |
| Usual bar | PhD or equivalent record | MS or PhD | Strong engineering; no doctorate needed |
Research Scientist
"What don't we know yet, and can I produce evidence that moves it?"
What you own
- Problem selection — deciding what is worth working on, which is the highest-variance decision in the role.
- The method: a novel approach, or a novel understanding of why an existing one behaves as it does.
- Experimental design that can actually support the claim — baselines, ablations, and the comparison a skeptic would demand.
- The claim itself, and its limits. Overclaiming is the cardinal sin here in a way it isn't elsewhere.
Technical skills
- Mathematical depth — linear algebra, probability, and optimisation held well enough to reason with, not just recite.
- Fluent literature reading: finding the three papers that matter, reproducing a result, and spotting the assumption doing the real work.
- Rigorous evaluation — ablations that isolate one variable, baselines tuned as carefully as your method, seeds and variance reported.
- Enough engineering to run your own experiments without waiting, even where a Research Engineer owns the platform.
- Writing. A result nobody can follow does not exist, and papers are the medium of the job.
Soft skills that actually get screened
- Tolerance for long stretches of failure. Most ideas do not work. The role selects for people who stay productive through months without a positive result.
- Taste in problems — the least teachable and most valued trait. Interviews probe it directly with "what would you work on next, and why that?"
- Taking hard critique without defending. Peer review, reading groups, and your own team exist to attack the claim; the useful reflex is curiosity, not protection.
- Honesty about negative results, including when the honest report undercuts your own narrative.
Tools
PyTorch / JAXWeights & BiasesSLURMNumPy / SciPyLaTeX / OverleafarXivHuggingFacematplotlib
Small project worth building
Reproduce a paper, then go one step past it. Pick a recent paper with released code, reproduce the headline result, and report honestly where your numbers differ and why. The differentiator is the step past: one ablation the authors didn't run, with a hypothesis stated up front. Without a publication record this is the most credible evidence available that you can do the work — and reproduction gaps are a real, publishable contribution in their own right.
On the PhD question. Research Scientist postings usually expect a PhD or an equivalent publication record, because the role is judged on original contribution. Research Engineer generally does not — it is judged on systems ability, and it is often the higher-leverage way into a lab for a strong engineer. If you want to work on frontier models without a doctorate, RE is usually the open door, and the two roles sit side by side on the same problems.
Applied Scientist
"Can I take a research method and make it actually work on our problem, at our scale?"
What you own
- Framing a business problem as a tractable modelling problem — the step where most of the value is won or lost.
- Method selection: reading what exists, choosing what fits the constraints, and adapting it rather than inventing from scratch.
- Evidence on both clocks — offline evaluation that predicts online behaviour, then the online test that confirms it.
- Getting it into production, either shipping it yourself or handing it over cleanly enough that it survives the handoff.
Technical skills
- ML fundamentals with genuine depth, plus the statistics to know whether a lift is real.
- Literature fluency — finding the method that already solves a version of your problem, and spotting the assumption that won't hold on your data.
- Real-data engineering: messy inputs, label noise, class imbalance, leakage, and distribution shift between training and serving.
- Experimental design across both offline metrics and online A/B tests, including when the two disagree.
- Enough production engineering to ship, or to write the handoff that doesn't get bounced back.
Soft skills that actually get screened
- Knowing when the simple method wins. The role's characteristic failure is spending six weeks on a method that beats logistic regression by half a point.
- Translating in both directions — turning a product manager's ask into a modelling problem, and a modelling result into something a business decision can rest on.
- Stopping at good enough. Research instincts pull toward the interesting question; the job rewards the one that moves the metric.
- Scoping honestly under pressure, including saying that the data available cannot support the accuracy someone has already promised.
Tools
PythonPyTorchscikit-learnSQLSparkSageMaker / Vertex AIWeights & BiasesA/B testing platformsDocker
Small project worth building
Take a published method somewhere it wasn't designed to go. Apply a recent paper's approach to a domain it didn't target, and compare it against a baseline you tuned as carefully as the method. The differentiator is the honest comparison: report the regime where the sophisticated method wins, the regime where the baseline is just as good, and the cost difference between them. That analysis is the applied-science skill — everything else is implementation.
The title is company-specific. "Applied Scientist" is used heavily at Amazon and Microsoft; at other companies the identical job is advertised as ML Engineer, Research Engineer, or Data Scientist. Judge by the responsibilities — if it says publish and invent, it leans Research Scientist; if it says ship and measure, it leans ML Engineer; Applied Scientist genuinely sits between the two and is expected to do both.
Research Engineer
"Can I make this experiment run — correctly, at scale, and fast enough to iterate?"
What you own
- The training stack: distributed runs, data loading at scale, checkpointing, and recovery when a node dies at hour thirty.
- Experiment velocity — the turnaround time between a researcher's idea and a result, which is the lab's real throughput metric.
- Reproducibility: same config, same seed, same result, months later and on different hardware.
- Performance: throughput per GPU, memory efficiency, and finding the bottleneck that makes a run 40% slower than it should be.
Technical skills
- Distributed training in depth — data, tensor, pipeline, and fully-sharded parallelism, and knowing which failure each one causes.
- Profiling and performance reasoning: reading a trace, spotting a stalled data loader, distinguishing memory-bound from compute-bound.
- Numerical debugging — loss spikes, NaNs, divergence at scale, and precision issues that only appear past a certain size.
- Genuinely strong software engineering. Research code rots fast; the RE is the reason it doesn't.
- Cluster reality: schedulers, GPU topology, interconnect, and the cost of a run before it starts.
Soft skills that actually get screened
- A service mindset. Your users are researchers, and your output is their productivity. Satisfaction has to come from someone else's result.
- Pushing back on an expensive run that has no hypothesis behind it — diplomatically, since the person proposing it is usually senior to you.
- Tolerating specification that arrives half-formed. "Try it with a different loss" is a complete request in this world, and you make it concrete.
Tools
PyTorchJAXFSDP / DeepSpeedSLURMKubernetesNCCLNsight / torch profilerWeights & BiasesCUDA (reading it)Docker
Small project worth building
Make one training script fast and reproducible. Take a single-GPU training script and scale it to multi-GPU with correct gradient synchronisation, deterministic seeding, and resumable checkpoints. The differentiator is the profile: publish tokens/second per GPU before and after, name the bottleneck you found, and show the fix. A number with a trace behind it is worth more than any amount of framework familiarity.
One system, seven roles
Role boundaries make far more sense against a single concrete project than in the abstract. Take one: a support-ticket triage assistant that routes incoming tickets and drafts a suggested first reply.
- Data Engineer lands tickets and historical resolutions in the warehouse on a freshness SLA, with quality tests — nothing downstream is possible until this is trustworthy.
- Data Analyst defines what "deflection rate" and "first response time" actually mean, and builds the baseline everyone will later argue about.
- Data Scientist asks whether automation is worth it at all, designs the offline evaluation and the A/B test, and quantifies the expected lift with an interval rather than a point.
- ML Engineer trains and serves the routing classifier, owns its latency and drift, and wires up retraining.
- AI Engineer builds the LLM layer — retrieval over past resolutions, draft-reply generation, guardrails, the eval harness, and the cost per ticket.
- Forward Deployed Engineer pilots it inside the largest customer's environment, discovers their taxonomy has sixty categories rather than eight, and brings that back before it becomes a churn event.
- TPM sequences all of it, spots that the model can't ship until the backfill completes, and runs the launch review.
Notice who isn't on this project: the two research roles. That absence is the most useful thing this scenario shows about them. The Research Scientist and Research Engineer produced the routing architecture and the training recipe that the ML Engineer is fine-tuning — one to three years earlier, on a different clock, measured by a different output. Research is upstream of the product, not a stage within it.
The practical consequence for a job search: if what you enjoy is watching something you built get used next quarter, research will feel slow and disconnected. If what you enjoy is the open question itself and you can wait years to see it land, product roles will feel like they never let you go deep enough. Both are honourable answers, and picking the wrong one is the most common reason people are unhappy a year into an otherwise good job.
Where the overlaps genuinely are. AI Engineer and ML Engineer overlap on serving. Data Scientist and Data Analyst overlap on analysis — the honest distinction is inference versus reporting, not seniority. Data Engineer and Analytics Engineer overlap almost entirely at some companies. A Lead AI Engineer would own the technical direction across the AI parts of this project without owning a stage of it. Research Engineer and Research Scientist overlap on the experiment itself — the split is who chooses the question versus who makes it runnable, and at smaller labs one person does both. If a job description spans two of these, it usually means the team is small and you'll do both, which is excellent for learning and worth asking about directly.
Choosing between them
A rough decision guide, phrased as what you'd rather be doing on a Wednesday afternoon:
- Chasing down why the number is wrong → Data Analyst or Data Engineer.
- Arguing about whether the effect is real → Data Scientist.
- Making something run faster and not fall over → ML Engineer.
- Getting a model to behave in a product → AI Engineer.
- Sitting with a customer while their system misbehaves → Forward Deployed Engineer.
- Finding out that two teams have been assuming different launch dates → TPM.
- Wanting the call to be yours, and being at peace with writing less code → Lead AI Engineer.
- Making a 400-GPU run finish before the weekend → Research Engineer.
- Being genuinely unsure whether the idea will work at all → Research Scientist.
- Wanting research depth but needing to see it used → Applied Scientist.
Things that hold across all twelve
- Ship something end to end and write about it. One finished, documented, honestly-evaluated project beats five tutorial repositories — in every one of these roles.
- Numbers on your resume, not adjectives. "Cut p99 latency from 2.4s to 700ms" carries; "optimised system performance" does not.
- Have the failure story ready. Every interview loop asks. The strong answer names your own mistake, the diagnosis, and what you changed afterwards.
- SQL is the common denominator. Six of the twelve use it regularly (the research roles least of all); being genuinely good at it is unusually high leverage per hour invested.
- Read the responsibilities, then ask what the last person did all week. It is the single most informative question available to you in an interview, and few candidates ask it.