Day 1 – Round 1:
The interviewer asked me to design database entities for a cab service. I suggested a normalized design with separate tables:
* user
* driver
* user_driver
* domestic_trip
* intercity_trip
* user_driver_domestic_trip
* user_driver_intercity_trip
My idea was to separate trip types and keep the database properly normalized using mapping tables. However, the interviewer didn’t like this approach and insisted that all trips should be stored in a single table. There was no discussion about trade-offs, normalization, or scalability — it felt like only one answer was considered correct.
My simple suggestion for the Round 1 panel: please revisit normalization concepts. There are multiple valid ways to design a database, and the right choice depends on requirements.
Day 2 – Round 2 (another interviewer):
The interviewer then asked:
"How do you design a solution to handle concurrent form updates where multiple users access the same record, ensuring stale data is detected and users are notified in real time without overwriting recent changes?"
I answered that we can use WebSocket-based notifications along with backend validation. But again, the panel insisted that versioning was the only solution.
My point was simple: versioning can prevent overwriting data, but how will other users know that the form has already been updated? Some kind of notification is still needed. For better user experience, WebSocket (or any real-time mechanism) is a practical solution — and that’s what I explained.
My suggestion to the Round 2 interviewer: my friend Shobhit, please revisit system design basics. Good system design usually combines multiple approaches to create an optimal solution.
Overall, it felt like the discussion was not about understanding design thinking, but about matching a predefined answer. For senior-level roles, interviews should focus on reasoning, trade-offs, and real-world experience — not just one fixed solution.
Advice to candidates: if possible, ask for interviews to be recorded or clarified. Sometimes answers are judged based on keywords rather than actual understanding.
Interviews should be about technical discussion and learning — not rigid answer validation. 🚫
For upper management: please ensure that interviewers are well-prepared and able to evaluate candidates fairly based on knowledge, reasoning, and practical experience.
