Showing Your Vantage Point

Learn how to demonstrate that you are fit for a role through your unique vantage point.

We’ll cover the following

From junior engineers to managerial roles, each role has a unique point of view, perspective, or in other words, vantage point that they have on a system’s design.

Showing your vantage point

Once you’ve completed a high-level design, you can then move on to discussing more detailed aspects of your design. While it’s easy to naturally gravitate toward your own interests or specialization, you’ll be expected to touch on specific talking points depending on the level of the role to which you’re applying. If you’re unable to demonstrate a vantage point specific to that role, you may be at risk of being down-leveled.

How each level’s vantage point differs

While the kernel of an answer may stay the same, the vantage point of an engineer changes based on their level.

A junior engineer will usually get into the details of a few components (for instance, how they’ve optimized their system to store, retrieve, modify, and delete large amounts of data). They will not be able to think about the more far-reaching implications of their design, and that’s generally acceptable given their level. On the other hand, the expectations for a senior engineer reach far beyond these starting points. A more senior engineer can see the bigger picture. They won’t necessarily go into the details of certain optimizations because they know they have a team of engineers helping them. Rather, their unique input for the design of the system will be tailored toward making the system more scalable and resilient. As you get more experienced, interviewers want to see that you have the foresight to design a system for the future. There’s no sense in designing a system that will be obsolete by the time you ship it. A junior engineer might get away with that, but a senior engineer cannot. For instance, if a senior engineer is asked to design a post search feature for Facebook today, and they currently have 100 million users, they should design a system for maybe a billion users so that the system can last a few years or decades.

A principal/distinguished engineer has even more insight into how to make a system successful, even if unforeseen problems arise. Because problems are inevitable, they must address how to scope the problem and limit its impact. They must be able to mitigate them. They’ll be concerned with making the system easily debuggable and maintainable in the face of many issues, such as a prolonged system outage. They also consider how problems impact broader concerns that are crucial to the business—for instance, the impact of a privacy breach on user experience and product reputation. The ability to address unforeseen circumstances shows that an engineer understands real-world problems. You can’t always rely on power backups to prevent outages. Your data center could be hit by lightning. It could even catch fire. Then what would you do? Obviously, you cannot code against natural disasters. If a big hurricane hits your data centers, no amount of software can protect them from going down. But you can design your system so that data centers in different parts of the world can take over the load when others are down. This is called regional failover.

Talking points for each level

What you discuss in the interview will be different based on your level. As your level goes up, you’re expected to quickly address the topics of the previous levels, as well as the more advanced topics expected for your level. The following table expands on the expectations of different roles during an interview:

Levels	Talking Points
SWE-I/SWE-II	Describe the basic components of the system Dive deep into 1-2 areas Discuss trade-offs
Senior engineer	Describe components and their interaction Describe the complete lifecycle of a request (e.g., from client to server to back-end services) Drive the conversation toward diving deep into components Explain and align the trade-offs with the desired product goals and user experience
Staff engineer	Describe components and identify the critical components Identify potential choke points and bottlenecks Identify future problems as systems need to scale and offer solutions Demonstrate an ability to build a solution for immediate needs while keeping in mind potential improvements that will help scale in the future Describe failover (e.g., talk about recovery paths when machines fail) Talk about the user experience when failures happen and how that impacts Service Level Agreements (SLAs) Think about privacy across the product (e.g., GDPR compliance)
Principal/Distinguished engineer	Discuss real-world implications of the solutions deployed Talk about data center failovers, regional backups, and disaster recovery Talk about usage patterns (e.g., query patterns, peak loads, handling DDOS attacks, and graceful degradations of the service) Talk about the negative impact on the company’s reputation in case of security breaches and service outages and how to manage those SLA expectations
Technical project manager/Project manager	Discuss how scalable systems work (e.g., Facebook storage systems) Discuss core concepts and building blocks of a distributed system and how they interact with each other at an abstract level Talk about how budget, stakeholder commitment, and other variables will affect the technologies they choose to use

What if I don’t have knowledge in a certain area?

You might be asked follow-up questions that surpass the limits of your knowledge. Your interviewers might challenge what you’ve said or simply ask your thoughts on an area in which you don’t have an adequate depth of knowledge. In these cases, being honest with your interviewer is always better. Being honest will result in a far better use of your interviewing time. If you’re honest about things you don’t know upfront, then an interviewer can assess your knowledge in different areas instead. You’re not expected to know everything. You just need to know enough to show that you can design a system collaboratively. People sometimes feel they have to pretend to know the answer to every question—but this can get you into more trouble if you lack the knowledge to answer well.

Remember: There’s nothing wrong with allowing you and the interviewer to move on to another topic by saying, “I’m sorry. I don’t understand [x] at this level. My understanding is quite superficial and I honestly don’t know more about it at this time.”

Owning your vantage point

In summary, some takeaways to remember are:

Target the talking points that are appropriate for the level of your desired role.
- Junior level candidates address the basic workflow and interactions between components.
- Senior level candidates address the broader consequences of their design choices.
Be honest about your knowledge gaps.