Search
⌘K
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.
Recommended Reading
Hello Interview Premium
Reading Progress
On This Page
Your account is free and you can post anonymously if you choose.