Why trying to sound senior by adding complexity is the fastest way to fail a technical interview.
In one of my interview out of 23 I gave last year, I was asked to design a simple notification system for a startup. I wanted to look like a senior engineer, so I started drawing boxes for Kafka clusters, stream processing engines, and multi-region database replication. I thought I was showing depth. In reality, I was showing that I didn’t understand how to solve a problem with the least amount of complexity required. The interviewer didn’t want a system that could handle the traffic of Netflix. They wanted a system that could be built in a week and maintained by 2 people. I learned that senior engineering is all about when to not use tools.
Here’s what they asked
The company was a series B fintech startup in the Flatiron district. The round was system design. The interviewer, a guy named Mark who looked like he hadn’t slept since the series A, gave me a straightforward problem.
“We need a service that sends transactional emails and push notifications,” Mark said. “Things like password resets, order confirmations, and marketing alerts. We have about fifty thousand users right now, and we might double that in a year. How would you build this?”
I had spent the entire weekend reading about distributed systems. I had watched every YouTube video on “How to design Twitter” and “How to scale to a billion users.” I was ready to be a senior architect.
The over-engineered architecture
I didn’t start with the requirements. I started with the buzzwords.
I drew a Kafka cluster right in the middle of the whiteboard. I told Mark that we needed to decouple the producers from the consumers to ensure maximum throughput and durability. I suggested using a stream processing engine like Flink to handle the notification logic because we might want to do real time analytics on the delivery rates.
For the database, I proposed a globally distributed NoSQL store. I argued that as the company expanded internationally, we would need low latency access to user preferences across different regions.
I even suggested breaking the service into four separate microservices: one for the API, one for the email worker, one for the push worker, and one for the analytics aggregator.
I felt great. I looked at the board and saw a masterpiece of modern engineering. I looked at Mark and expected him to be impressed.
He was just staring at the Kafka box with a look of profound exhaustion.
The interviewer’s reality check
Mark asked one question:
“How many engineers do we have to manage this Kafka cluster?”
I didn’t have an answer. I said we could use a managed service.
“Okay,” he said.
“The managed service costs five hundred dollars a month. Our total notification volume is about three thousand messages a day. Most of those are password resets. Do we really need a distributed log for three thousand messages a day?”
I started talking about future scale.
I said we needed to be ready for when we hit a million users.
“If we hit a million users, we’ll have a different set of problems,” Mark replied.
“Right now, we need a system that works tomorrow. You just proposed an architecture that requires three different infrastructure platforms and a dedicated DevOps engineer to keep it running. Can you build this with just the tools we already have?”
I realized then that I had failed. I had ignored the most important constraint in any engineering project: the human cost of maintenance.
What a senior answer actually looks like
A senior engineer doesn’t solve for the scale of a billion users unless they are actually at a company with a billion users. They solve for the requirements they have, with a clear path for when those requirements change.
If I were to do that interview again, my answer would be much shorter and much more boring.
I would start with a simple background job library like Sidekiq or Celery, using the Redis instance the company probably already has. The notification requests go into a queue. A few workers pull from the queue and hit the SendGrid or Twilio API. If the API is down, the worker retries with exponential backoff.
For the data, I would use a single table in the existing Postgres database to store the notification logs and user preferences. No microservices. Just a well structured module within the main application.
This system can handle fifty thousand users without breaking a sweat. It can handle five hundred thousand users with about ten minutes of vertical scaling. It takes one engineer two days to build and requires zero additional infrastructure management.
That is the senior answer. It shows that you value the company’s time and money more than your own desire to play with cool technology.
The lesson
I used to think that Senior Software Engineer was a title given to people who knew the most complex patterns. I was wrong. It is a title given to people who can be trusted not to build complex things when simple things will do.
Complexity is a tax. Every box you draw on a whiteboard is a box that someone has to debug at three in the morning. If you can solve a problem with a simple SQL query and a cron job, you should do that. Only move to the distributed systems and the stream processing when the simple solution literally cannot handle the load anymore.
If you are walking into a system design interview, your goal is not to show off. Your goal is to show that you are a pragmatist.
Final thoughts
I stopped reading about scale and started reading about maintenance. It changed how I approached every interview after that. I stopped trying to sound like an architect and started trying to sound like a colleague. Remember whenever you make mistakes in any of your interview, do not forget that.. keep that mistake in the list, work on it and try not to make the same mistake again.
If you want to practice system design in a way that focuses on these realistic trade offs rather than just drawing boxes, PracHub has real interview questions that specifically test for over-engineering. They provide the constraints that force you to choose the simplest viable solution, which is exactly what top tier engineering teams are looking for.
Top comments (0)