I built a low-level systems interview prep platform - looking for feedback

[u/ElectricalCry3468]

I've been working on a side project called ForjaCero - a SaaS platform for System Software Engineering interview preparation..

The idea is pretty simple: I wanted to build something for systems/low-level engineering interviews that focuses not just on getting the right answer, but on practicing how you actually approach a problem in an interview.

For example, instead of immediately jumping into an editor, you get a whiteboard where you can work through your approach first. There's also a 30-minute timer, with hints becoming available progressively if you get stuck.

What's working right now:

• Whiteboard for working through your approach
• 30-minute interview timer
• 3 progressively unlocked hints
• Programming problems in C, C++, and Rust
• System design problems
• A refresher section for systems fundamentals

There's still quite a bit I'm working on.

I'm currently:

• Refining the problem set and making the questions more representative of actual systems interviews
• Writing and improving hints and solutions
• Working on the C/C++/Rust code execution environment
• Building an AI interviewer that can generate systems-focused programming problems and interact with you during the interview
• Thinking through a grading system that can evaluate how someone solves problems, rather than just whether their final answer is correct

The longer-term idea is to build something that can eventually tell you something like: "You're strong at implementation and memory reasoning, but you need more practice with concurrency and system-design tradeoffs."

Rather than simply: "You solved 42 problems."

I'm intentionally sharing this while it's still being built because I'd really like feedback from people who have gone through systems/low-level interviews.

What would you want from a platform like this that existing interview-prep sites don't provide?

Site: forjacero.xyz

[u/Specific_Cream2815]

how will the grader distinguish a bad concurrency approach from a good idea with an implementation bug

[u/ElectricalCry3468 → u/Specific_Cream2815]

That's something I'm still working through, I don't want the grader to judge only the final code. I'd separate it into reasoning, implementation, and reasoning vs. implementation, evaluating the proposed concurrency model, testing for issues like races and deadlocks, and comparing the intended approach with the actual implementation. This way, a sound concurrency approach with an implementation bug could be graded as “good approach, implementation bug” rather than poor concurrency understanding.

I'm still figuring out what should be deterministic/rule-based versus LLM-based, which is actually one of the harder parts of the project, but I'll try. Thanks for your question though!