Software Developer III Interview Experience
The weirdest round was basically a PR review for an order-messaging system where I had to spot bugs and explain how I'd structure it so a Kafka-to-SQS switch later wouldn't turn into a rewrite.
Interview process
I interviewed for an SD3 role at Mindbody, and the process felt pretty standard structurally, just long. They told me it was around six rounds, and a lot of it was centered on DSA and design. The most memorable part was a PR review round on an order-messaging flow where I had to find bugs, make it easier to follow, and explain how I'd keep it extensible if the messaging vendor changed later. AI was not a side topic either, because it kept showing up in different rounds. By the end, it felt like they were testing both the usual engineering fundamentals and whether I could actually use AI in a practical way.
- Technical interview
- Final round
Interview rounds
8 questions across 5 roundsTechnical interview (1)
1 questionOverview
I started with a DSA round that felt pretty standard, but they didn't just ask me to solve from scratch. They gave me something in the number-of-islands family and kept changing the conditions to see how I would adapt the logic.
Question types asked
Specific questions asked
How would you modify the solution for the extra conditions we add?
I had to work through a number-of-islands-type problem, but the twist was that they gave a specific code setup and then asked me to improvise based on changing conditions. So it was less about memorizing the exact LeetCode answer and more about showing I could adjust the traversal and logic cleanly when constraints changed.
Technical interview (2)
1 questionOverview
The next round was more like a document critique plus HLD discussion. I had to read a technical design doc, explain what I understood, and then push on tradeoffs and improvements.
Question types asked
Specific questions asked
Read this technical document and walk me through a high-level design for it. What would you improve?
Would adding a CDN help here, and what are the downsides?
What newer technologies would you bring in to improve this design?
I first explained the design back to them to show I understood the doc, then I talked through improvements. A big part was discussing whether adding a CDN made sense, what it would help with, and what tradeoffs it would introduce. They also wanted to hear what newer technologies I knew and where I would actually use them instead of just name-dropping tools.
Technical interview (3)
2 questionsOverview
The most distinctive round was a PR review and debugging exercise. It felt very practical because they wanted me to read someone else's code, find issues, and explain how I'd make it scale and stay extensible.
Question types asked
Specific questions asked
Review this PR for an order messaging flow, find the bugs, and explain how you would optimize it for a large-scale system.
How would you make the flow easier to understand?
How would you extend it using a strategy pattern?
What naming or variable improvements would you make?
How would you restructure it so switching vendors, like Kafka to SQS, is easier later?
I was given a PR around order messaging where events were being published and consumed, and I had to spot bugs plus talk through scale issues. I focused on making the flow easier to reason about, using a strategy pattern so the implementation was cleaner, improving naming, and restructuring the code for extensibility. One concrete angle was making the messaging layer vendor-agnostic so if we switched from Kafka to SQS later, we wouldn't have to rewrite everything.
How do you drive conversations with AI effectively?
How fast can you implement things with AI?
Have you used AI to explore a new cohort or use case?
They were pretty direct about AI. I had to explain what tools I use, how I structure conversations with AI, and how that helps me implement things faster. They also asked what kinds of models I've used and how I think about using AI to explore new cohorts or use cases, so they clearly cared about practical adoption and not just surface-level familiarity.
Technical interview (4)
1 questionOverview
Then I had a low-level design round that was more object modeling than coding. They wanted the class structure, entities, relationships, and API thinking for a familiar system design problem.
Question types asked
Specific questions asked
How do the classes relate to each other?
What functionality would each API expose?
This was a parking-lot-style LLD round. I didn't have to write code, but I had to lay out the entities, how they map to each other, the class design, and the API-level functionality. It was really about showing theoretical clarity and whether I could structure the objects and responsibilities cleanly.
Final round
3 questionsOverview
The last round was a VP conversation that mixed behavioral questions with AI discussion. It was less about problem solving and more about how I work, how I think about tools, and whether I fit what they're building.
Question types asked
Specific questions asked
What models do you use?
Why are you using one AI tool over another?
They went pretty specific on models and tool choice, so I got the sense they were checking whether I had real hands-on judgment about AI tools rather than just saying I use them.
Do you have any questions about our culture?
Interview tips
I'd definitely prep for DSA in the format where they give you a base problem and then start changing the conditions on you, because that was more the flavor than a pure solve-from-scratch round. I'd also practice reading a design doc and critiquing it out loud, especially tradeoffs like whether a CDN helps and what downside comes with it. For LLD, I'd be ready to design something like a parking lot without writing code, just entities, relationships, classes, and APIs. And for AI, I wouldn't keep it vague at all. I'd walk in with specific examples of tools, model choices, how I prompt, and where it actually made me faster.
Company culture
The culture seemed great from what I saw. At the same time, they're clearly leaning hard into AI because their end consumers are not very technical, so a lot of the conversation was about what they can build there and how to use AI in a useful way. They also seem to care about practical engineering habits, not just interview-style problem solving, since one of the rounds was literally reviewing a PR and thinking about maintainability, naming, and how to avoid locking yourself into one messaging vendor.
Get full access with a membership, or share your experience to try it free.
