Communications

Highlighted from System Design Interview Fundamentals, Chapter 4

Improve Public Speaking

A system design interview has a lot to do with how you present yourself.
If you don’t speak clearly and at a good pace, it can make the interviewer switch off, just like people falling asleep during a boring presentation.
It is worth investing in public speaking techniques like pacing, enunciation, modulation, body language, and confidence.

Keep the Requirements Simple

many candidates attempt to get that offer by intense studying … While the real-life signals are interesting, it unnecessarily complicates the interview by looking at many signals with different system complexities.

Don’t Do This: “I will use Facebook edge ranking that takes into account affinity, weight and decay. For affinity we need to store the score between friends. For weight we need a configuration for different post types and we need a cronjob to periodically decay the score.” …

Do This: “I know Facebook uses EdgeRank to calculate each feed’s score. For now, we’ll assume the scores are computed and stored. If we have time, we can come back and see how we can update the scores as things change. Are you ok with that approach?”

Conclude and Make a Stance

In an interview it may be difficult to decide on the preferred option when coming up with options and trade-offs. Leaving the options in the air with an inconclusive attitude will make the interviewer think, Ok, so what’s your preference?
Senior engineers need to be able to deal with ambiguity and take a stance. Making a conclusion is your opportunity to demonstrate that attribute. Use the agreed-upon assumptions to strengthen your reasoning.
In addition, you will need to build designs on top of previous designs.

Don’t Do This: “So there are option 1 and option 2 with the trade-offs so it really depends on the use cases.”

Do This: “So there are option 1 and option 2 with the trade-off. I’m going to assume the users only visit the site once a day so I will pick option 2 for this design, is the assumption fine with you?”

Articulate Your Thoughts

The system design interview is not a race to spit out the final perfect solution.
It is a process of identifying important bottlenecks and problems, coming up with options, and justifying your design.
Sharing your thought process is the majority of what the interviewer is looking for.
- Even if you are able to identify exactly what technology uses, you will still fail the interview if you don’t justify your thoughts because it is all contextual to the assumptions you make with the interviewer.

Don’t Do This: “I will use a wide-column store.”

Do This: “I will use a wide-column store because the write to read ratio is extremely high with 100k write QPS where I expect a RDBMS to not perform as well. Also, based on the time series nature of the query, wide-column is a better fit because of disk locality.

Control the Interview

During a system design interview, you will be doing most of the talking, and you want to be driving the interviewer in a favorable direction.
- For example, if there are multiple potential talking points during the deep dive and you are more familiar with databases than concurrency control, optimize your time and drive toward that direction where you would be discussing the database.
But also be aware that sometimes the interviewer may still stop the flow and ask you to focus on a particular direction. You have to go along with their flow since they’re looking for something particular.
There are many ways to pass an interview, but having structure will make your presentation much stronger.

Listen to the Interviewer

We can not emphasize enough that you need to be able to read the room and get a good sense of what the interviewer is expecting.
- Any system design question can go in an infinite number of directions, and sometimes the interviewer may just let you talk or interject with a direction they would like to go in. Listen very carefully!
If you’re unsure about what they’re asking for, try to clarify it. And after you have answered their question, you should get a confirmation of whether you’ve addressed the interviewer’s concern. Not doing well here will lead the interviewer to think that you don’t listen well and not get the data points they’re looking for.

Situation: Interviewer: “Tell me more about the queue.”

Don’t Do This: “I’m using a Kafka queue because it is scalable. Now back to sharding, I would shard using user_id.”

Do This: “Would you like me to discuss what kind of queue I would use and why, or talk about the scalability aspect of the queue?” “I would use a Kafka queue because the replay capability is useful for this streaming question in case the aggregator goes down. Should I go deeper into scalability or is there any direction you would like me to go in regarding the queue?

Talk Over the Interviewer

Driving the interview is a leadership quality the interviewer looks for. However, you need to make sure you periodically check in with the interviewer to make sure you both are on the same page.
That doesn’t mean continuously talking so the interviewer doesn’t have a chance to speak. And it also doesn’t mean that when they do start speaking, you should interrupt them halfway through their statement. Not only is it rude, but you won’t be understanding what the interviewer is looking for. In addition, if you talk over the interviewer, it doesn’t matter what you’re saying, they won’t be listening.

Show Confidence with Your Justifications

During the interview, you should try to show confidence in your design instead of appearing unsure about your proposal.

Of course, if you are really stuck and genuinely unsure, you can try to take a hint from the interviewer instead of faking it as if you know it.

The point of showing confidence is that some candidates lack confidence throughout the interview even though they already have reasonable options, which usually leads to a low behavioral score

Here are some common phrases that show a lack of confidence and are indirectly asking for hints from the interviewer:

“Do you [the interviewer] think this design would work?”

You shouldn’t ask the interviewer whether it’ll work since you shouldn’t be designing for something that doesn’t work.

“What do you think about the solution?”

You should be the one thinking about the solution. The interviewer is there to evaluate your thought process but not to share their own thoughts about the solution.

“Am I missing anything?”

Ideally, you shouldn’t be missing anything, so this sounds like you’re unsure if you’re comprehensive and asking for a hint.
So instead, say, “Here are the considerations I can think of. Should I continue to dig deeper and move on to the next topic, or is there anything else you would like to cover?”

“Am I heading in the right direction?”

There’s no right or wrong direction. If you intend to gauge whether it’s a direction the interviewer wants you to go, you can ask, “Is there a direction you would like me to head to?”
Instead of “asking for a hint,” you should demonstrate what you can think of first and conclude with: “Here are the options and trade-offs I can think of and would pick option 1 because of the assumptions. Is there any direction you would like me to go into?”
Sometimes the interviewer might already be satisfied with your answer, and if there’s any missing part, the interview might bring it up.

Resolving Disagreement

When the interviewer appears like they may be disagreeing with you or is skeptical of your answer, they may or may not be, but you need to be very careful here. Here are a couple of possibilities:

Possibility 1: They Propose a Solution

Just like in real life, when other engineers propose solutions, you need to listen to the proposal and try to decide if it’s better or worse with the assumptions.

The interviewer may sometimes propose an alternative solution to see how you react. For example, they may say, “Instead of doing a push here, why can’t you do a pull instead?”

It may be in a direction you didn’t think of, so you should digest it and come up with the pros and cons and rethink your conclusion.
It is acceptable ot to pick their solution based on your trade-off discussions.
But if you’re “wrong” about your solution and continue to be adamant about your initial choice, it will look bad.

Possibility 2: They Seem to Like Their Solution

If the interviewer is inclined toward their solution and you want the job, don’t get defensive or argumentative.

If they seem to disagree, it is likely the assumptions you two are basing your thoughts on are misaligned.

Try to neutralize the disagreement by taking a neutral stance and acknowledging where they are coming from.
Understanding the interviewer is extremely important because many candidates have been rejected for not managing the conflict well.

For example, imagine the interviewer thinks a driver location update every 30 seconds is too infrequent, leading to a terrible experience for a ridesharing application.

If you disagree, you can neutralize by saying, “I understand your concern is the freshness of location. In practice, we can experiment with different update rates through A/B testing and adjust accordingly. For now, we can go with a more frequent update.”

Don’t make the interviewer look bad. Try to understand where they might be coming from. But, of course, don’t always give in to whatever the interviewer says. You need to have some backbone as well. Just make sure there are strong justifications for your stance.

Discussion Point With Trade-Offs

For a system design interview question, there are usually a couple of core discussion points. For those discussion points, it is helpful to bring up a couple of options, discuss each option’s pros and cons, and sell the interviewer on your final choice.

If you just describe what you’re going to do, it doesn’t give the interviewer confidence that you’ve considered alternatives. It also makes you look like you’ve just recalled a solution you’ve memorized from a blog or other prep material.
Coming up with alternatives with pros and cons and picking a final candidate also demonstrates your ability to deal with tough design dilemmas where there isn’t a strictly better solution.

Don’t Do This: “To design for a ridesharing service, we need to update the drivers’ location. To update the driver location data, I am going to send the driver location every 5 seconds and we will update the location data into a quadtree.”

Do This “To design for a ridesharing service, we need to update the drivers’ location. There’s a trade-off to be made based on the frequency. The advantage of higher frequency is more accurate data but the system will need to handle a higher QPS and vice versa. While accuracy is important, it isn’t the end of the world if the assigned driver isn’t globally the best so we have some room. Let’s start with 20 seconds per update and readjust if we need to.”

Quality Over Quantity

Interviews are short. Avoid the trap of discussing many requirements in a handwavy manner and focus and deep dive into that core requirement.

It is more important to demonstrate your ability to identify the most important topics to talk about than demonstrate breadth on a shallow level.

Don’t Do This: “Here are the requirements I can think of. When the rider opens the app, the rider can see all the drivers around them. We can call the location service and we can use a quadtree for that. We can match the riders with drivers, the drivers can have different tiers of cars, we can pass and store the driver metadata. When a user requests for a ride, we can show the rider the ETA and we can call the Google Maps API for that.”

Do This: “Above are the requirements I can think of. I am only going to focus on the rider and driver matching part for now. If we have more time, in the end, we can go through more requirements. I will go over the API, high-level diagram, and deep dive into any interest areas for this core use case. Are you ok with that?”

Math With a Purpose

the interviewers aren’t looking to assess your basic algebra skills. Instead, use the results to justify your design choice.

Also, candidates often try to perform back-of-the-envelope calculations after gathering the initial requirements and before API, high-level diagram, and schema design. Early math calculation is quite dangerous because without defining all the APIs and schema, you might only be calculating the number for one of the APIs. In addition, your storage capacity calculation might be inaccurate since you haven’t finalized the schema.
The purpose of the back-of-the-envelope calculation is to demonstrate your ability to make reasonable assumptions and derive a result to justify a design you’re going to make.
For example, if you decide you want to start sharding the database or introduce a cache layer, calculating the QPS and identifying the system has a high QPS can be one of the factors to justify your desire to partition or introduce a cache. If the QPS is low, proposing database partitioning is introducing complexity with no benefit.

Don’t Do This: “I’ve calculated the QPS is 100k and storage is 20 PB, let me talk about the API design now.”

Do This: “ I’ve calculated the QPS is 100k, looks like we will need to scale our app servers since each app server I’m assuming can only take 30k QPS.”

Focus on the Right Things

After you’ve clarified the requirements and are diving into a requirement, there are still many technical components you can discuss. There are a few core design points unique to a requirement. While you’re not a mind reader into what the interviewer is thinking, we need to develop intuition to focus on what matters.

For example, suppose the interviewer asks you to develop a private messaging system to enable one-on-one chat, while authentication is important. In that case, it is a waste of time to spend 10 minutes on how OAuth 2.0 works.

There are two caveats.

The first caveat is when the interviewer specifically asks you to focus on an area. Then you need to adjust the course to accommodate their expectations.
The second caveat is when the interview is domain-specific, like security, where the heart of the problem changes.

Don’t Do This: “To design an e-commerce checkout API, we need an API to call the API Gateway. For this API, I will use TCP/IP instead of UDP because of reliability. I will call the authentication server first to fetch the security token. There will be a load balancer to handle my request and I will use a round robin algorithm instead of session based because it is simpler to keep the load balancer stateless and it scales better. I will make sure I have TLS set up for Https.”

Do This: “To design an e-commerce checkout API, we need to ensure it is available and low latency because there are studies that show low latency and availability result in greater profit. I will focus on the signature of the API, how different services interact with each other, and the schema of the storage layer to ensure we meet the low latency and highly available requirements.”

Spewing Technical Details With an Intention

While knowing the ins and outs of how a piece of technology works is impressive, spewing details about how a specific technology works without an intention isn’t helpful in a system design interview.

Technical knowledge is only impressive if you’re able to apply it to justify a chosen design.
For example, when the interviewer asks you to design a chat system network protocol, instead of spewing the deep technical details of WebSocket, focus on a couple of network protocol options and describe how the technical details of the chosen solution help solve the requirement at hand.

Don’t Do This: “I would use WebSocket to establish the connection between the client and the API gateway. WebSocket is a channel over HTTP through TCP connection, allowing client and server to communicate bidirectionally. …

Do This: “Our requirement is to have a seamless chatting experience where users should receive the sent messages almost instantaneously. For this we have two options, we can have the client periodically pull from the server or establish a WebSocket connection. Since WebSocket establishes a bidirectional connection between client and server, it allows the server to push new messages immediately to the client. This is better than a periodic pull that would result in a slight delay.”

Don’t Jump Into a Real-World Design

Studying for a system design interview is challenging. Most people study by reading technical blogs, watching tech talks, and exploring other materials for design ideas. Please don’t start memorizing and retelling a design that you’ve read somewhere.
Instead, apply the fundamentals and articulate how the learned fundamentals are related to your current design.
You might face unique requirements and nonfunctional assumptions in a real interview, so the same design might not apply. Also, it’s obvious when a candidate memorizes a solution because they are not flexible.

Don’t Do This: “I will use Cassandra to build the chat application and use Snowflake to generate the ID as a cluster key because that is a well-known design.”