Posture in system design interviews

Written on · 5-minute read · by Diego Ballona

If I could pick only one interview method to assess engineers, it would be system design. Coding, behavioural, role-play, and case interviews are all valuable — a well-resourced, multi-stage process with fair frameworks will reduce false positives. But if constrained to one, system design wins.

It blends subjective and objective criteria in a way that assesses candidates from multiple angles. A solid design alone isn't necessarily a pass, and strong behaviour without technical substance reveals gaps just as clearly.

There are excellent resources for the objective, technical side — I've listed favourites in the appendix. Those deserve most of your study time. But having recently gone through interviews myself, I wanted to share what I've learned about the subjective side, specifically posture.

Don't just communicate: collaborate with the interviewers

Turn the interview into collaboration, not a one-way assessment. Interviewers are evaluating whether you'd be a good colleague. A collaborative atmosphere gives them a better lens to assess fit.

Once you hear the problem, rephrase the objective in your own words. This prevents you from designing the right solution to the wrong problem. Ask questions, even obvious ones, and gather all available information before proceeding.

Next, establish what is in scope and what is out. Narrowing scope boundaries helps you focus on what matters and avoid spending limited time on tangential topics.

When you draw conclusions or fill in gaps, voice your assumptions. Bring interviewers into your perspective so they can course-correct if needed.

While working through your solution, leave spaces for feedback — avoid monologues. Let interviewers contribute, whether it's about design trade-offs or whether to split a component.

In short, communication matters in technical interviews. Active collaboration improves your performance and helps both sides gauge whether they want to work together.

Go wide first and then deep afterwards

Design problems won't fit neatly within the time available, unlike most coding problems. Nobody expects the perfect solution for a system run by hundreds of people — but you should have a rough end-to-end sketch.

Start simple. Favour extensibility over perfection. Put forward the simplest design without obvious scalability issues, keep the interviewer informed of your strategy, then optimize as you cover requirements.

A good starting frame: put yourself in the shoes of the user. Walk through the steps a user takes to interact with the system. This clarifies which capabilities need public APIs, which components are read-heavy vs write-heavy, and when to favour consistency over availability. The user perspective surfaces what's fundamental and anchors your design decisions.

Once you have a high-level design and have shown the interviewer you grasp the overall problem, go deep on your strengths. Pick the aspect you can speak most confidently about — client-side optimization, data modelling and partitioning, ML infrastructure, whatever it is.

Resist the urge to dive into detail before understanding the full problem. Starting with motivations and expected outcomes leads to better design decisions.

Talk about caveats and edge cases

What happens if your system stops sending data downstream? How do you notify upstream systems to roll back a bad change? How does the system behave for your 99th-percentile power users? Thinking about failure either gives you the chance to fix your design or confirms you made the right call.

In large-scale distributed systems, optimizing for specific characteristics inevitably introduces unwanted behaviours. Talk about trade-offs and why you chose one approach over another.

Explore failure scenarios and recovery options. Cover not just system failures, but user abuse, accepted risks, and human error. Where possible, explain how you'd prevent or recover from these.

Talk about making things right when things go wrong. In one interview, I accidentally set a free-tier storage quota at 1TB instead of 1GB. I caught it later when storage and bandwidth numbers felt absurd. After acknowledging the mistake, I walked through recovery: honouring the 1TB commitment for users already signed up, notifying advertising and intake teams, and other damage control. That conversation ended up being more interesting than getting the number right would have been.

Things will go wrong. Showing readiness to walk the unhappy path builds confidence in your design — and if you made a bad call, you still have time to adapt.

Touch on adjacencies of the problem

Given the time constraints, be deliberate about what you emphasize. While a narrow scope is good, briefly touching adjacent topics shows breadth. Some examples:

Cover operations, not only design. At large companies with dedicated infrastructure teams, it's easy to take ops for granted. Briefly mentioning alerting, monitoring, tracing, and observability can reveal scaling problems in a design.

In regulated environments like payments or abuse prevention, touching on security, compliance, and regulatory constraints adds value — data retention, anonymisation of personally identifiable information, or risk management through network segmentation for audit scopes.

On the technical leadership side, design decisions dictate how teams organize around domains. Discussing how you'd mobilize teams across the design — and showing awareness that you're scaling organizations, not just infrastructure — can spark strong conversations.

These examples reflect my own experience, but brief asides on adjacent topics serve as additional signal and build interviewer confidence.

All of these tips come from my own experiences and preferences. Different organizations focus on different things — start by understanding the expectations of the company you're applying to. Incorporating these ideas into my interview posture has helped me, and I hope it helps you too.

Appendix

Resources for the technical side: