Engineering Manager, ML Engineer and Designer Interviews Explained

What each round tests in EM, ML engineer and UI/UX designer loops, how to answer scenario and ML system design questions, and how to time a design challenge.

2026-10-24 · 7 min read

A staff engineer interviewing for her first manager role prepared the way she always had: algorithms, a couple of system design prompts, a few behavioral stories. The loop had one technical round. The other four were about a struggling report, a hiring decision she disagreed with, a missed quarter, and how she would split a team that had grown too big. She knew the material from years of tech leading. She had never organised it into answers.

Specialist roles reuse the familiar interview formats but change what each round is listening for. This guide covers three of them: engineering managers, machine learning engineers and UI/UX designers. Each section explains what the rounds test, a preparation plan, and the mistakes that come up most. The practice pages are Engineering Manager Interview Prep, ML Engineer Interview Prep and UI/UX Designer Interview Prep.

Formats vary by company. Ask the recruiter for the list of rounds and what each assesses; it is a normal question.

Engineering manager interviews

What the rounds test

An EM loop asks three questions about you. Can you grow and manage people? Can you deliver through a team rather than through your own code? Do you still have the technical judgement to make or challenge architecture decisions?

The people round is the one that most often sinks strong engineers. Expect questions such as "Tell me about someone you managed who was underperforming", "How do you give difficult feedback?" and "Tell me about a hiring decision you got wrong." The interviewer wants specifics: what you noticed, the conversation you had, what you wrote down, the timeline, what support you offered, and what actually happened.

How to answer a scenario

The Scenario Practice tab includes a case many interviewers use in some form: a former top performer whose work has slipped for two months. A strong answer moves through these beats:

1. Talk privately first and find out why: workload, clarity, personal circumstances, or a mismatch with the work.
2. Agree specific, written expectations with a timeline.
3. Offer real support (scope changes, pairing, time off) and check in weekly.
4. Be clear about consequences if things do not improve, and involve HR at the right point.
5. Close with the real outcome from your own experience and what you would do differently.

Click Generate Structured Response in the tool to get the key points as an outline, then rewrite it around your own story. For performance plans, the Performance Improvement Plan tool shows what a written plan with measurable goals looks like.

Technical judgement for managers

Managers usually get a system design round at a higher level than senior engineers, or an architecture discussion about something they led. You will not write code. You will be asked why your team chose an approach, what it cost, what the alternatives were, and how you would know if it was wrong. If you need a refresher on structure, the System Design Interview guide applies directly.

Common EM mistakes

• Process with no person in it. "I followed the PIP process" scores less than describing the conversation and the human outcome.
• Vanity team metrics. Lines of code and story points are red flags. Talk about delivery outcomes, lead time for changes, change failure rate and team health.
• Avoiding the hard story. Most loops ask about letting someone go or a failed hire. Have one ready and be honest.
• "We" all the way through. You are being assessed on your decisions as the manager.

ML engineer interviews

What the rounds test

An ML engineer loop usually combines a standard coding round, an ML fundamentals round, an ML system design round and behavioral questions. Some add ML coding, such as implementing k-means, a training loop or a metric from scratch.

The fundamentals round checks that you understand rather than recite: bias and variance, regularization, why a model overfits, how gradient descent behaves, evaluation metrics and when each misleads. Expect "why" follow-ups after every definition.

ML system design, step by step

This is where most candidates lose points, usually by jumping straight to a model architecture. Work through it in this order:

1. Business goal to ML objective. "Reduce fraud losses" becomes "score each transaction for fraud probability within the payment latency budget".
2. Metrics. Offline (precision and recall at a threshold, PR-AUC) and online (fraud loss, false decline rate). Say how they relate.
3. Data and labels. Where labels come from and how delayed they are. Chargebacks can take weeks.
4. Baseline. Rules or logistic regression first, so there is something to beat.
5. Features and model. Transaction velocity, device and merchant features; gradient-boosted trees are a common strong choice for tabular data.
6. Serving. Latency budget, feature freshness, fallback when the model service fails.
7. Monitoring. Data drift, prediction drift, label-delay-aware evaluation, retraining cadence.

Imbalance check: 1,000,000 transactions, 1,000 fraudulent (0.1%)
Model A predicts "not fraud" for everything:
  accuracy  = 999,000 / 1,000,000 = 99.9%
  recall    = 0 / 1,000            = 0%

That small calculation is worth saying out loud in an interview. It shows why accuracy is the wrong headline metric and leads naturally to precision, recall and the cost of each error type.

Common ML mistakes

• No baseline. Proposing a transformer before a heuristic suggests you have not shipped models.
• Ignoring leakage. A feature that will not exist at prediction time produces great offline scores and a production failure.
• Training-serving skew. Features computed differently in batch training and the live service. Mention shared feature code or a feature store.
• Skipping coding practice. Most ML loops still include a normal algorithms round; the Coding Interview Prep guide covers it.

UI/UX designer interviews

What the rounds test

Design loops typically include a portfolio presentation, a live whiteboard or take-home challenge, a critique of an existing product, and conversations with engineers and product managers. All of them are assessing how you think and decide, not the polish of your mockups.

The portfolio presentation

Two or three case studies, presented in depth, usually fill a 45 to 60 minute slot. For each one, cover:

1. Context and challenge. The problem, the users, the constraints, and your exact role.
2. Process and approach. Research, options explored, and what you rejected and why.
3. Solutions and decisions. The design, with the reasoning behind its key choices.
4. Results and learning. Measured outcomes where you have them, and what you would change.

The Portfolio Questions tab lists 24 questions reviewers ask. Rehearse each case study against them; the ones you cannot answer show where the story is thin.

The live challenge

The most common failure is running out of time before designing anything. The plan in the tool fits a 40 to 60 minute session:

Accessibility comes up often. WCAG 2.2 level AA requires a contrast ratio of at least 4.5:1 for normal text and 3:1 for large text, along with visible keyboard focus and minimum target sizes. Checking your palette with the Contrast Checker before the interview is an easy win.

Common design mistakes

• Unclear role in team projects. Say what you did and what the researcher, other designers and engineers did.
• Only happy paths. Interviewers look for empty states, errors and edge cases.
• No outcomes. Even qualitative results from usability testing beat "the client was happy".
• Too many case studies. Eight thin projects show less than three deep ones.

Preparing for any of the three in three weeks

Week 1: Get the list of rounds from your recruiter. Tick through the skills or concepts checklist on the relevant page honestly, and note the gaps.

Week 2: Practise the role-specific round you are weakest at: people scenarios for managers, ML system design for ML engineers, timed challenges for designers. Use the generated outlines as scaffolding and rewrite them in your own words.

Week 3: Behavioral stories and mocks. All three roles get behavioral questions, so draft six to eight stories in the STAR answer builder, then do at least two full mock interviews with someone who works in the role you want.

The structure of these loops is predictable even when the questions are not. Knowing which round carries the most weight for your role, and practising that one hardest, is usually the difference between a close decision and a clear yes.

Open the Engineering Manager Interview Prep