For years, I've found the system design round to be the most intimidating part of the software engineering interview loop. I consumed countless articles and videos, but when I faced a blank whiteboard, I realized there's a huge gap between passive learning and actively designing a system under pressure.
I wanted a tool that would let me practice in a more structured, hands-on way, similar to how LeetCode works for algorithms. I couldn't find exactly what I was looking for, so I decided to build it myself.
The goal is to provide an interactive environment that guides you through the same framework you'd use in a real interview:
Requirements Gathering: Defining functional and non-functional specs.
Estimation: Calculating potential scale for traffic, storage, etc.
High-Level Design: Sketching out the main components and their interactions.
Deep Dive: Exploring specific trade-offs for databases, caching, and other components.
After you attempt a problem, you can review a detailed solution with explanations and diagrams to see how your approach compares.
The project is still early, and I'm sure there's a lot to improve. I'm posting it here to get some honest feedback from the HN community. Is the approach useful? Are there critical features missing? What interview problems should I add next?
Hey HN,
For years, I've found the system design round to be the most intimidating part of the software engineering interview loop. I consumed countless articles and videos, but when I faced a blank whiteboard, I realized there's a huge gap between passive learning and actively designing a system under pressure.
I wanted a tool that would let me practice in a more structured, hands-on way, similar to how LeetCode works for algorithms. I couldn't find exactly what I was looking for, so I decided to build it myself.
I'm launching it today. It's called Sysdine: https://sysdine.dev/
The goal is to provide an interactive environment that guides you through the same framework you'd use in a real interview:
Requirements Gathering: Defining functional and non-functional specs.
Estimation: Calculating potential scale for traffic, storage, etc.
High-Level Design: Sketching out the main components and their interactions.
Deep Dive: Exploring specific trade-offs for databases, caching, and other components.
After you attempt a problem, you can review a detailed solution with explanations and diagrams to see how your approach compares.
The project is still early, and I'm sure there's a lot to improve. I'm posting it here to get some honest feedback from the HN community. Is the approach useful? Are there critical features missing? What interview problems should I add next?
Thanks for taking a look.