This post is part of a series titled, “How to Select Your Next Job”. I’d love to hear your feedback in the comments section below!
If you’re in the process of seeking a new technical job as a Software Engineer or Engineering Manager, you’ll likely have to do a System Design interview. The interview involves solving a high-level technical problem (e.g. designing some well-known product or service) and demonstrating your technical experience and intuition for coming up with a solution.
Currently, with the global pandemic and the work-from-home environment (in 2020/2021), tech companies are conducting these interviews over VC, which introduces some challenges for the interviewee. Most candidates have extensive experience interviewing in-person on a white-board, but are new to being interviewed for system design over VC. The purpose of this article is to help you best prepare and do well during these interviews.
Why are Remote System Design Interviews Challenging?
There are several reasons why doing a system design interview remotely over VC is challenging:
1. Unfamiliar setting and tooling
When you do a remote system design interview, you must utilize a different set of tooling (Bluejeans for VC, Google Draw or an equivalent in place of a whiteboard).
- Most candidates are fairly experienced at white-boarding a problem/solution to a technical problem. You can quickly draw boxes and label diagrams on a whiteboard and adjust the size easily.
- While doing an interview over VC you’ll have to use a tool like LucidChart or Google Draw, that you might not be as familiar with. As a result, drawing and configuring diagrams (e.g. sizing them correctly, adjusting fonts, etc.) will slow you down.
2. Communication latency
Communication can be challenging because of network latency on VC, as both you and the interviewer may inadvertently interrupt each other while discussion is ongoing.
3. Interviewer inexperience and lack of calibration
Most of the interviewers you’ll face will have extensive experience with interviewing candidates in person, but have more limited experience with interviewing over VC. As a result they’re likely to be less well-calibrated in evaluating remote interview performance.
4. Lack of tactile feedback from the interviewer.
In a normal face-to-face setting, the interviewer can easily jump in with her/her own marker and work with you on the problem or provide clarification for points of confusion. This is significantly more challenging and less natural to do in a remote setting.
Opportunity for Preparation
However, the fact that your system design interview is being done in a remote fashion, does give you the opportunity for preparation. This document will highlight some tips to help you set up and prepare for an optimal remote interview session.
Monitor and Sizing
Monitors. I recommend that in preparation for remote system interview, you have two monitors set up, one for the Bluejeans/Zoom video itself as well as the Components Setup scratchpad (see below), and one other monitor for the actual Google Draw / Lucidchart where you’ll conduct the system design interview. I also recommend getting a desk lamp and move the interviewer’s video overlay close to your video camera so you make eye contact when looking at them.
Sizing. Play around with the size of your drawing canvas ahead of time. In a normal face-to-face interview, you have an entire large whiteboard that you are free to utilize. However, I’ve observed a lot of candidates spend precious interview time resizing their canvas to create more space as the interview progresses.
To avoid this, you should set the size of the canvas to be as big as possible such that the default font is still visible on a full-screen VC screen share. If you’re using Google Draw, I personally recommend pre-setting the page to be Custom, 30 in. by 20 in (see below).
Pre-set Components
When using Google Draw or Lucidchart, interviewees often end up struggling to draw components quickly. Since your goal in the interview is to as quickly as possible convey conceptual concepts to the interviewer, you don’t want to waste time playing around with the tooling during the interview. In the face-to-face setting, when working with a whiteboard, you can easily draw a square/rectangle/cylinder however large you’d like and draw inter-connected arrows easily. However in a remote environment, I often see candidates spend all their time dragging and dropping boxes, resizing and adjusting colors in order to get it to show up appropriately onto the canvas.
To help mitigate this, I recommend for candidates to prepare a set of “pre-set” interview components that they can quickly copy-paste onto the interview canvas as needed, simply by using “cmd-c, cmd-v”. One of the good things about using Google Draw is that copy-pasting components works across Google Chrome browsers.
Here’s an example template that includes commonly used components for system design interviews (just to give you an idea). You can include:
- Text boxes (copy-pasteable to discuss one specific aspect of a system design)
- Math Computation. In case you want to do some math around # of machines or $$ cost required to solve a problem.
- Cache Definition. If you’re asked to provide what a cache looks like.
- Schema Definition. If you need to do some schema definitions.
- API Definition. In all likelihood you’ll have to define a protocol between two different components/services.
2. Components (easily copy-pasteable into an interview): Databases, Services, Clients, Caches, Queues, etc.
By preparing a templated set of “components” that you can easily copy-paste into your interview window as needed it ensures: 1) You spend a minimal amount of time conveying your ideas across to the interview and 2) That you hit all of the key points you want to talk about for a given topic (ie. for schema definition, api definition, match computation, you don’t forget any of the standard things you want to cover).
During Interview: Guiding and Collecting Feedback
Keep in mind that the purpose of the interview is for you to help the interviewer collect the signal rather than for you to arrive at the “right answer”. This means that even if you have the perfect answer, but either your interviewer doesn’t grok/buy into it or you fail to communicate in a way they understand, then you’ll fail the interview all the same. For example, if you design the perfect system that uses all common / open source software (e.g. kafka + Redis + EC2 + Docker + Redshift, etc.) but your interviewer has worked his/her entire career at Microsoft or Facebook, and has never heard of these concepts, then it’s likely you won’t achieve success in the interview.
While shadowing interviews, I’ve observed a common failure pattern where a candidate spends most of the interview talking non-stop only to have the interviewer not get a chance to cover a major piece of signal or follow-up to the interview question they wanted to collect signal on.
However, this doesn’t mean that as an interviewee you should be passive — the interviewer is still expecting for you to drive the conversation. Let’s go through some techniques you can use to ensure that you thread this needle to success.
Expectation-setting
To ensure that you cover parts of the problem-space that the interviewer cares about, ensure that you level-set during the interview, but do so in a proactive way that gives him/her the impression that you have a broad set of capabilities. Here are some example level-setting statements you can make during the beginning of the interview:
- “This is a very interesting problem that has many different facets. Just off the top of my head, we can talk about API design, doing some computation scale analysis, data modeling for storing the Tweets, I can also talk about how to scale this or how to handle whale users. Is there a specific area you want me to cover first or dive deep into?”
- “Before we start, I’m going to spend 5 minutes quickly doing some back-of-the-envelope calculation to figure out how many PetaBytes of in-memory cache and hard storage we need. Does that sound good to you?”
- “After I talk about the storage layer, I can either talk about how to scale this up for billions of users or I can talk about authentication and security. I think the former is more intellectually interesting, but do you have a preference?”
- “Coming from a startup background, I’m intimately familiar with the AWS stack (redshift, EC2, S3, Cloudflare). Are you okay if I proceed using terminology from that?
In each of the above examples, you’re collecting signals from the interviewer about his/her general expectations, while also staying in the driver’s seat of the interview. This allows you to project an impression of being very broad and versatile, while also making sure you don’t waste much time covering any areas the interviewer is not as interested in.
Familiarize yourself with the company’s tech
If the company you are interviewing at has built a ton of technology in-house, it’s important that you spend some time researching what the in-house technology versions are. This is especially true if your interviewer has been at the given company for a long time (e.g. a 12-year Microsoft or Facebook veteran).
For example if you’re interviewing at the following companies, it’s probably good to familiarize yourself with some key terms (non-exhaustive):
- Google: Spanner, BigTable, Hadoop, Firebase, Angular, TensorFlow, etc.
- Facebook: Presto, React/Native, Scribe, Scuba, Cassandra, HBase, HipHop, Hacklang
- Microsoft: Entire Azure stack, SQLServer, CosmosDB, Azure
- Amazon: You should know AWS like the back of your hand, RDS, Redshift
Even if you don’t understand a given technology in-depth, literally just knowing the term can be helpful to quickly resolve understanding gaps during the interview. For example, if a Facebook interviewer asks you, “What’s Kafka?”, you can respond quickly with, “It’s basically just what you guys call Scribe”.
Constant Checking-In
In general, interviewers are trained to not reveal too much signal with respect to whether you’re doing well or not during the interview. It can be challenging to know if you’re missing something or going into sufficient depth on a specific portion of the interview (e.g. Did I cover the data model schema in enough detail? Should I write an immutable version of this API definition?).
To ensure that you’re covering the key points and giving the interviewer sufficient signal, you should constantly check-in with the interviewer to ensure that you’re on the right track. Here are some things you can say:
- “I’ll pause here and see if you have any questions.”
- “Would you like me to write out the full API definition, or just go over it a very high-level or just move onto X?”
- “This specific design does have some weaknesses however, it does heavily sacrifice latency/performance for future extensibility and cleaner abstraction. Would you like me to quantify precisely how much or propose an alternative solution that reverses this trade-off?”
- “I front the database call here with a Redis LRU cache, which under the hood is implemented with a LinkedHashMap data structure. Would you like me to explain/explore the specifics of how this works under the hood?”
Pre-Interview Checklist
To recap, here’s a checklist that you should just quickly go through before you jump into your system design interview. Set aside 15–30 minutes prior to starting your full slate of interviews to ensure that you go through each:
- Have two monitors set up, one is your main (interview canvas), and one is your side (put your templated components).
- Do a quick copy-paste test between your “templated components” to your “main interview canvas” to make sure your clipboard is working.
- Practice dialing in and sharing your screen using the given VC software the company’s provided (Bluejeans, Zoom, Webex, etc.).
- Go to the bathroom if needed.
- Set the interview canvas side as appropriate (30 in. by 20 in. for Google Draw).
- Look up your interviewer ahead of time on LinkedIn (usually your recruiter gives you interviewer information).
References and Reading
You made it to the end of the guide! Good luck with your interviews.
