Over-engineering is getting you down-levelled
Avoid this junior mistake at your peril.
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!
Changelog
People are constantly asking us what’s new with Hello Interview, so we’re going to keep a changelog here to keep you up-to-date. Since our last update:
Platform Updates
New Content
Distributed Cache Problem Breakdown
Numbers to Know Deep Dive
🆓 DynamoDB Deep Dive Video
🆓 Recommendation System Basics Video
Content Updates
🆓 Clarity updates for Whatsapp and FB Live Comments
We’ve got more coming down the pipe that we’re excited to share in our next update!
You can vote for what content you want to see next here.
Until next time!