Design Discussion (First 35–40 minutes): I began with the core entities essential for any notification system: User – the recipient of the notifications. Notification – the actual message that needs to be sent. Template – the format or structure of the messages. Following this, I moved into defining the API endpoints for: Sending a notification Creating templates Listing or fetching past notifications, etc. During the discussion, the interviewer shifted into HLD territory, asking about: Handling failures in third-party integrators Retry strategies Ensuring no data loss in case of downstream issues While these questions are valid and relevant, they diverted attention from core LLD aspects and took a significant portion of the allotted time (around 35–40 minutes). Nevertheless, I answered them to the best of my understanding, balancing both design and operational concerns. Coding Expectation (Next 40–45 minutes): Unexpectedly, the interviewer asked me to implement the entire notification system in code using Java and Spring Boot, with a fully modular design, proper database integration, and execution through API endpoints. To add to the complexity, he asked me to use Cursor AI tools. However, I was not familiar with Cursor and its integration with IntelliJ .Cursor was misinterpreting prompts and not giving the correct code output. Additionally, using Cursor on my old laptop caused performance lags, further slowing down the development process. Despite these hurdles, I: Wrote one complete API Showed modular design Connected it to a real database Applied object-oriented principles Implemented the Strategy Pattern to abstract channel-specific notification logic Used the Command Pattern to execute API-level business logic All this was completed within the next 40 minutes, showcasing my design and development skills under pressure. Final Feedback from Interviewer (and my take): API Naming Convention – One of the API endpoints was reportedly not named properly. While naming is important, this seems like a minor oversight in the bigger picture. Given that I was aiming to build multiple endpoints under time pressure, this shouldn't have been a primary reason for rejection. Idempotency Checks Not Present – While I agree this was missing, I would have addressed it once the foundational design was in place. It’s unrealistic to expect every detail to be perfectly handled when building an entire system from scratch within 40 minutes, especially when the priority was showcasing architecture, modularity, and design patterns. Conclusion: Overall, the interview felt rushed and tool-constrained, reducing the opportunity to properly demonstrate my capabilities. The shift from LLD to full-blown implementation (without prior clarity), insistence on using a tool I wasn’t familiar with, and shortened time frame all contributed to an experience that didn’t allow fair evaluation. While I appreciate the learning experience, I believe the evaluation criteria lacked context sensitivity, and the decision didn't fully reflect the depth and quality of work delivered under pressure.