Prepare for AI/ML Interviews Systematically

The four dimensions of AI/ML interviews

Most people prepare for AI/ML interviews by doing one of two things: either grinding LeetCode coding problems, or cramming flashcards about neural networks. Both are incomplete. A real AI/ML interview—especially one for a substantive role—tests four different capabilities, and being strong in only one makes you fragile.

Dimension 1: Conceptual/theory. Interviewers ask: "Explain backpropagation," "Why do transformers use attention?", "What's the bias-variance trade-off?" These test whether you understand why models work, not just that they do. Without this, you'll cargo-cult model choices and miss obvious bugs.

Dimension 2: Coding/implementation. "Write me a function to compute softmax," "Implement k-nearest neighbors from scratch," "Debug this code that's silently producing NaNs." These test whether you can translate theory into working code, handle edge cases, and troubleshoot. This is where most interview prep concentrates—and it's necessary, but not sufficient.

Dimension 3: Applied ML case study. "Here's a dataset of customer churn. Design an ML system to predict it," or "We need to rank search results by relevance. Walk me through your approach." These test your engineering intuition: Can you scope a problem, choose metrics, sketch a pipeline, and think through deployment? This dimension almost never appears in LeetCode-style preparation, and it's where many technically strong candidates stumble.

Dimension 4: Behavioral/project deep dive. "Tell me about a project where you failed," "Walk me through the most complex model you've built—why did you choose it?", "How do you approach a problem you've never seen before?" These test your judgment, maturity, and learning ability. Your portfolio pieces and learning logs from earlier lessons are directly useful here.

Most candidates who fail interviews do so not because they can't code or don't know theory, but because they're weak in dimension 3 or 4—and they only discover this weakness mid-interview when they're asked to design a system, not implement a function.

Assess your current readiness

Before you start intensive interview prep, diagnose where you actually need work. Create a readiness matrix:

Be honest with yourself. If you rate yourself 1-2 on conceptual knowledge but 4-5 on coding, you're going to walk into the interview confident about LeetCode, then get blindsided when they ask you to reason about model behavior, not just write a function.

For each dimension where you score 1-3, design a 2-week mini-prep cycle (reusing the four-week cycle structure from earlier in this course).

Interview question types by company and role

Different companies and roles emphasize different dimensions. Use this table to tailor your prep:

| Company type | Role | Emphasis | Sample questions | |---|---|---|---| | FAANG (Google, Meta, Apple) | ML Engineer | All four: 30% theory, 30% coding, 25% systems, 15% behavioral | Explain backpropagation. Implement attention. Design a recommendation system. Tell me about a technical failure. | | Research labs (DeepMind, Anthropic, OpenAI) | Research Scientist | Heavy theory (50%), some coding (30%), less systems (15%), some behavioral (5%) | Derive the loss function for VAEs. Reproduce paper results. Why do transformers scale better than RNNs? | | Startups / early-stage | ML Engineer | Light theory (10%), heavy coding (40%), heavy systems (40%), behavioral (10%) | Build a quick prototype. Design an ML pipeline for a new product. Solve this LeetCode problem. | | Tech giants (AWS, Azure ML) | ML Platform Engineer | Moderate theory (20%), heavy coding (40%), systems (30%), behavioral (10%) | Design a distributed training system. Implement a feature store. Debug this TensorFlow code. | | Finance / quant | ML Researcher or Quantitative Developer | Theory (35%), coding (35%), systems (20%), behavioral (10%) | Explain maximum likelihood estimation. Implement gradient descent. Why does this trading model overfit? |

Your target company and role determine which dimensions to emphasize in prep. If you're interviewing at a startup, spending 4 weeks on theoretical papers is inefficient; spend 2 weeks and invest the other 2 in coding and system design.

Dimension 1: Conceptual prep (if you scored 1-3)

The goal of conceptual prep is to move from "I memorized the formula" to "I understand why this works and when it fails."

Week 1 orientation: Pick a canonical paper or textbook chapter in your target area (transformers, representation learning, etc.) and skim it. Note down the questions that confuse you.

Week 2 guided repetition: Watch a lecture series (MIT Deep Learning, Andrew Ng's Machine Learning Specialization) on the same topic. Pause and rewind frequently. Maintain a glossary: for every concept that confused you in week 1, write a one-sentence explanation in plain language.

Week 3 variation: Teach the concept to someone else—a colleague, a friend, or even your rubber duck. Your goal: explain it in 3 minutes without jargon. Record yourself. Watch it back. Cringe. Rewrite. Repeat.

Week 4 delivery: Write a short blog post (500 words) or create a 5-minute YouTube video explaining the concept. If you can explain it clearly to strangers, you can explain it calmly in an interview.

Sample conceptual questions to practice

Here's a real question bank. For each, first write down your answer (2-3 minutes), then check a reference.

## Transformers & Attention

1. Explain attention in one sentence. Why is it better than a fixed context window?
2. What's the difference between self-attention and cross-attention? Give an example where each is used.
3. Why do transformers have multiple attention heads? What happens if you only have one?
4. How does positional encoding work? Why not just use word position 1, 2, 3, ...?
5. Transformer models can process very long sequences, but latency scales with sequence length. Why? What are practical solutions?

## Loss functions & Optimization

1. Explain cross-entropy loss. Why is it better than MSE for classification?
2. Why does gradient descent sometimes get stuck? Name three failure modes and a fix for each.
3. What's the difference between batch gradient descent and stochastic GD? When would you use each?
4. Momentum, Adam, RMSprop—when do you use each optimizer and why?
5. What does regularization (L1/L2) do to the loss landscape?

## Model evaluation

1. You have an imbalanced dataset (95% class A, 5% class B). Accuracy is 95%. Is this good?
2. When would you use precision vs. recall vs. F1? Give a real example for each.
3. Why do you need both training and validation sets? Why not just report test accuracy?
4. What's overfitting? How do you detect it? How do you fix it?
5. You train a model on data from January–June. You test on July data. You get 85% accuracy in July. But by December, accuracy drops to 70%. What happened?

Dimension 2: Coding prep (if you scored 1-3)

LeetCode is useful, but for AI/ML interviews, focus on domain-relevant coding:

• Implement algorithms from scratch in NumPy or PyTorch, not just LeetCode strings/arrays.
• Examples: softmax, cross-entropy loss, gradient descent, k-means, basic CNN forward pass, attention mechanism.
• Spend 50% of your time writing code, 50% tracing through the code by hand to understand what each line does.
• When you write a function, test it on edge cases: what happens with NaN inputs? Division by zero? Empty arrays?

Quick prep routine (15 min/day):

• Day 1: Implement one algorithm from scratch, no looking at solutions.
• Day 2-3: Write test cases for it.
• Day 4: Trace through your implementation by hand on a small example.
• Day 5: Look at a reference implementation; what would you do differently?

Sample coding problems to practice

# 1. Implement softmax
def softmax(logits):
    """
    Args: logits (array of shape [N,]) — raw model outputs
    Returns: probabilities (array of shape [N,]) summing to 1
    """
    # Numerically stable version (subtract max to avoid overflow)
    pass

# Test:
# softmax([1, 2, 3]) should return roughly [0.09, 0.24, 0.67]
# softmax([0, 0, 0]) should return [0.33, 0.33, 0.33]


# 2. Implement cross-entropy loss
def cross_entropy_loss(predictions, labels):
    """
    Args:
      predictions (array of shape [N, C]) — softmax probabilities for N samples, C classes
      labels (array of shape [N,]) — true class index for each sample
    Returns: scalar loss (average over batch)
    """
    pass

# Test:
# Perfect prediction (label=0, pred=[1.0, 0, 0]) should return 0
# Random guess (label=0, pred=[0.33, 0.33, 0.34]) should return ~1.1


# 3. Implement L2 regularization + gradient descent
def gradient_descent_with_l2(weights, gradients, learning_rate, l2_lambda):
    """
    Apply one step of gradient descent with L2 regularization.
    L2 regularization: adds l2_lambda * ||weights|| to loss
    """
    pass

# 4. Implement k-means clustering from scratch
def kmeans(X, k, num_iterations=10):
    """
    Args: X (array of shape [N, D]) — N samples, D features
          k (int) — number of clusters
    Returns: cluster_assignments (array of shape [N,]) and centroids (array of shape [k, D])
    """
    pass


# 5. Implement confusion matrix
def confusion_matrix(predictions, labels, num_classes):
    """
    Args: predictions, labels (arrays of shape [N,])
    Returns: 2D matrix of shape [num_classes, num_classes]
             where matrix[i,j] = number of samples predicted as j but true label is i
    """
    pass

# Then compute precision, recall, F1 from the confusion matrix
def precision_recall_f1(cm):
    """Args: confusion matrix"""
    pass

Dimension 3: Applied case study prep (if you scored 1-3)

This is where most people have the biggest gap. Case study interviews test your engineering judgment: Can you handle ambiguity, ask clarifying questions, scope a problem, and think through a pipeline end-to-end?

Structure for a case study interview

Start by asking clarifying questions (don't jump straight into modeling):

• "What's the business goal here? (Minimize false positives? Maximize accuracy? Minimize latency?)"
• "What data do I have? How much? How stale?"
• "What are the constraints? (Budget, latency, interpretability, fairness?)"

Then walk through your approach in this order:

1. Problem framing: "This is a binary classification problem, so I'd measure precision/recall, not just accuracy, because false positives have a different cost than false negatives."
2. Baseline: "I'd start with a simple baseline—logistic regression—to set a performance floor, so I know when I'm actually improving."
3. Feature engineering: "I'd engineer features for [obvious domain features], then look for interactions or temporal patterns."
4. Model selection: "I'd start with something interpretable (decision tree, linear model) because we need to explain decisions to stakeholders, not just predict."
5. Evaluation and iteration: "I'd use cross-validation on the training set, then evaluate on a holdout test set. If performance is poor, I'd debug: Is this a data quality issue? A feature issue? A model capacity issue?"
6. Deployment considerations: "At scale, I'd monitor for data drift. If the distribution of new data changes, old models degrade fast."

Sample case study problems with structure

Case study 1: Fraud detection

Problem: "We want to detect fraudulent credit card transactions in real-time.
We have 10 million transactions per day, and fraud is ~0.1% of transactions."

Your response structure:
1. Clarify the goal: Cost of false positive (declining a legitimate card) vs. false negative (missing fraud)?
2. What data do I have? Transaction history? Merchant info? Customer location?
3. Propose a baseline: "Flag any transaction >$X or from unusual location." Measure: recall, precision, cost.
4. Feature engineering: transaction amount, merchant category, time of day, customer history...
5. Model: Start with logistic regression (interpretable), then test gradient boosting if needed.
6. Deployment: Need latency <100ms. Monitor for concept drift (fraud patterns change).

Case study 2: Recommendation system

Problem: "Design a system to recommend products to users on an e-commerce site.
We have 1M users, 100K products, and 50M historical purchase interactions."

Your response:
1. Clarify: Real-time recommendations? Accuracy vs. diversity?
2. Data: User interactions? Product metadata? Seasonal trends?
3. Baseline: "Show popular products." Measure: click-through rate, conversion rate.
4. Collaborative filtering: "Start with matrix factorization (user-item embeddings)."
5. Scale: "Use approximate nearest neighbors (e.g., Faiss) to find similar users quickly."
6. Deployment: Cache popular recommendations, compute fresh recs for new users.

Practice: Do 2-3 case study problems under time pressure (45 minutes). Sites like Springboard or Fast.ai have ML system design problems. The goal is not to have a "right" answer—there rarely is one—but to demonstrate clear thinking and ask good questions.

Evaluation rubric for your own case study responses:

| Dimension | Weak (1) | Okay (3) | Strong (5) | |---|---|---|---| | Clarifying questions | Jumps straight to modeling | Asks about data and goal | Asks business context, constraints, metrics, and edge cases | | Problem framing | "I'll build a neural network" | "This is classification; I'll use precision/recall" | Identifies specific metric-driven tradeoff: "False negatives cost $Y; false positives cost $X. I'll optimize for..." | | Approach | Proposes one model | Proposes baseline + iterative improvements | Proposes baseline, explains why you'd upgrade, considers scalability | | Communication | Hard to follow; vague | Clear steps; explains reasoning | Clear narrative; shows tradeoffs and constraints driving each decision | | Debugging | Can't explain failures | Hypothesizes causes (data? model?) | Traces root cause: "Performance low because... I'd check X first" |

Dimension 4: Behavioral/project deep dive prep (if you scored 1-3)

This is where your learning portfolio shines. You've been documenting projects, learning logs, and decision-making throughout this course. Now package that for the interview.

Polish 2-3 projects:

• Pick projects that showcase different dimensions of your learning: one with a cool technical insight, one where you failed and recovered, one that shipped and was used.
• For each, write a 2-minute story: problem → approach → interesting decision → result.
• Practice delivering this story conversationally, not robotically. A hiring manager will interrupt with "Why did you choose that model?" and you should be ready to go deeper.

Prepare answers to behavioral questions:

• "Tell me about a time you had to learn something quickly."
• "Tell me about a project that didn't go as planned."
• "What's the most complex model you've built, and why?"
• "How do you stay current with AI research?"

For each question, use your actual learning experiences from this course. You have a learning log, portfolio pieces, a four-week cycle framework, and evidence of how you handle ambiguity. That's better material than a generic "I'm passionate about ML" answer.

Practice: run a mock interview

Before your real interview, do a dry run. Ask a friend to interview you on all four dimensions:

• Ask 2 conceptual questions (draw a diagram, explain a concept).
• Ask 1 coding problem (implement something; they don't need to know if your code works, just watch how you approach it).
• Ask 1 case study (here's a business problem, walk me through your approach).
• Ask 1 behavioral question (tell me about a challenging project).

Record yourself (if permitted). Watch it back. Do you:

• Pause and think, or do you ramble?
• Ask clarifying questions, or jump to conclusions?
• Show your work, or assume knowledge?
• Finish your thoughts, or trail off?

Iterate. Do this mock interview twice before your real interview. The second time, you'll be visibly calmer and more articulate.

Common mistake

Do not prepare for interviews by doing 100 LeetCode problems and zero case studies. You'll walk in feeling confident, nail the coding round, and then freeze when asked to design a fraud detection system. Breadth matters more than depth in interview prep. A 3/5 on all four dimensions beats a 5/5 on one and 1/5 on the others.

Also, do not answer case study questions by immediately proposing a complex model ("I'd use a transformer with an attention mechanism..."). Propose something simple first, then explain why you'd upgrade. Engineers respect the person who can explain why complexity is necessary, not the person who jumps straight to complexity because it sounds impressive.