
There's a lot of great literature out there on [why you should build a technical platform](https://kislayverma.com/platform-thinking/why-you-should-build-a-platform/), and [what is a platform](https://martinfowler.com/articles/talk-about-platforms.html), but I haven't found a resource which illustrates specific situations where you might want to build one. With that, I started thinking about patterns that could help spot the need for a platform and what to do about it when you find yourself in this situation as an engineering leader.

I plan to write a few articles about the different patterns I've seen in the past. If you think of any other examples, <SocialLink type="twitter">please reach out on twitter</SocialLink> and I will write about it and credit you as a contributor.

### What is a platform?

For those less familiar with technical platforms, I'll be using the following overly simplified terminology and set of principles that might help understand the basics. If you'd like to go deeper on the subject, the articles in the introduction will give you more depth on the subject.

##### Terminology

- **Application team** is a team that leverages the technical platform for a specific use-case, e.g. a team building recurring billing through a payments platform;
- **Platform team** is the team that operates and maintains the technical platform leveraged by application teams, e.g., the payments platform team;
- **Capability** is a piece of software that provides the business and a user the ability to do something, e.g., "charging a credit card" is a capability of the payments platform, and so is "refunding a card transaction".

##### Principles

1. **A platform is self-serve for most use-cases.** Not only from a tech standpoint – meaning excellent documentation, developer experience, etc. – but also from a people and process standpoint. [Jade Rubick's self-service coordination model](https://www.rubick.com/platform-teams-and-the-self-service-model/) article illustrates in detail what I mean.
2. **A platform is extensible for use-cases it doesn't support.** Application teams can leverage the platform as building blocks rather than a black box to build and support their own needs. For instance, extending a payments platform to support recurring billing by an application team might be easy if it has a "store cards" capability and supports "charging a credit card".
3. **A platform operates similarly to a third-party to the use-cases.** All complexity on maintaining the platform's domain is abstracted from the application team. Abuse prevention, security, compliance and 3rd-party vendors are good examples of the complexity a platform should abstract away.

The following quote I took from [this article](https://martinfowler.com/articles/talk-about-platforms.html) written by Evan Bottcher on Martin Fowler's blog illustrates the concept very well:

<Quote quote="A digital platform is a foundation of self-service APIs, tools, services, knowledge and support which are arranged as a compelling internal product. Autonomous delivery teams can make use of the platform to deliver product features at a higher pace, with reduced coordination." author="Evan Bottcher" />

With this quick primer on technical platforms, here's a fictitious story that  exemplifies what I mean by the "consolidation" pattern.

### A story & the problem

Acme corp started its business by serving only business customers. Besides building a great product, they also had a software engineering team whose charter was onboarding new businesses. Besides designing the experience, the business onboarding team developed some basic functionality for:
- Authenticity checks through a tax ID to ensure the businesses  onboarded are legally registered;
- Compliance checks for preventing money laundering, for compliance, security and quality reasons;
- Contact information verification to ensure any onboarded business could be contacted for any reason;
- And, as part of the onboarding flow, a credit card was required, which would get charged after the product trial ended.

Product-market fit came very fast for Acme, given their innovative product. Consequently, their ambitions broadened, and Acme's leadership announced a new strategy to support consumers without a legal business, with a different set of features. To do so, they staffed another team to build consumer onboarding. With the rising pressure from investors to hit targets, it made sense for the consumer onboarding team to develop their own set of systems. At this stage, to prevent fake accounts, it was as simple as just sending an email to confirm the consumer's email address.

Over a few months, the consumer side of the business also grew considerably. Acme saw another opportunity to charge a subset of consumers for a specific tier of their business product. The consumer onboarding team quickly implemented the feature, which was an excellent win. Nonetheless, a few months after the launch, some issues came to light:
- Trials between the consumer and business profiles were inconsistent, and managing different lengths of cycles created a lot of overhead for the finance team;
- Given consumer and business onboarding used different payment vendors, the same credit card that would work in a business account wouldn't work in a consumer account;
- As both products were built independently, language to refer to the domain varied across consumer & business, and sometimes was even conflicting;
- As Acme expanded to new markets, both consumer & business teams had to add new payment types, new compliance checks, and support for new currencies.

### Symptoms

Usually, there are a few symptoms that precede the need to apply the consolidation pattern:
1. **Fragmented technology for a capability**. Especially when you're experimenting with a new product, over-indexing in cohesion is usually a bad idea, as you barely know if the product will ever be successful. In the anecdote above, when the engineering leadership team staffed the consumer onboarding team, taking a payment was off the scope, so it probably was the right decision to build a new set of systems. Although as the scope increased, the company ended up with duplicated systems for many capabilities such as "taking a payment", "running compliance checks", "managing trials".
2. **Duplication of work or similar indirect dependencies**. In the anecdote, when expanding to new markets, both consumer and business onboarding teams would depend on a "user management team" to add a "country" field to the user model to select which currency to use when making a payment. We can abstract this as more than one team having to do very similar implementation or sometimes the same work, or two teams having indirect dependencies for the same reasons to the same parties. 
3. **Broken language across the business**. In the example above, referring to "product trial" or "compliance checks" is very ambiguous, as you may be referring to very different things depending on who you talk with. For folks familiar with the Domain-Driven Design book, the [Ubiquitous Language](https://martinfowler.com/bliki/UbiquitousLanguage.html) chapter comes to mind here.

### A solution to the problem

One example of a path forward for teams in such a situation is using the ["application/platform" model](/en/composition-for-teams-platform-and-application-pattern) and splitting up responsibility into three areas: 
- Consumer onboarding, which focuses on the experience of the consumer onboarding and anything specific to the consumer side;
- Business onboarding, which focuses on the business experience and its specifics;
- Onboarding platform, which consolidates the capabilities used by both onboarding teams into a platform. Good examples of capabilities in this platform team might be "taking payments", "managing trials", "running compliance checks", which can be configured or extended to different use-cases;

And here's a breakdown of a step-by-step to test the change and see if it makes sense for your case:

1. **Set up a [virtual team](https://www.referenceforbusiness.com/management/Tr-Z/Virtual-Organizations.html) with representation from both teams**. This group of people will be accountable for putting together an action plan and test the hypothesis. Besides working on a shared roadmap, I recommend looking into SLAs per use-case, level of extensibility needed per team, and prioritising future cases in the new platform with input from both teams. You might find that maybe you can live with duplication for a while longer, or even conclude that a platform is not the right fit;
2. **Carve out capacity to consolidate capabilities** If that proves to be the path forward, rather than going with a big-bang migration, or rewriting everything from the ground up, pull one capability at a time from former systems into the new platform. A way to prioritise is pick the use-cases that are the largest pain points for both teams and the business first, or the largest bottlenecks for the business first;
3. **Eventually staff a new team**, preferably with some degree of resourcing from existing teams, and move to the application/platform model.

And to wrap up, here's how doing this solves the symptoms aforementioned:

1. Fragmented technology is no longer an issue, as, by design, the shared capabilities are in a single team;
2. Ideally, most of the work should sit with the platform team when adding a new payment type, complying with a new policy, or adding a new trial type;
3. The new organisational boundary in the platform team can be a forcing function for language correction, even though there will be a need for conscious effort from the platform team.

_____

*Special thanks to [David Golden](https://xdg.me/) for his feedback on a previous version of this article.*


Platform patterns is a series about how to use patterns for building platforms. The consolidation pattern consists of merging scattered capabilities into a platform team.

Platform patterns #1: Consolidation


A usually overlooked, yet fundamental part of designing high performing systems is capacity planning. I particularly didn't pay much attention to this topic in the past. I had a tendency to only think of it only at a very early stage of designing systems and thought it was only valuable for massive scale systems.

In fact, capacity planning is an incredibly informative exercise. It can help you understand the feasibility of a particular design and can also hint you better options. Approaching it as part of the design process in any considerable change – "considerable" defined as a function of how the change impacts relative scale – can be tremendously helpful.

That said, I thought I'd share some of the basics of capacity planning for system design.

### Clarify the design scope

If you're building a new system from scratch or introducing change, the usual process is understanding what the software is supposed to do. **Understanding [functional requirements](https://en.wikipedia.org/wiki/Functional_requirement), as what features are needed, and [non-functional requirements](https://en.wikipedia.org/wiki/Non-functional_requirement), as constraints the system should abide by** are a good place to start. An example of a functional requirement is adding video upload to a social media post/feed that only supports pictures. A non-functional requirement could be a need that these videos should work in 2g connection.

**Once you understand what the change entails, explore its characteristics.** For instance, observe read vs write ratios. Different systems will need different optimisations because of these characteristics. For example, a news feed will likely have more reads than writes and a wellness app that tracks your activity while exercising will probably be the other way around.

Another set of characteristics that will impact the overall capacity planning exercise are **understanding how non-functional requirements impact storage or bandwidth.** For instance, for a messaging app, choosing client over server persistence for messages will drastically impact storage investment. Nonetheless, it will also have its own set of challenges when syncing up data across devices.

At this stage, clarifying what matters will support defining the best trade-offs and potentially will simplify implementation.

### Estimate a few options

Once you know the scope, you are ready to move to some estimates. At this stage, you likely have a rough idea of which features to pick for estimation. **Your initial measure for quantifying capacity is usually an assumed throughput**, inferred from a similar feature or another number such as daily active users.

Firstly **come up with a ballpark estimate of how much a request costs in bytes.** Rounding up is a good idea to keep figures conservative. Estimates for text should be straightforward as you can assume a set of fields and their sizes in bytes. For object storage, such as images or videos, think of versioning, for instance, the average size of a thumbnail vs full-size, or video in 480p vs 1080p. Note how this interacts with non-functional requirements and which options you have available to fulfil the specification.

**Once you know how much each record costs, think of bandwidth per operation.** Think of how you can potentially reduce the amount of data sent both ways: client to server and server to client. Especially for reads, you usually have opportunities for savings. For instance, instead of fetching the entire record and all of its fields every time, you can likely send a fraction of the content from the server sometimes. Examples of that are truncating content or rendering versions. In short, not every operation will need the whole record so you can factor it and discount accordingly.

From there on it is just byte maths and [back of the envelope calculations](http://highscalability.com/blog/2011/1/26/google-pro-tip-use-back-of-the-envelope-calculations-to-choo.html). **With the average record size per operation you can get estimate measures** and understand trade-offs for different design options.

### Seek opportunities for optimisation

Next up, optimisation. **A very typical opportunity for storage optimisation is defining data retention.** Not all systems need – or even can, because of compliance – keep data forever. A typical opportunity is looking into data granularity, for instance, aggregating data by a dimension such as time or user. Especially at large scale, an appropriate data retention policy can drastically improve systems performance and save costs.

Another opportunity to reduce overhead is caching. **For read-heavy systems, usually, a small portion of the content gets a disproportionate amount of reads**, and caching can reduce bandwidth dramatically for such cases. There's a myriad of ways you can explore optimisation for reads such as lazily loading content based on what's on the viewport, making use of content delivery networks, incrementally improving video/audio quality over user engagement time, and so forth. These are very much dependent on non-functional requirements as well.

Similarly, you can **leverage caching for write-heavy systems as a way to reduce storage capacity needs**. For instance, in a time-series event-based architecture, omitting writes where there is no state change. Temperature-reading sensors which push updates on a fixed time interval to a server are an excellent example of that. Temperatures aren't prone to change drastically within a short timespan, so you can cache a sensor/temperature pair and only write to longer-term storage when a change happens.

In short, there are many ways to go about capacity optimisation. I believe two key aspects to keep in mind are how optimisation impacts relative capacity, and what you are optimising for.

### Be prepared to operate

Much of the truly challenging work for capacity planning, in my opinion, is in operating capacity. **Sometimes, assumptions we base off capacity planning at the design stage are untrue in practice**. That's why being prepared to operate and thus, continuously plan, is extremely important.

**A good practice for detecting misconceptions is writing some of the assumptions made at the design stage in the form of alerts**. Let's say at the design stage you assume the system will have 20% cache hit, and in practice, you have 5%. Even though you likely will have monitoring in place, the assumption made can slip off. Monitoring the assumptions made previously gives you the ability to act proactively instead of only knowing it on your next infra bill arrives or when an incident happens.

Even though you have ways to rely on data to forecast and know how load evolves, you can't predict every single scenario. To reduce this risk, what you can do on an ongoing basis is **using some concepts of [threat modeling](https://en.wikipedia.org/wiki/Threat_model) to understand which safeguards are missing**, what happens if a certain characteristic changes, or if a non-functional requirement changes. These help to indicate where you might have blind spots.

___

With this said, capacity planning is a deep and fascinating subject. It can inform design decisions, support systems operations, and even help you challenge your initial requirements. Having this as part of the design process can help increasing awareness of the trade-offs you make, and puts you in a stronger position to approach change.


Capacity planning is an underemphasized subject in system design. Approaching it as part of the design process can be tremendously helpful. Here are some of the basics.

System Design: Capacity Planning basics


After posting [my takes on posture in system design interviews](/en/posture-in-system-design-interviews) in [TechWriters](https://lethain.com/techwriters/), [David Golden](https://twitter.com/xdg) inspired me to write about calibrations on technical interviews. The angle I'm looking at calibrations in this article is intentionally narrow, as I took a route to talk more about how calibrations contribute to a fairer, more balanced, and as a consequence of that, more efficient hiring processes. For the sake of this, I'm containing the subject of calibrations to two perspectives:

1. How can a group of peer interviewers assess and land onto a shared understanding of who is the best fit for a role;
2. How can a hiring manager increase the certainty that they are making the best hire decision for their team and organisation.

Even though my goal is approaching the subject with as much transposability and objectiveness as possible, calibrating interviews isn't in any means an immutable, transferable or exact matter. Similar to any complex system or concept, this is an overly-simplified representation of the subject as an attempt to make it more digestible. Calibrations are a highly nuanced subject even within the same organisational culture context, and even further for different organisations. Different organisations will expect different outcomes from hiring processes, and covering calibrations to the degree of depth to make it justice would overlap with specifics of the hiring process designed for your organisation, which is out of scope and reach to cover.

### Context & Pre-requisites

For those who are unfamiliar with the term: interview calibrations serve the purpose of finding common ground between interviewers about a candidate's overall performance and then measuring the performance of candidates against each other, so you move forward with the most appropriate candidate for the next step or to a job offer.

Even though interview calibrations can be unstructured, as in just talking through overall impressions about a candidate, approaching it from this angle has a large propensity to go wrong. Hiring managers and the seniormost people in the interview loop are usually well-positioned – even if unintentionally – to influence other's opinions, therefore making the process less fair and more biased if you go fully unstructured.

To that extent, I believe pre-requisites to reasonably calibrating candidates are:

1. **A framework that defines leveling organisation-wide** by outlining roles, expectations and impact for each level – what Senior, Staff, and other roles mean in practice;
2. **A well-defined interview process per level or career track** that is equitably used for all candidates, regardless of circumstances such as referrals or returning employees;
3. For more structured interview stages, such as technical interviews, **a database of questions with clear guidelines** at the interviewer's disposal;
4. **A training program as a pre-requisite for interviewing** covering what matters for the organisation covering from practicalities to D&I and unconscious bias training.

These pre-requisites will help to establish a foundation for objective comparison between existing talent at the organisation, a standardised way to assess candidates, and that interviewers understand how to evaluate candidates fairly.

### The interviewer's role

I believe a good starting point from the interviewers' perspective, regardless of their role, is **studying the framework for leveling people**. Understanding leveling is inherently understanding expectations for a role – and that's a starting point to assure fairness. In other words, further than defining that whoever does x, y and z is Senior Engineer, defining what type of impact and effect you expect these people to have in the role helps to clarify what you are looking for the needs for the open role. Studying the framework helps calibrations as if you understand expectations for a role, you can assess a candidate more objectively.

Next up, **having comparative data and criteria between candidates under different lenses** can be helpful too. In situations where there are constraints such as fewer roles open than candidates passing the interview bar, it can be hard to define who is better suited for the role, especially if different people interviewed them. I've seen this solved in two ways: having more than one interviewer per interview (e.g., one lead interviewer and one [shadow interviewer](https://rework.withgoogle.com/guides/hiring-train-your-interviewers/steps/giving-interviewers-practice/)) or having more than one interview of the same type per candidate (e.g., two system design interviews within the same interview loop done by different people). Both can help to decrease bias and give interviewers more angles to debate, compare and calibrate candidates between themselves through more perspectives for the same criteria.

Another critical task is **defining what is expected as a good outcome for an interview stage upfront**, so you have what to calibrate against after the interview in case you have multiple passes. What "better" means is for the majority of the times relative, so discussing it on the same terms with other interviewers in case of multiple passes will help to keep discussions to specifics. As an example, for a system design interview, you are likely looking for criteria such as "completion", "prioritisation", "depth of knowledge", "breadth of knowledge", "communication", "trade-off awareness" and so forth. Further observation out of scope as a note can help on the overall decision, but to ensure the process works as envisioned when designed is essential to limit grading to the stage's criteria.

To this point, **defining how interview stage performance maps to candidate leveling** can help to inform the decision process. For context, candidate leveling usually takes into consideration the overall performance of a candidate during the interview, plus their previous accomplishments and experiences. That is, the overall performance should be supported by stage performance, which then should be backed by interview criteria. A slightly more tangible example is, for instance, in system design interviews, seasoned engineers are more likely to have a deeper level of awareness of the trade-offs being made compared to less experienced engineers. Understanding what to expect performance-wise for each interview stage for each level can help to make the decision fairer. Be mindful though that turning the assessment into an exclusively objective or mechanical process is not desirable too, which brings us to the next two points.

You likely won't need to make a decision exclusively given the signals gathered in the interview stage you conducted. That said, **giving candidates the benefit of the doubt by default** can be a compassionate way to speak of someone's abilities that you barely know. Interviewing is a stressful experience, especially when the candidate really wants the role. Instead of pretentiously judging whether someone is fit or not for a role, understanding the interview as a snapshot of behaviours observed helps to keep yourself open to being convinced otherwise – both to favour hiring or to withdraw your hire recommendation.

Finally, if you get to a situation where you have more than one great candidate per role and grading between interviewers for the same interview type reveals a draw, **delegate the decision to other stages**. It is hard to get an accurate picture of one's ability through a 45-minute interview. At some point, the precision for stacking candidates speaks more about your own bias than about their qualities, so leave it for other criteria to drive the decision instead.

### The hiring manager's role

One of the main learnings I've had as a hiring manager is **hiring first for the organisation, then for the team**. Things will go wrong often, regardless of the organisation's maturity. Having a narrow/tightly-fit hiring strategy can backfire dramatically. Good examples of that are a project the candidate was an excellent fit for getting disincentivised or deciding to buy software from a vendor instead of building it in-house. Those are circumstances where calibrations are helpful – if leveling is standardised across the organisation, moving people to their next endeavour is less disruptive for everyone involved.

That said, **resist the urge to think exclusively of the capability gaps your teams have** and your particular needs. As a hiring manager, you obviously should be well focused in your problem space, although people can end up needing more than that to stay or grow within the organisation. Investigating whether similar needs exist somewhere else within your organisation can help to make a more thoughtful decision. Validating your assumptions with peers and aligning potential further remit for your hires before even hiring them can force you to think of what is this candidate's progression path and ensure that you can bring someone with a clear problem space to own. On the flip side of the previous example, if things go incredibly well, this person will have options to pick for their path forward.

**Before deciding for a specific candidate, calibrate them against the leveling framework** to assure you're leveling newcomers fairly. Most companies have situations where levels have overlapping responsibilities and compensation bands. To achieve promotion to the next level, one has to be consistently performing at the next level, so when bringing new people in, you want to level them correctly, but even more so, you want to make sure to make things right for their peers too. In cases where you are unsure, down-leveling is usually the right thing to do as promoting someone within 6-12 months is simpler than demoting them.

A typical scenario as a hiring manager is biasing hiring towards your projects, teams and needs. [This article from Google](https://ai.googleblog.com/2006/03/hiring-lake-wobegon-strategy.html) describes how project/team-driven hiring impacts overall talent quality. As the hiring manager, what you can do to that regard is **calibrate candidates against their potential peer group**. Doing this can help to achieve similar results in talent quality terms to the strategy used by Google. Think of adjacent teams or organisations who have people on the same level that you're hiring for, within the same discipline, and understand the peer group duties, impact, and responsibilities. Doing so will likely reveal how this candidate would fit into the overall picture, thus assuring talent quality across the organisation.

Furthermore, **calibrate interviewers against each other, so you have a weighted average as a measure**. Different interviewers have different criteria to assess people, even with a well-set frame. I have the impression that I tend to often ebb on the bright-side. Others might be much more conservative to risks and tend to recommend "no-hire" where I make " hire" recommendations. The vast majority of application tracking systems have [calibration reporting](https://help.lever.co/hc/en-us/articles/206403385-How-can-the-Interview-Calibration-report-help-me-identify-bias-in-interview-feedback-) which can help to understand how interviewers tend to grade interviewees who got offers, and this can serve as a signal to gauge overall performance quantitatively without going too deep into analysis.

Then, for split decisions, where interviewers have diametrically differing opinions or the uncertainty level is high across multiple stages, **increase alignment and consistency by hosting an interview packet review meeting**. This type of meeting usually consists of bringing all interviewers that attended each stage of the candidate's interview process together, build consensus, and then make a final decision. Usually, it is an excellent opportunity to understand where there might be ambiguity for a criterion within an interview stage, to give feedback to interviewers and receive feedback about the candidate and process, and as a consequence of that,  improve the process and make fairer and more accurate decisions.


___

As previously said, this is just the tip of the iceberg – software engineering interview calibrations are a fascinating subject which likely will require cross-disciplinary efforts from people teams such as talent acquisition and human resources as well as technical input. To assure fairer calibrations and hiring, it is fundamental to continuously assess, measure, and through quantitative and qualitative signals evolve the process.


Assessing who is the best candidate for a role is not in any means a straightforward task. Here are some of my takes on this subject.

Calibrations for software engineering interviews


If I had to pick only one interview method to assess engineers, it would likely be system design. That's not because coding, behavioural, role-play or case interviews are less valuable – they are revealing and help to build a bigger picture of the candidate. If you have resources to create a process that will support diversity, a fair framework to avoid bias, and the time, people and training to run a multi-stage process it will likely reduce the propensity of false positives. Nonetheless, if I were constrained to pick just one, I'd pick system design.

I find the mix between subjective and objective criteria that the system design interview imposes very useful for assessing candidates from multiple angles. There is a reasonably well-set frame for technical assessment, but just coming up with a solid design is not necessarily a pass. Similarly, candidate behaviour has a vital role to play, but the lack of causal nexus and technical-ability can reveal lack of fit to the position quite clearly.

There's a lot of resources out there which are an excellent foundation for the more objective parts. I curated a few of my favourite ones in the [appendix](#appendix) of this article. These deserve great focus when studying for an interview, as they are the most fundamental part of the assessment being made. However, having undergone some interviews recently and practicing it, I thought I'd write about a few points I have learned and that I believe can help on the subjective aspects of it, especially in regards to posture.


### Don't just communicate: collaborate with the interviewers

One of the things I find very helpful in technical interviews is turning it into collaboration rather than just an assessment. The role interviewers are trusted to play fundamentally is assessing whether a candidate is a good fit to be a colleague of theirs. I believe that when you achieve a collaborative atmosphere at the interview you are giving people a much better perspective to assess your fit fairly.

With that in mind, once the interviewer shares what the problem to be solved is, a technique which can help is **rephrasing the objective in your own words.** I find this helps to avoid situations where you presume understanding what is being asked. It is much better to clarify with the interviewer than design the right solution to the wrong problem. Ask questions as obvious as they can sound, and try to engage in gathering all the information you can before proceeding.

As the objective is better defined, it is essential to **establish what is in scope and what is out.** Narrowing down what are the scope boundaries for the interview problem will help you to focus on what matters the most for the design in question. Making compromises on scope early on will prevent you from spending the very little time you have on going deep in off-scope topics of the problem at hand.

When you infer information from what you are told, or when you reach to a conclusion **voice your assumptions and conclusions.** You need to bring your interviewers to see the problem from the angle that you are looking at to make a fair judgement if you are going off track and nudge you on the right direction if it needs to be.

Then, when working on the proposed solution, **avoid turning the experience into a monologue by leaving spaces for feedback**. Interviewers are usually fine to signal when you might be going off-track. Have them contribute to the discussion even if in a non-verbal way, regardless if it is about implications of the design decisions you are making and why, or if it is more specific such as whether you should split a component into two.

In summary, communication goes a very long way for technical interviews. Even further, actively seeking collaboration improves your chances of performing well in the interview, and also helps interviewers gauge whether they would like to work with you – and vice-versa.

### Go wide first and then deep afterwards

It is easy to go deep prematurely as design interview questions are unlikely to fit within the timespan available, conversely to a coding interview, for example, where the problem likely fits within the time available. Nobody will expect you to come up with the perfect solution for a system which is run by dozens, hundreds or even thousands of people – although ideally, you should have a rough sketch to solve the problem end-to-end.

As in real-life systems, the design will evolve. Done is usually better than perfect. **Start simple before going complex by favouring extensibility rather than perfection**. Put forward the most straightforward design which won't pose obvious scalability issues first, while keeping the interviewer informed of your strategy, and then as you cover the requirements, get into more in-depth optimisation.

A way I have found to frame the problem at the right level at the starting point is to **put yourself in the shoes of the user of the system you are about to design.** Basically, talk with the interviewer about the steps the user would take to use the product/system you are designing for the features in scope. Being mindful of the user's needs will help to clarify the characteristics of this system, for example, what are the capabilities which will need public-facing APIs, which components will have higher reads vs writes, or when to ebb on consistency over availability. Looking into the system from a user experience perspective usually hints what is fundamental and will help define a few whys further down the path.

Once you feel like you understood the whole picture, came up with a high-level design and have shown the interviewer you have a hold of the overall problem, pick the part which you are most comfortable with to go deep and explore it. **Focus on your strengths rather than your areas for development.** Most likely, the problem at hand has some exciting scale challenges for any discipline. Pick your favourite aspect of the problem that you can speak deeply of, regardless if it is client-side bandwidth optimisation, data model and partitioning, machine learning infra automation or whatever you want.

That said, resist the urge to get into the detail before you fully understand the problem. Attaining the conversation to motivations and expected outcomes first will help you make more assertive design decisions and make a few whys more evident to both you and the interviewer later.

### Talk about caveats and edge cases

What will happen if your system stops sending data to a downstream system? How do you notify upstream systems to rollback something which was mistakenly changed? How does the system work for the 99th percentile of your power users? These are all questions which can influence your design choices, so thinking of what could go wrong gives you either the opportunity to change it or to confirm that you made the right design decisions.

Especially in large scale distributed systems, you usually will have to optimise for specific characteristics. That inexorably introduces unwanted behaviours – which you need to be aware of to make the right decision. **Talk about trade-offs you've made and why** you chose an approach instead of all the other options you had.

Further, **exploring failure scenarios and recovery options** will show you understand the design that you have committed. This can get especially interesting when you can cover not only system failures but how users could abuse the system, which potential risks are introduced that you will have to accept, or even human error. When possible, talk about how you recover or prevent these from happening.

**Talk about how to make things right when things go wrong**. One example of this is a personal experience where I overestimated capacity in one interview – instead of going with 1GB storage for a free-tier product quota, I went with 1TB. I realised it later in the process, as storage and bandwidth started to feel absurd for the problem at hand with the volume the interviewer and I had committed to. After acknowledging something was wrong, I spoke about the steps I'd take to revert the mistake if this went live such as keeping users who signed up to the 1TB proposition with the benefits they paid for indefinitely, talking to teams responsible for advertising and intake about the mistake, and other damage control activities that could be done. I think this turned out to be an even more interesting conversation than it would be if I had calculated the right capacity at first.

In short, things will go wrong at some point – displaying readiness on walking the not-so-happy path will increase your confidence in your design choices, and if you made a wrong decision, you still have time to adapt and make it better or at least acknowledge it.

### Touch on adjacencies of the problem

Again, given the system design interview is extremely time-constrained, you need to be mindful of what you want to emphasise. Whilst it is great to have a narrow scope to work through, touching lightly on adjacent topics to the design itself can show even further breadth of knowledge. Here are some examples of subjects to cover, which might be off-scope but can increase the number of signals, thereby increasing your chances of performing well.

I believe most engineers appreciate that operating large scale systems is very hard. I personally like to **cover operations, not only design**. Especially at large companies, where you usually have dedicated infrastructure engineering functions, it is easy to take a lot of ops for granted. Briefly talking about subjects such as alerting, monitoring, tracing, observability can reveal problems on scaling a specific design.

Especially for highly regulated environments such as payments and abuse prevention, touching on **security, compliance & regulatory constraints** can be a plus. Some ideas of subjects to touch upon are data retention or data anonymisation for systems with personally identifiable information, or risk management by splitting components in different networks which are in scope for audits.

Maybe a subject more on the technical leadership or management side, design decisions will inherently dictate how teams will be mobilised for specific domains. A pretty large upside of microservices is making scaling independent – people and organisational design included. Talking about how the design will likely impact **how you mobilise folks in the set of teams owning the design** and showing awareness of scaling not only infra and systems but also organisations can spark engaging conversations.

My examples here are highly biased to my own experience, but making a short aside whilst you cover something within the scope of the interview can serve as an additional signal and increase the interviewer's confidence in you.

___

In closing, it is worth noting that all of these tips are based on my own experiences and preferences. Different organisations will focus on different things, and your best starting point is understanding the expectations of the company you are applying to. I believe incorporating the topics above to my posture when interviewing has helped me, and I hope it will help you too.

___


### Appendix

Below I've added a small appendix for some resources on the technical side of things. I hope you like it!

- [Grokking the System Design Interview](https://www.educative.io/courses/grokking-the-system-design-interview) course by [Design Gurus](https://designgurus.org) at educative.io;
- [Designing Data-Intensive Applications](https://dataintensive.net/) book by Martin Kleppmann;
- [System Design Primer](https://github.com/donnemartin/system-design-primer) by Donne Martin;
- [High Scalability](http://highscalability.com/all-time-favorites/) blog;
- [How the Web Works](https://github.com/vasanthk/how-web-works) by @vasanthk;
- [SuccessInTech's](https://www.youtube.com/c/SuccessinTech/videos) YouTube channel;
- [TechDummies'](https://www.youtube.com/c/TechDummiesNarendraL/videos) YouTube channel;
- [How we've scaled Dropbox](https://www.youtube.com/watch?v=PE4gwstWhmc) video;
- Amazon's [DynamoDB](https://www.allthingsdistributed.com/files/amazon-dynamo-sosp2007.pdf) paper;
- Google's [MapReduce](https://static.googleusercontent.com/media/research.google.com/en//archive/mapreduce-osdi04.pdf) paper;
- Google's [Hypertextual Web Search Engines](http://infolab.stanford.edu/~backrub/google.html) paper;
- Google's [GFS/Google File System](https://static.googleusercontent.com/media/research.google.com/en//archive/gfs-sosp2003.pdf) paper;
- Facebook's [Cassandra](https://www.cs.cornell.edu/projects/ladis2009/papers/lakshman-ladis2009.pdf) paper;
- Facebook's [TAO, a social graph data store](https://www.usenix.org/system/files/conference/atc13/atc13-bronson.pdf) paper;


Some ideas on how to perform better in the behavioural and subjective bits of my favourite technical interview type: system design.

Software Engineering

Platform patterns #1: Consolidation

System Design: Capacity Planning basics

Calibrations for software engineering interviews

Posture in system design interviews