A Field Guide to Machine Learning Research Interviews

Who this is for

If you are a late-stage PhD student, a postdoc, or a working researcher looking at Research Scientist or Research Engineer roles, this should be useful. The specifics lean toward machine learning and deep learning, but the structure transfers across subfields.

The single most important idea is this: getting interviews and passing interviews are two different skills. Your research record opens the door; a separate, entirely learnable skill set gets you the offer. Most strong researchers who stumble do so not because they lack knowledge, but because they never treated interviewing as its own discipline with its own preparation.

Getting interviews

If you are struggling to get interviews at all, the levers are the familiar ones: more first-author papers, work on topics people currently care about, and at least one industry internship. As a rough calibration, a few first-author papers at venues like NeurIPS, ICML, ICLR, CVPR, or AAAI, plus an internship, tends to make callbacks from strong labs reliable. Below that bar, you compensate with referrals and direct outreach.

Once you are getting interviews, more papers stop helping. The marginal hour is far better spent preparing, because the people interviewing you often will not have read your work in any detail. A few channels are worth understanding:

Where roles actually surface

Company career pages are the obvious route, but many research roles — and most internships — are announced on LinkedIn and X first, sometimes with the real application hidden behind a form linked from the post. Follow the researchers and recruiters at the labs you care about so these do not pass you by.

Referrals, cold emails, and materials

A referral is nice but rarely decisive; mostly it guarantees a human looks at your application. Ask a former collaborator if you have one, and do not agonize if you do not. A cold email is underrated for research roles: write to the hiring manager or a researcher whose agenda you would want to join, and make it specific — one concrete paragraph about their work and what you would contribute beats three paragraphs restating your CV. Finally, make yourself trivially easy to verify: a clean CV with your role and venue on each paper, a Google Scholar page, and a simple website that ties it together. A busy person should be able to confirm you are real and relevant in about thirty seconds.

Roles and companies

Two distinctions are worth getting straight before you apply, because they shape both the interview and the job.

Research Scientist vs Research Engineer

The line is blurry and lab-dependent. A Scientist typically owns research direction and publishes; an Engineer typically owns the infrastructure, scaling, and implementation that make the research possible — though strong Engineers co-author papers and shape direction too. The loops overlap heavily, and some labs will reroute a strong candidate from one track to the other. Unless you have a firm preference, applying with an open mind widens your options.

Big lab vs startup

A real trade-off, and “it depends” is the honest answer. Big labs offer a predictable process, a recognizable name on your CV, deep compute, and a lot of brilliant colleagues — but you are one of many, and direction is largely set above you. Startups offer ownership, faster growth, and sometimes more interesting and impactful work — alongside more variance in quality, more infrastructure work you did not sign up for, agendas that shift, and a brand you will have to explain later. Use the interview to probe: who sets research priorities? how is success measured? what is the compute budget? what happens if a frontier lab ships your idea next quarter? The answers reveal more than any recruiting pitch.

A note on compensation

When an offer leans heavily on startup equity, discount the headline number in your head until you understand how it actually works: vesting schedules, how each funding round dilutes your share, whether and when you could ever sell, and the tax treatment of options, which can land you a bill before you have seen any cash. Treatment varies significantly by country, and none of this is financial advice — but be skeptical of large numbers that depend on a private company’s future valuation, and ask precise questions before weighing them against cash.

The interview loop

Most processes follow a similar arc, though the weight on each stage varies a lot from one company to the next.

The recruiter screen is usually a low-stakes conversation that calibrates your level and checks basic fit. Be able to summarize your research in two minutes for a non-expert, and be clear about what you are looking for — recruiters route you, so help them route you well. The technical rounds are the bulk of the process: expect some combination of data-structures-and-algorithms coding, hands-on ML implementation and debugging, broad-and-deep ML knowledge, and occasionally an ML or system design round. A research deep-dive asks you to present and defend your own work and discuss where the field is going. Finally, behavioral rounds probe collaboration, conflict, failure, and motivation; they are lower-variance but not negligible, and unprepared answers do sink candidates. Ask your recruiter what each round will contain — they will almost always tell you.

Preparing: the technical loop

Here is the uncomfortable truth: being excellent at research does not automatically transfer to interview performance. Implementing multi-head attention while someone watches the cursor blink is a different skill from having published on attention. Budget at least four to six weeks of deliberate practice, and target most of it at the specific companies and rounds coming up rather than at generic preparation.

Coding (data structures and algorithms)

Work through a focused, finite set of problems rather than grinding endlessly — a curated list of the common patterns, then more medium-difficulty problems if you have time. Prioritize breadth of patterns over hard puzzles: arrays and hashing, two pointers, sliding window, stacks, trees, graph traversal, backtracking, binary search, heaps, intervals, and a working command of dynamic programming. Aim to solve a medium problem cleanly in around twenty minutes, at optimal time complexity, narrating as you go; a brute-force-only answer generally reads as a miss. The first fifty problems feel demoralizing and then it suddenly clicks — push through that wall.

ML implementation and debugging

This is often the highest-signal and least-practiced round. Be able to write, from scratch and under time pressure:

• a transformer block, end to end;
• self-, causal, and cross-attention;
• an MLP’s forward and backward pass;
• a minimal training loop in PyTorch or JAX;
• and, ideally, a memory-efficient attention variant.

The debugging variant is genuinely hard to fake. Practice it by taking working training code, breaking it on purpose, and re-finding the bug — or by reviewing your own old code for the classics: shape mismatches, the wrong reduction axis, a missing detach, train-versus-eval mode, a learning rate off by an order of magnitude, label leakage. Reps matter more here than cleverness.

ML knowledge (breadth and depth)

You will be tested broadly — overfitting, regularization, optimization, evaluation metrics — and deeply within your own area. Build your own notes or flashcards in your own words; the act of writing them is most of the learning. Aim to be able to derive rather than recall: if you can reconstruct the bias–variance decomposition, the VAE’s ELBO, or why normalization helps, you can survive the follow-ups. A topics map is at the end of this guide.

ML and system design

Less common, but real — especially for applied or engineering-leaning roles. Practice a structure: clarify the objective and constraints, propose the data and a simple baseline, choose a model, define evaluation and metrics, then discuss scaling, serving, and failure modes. A clear structure beats a clever model.

The research interview

Researchers routinely under-prepare for this round on the assumption that talking about their own work is automatic. It is not. Prepare a crisp account of one or two of your strongest projects at two depths: a two-minute version for a generalist, and a twenty-minute version that withstands an expert probing every design choice. Rehearse the transitions between them.

Expect questions like “why this choice and not the obvious alternative?”, “what would you do with ten times the compute?”, and “what is the weakest part of this work?” Knowing your own limitations cold reads as maturity, not weakness. Have a considered opinion on where your field is heading, and be willing to disagree thoughtfully — the interviewer is evaluating a future colleague, not an audience.

They are not checking whether you can present. They are checking whether they want to argue about research with you every week.

Mock interviews

Practice out loud, under realistic constraints. Solving a problem silently on paper is a different activity from narrating a solution while someone interrupts you. The gap between the two is exactly what the interview tests.

A large language model makes a tireless mock interviewer. Paste in the role description and the round type, ask it to interview you at the appropriate level, and ask it to critique your answers afterward. The overlap between good practice questions and real ones is often surprising, and the feedback loop is fast and free; if the difficulty feels off, restate your level and background explicitly and try again. Where you can, add a few mocks with peers — especially for coding and the research talk, where a human’s live follow-ups are hard to simulate.

Running the process

Treat the search as a campaign, and track it. A simple spreadsheet — companies, current stage, contacts, deadlines — prevents the avoidable losses: forgetting to follow up, missing an application form, letting a deadline quietly lapse. It is not sophisticated; it just works.

Sequence deliberately. Begin with the roles you care about least, to calibrate your confidence and warm up your answers, and aim to reach your top choices once you are sharp. Where possible, line up timelines so that offers arrive in roughly the same window — real leverage comes from holding genuine, concurrent options, not from one offer at a time. Do no more than one loop per day when you can manage it; interviews are draining and your third of the day is reliably your worst, so protect sleep and energy around them. And be transparent about your parallel processes: telling companies you are interviewing elsewhere is normal, keeps everyone’s timelines honest, often speeds things up, and signals that others already take you seriously.

Negotiation

Negotiating is expected, and skipping it leaves value on the table. Most offers have more room than candidates assume, and asking politely rarely costs anything. A few principles:

• Leverage comes from comparable alternatives. A competing offer from a true peer lab moves numbers in a way that a non-comparable one simply does not.
• Be straight about what would make the decision easy, whether or not you share exact figures. Some companies will ask for proof of competing offers; decide your comfort level with that in advance.
• Watch what you signal. Recruiters read enthusiasm accurately. If they already know you have decided in their favor, your leverage drops — warmth is fine, but showing your whole hand early is not.
• Respect the deadlines. They are often firmer than you would like and vary widely, from a week to “take your time.” Factor exploding offers into how you sequence everything.

Choosing an offer

There is no formula. Weigh what actually matters to you — the work, the people and your immediate manager, room to grow, location, compensation, the brand — and write those priorities down before offers arrive, while you can still think clearly. Day to day, the team and the manager usually matter more than the logo on the building.

Talk to as many of your would-be colleagues as you can, but remember that everyone recommends their own team, so weight concrete specifics over enthusiasm. Beware decisions driven by insecurity: accepting an early offer out of fear can foreclose better ones, while chasing marginal prestige can cost you a genuinely better fit. The process is noisy and partly luck; a rejection is not a verdict on your worth as a researcher. Once you have done the homework, trust your read.

A topics checklist

A non-exhaustive map of what gets asked. You will not be tested on all of it, but gaps inside your own subfield are the most dangerous, so cover those first. Organize your own notes around something like this.

Foundations and math. Linear algebra (eigen-decomposition, SVD, rank, positive semi-definiteness, the Jacobian and Hessian); probability (expectation, variance and covariance, common distributions, Bayes’ rule); optimization (convexity, gradient descent and SGD, momentum, Adam and AdamW, second-order methods); information theory (entropy, cross-entropy, KL and Jensen–Shannon divergence).

Core machine learning. Bias–variance, regularization, cross-validation, over- and under-fitting, evaluation (precision, recall, F1, ROC-AUC, calibration), the classic models (linear and logistic regression, SVMs, k-nearest neighbours, decision trees, bagging and boosting, k-means), dimensionality reduction (PCA), and MLE versus MAP.

Deep learning. Backpropagation, weight initialization, normalization (batch, layer, RMS), activation functions, vanishing and exploding gradients, CNNs, RNNs and LSTMs, autoencoders, and the attention mechanism and transformer architecture.

LLMs and sequence models. Tokenization, pre-training versus fine-tuning, RLHF and DPO, positional encodings (sinusoidal, relative, RoPE), efficient attention (such as flash attention), parameter-efficient fine-tuning (LoRA), mixture-of-experts, scaling laws, decoding strategies, and attention alternatives such as state-space models.

Generative modeling. GANs, VAEs and the ELBO, the score function, diffusion (forward and reverse processes, DDPM and DDIM, the SDE and ODE views), flow matching, and classifier-free guidance.

Reinforcement learning. Markov decision processes and the Bellman equations, value- versus policy-based methods, Q-learning and temporal-difference learning, policy gradients and actor–critic, PPO, exploration versus exploitation, on- versus off-policy, model-based RL and world models, and the link back to RLHF.

Systems and applied ML. Data and model parallelism (DDP, FSDP, tensor and pipeline parallelism), mixed-precision training, gradient checkpointing and accumulation, profiling and bottlenecks, numerical precision, and the practical differences between PyTorch and JAX.

Closing thoughts

The meta-point is the one worth keeping: interviewing is a separate, learnable skill stacked on top of research ability. Strong researchers who prepare for it deliberately do well; equally strong researchers who assume their record will speak for itself often do not. Prepare like it is a project, aim your preparation at the next concrete loop, practice out loud, and keep perspective — the process is stochastic, and one bad afternoon is not a referendum on you.

If this was useful, or you think something here is wrong, I’m at sunnygupta@iitb.ac.in.