How to Prepare for ML & LLM Engineering Interviews in 2026

An assistant calls March 15 “yesterday” on March 20. A practice interviewer asks what went wrong. Is the source stale? Did the prompt omit the current date? Did the model receive the right facts and still make the wrong comparison?

Knowing the vocabulary helps, but it doesn't answer those questions. You need to inspect evidence, make an assumption explicit, write or reason through a small test, and explain what the result establishes.

That is a productive way to prepare for ML and LLM engineering interviews: attempt representative work and use the failures to choose what to study. The representative work depends on the role. A serving-performance interview, a predictive-modeling discussion, and a research presentation deserve different preparation.

Confirm the interview before planning the study

Public hiring guides can help you ask better questions, but they don't specify your personal interview schedule. As checked on October 10, 2026:

• OpenAI says assessments vary by team and may include pair coding, take-home projects, or technical tests. Its guide emphasizes design, code quality, performance, and test coverage for engineering interviews.^{[1]Reference 1Interview guidehttps://openai.com/interview-guide/}
• Anthropic says technical interviews use live coding tools such as Colab and CodeSignal, and advises familiarity with basic syntax and standard libraries.^{[2]Reference 2Careershttps://www.anthropic.com/careers}
• Anthropic's separate AI-use guidance permits preparation with AI but says take-homes and live interviews should be completed without it unless explicitly allowed. OpenAI likewise says tool permissions vary by interview.^{[3]Reference 3Guidance on Candidates' AI Usagehttps://www.anthropic.com/candidate-ai-guidance[1]Reference 1Interview guidehttps://openai.com/interview-guide/}

Don't infer that web lookup, autocomplete, or an AI assistant is permitted because the employer builds AI products. Ask the recruiter what is allowed. If instructions conflict or are unclear, resolve that before the assessment.

Write down the answers to a few practical questions:

You can start studying before every answer arrives. Just label what is confirmed and what you're assuming.

Match practice to the work, not the title

Use the posting's responsibilities to choose a baseline exercise. The table below contains suggested practice, not a claim that every employer asks these questions.

Roles overlap. A product engineer may need statistical judgment; a research engineer may spend much of the day debugging distributed code. What Does an AI Engineer Actually Do? covers those distinctions. The posting and recruiter should determine where you go deep.

Make one baseline attempt before filling a calendar with reading. Use the expected interview duration if you know it. Work without hints during the attempt, then review the code, notes, or recording. Separate gaps in knowledge from gaps in execution. Forgetting a library method, choosing an invalid data split, and failing to explain an assumption need different repairs.

Practice diagnosis without pretending to know the cause

Here is an invented debugging exercise you can use with a peer. It isn't an interview question attributed to an employer or a measured model run.

A user asks, “Was INC-4829 resolved yesterday?” The test harness says the request time is 2026-03-20T12:00:00Z and the reporting timezone is UTC. The authoritative status record has resolved_at=2026-03-15T18:02:00Z. The captured model input contains that record but no reference time. The assistant answers, “Yes, it was resolved yesterday.”

Under the stated UTC convention, yesterday is March 19, so the answer is wrong. The missing reference time is also a concrete input defect. Those observations do not prove that adding a clock will eliminate every wrong answer. The model might still misinterpret the record, ignore the clock, or invent another claim.

A careful investigation asks for different evidence at each stage:

For an exact incident ID, a keyed status lookup may be preferable to semantic retrieval. If a search is used, rank matters through what gets selected and presented; rank one isn't a universal correctness requirement.

Propose a controlled replay: keep the record, model, and other instructions fixed, supply the trusted reference time and timezone, and inspect the response. A passing replay supports that repair for the case. It doesn't establish reliability across incidents, and a failing replay means another problem remains. Also test the behavior when the reference time is unavailable: an explicit limitation is better than a guessed relative date.

In a live discussion, you can say: “I found a missing input. I'll repair and test it first. I haven't yet shown it's the only cause.” That is more precise than presenting the first suspicious component as a completed diagnosis.

Turn the date question into a small coding exercise

The debugging problem has a deterministic core: whether a known resolution timestamp falls on the previous calendar day. Practice implementing that rule without asking a model to do date arithmetic.

Clarify the contract first. Here, both timestamps must include UTC offsets. “Yesterday” is the previous calendar date in the chosen reporting timezone, not simply an elapsed interval of 24 hours. Missing timestamps return None, meaning insufficient information. Malformed or offset-free timestamps raise an error.

Python distinguishes timezone-aware from naive datetimes; zoneinfo supplies IANA timezone rules.^{[4]Reference 4datetime: Basic date and time typeshttps://docs.python.org/3/library/datetime.html[5]Reference 5zoneinfo: IANA time zone supporthttps://docs.python.org/3/library/zoneinfo.html} This example uses Python 3.11 or newer. zoneinfo needs system timezone data or the tzdata package installed in the environment.

from datetime import datetime, timedelta
from zoneinfo import ZoneInfo

def resolved_yesterday(
    resolved_at: str | None,
    reference_time: str | None,
    zone_name: str = "UTC",
) -> bool | None:
    if resolved_at is None or reference_time is None:
        return None
    resolved = datetime.fromisoformat(resolved_at)
    reference = datetime.fromisoformat(reference_time)
    if resolved.utcoffset() is None or reference.utcoffset() is None:
        raise ValueError("Timestamps must include a UTC offset")
    zone = ZoneInfo(zone_name)
    resolved_day = resolved.astimezone(zone).date()
    yesterday = reference.astimezone(zone).date() - timedelta(days=1)
    return resolved_day == yesterday

resolved = "2026-03-19T23:30:00Z"
reference = "2026-03-20T01:00:00Z"
assert resolved_yesterday(resolved, reference, "UTC") is True
assert resolved_yesterday(resolved, reference, "America/Los_Angeles") is False
assert resolved_yesterday("2026-03-15T18:02:00Z", reference) is False
assert resolved_yesterday(resolved, None) is None
assert resolved_yesterday(None, reference) is None
assert resolved_yesterday("2024-02-29T12:00:00Z", "2024-03-01T12:00:00Z") is True
fall_resolution = "2026-11-01T00:30:00-07:00"
fall_reference = "2026-11-02T00:15:00-08:00"
assert resolved_yesterday(fall_resolution, fall_reference, "America/Los_Angeles") is True
elapsed = datetime.fromisoformat(fall_reference) - datetime.fromisoformat(fall_resolution)
assert elapsed.total_seconds() == 24 * 3600 + 45 * 60
for malformed in ["not-a-timestamp", "2026-03-19T23:30:00"]:
    try:
        resolved_yesterday(malformed, reference)
    except ValueError:
        pass
    else:
        raise AssertionError("Invalid timestamp was accepted")
print("UTC:", resolved_yesterday(resolved, reference, "UTC"))
print("Los Angeles:", resolved_yesterday(resolved, reference, "America/Los_Angeles"))
print("Missing clock:", resolved_yesterday(resolved, None))
print("Fall transition: yesterday, despite 24 hours 45 minutes elapsed.")
print("9 calendar-day cases passed.")

UTC: True
Los Angeles: False
Missing clock: None
Fall transition: yesterday, despite 24 hours 45 minutes elapsed.
9 calendar-day cases passed.

The timezone follow-up tests whether your implementation follows its definition. It doesn't require memorizing that day's UTC offset: the timezone library handles the conversion.

The added November case crosses the Los Angeles fall clock change. Resolution was on November 1 locally, and the reference date is November 2, so the answer is true. Yet 24 hours and 45 minutes elapsed between the two offset-aware timestamps. A rule that accepts only the last 24 hours would give the wrong answer. Calendar dates and durations are different contracts.

This function isn't a grader for arbitrary natural-language answers. Searching for the word “yesterday” would flag both “resolved yesterday” and “not resolved yesterday.” Keep the structured date decision separate from how the assistant phrases it. Nor does this function verify source freshness, incident identity, or an incident's full history; those belong to other checks.

To extend the exercise, test a month boundary, the spring daylight-saving transition, a future timestamp, and a missing reporting timezone. Discuss whether the API should reject, abstain, or choose a documented default. Make that choice before changing the code. AI Lab Coding Interview: Python Systems provides broader stateful coding practice.

For classical ML, make the prediction time explicit

A separate practice prompt: predict, when an incident opens, whether it will escalate within 24 hours. You receive historical incident rows with an opening timestamp, customer ID, initial severity, final resolution code, and escalation outcome.

Before choosing an algorithm, identify what the model could know at opening time. The initial severity may be available. The final resolution code is not. Including it creates leakage: information from beyond the prediction boundary enters training or evaluation. Feature selection and preprocessing must also be fitted without using held-out data.^{[6]Reference 6Common Pitfalls and Recommended Practices: Data Leakagehttps://scikit-learn.org/stable/common_pitfalls.html#data-leakage}

Next ask what deployment you are trying to represent:

• Future incidents from existing customers: use a time-based evaluation that respects feature and label availability. For a 24-hour label, don't train on examples whose outcome would still be unknown at the simulated training cutoff.
• Previously unseen customers: hold customers out as groups so the same customer's incidents don't appear on both sides merely through a random row split.
• Future incidents from new customers: the evaluation may need both time and group restrictions. One splitter's name doesn't solve both constraints automatically.

Scikit-learn documents why dependent groups and time-ordered observations need different cross-validation strategies.^{[7]Reference 7Cross-validation: evaluating estimator performancehttps://scikit-learn.org/stable/modules/cross_validation.html} The important interview move is to explain what population your test estimates, not to name GroupKFold or TimeSeriesSplit without a deployment story.

Then choose a baseline and a metric tied to a decision. If humans can inspect only a fixed number of incidents, discuss how many true escalations the review queue captures and how much unnecessary work it creates. If probabilities determine action thresholds, discuss calibration too. State the class prevalence and error costs before celebrating accuracy.

A useful follow-up is: “Our score fell after removing the final resolution code. Did the model get worse?” The earlier result was invalid for the stated prediction time. A lower honest estimate is more informative than a higher score from unavailable information. Validation and Leakage develops this reasoning.

For systems work, put numbers beside the diagram

Practice a design in enough detail that another person can challenge it. For a support assistant, clarify who can read which records, how fresh they must be, whether a slow answer is acceptable, and what happens when evidence is missing. Trace one request before adding caches, agents, or another database.

Use small, explicit estimates. Suppose one illustrative request spends 120 ms fetching records, 80 ms assembling context, and 900 ms generating a response, sequentially. Its total is 1,100 ms. Removing 40 ms of assembly work saves about 3.6% for that request; it doesn't make generation disappear. Those are assumed timings, not benchmark results or a service-level percentile.

A good follow-up changes a constraint: “Now ten users arrive together,” or “The records must reflect a change made one second ago.” Explain which parts of the design need new measurements. A latency estimate for one request doesn't establish throughput under load; a cache that improves response time may violate freshness unless invalidation and staleness are defined.

For ML serving or training roles, use the same habit with a concrete workload: model and precision, input lengths or batch shape, hardware, concurrency, and the measurement interval. Inspect a profile before deciding that compute, memory, networking, or data loading is the bottleneck. Keep quality and workload comparable when claiming a speedup.

AI Lab System Design Interview covers the design discussion. If the role needs inference depth, use Inference: TTFT, TPS & KV Cache to connect a request trace to model execution. Don't study a new serving technique merely to add its name to your answer.

Rehearse follow-ups and personal ownership

A polished opening answer is only part of preparation. Ask a peer to interrupt, change a constraint, or challenge the evidence. You can also use an AI assistant for rehearsal when appropriate, but its praise isn't evidence that your claim is correct.

Prepare project stories from work you actually did. Explain the original problem, your responsibility, the alternatives considered, and the result you can support. Separate your contribution from the team's. If a metric wasn't measured, don't invent one to improve the story.

For the date example, useful questions include:

• Why did you inspect the model input before changing retrieval?
• What would show that the clock fix didn't solve the problem?
• Why is a calendar-day comparison different from a duration check?
• What remains outside the helper function's contract?
• Which parts of the investigation did you personally implement?

For a research project, replace the date details with hypotheses, controls, baselines, uncertainty, and alternative explanations. Be ready to describe a negative result or a decision you changed. AI Lab Behavioral Interview and AI Lab Technical Presentation provide longer practice formats.

Build a study schedule from the review

After an attempt, write three short notes: what failed, what evidence showed it, and the next exercise. “Study RAG” isn't specific enough. “The selected record was correct, but I never inspected the submitted messages” points to a debugging drill. “I couldn't explain why customers crossed the train/test split” points to validation study.

Spend the next session repairing that gap, then try a variation you haven't memorized. A repeat of the original problem is a regression check. A changed timezone, new data dependency, or different workload tests whether you learned the underlying idea.

Choose a schedule you can sustain. If the interview is close, prioritize confirmed rounds and weaknesses exposed by practice instead of starting a comprehensive course. If the foundations are missing, allow time to build them. No fixed four-week or eight-week plan can account for every starting point or hiring bar.

Use 50 LLM Interview Questions for 2026 to sample gaps, not as a script to memorize. Cover an answer, attempt it, and follow the explanation into code or a concrete example. Stop adding topics long enough to see whether your existing knowledge survives a follow-up.

The next useful step is one representative attempt under known constraints. Review it honestly, repair a specific weakness, and try again on a new case. That won't guarantee an offer, but it will tell you much more about your preparation than another unchecked list of topics.