Over-engineering is getting you down-levelled
By Stefan Mai
•
We're seeing a lot more down-levels lately to top companies where candidates are expecting a senior role and get an offer for mid-level, or angling for staff and get a senior-level offer.
Some of this can clearly be attributed to the market and down-levels have always been around especially for transitions between companies of different sizes, but as a candidate you have a lot more control over this than you think.
In system design interviews, the evaluation is partly subjective: how does the interviewer feel you did? Do you seem like one of their (mid-level, senior, staff) peers? Many candidates assume if they correctly bring in Elasticsearch to the search problem or use a distributed queue to handle burstiness they necessarily got the nod — but this unfortunately isn't the case.
One of the most common ways to get down-levelled in system design interviews is to over-engineer. Over-engineering is a classic sign of a more junior candidate and frequently comes from overzealously applying a new (to you) technique or technology to a problem where it's not appropriate. This sticks out like a sore thumb to your interviewer because:
-
You're almost always missing something. The more technologies and approaches you bring to bear on a problem, the more likely you're making mistakes.
-
The maintenance overhead is huge. Companies are all trying to bring in costs and having a candidate who wants to drag in many new technologies to solve a simple problem can be a red flag.
-
More moving parts means more mistakes. Senior engineers have seen all the ways that cleverness can make their job a nightmare over time.
-
It's difficult to cover the details. Interviewers are on red alert for name-dropping and referencing stuff you don't know.
So, what should you do?
First, simplify where possible
Senior+ candidates ask themselves whether something simpler can get the job done before adding complexity. In interviews, it's a good idea to start with the most basic design that satisfies your functional requirements before loading up on fancy optimizations that might not be necessary.
Note for staff candidates: Skipping some of the more obvious or boring parts of this is expected, bonus points if you can explain why a more technically sophisticated approach is actually not necessary.
Next, research the downsides
You just learned about Redis? Great! Now you know what things it can do for you in a design. Before you yeet it into your next interview, go find the issues! Did you know Redis' full-text capabilities can bring your key-value gets and sets to a crawl (it's single-threaded, remember)? Do you know how to bring a Redis instance back up after a crash (append-only files only go so far)?
Lastly, learn the details
You don't want to be caught flat-footed by your interviewer when they ask you to explain your decision. Our deep dives are a great way to get the 80/20 of the depth you need, but nothing compares to working with a technology firsthand.
Here's some great deep dives to get you started!
Mark as read
About The Author
Stefan is one of the co-founders of HelloInterview, a platform to help software engineers and other tech professionals to prepare for their dream roles. He's conducted 1,000+ interviews and hired dozens of individuals at big companies and small startups.
Your account is free and you can post anonymously if you choose.