Ognjen Regoje bio photo

Ognjen Regoje
But you can call me Oggy

I make things that run on the web (mostly).
More ABOUT me and my PROJECTS.

me@ognjen.io LinkedIn

As silly as it sounds, system design interviews are about systems and design

#interviewing #system design interview

Over the past year or so I’ve done about two dozen systems design interviews (as an interviewer) and have two somewhat subtle observations that would help some candidates.

1. The word system has two meanings

The definition most engineers reach for immediately is the one relating to computers.

But the organization itself is a system, in a generic meaning of the word.

It’s important to consider the organization for two reasons:

1. Its structure informs the computer systems

Boundaries between domains are often strong indicators that boundaries between computer systems should also exist. Conway’s law and all that.

2. Tech exists in service of the business

Putting systems in the context of the orga demonstrates the understanding that business requirements take precedence over technical convenience.

These two considerations get considerably more important with seniority.

While junior developers often don’t consider the organization, their area of influence is local so it’s not too relevant to their everyday work.

On the other hand, staff+ engineers who are supposed to influence entire domains or even the whole organization must understand this.

2. The interview is about design

Several candidates shy away from designing a system using tech they theoretically know about but wouldn’t be able to implement themselves.

It mostly happens to senior engineers who are in a transitionary phase to staff where they have a wide overview of tech and understand much of the implications to the organization. They have an overview of a lot of tech and can discuss tradeoffs. But, they do not have hands-on experience in all of them.

Secondly, candidates often don’t appreciate that design is iterative. As the interview progresses the experienced engineer re-evaluates assumptions, re-checks constraints and iterates. Components are changed, replaced or removed entirely. The less experienced candidates typically just add components.

And finally, design is about trade-offs. What are you willing to sacrifice and, most importantly, why? As you’re making trade-offs it’s the process you go through to make the call that’s being evaluated.