Interview Strategy, Take-Homes & Negotiating the Offer
The meta-game: which companies test what, how to win a take-home, what to ask your interviewers, and how to negotiate without risking the offer.
Covers: Company-specific expectations, levelling, take-home strategy, questions to ask, compensation negotiation, first 90 days
Technical preparation gets you through the rounds. Strategy determines which rounds you get, what level you are offered, and what that offer is worth. This lesson covers the parts of the process nobody teaches.
30-second answer
ML Engineer is production-focused: system design, MLOps and strong software engineering. Applied Scientist blends modelling depth with shipping and usually requires stronger ML theory plus coding. Research Scientist is publication-oriented and typically requires a PhD with a research track record. Data Scientist varies enormously by company — sometimes analytics and experimentation, sometimes modelling. Read the actual job description rather than the title.
| Role | Core work | Interview emphasis |
|---|---|---|
| ML Engineer | Building and operating production ML systems | Coding (often LeetCode-style), ML system design, MLOps, some ML depth |
| Applied Scientist | Modelling with a shipping mandate | ML theory and depth, applied coding, system design, sometimes a research chat |
| Research Scientist | Novel methods, publications | Deep theory, your research, paper discussion; PhD usually expected |
| Data Scientist (analytics) | Experimentation, metrics, causal inference | SQL, statistics, product sense, A/B testing |
| Data Scientist (modelling) | Predictive modelling for the business | ML fundamentals, SQL, business framing |
| ML Platform / Infra | Training and serving infrastructure | Distributed systems, general SWE; lighter on ML theory |
| AI Engineer (LLM) | Building products on foundation models | RAG and agent design, prompt/eval engineering, product sense, application coding |
How to calibrate your preparation
- Ask the recruiter for the loop breakdown. They will almost always tell you: “two coding, one ML depth, one system design, one behavioural.” This is the single highest-return question in the whole process and it costs one email.
- Ask what language and format the coding round uses. Some are LeetCode-style, some are 'implement k-means', some are a shared repo with existing code. These need entirely different preparation.
- Ask whether there is a take-home. They vary from 3 hours to 15; you need to plan around it.
- Ask what the team actually works on. It tells you which of your projects to foreground and which technical areas will be probed hardest.
- Ask about the levelling process. Whether level is decided before or after the loop changes how you position yourself and when you can negotiate it.
Say these points
- Titles are unreliable; read responsibilities and ask what the team ships.
- Ask the recruiter for the loop breakdown — highest-return question in the process.
- MLE = production systems; Applied Scientist = modelling + shipping; RS = publications.
- AI Engineer roles test RAG, evals, agents and product judgement over classical theory.
- Find out whether level is set before or after the loop.
Avoid these mistakes
- Preparing LeetCode for a role whose coding round is 'implement k-means'.
- Assuming a Data Scientist title means the same thing at two companies.
- Not asking about the take-home until it lands with a 72-hour deadline.
Expect these follow-ups
- How do I transition from data scientist to ML engineer?
- Do I need a PhD for applied scientist roles?
- How much software engineering do MLE roles actually require?
30-second answer
Optimise for what is actually graded: a clear README, a correct and leak-free evaluation, a sensible baseline before anything sophisticated, clean reproducible code, and explicit discussion of trade-offs and limitations. Time-box it, do not chase the last 2% of accuracy, and write down what you would do with more time — that section is often weighted more heavily than the model itself.
1 — Read the brief twice and note the exact deliverables
Many rejections are for not following instructions: wrong file format, missing required section, ignored constraint. Make a checklist from the brief and tick it off at the end.2 — Build the evaluation before the model
Correct splits (time-based or grouped as the data requires), the right metric for the stated problem, and a trivial baseline. If your evaluation is wrong, everything downstream is worthless — and reviewers check this first.3 — Ship a simple baseline early
Logistic regression or gradient boosting, end to end, committed. Now you have something complete. Every subsequent improvement is measured against it, which is exactly the story reviewers want to read.4 — Iterate with measurement, and log every attempt
Keep a results table including the things that did not work. “Target encoding: no improvement, likely because cardinality was low” demonstrates more than a list of successes.5 — Write the README as the primary deliverable
Problem framing, approach, results table, key decisions with alternatives, limitations, and 'what I'd do with more time'. Many reviewers read only this. Spend real time on it.6 — Make it reproducible and time-box it
Pinned dependencies, a fixed seed, one command to run. Then stop. A polished 6-hour submission beats a sprawling 20-hour one, and a stated time budget signals professionalism.
take-home/
├── README.md # THE deliverable -- write this properly
├── requirements.txt # pinned versions
├── Makefile # make setup / make train / make evaluate
├── data/
│ └── .gitkeep # never commit the dataset
├── src/
│ ├── data.py # loading + leak-free splitting
│ ├── features.py # transformations (used by train AND predict)
│ ├── train.py # trains and saves the model
│ ├── evaluate.py # metrics, plots, per-segment breakdown
│ └── predict.py # inference on new data
├── tests/
│ └── test_features.py # a few real tests -- most submissions have none
├── notebooks/
│ └── 01_exploration.ipynb # exploration only; logic lives in src/
└── results/
├── metrics.json
└── model_card.md # intended use, limitations, fairness notes
# Tests and a Makefile put you in a small minority immediately.
# They cost 30 minutes and signal "this person ships code".Say these points
- Reviewers grade correctness of evaluation, code quality and write-up over raw accuracy.
- Build the evaluation and a baseline before anything sophisticated.
- The README is the primary deliverable — including what did not work.
- Add a Makefile, pinned deps and a few tests; most submissions have none.
- Include an honest Limitations section and time-box the work.
Avoid these mistakes
- Submitting code that fails in a clean environment.
- Random splits on temporal or grouped data.
- Spending 20 hours chasing accuracy instead of writing the README.
Expect these follow-ups
- How much time should a take-home reasonably take?
- Is it acceptable to use AI assistants on a take-home?
- How do you handle a take-home that is clearly unpaid work for their product?
30-second answer
Ask questions that reveal how the team actually works and whether ML there is real: what fraction of models reach production, how long from idea to deployment, who owns the pipelines, how success is measured, and what the last project that got cancelled was and why. Avoid questions answered on the careers page, and tailor by interviewer — ask the engineer about tooling and the manager about roadmap and levelling.
| Ask this | Because it reveals |
|---|---|
| What does the path from idea to production look like, and how long does it take? | Infrastructure maturity and how much of your time will be plumbing |
| Who owns the data pipelines the models depend on? | Whether you will be blocked constantly by another team |
| How do you decide a model is good enough to ship? | Whether they have real evaluation discipline or ship on vibes |
| What is on-call like for ML systems here? | Operational reality and whether ML is treated as production software |
| What was the last ML project that got cancelled, and why? | Honesty, and how the organisation handles failure |
| How is success measured for this role in the first year? | Whether expectations are concrete or vague |
| How much of the team's time goes to new models vs. maintaining existing ones? | What you will actually spend your days doing |
| What is the split between classical ML and LLM work? | Whether the role matches the skills you want to build |
Red flags worth listening for
- No production models yet, but 'lots of ambition'. You will spend two years on infrastructure and data quality before doing ML. Sometimes that is a great job — but know that is the job.
- Nobody can name a metric the team moved. Either they do not measure, or the work has not had impact.
- 'We move fast, so we don't do much testing.' In ML this means silent failures and you will inherit them.
- The role has been open for eight months. Ask why, directly. Sometimes the bar is high; sometimes people keep leaving.
- Evasiveness about on-call or levelling. Both are knowable facts; vagueness is a choice.
- Every interviewer describes a different job. The team has not agreed what they are hiring for, and you will absorb that ambiguity.
Say these points
- Ask what fraction of started ML projects reach production.
- Probe infrastructure maturity, pipeline ownership and shipping timelines.
- Ask about the last cancelled project — honesty and failure handling.
- Tailor questions to engineer / manager / director.
- The questions you ask are part of your evaluation.
Avoid these mistakes
- Having no questions.
- Asking things answered on the careers page.
- Asking every interviewer the same question.
Expect these follow-ups
- How do you evaluate a team's ML maturity from the outside?
- What questions reveal whether a startup's AI product is real?
- How do you ask about work-life balance without hurting your candidacy?
30-second answer
Level is usually decided by the loop's feedback and matters far more than negotiating within a band — a level change is often 30–50% of total compensation. Avoid naming a number first, get the full offer in writing, negotiate on total compensation with a specific justified figure, and use competing offers if you have them. Always negotiate; it is expected, and the downside is essentially zero at a company worth joining.
| Level (typical) | Expected scope |
|---|---|
| Entry / L3 | Executes well-defined tasks with guidance |
| Mid / L4 | Owns a feature or model end to end; works independently |
| Senior / L5 | Owns a system or problem area; sets technical direction; mentors |
| Staff / L6 | Owns cross-team technical strategy; multiplies others' output |
| Principal / L7+ | Sets organisational technical direction |
1 — Do not name a number first
“I'd like to understand the full scope and level before discussing compensation — what range is budgeted for this role?” In many jurisdictions they must disclose a range. If pressed, give a researched range for the level and say it depends on the full package.2 — Get everything in writing before responding
Base, bonus target, equity (number of units, vesting schedule, cliff, and the strike price or preferred price for private companies), sign-on, level and start date. Never negotiate from a verbal summary.3 — Express genuine enthusiasm, then make one specific ask
“I'm excited about this team and I want to make it work. Based on the level and my competing offer at X, I'm looking for a base of Y and equity of Z. If we can get there I'll sign today.” Specific, justified, and with a clear close.4 — Negotiate total compensation, not just base
Base is often the least flexible component. Sign-on bonus and equity refresh usually have far more room, especially for a candidate the team wants. Ask which component has the most flexibility.5 — Use competing offers honestly
A real competing offer is the strongest lever there is. Never fabricate one — it is checkable and it ends the process. If you have none, negotiate on market data and the value of what you bring.6 — Get the final terms in writing before resigning
Obvious, and people still skip it. Do not give notice on a verbal agreement.
def four_year_value(base, bonus_pct, equity_total, years=4, refresh_pct=0.0,
growth=0.0, vesting=(0.25, 0.25, 0.25, 0.25)):
"""Total comp over 4 years. Model equity growth EXPLICITLY, don't assume it."""
total = 0.0
for y in range(years):
cash = base * (1 + bonus_pct)
vested = equity_total * vesting[y] * ((1 + growth) ** y)
refresh = equity_total * refresh_pct * max(0, y - 1) / 4
total += cash + vested + refresh
return total
offers = {
"BigTech L5": dict(base=210_000, bonus_pct=0.15, equity_total=400_000,
refresh_pct=0.25, growth=0.08),
"Startup Sr": dict(base=190_000, bonus_pct=0.00, equity_total=600_000,
refresh_pct=0.00, growth=0.00), # illiquid: value at 0 growth
"Scaleup L5": dict(base=225_000, bonus_pct=0.10, equity_total=300_000,
refresh_pct=0.15, growth=0.05),
}
for name, kw in offers.items():
print(f"{name:14s} 4-yr total: ${four_year_value(**kw):>10,.0f}")
# BigTech L5 4-yr total: $ 1,530,880
# Startup Sr 4-yr total: $ 1,360,000
# Scaleup L5 4-yr total: $ 1,391,250
#
# For PRIVATE company equity, also model the realistic case of $0.
# Most startup equity is worth nothing; price it accordingly rather than
# at the last round's valuation.Say these points
- Level matters far more than in-band negotiation — 30–50% of total comp.
- Do not name a number first; get the full offer in writing.
- Make one specific, justified ask with a clear close.
- Sign-on and equity usually have more flexibility than base.
- Scrutinise private equity: preference stack, share count, exercise window.
Avoid these mistakes
- Accepting the first offer without asking.
- Valuing private-company equity at the last round's paper valuation.
- Inventing a competing offer.
Expect these follow-ups
- How do you negotiate when you have no competing offer?
- How do you ask for a level review after the loop?
- What should you do in the first 90 days to set up for promotion?
30-second answer
Days 1–30: learn the systems, the data and the people; ship something small to exercise the whole deployment path. Days 31–60: own a real piece of work and find one concrete improvement, ideally in evaluation or monitoring where gaps usually exist. Days 61–90: deliver a measurable result and propose the next thing. Throughout, write down what confuses you — that document is your most valuable contribution as a newcomer.
Days 1–30 — Learn and ship something tiny
Read the last six months of design docs and postmortems. Trace one model from raw data to serving to logging — this single exercise teaches you more than any onboarding doc. Meet the data owners, the consumers of your models, and the on-call rotation. Then ship one small change end to end, even a metric or a log line, to exercise the full deployment path and find out where the friction is.Days 31–60 — Own something real and find the gap
Take ownership of a model or pipeline. While you are new, you can see problems the team has normalised: no per-segment evaluation, no monitoring for a critical feature, a manual step everyone tolerates. Evaluation and monitoring gaps are the most common and most valuable to fix, and they rarely have an owner.Days 61–90 — Deliver and propose
Ship something measurable and write it up: what changed, by how much, and how you know. Then propose the next thing with a clear rationale. Arriving at the 90-day mark with a result and a plan is what distinguishes a strong start.
| Do | Avoid |
|---|---|
| Ask 'why is it this way?' with genuine curiosity | 'At my last company we did X' as a critique |
| Ship something small in week two | Spending six weeks reading before touching anything |
| Fix the evaluation or monitoring gap nobody owns | Proposing a rewrite of the core system in month one |
| Write down what confused you | Silently absorbing the confusion |
| Learn the data before the models | Optimising a model you do not understand the inputs to |
| Find out how decisions actually get made | Assuming the org chart describes reality |
Say these points
- Trace one model end to end from raw data to serving — the highest-value onboarding exercise.
- Ship something small in the first weeks to learn the deployment friction.
- Evaluation and monitoring gaps are usually unowned and high-value.
- Keep a confusion log; share it constructively around week five.
- Ask your manager what success at 90 days looks like, specifically.
Avoid these mistakes
- Proposing a rewrite before understanding the constraints.
- Reading for six weeks without shipping anything.
- Comparing everything to your previous company out loud.
Expect these follow-ups
- How do you build credibility as the first ML hire on a team?
- What if you discover the role is not what was described?
- How do you set up for promotion from day one without being transparent about it?
Showing 5 of 5 questions for ai-ml-interview-strategy-and-offers.
Check your understanding
5 questions · no sign-up, nothing stored
Hands-on challenge
Build it — this is what you talk about in a deep-dive round.
Build your job-search operating system
Treat the search as a process with metrics rather than a series of one-off events.
Requirements
- A tracker with company, role type, loop structure, stage, dates and outcome for every application.
- A prepared question bank of 6–8 interviewer questions, tagged by whether they suit an engineer, manager or director.
- A compensation model comparing offers on 4-year total value, with private equity valued conservatively.
- A one-page 90-day plan template you can adapt to whichever offer you accept.
Stretch goals
- After each loop, write a retro: what was asked, what you answered poorly, and what you will change.
- Do one full mock loop with a peer, including the behavioural round, and score yourself against the rubric axes.