Showing Your Vantage Point

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:

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.