Most of Oso’s customers run on microservices and need engineers who understand distributed systems. Our customers often ask if we can connect them with people who understand how to design and secure these systems (particularly best practices for microservices authorization). To help, I reached out to several senior engineering leaders to learn how they evaluate candidates’ understanding of microservices in technical interviews.
I got responses from several experienced leaders. Their answers fell into three main categories:
- System design prompts for hyperscale systems
- Questions about monolith vs. microservices tradeoffs
- Deep dives into specific microservices challenges
Below are their questions.
1. Design a Hyperscale System
These questions start with an intentionally broad prompt. By asking a candidate such an open-ended question, you can understand how the candidate decomposes complexity, surfaces constraints, and structures their thinking.
Steve Briskin, VP Engineering at Viam
“I’d either ask them to design a system — like Spotify, Twitter, or Slack — and dig into how they’d scale it.”
Steve treats the microservices interview like a system design exercise. He looks for candidates who can outline a high-level architecture, then pause to clarify assumptions before going deep. The best answers, he says, show an ability to reason about partitioning, scaling, and tradeoffs.
“Anyone who’s 100% on the microservices train is a hard no from me,” he adds. “I look for awareness of issues with code, release management, permissions, operations, APIs, and so on.”
Antoine Patton, Senior Software Engineer at Atlas Digital
Antoine’s go-to questions similarly start big:
“How would you design a system that handles high-volume events between multiple services?”
And he follows with:
“How do you ensure data consistency across distributed services?”
These questions reveal systems intuition and practical understanding of distributed data, both of which are a must for engineers working in microservices environments.
Edouard Servan-Schreiber, VP Solutions Engineering at Viam and former Head of Solutions Architecture at MongoDB
“Every solution architect I interviewed at MongoDB had to ‘design Twitter.’”
For Edouard, simplicity wins. The “design Twitter” prompt forces candidates to think about sharding, caching, and service boundaries under real-world conditions.
“When Darren Wood started at MongoDB, on his first day he asked what he should do. I said, ‘Why don’t you actually build Twitter?’ And he did.”
That project became Socialite — a fully implemented microservices demo still referenced in High Performance MongoDB by one of Edouard’s very first hires, Asya Kamsky.
Mike Cen, Engineering at Oso
Mike prefers to make system design questions relevant to real problems the team solves:
“We ask candidates to design a miniature version of a real system, or one that mirrors similar challenges. It gives them a better view into the kind of projects we work on, and lets us evaluate their skills in context.”
His focus isn’t on scale for its own sake:
“In a startup environment, we’d rather see something that works. Then we’ll ask how they’d scale it as new requirements come in — that shows how they think about functionality, flexibility, and time to market.”
2. Weighing Monoliths vs. Microservices
The second category digs into judgment calls: when and why to adopt microservices, and what tradeoffs they introduce.
Sam Weaver, CEO & Co-founder at Plural
“When would you favor microservices over a monolith?”
Sam Weaver’s interviews test a candidate’s architectural decision-making. His follow-ups explore the reasoning behind the model:
- What are the pros and cons of moving to microservices?
- If you were running Facebook back in the day, when would you start splitting the app?
- How do services communicate, and how do you ensure that happens securely?
“These questions expose whether someone sees microservices as a technical fad or a tool for scaling teams and complexity,” he explains.
Jeff Doll, SVP, Head of Product & Platform Engineering at Auditboard
LinkedIn | Careers at Auditboard
Jeff Doll probes into how candidates reason about service boundaries and architectural readiness before diving into microservices.
An example question would be, "How do you determine the right level of service abstraction or fidelity? If possible, sharing an example of how you defined the scope of a service you've architected or built."
Jeff explains, "I usually try to understand the candidate's grasp of service-oriented architectures and how to think about the ideal decomposition on the spectrum from classical service-oriented architectures to what people broadly think of as microservice architectures. The intent is to understand how the candidate thinks about decomposition fidelity."
Here is another example question from Jeff along this theme: "Are there fundamentals that you believe organizations need to solve for first before pursuing a microservice architecture for their application(s)?"
What's Jeff driving at? "Many Engineers have worked within microservice architectures or defined services for them; a few have built them from the ground up. Considerations like tracing, observability, async/sync communication methods, and more are often things that are overlooked as components that already exist or oversimplified as 'we can just use x' (Cloudtrail for logging is a common example) without ensuring that they have considered the impacts or implications on what it will mean for them to interact with other teams and services and/or support that service in production."
Chris Richardson, Creator of microservices.io
Chris Richardson, author and educator, frames this decision as an ongoing architectural balancing act:
“What criteria do you need to consider when determining whether a new feature should be implemented as a new service or as part of an existing one?”
He breaks this down in his article Dark Energy, Dark Matter, and Microservices, describing how too many small services can become as problematic as a monolith.
3. Solving Microservices Challenges
Finally, there are the practical microservices questions, grounded in scaling pain.
Jared Rosoff, VP Product at Roblox
Jared asks candidates to reason about infrastructure growth, dependency management, and cost attribution, often reflecting painful, firsthand experience and scars.
Examples from his repertoire:
- You have 3,500 microservices. What happens when your DAUs double?
- How do you determine CPU allocation for thousands of microservices as traffic scales?
- How do you patch a shared logging library when there’s a critical security vulnerability?
- How do you show cost allocation per team across shared infrastructure?
- How do you design load balancing across multiple geographic regions when some services are singletons?
- If a public API call traverses N layers deep into your microservice graph, what’s the maximum expected availability of your public API if your network is 99.999% available?”
Justin Helmer, Principal Engineer at Webflow
Justin also prefers questions that dig into the engineering realities of maintaining microservices at scale, where small design choices can have big downstream effects. His questions include:
- When designing APIs between services, how do you prevent implicit coupling while still ensuring data integrity?
- What’s your approach to evolving a shared library or schema that’s used by multiple services in production? (i.e. versioning strategy)
- What are the signs that a microservice boundary is either too coarse or too fine-grained, and how do you correct it?
Having recently implemented Oso for fine-grained access control, Justin also recommended the following questions:
- What approaches would you take to ensure authorization policy updates propagate safely and quickly across microservices?
- How would you model and synchronize user permissions when identity and authorization data live in separate systems?
- How do you design an audit trail that captures authorization decisions across many services without introducing performance bottlenecks?
What are your best microservices interview questions?
This article is a first draft, and we will continue to update it with contribution from the community. If you have suggested themes, please weigh in on this Reddit conversation.
Frequently asked questions
