Microsoft Machine Learning Engineer Interview Experience — UX Project Deep Dive and Eight Behavioral Stories

The second half of this VO was a project deep dive and Behavioral. You can grind the technical questions, but BQ comes down to breaking down your own experience in advance. In this post I'm sharing the questions I was asked, the structure of my answers, and a few takeaways from preparing my stories.

1. Project deep dive: "How do you present a UX proposal?"

The interviewer first gave me a hypothetical: the team only has engineers plus one UI designer, and I'm asked to propose a user experience plan. What format would I use to present it? This question was later asked two more times in different wording.

My answer framework:

• Prioritize a clickable UX prototype (for example in Figma) rather than static screenshots;
• First define the main pages and the user journey, then wire up the key interactions so the designer and product can experience the flow directly;
• When the idea needs validating, build a lightweight functional prototype with the core interactions;
• When presenting, explain the user flow and the key design decisions, and collect feedback.

The interviewer also followed up on one key point: the interfaces I had previously generated with AI design tools, were they really usable prototypes, or just visual proposals?

I answered that they were "working functional prototypes" and walked through the process:

• Use design references to settle the overall direction;
• Generate the first version of the pages with an AI tool;
• Turn the design into real front-end pages;
• Adjust the details by hand based on product requirements and the user flow;
• The end result is something that runs and can be reviewed, not a static mockup.

Takeaways: when the same question gets asked three times, don't panic, and don't just repeat yourself mechanically. Keep the conclusion consistent and add detail from a different angle. When you talk about an AI-assisted project, make clear which part was generated by the tool and which part was your own judgment and changes.

2. BQ: eight stories

For every story I used the structure Situation -> Action -> Result -> Reflection. Most of these stories came from the same healthcare platform project and one internal engineering tool project.

1 | Digging deep to understand a complex problem before solving it

On the healthcare platform, a user had submitted the missing health metrics, but the report list still showed "more information needed".

• I first assumed the front end hadn't refreshed. I checked the code and the refresh logic was already there, so I traced the call chain down to the API;
• I found that the update endpoint was asynchronous: after submission the backend still had to regenerate the full report, so refreshing immediately couldn't get the final state;
• After discussing it with a senior engineer, I realized that making the user wait on the submit page wasn't robust enough: processing time isn't fixed, and users could also submit twice;
• In the end I changed it so that after submitting, the user goes straight back to the report list, which shows an "updating" status, and the page polls in the background until the report is ready.

What to emphasize: tracing the root cause down the call chain instead of stopping at the surface symptom.

2 | Stepping out of your comfort zone: how you identify and fill gaps

I joined a high-priority internal engineering tool project. I wasn't familiar with the tech stack, and at the start the scope and responsibilities were unclear.

• I listed the gap between what I already had and what the project needed, and focused on the technologies and processes I didn't know and the parts I was responsible for implementing;
• I read the existing code and docs, researched similar implementations, and asked senior engineers for advice;
• At the same time I practiced project management: breaking tasks into small pieces, following up every day, and syncing progress and risks every week;
• I learned to expose my skill gaps early and to ask senior engineers on other teams for help.

3 | A time I didn't deliver on a commitment

Still the same tool project. I had committed to delivering the first usable version at the original milestone, but the tech was unfamiliar, the scope and responsibilities were unclear, and team members were each going in their own direction, so the milestone slipped.

• Once I realized the problem, I re-prioritized around the minimum usable flow;
• I made the division of work explicit, tracked risks closely, and got support from other teams;
• I delivered the planned version within the adjusted deadline.

What to emphasize: be willing to admit failure, and put the weight on what you did afterward and what you learned.

4 | Solving a major problem (an N+1 performance issue)

I built a page showing the patients managed by each team. I reused the existing team list endpoint, and didn't notice it had a task type parameter.

• Without that parameter, the backend queries the counts for all task types and fires an extra downstream request for every team, which is an N+1 remote call problem;
• The test data was small, so it didn't show up in testing, but after launch customers with lots of teams saw it get noticeably slow;
• I traced the call chain of the endpoint to the redundant downstream requests and changed the endpoint so it only returns the team information that's needed.

Reflection: before reusing an endpoint, read its parameters and side effects properly; performance tests need data at close to real scale.

5 | A teammate pushing me to think about a problem from a different angle

For the async report update flow, my original plan was to keep the user on the submit page until the background processing finished. In code review a senior engineer pointed out that the processing time is unpredictable, and users might leave the page and submit again. That made me rethink it from the whole user journey instead of a single page, and I ended up changing it to return to the list page immediately, show the updating status, and poll in the background.

Stories 1 and 5 are the same project but with different angles: the first is about how I chase down a root cause, the second is about how I accept feedback.

6 | A teammate or product disagrees with your plan

Alert rules were originally designed as a team-level shared entity that could be reused across multiple plans. I thought this would cause ownership and versioning conflicts, because each plan has its own version lifecycle. The product manager leaned toward the shared model because it's easier to manage centrally.

• I didn't argue in the abstract. I walked through concrete user scenarios one by one and showed what kind of messy versioning behavior editing a shared rule would cause;
• We ended up moving to a "template + instance" model, which keeps the reuse but lets each plan own its rule lifecycle.

What to emphasize: persuade with scenarios and evidence, and the result is a better compromise, not "I won".

7 | Harsh or critical feedback

The feedback was about my use of AI-generated code: the reviewer pointed out that the generated code had too much defensive programming, especially unnecessary try-catch blocks.

• I realized that catching exceptions without hooking them into the app's existing error-handling flow only makes the code more complicated without improving the user experience;
• From then on I made the AI-generated code line up with the team's shared error-handling utilities and the project conventions;
• My standard for evaluating AI code also changed: not just correctness, but also consistency with the architecture and the user experience.

8 | Taking on UI / product design yourself when there's no designer

The team had no dedicated UI/UX designer, and I was responsible for designing several key pages.

• I looked for references on sites like Dribbble, and used AI tools to generate initial concepts for the landing page and the dashboard;
• I iterated through multiple versions, aiming for consistent design quality rather than a generic interface that looks AI-generated at first glance;
• After collecting team feedback, I worked closely with the front-end engineers to ship the final design.

This story echoes the UX follow-up in the first part, and what I say in the two places has to stay consistent.

3. A few takeaways on preparing for BQ

• It's not about having many stories, it's about getting multiple uses out of one. These 8 questions only used four or five projects' worth of material, and the same project can be split into different angles like "chasing root causes" and "accepting feedback".
• Don't skimp on the result and the reflection. A lot of people spend their time on the situation and rush through the ending, but what interviewers most want to hear is often "what did you learn and what did you change afterward".
• Be honest in failure and disagreement stories. Admitting a missed deadline or admitting you overlooked a parameter is actually more convincing than a "perfect story".
• Keep your answers consistent across rounds. When the project deep dive and the BQ mention the same experience, the details and conclusions shouldn't contradict each other.
• When you talk about using AI, show your own judgment. Whether it's generated interfaces or generated code, explaining how you evaluated it, what you kept and dropped, and how you took responsibility for the result matters far more than "I used AI".