About Gronex

Sahil Srivastav is a backend and infrastructure engineer currently working at Atlassian. He previously worked with Snabbit, Coupang, and Flipkart, building and scaling distributed systems, high-throughput backend services, and production infrastructure.

He is the founder of Gronex and builds both the platform and its challenge catalogue. The goal is practical preparation for interviews that ask candidates to work inside a repository rather than solve an isolated function from a blank editor.

Sahil has also cleared interview processes at Amazon, Microsoft, Google, Uber, and other product-based companies. That combination of production engineering and interview experience informs Gronex's repository-first format.

Before Gronex, Sahil taught more than 1,000 students through Swag Wala Developer, an education platform where he ran a data structures and algorithms bootcamp. That teaching experience shapes how Gronex explains tradeoffs, common mistakes, and interview follow-up questions after each practical attempt.

Questions about the platform or its content can be sent through the Gronex contact page.

Each challenge begins with a concrete backend scenario and an observable contract. The brief describes the existing system, the behavior to repair or implement, the constraints, and the edge cases the repository must handle.

The challenge is then built as two matched repository states. The starter state contains the intended bug or missing implementation; the solution state contains the completed source and a written solution. The brief, tests, and verification script stay the same in both states so the target does not move between practice and review.

For every language supported by a challenge, the bundled verify.sh must fail against the starter state and pass against the solution state. This confirms both that the problem is reproducible and that the reference implementation satisfies the same tests learners run.

• Tests are designed to be repeatable without network access, real external services, or wall-clock timing.
• Time, configuration, databases, and downstream systems are represented with controlled inputs or fakes.
• Concurrency checks use bounded waits so a failed implementation cannot leave the verification run hanging.

Before publication, the starter-to-solution diff is checked to ensure that only the intended source changes and written solution are different. Harness files, tests, and the problem statement remain aligned across both states, and the metadata is checked against the platform's challenge format.

The learner-facing solution review is assembled from that verified repository. It includes the approach, patch summary, key files changed, common mistakes, follow-up questions, and a file-level diff so learners can compare reasoning as well as code.