I recently took this assessment, and honestly, it was a incredibly refreshing and new experience compared to the standard algorithmic grinds. It really tests your actual day-to-day software engineering skills rather than trick puzzles.

The 60-minute clock ticks down fast, but by staying focused on code quality and cleanly mapping the file structure first, I was able to successfully solve and verify both tasks within the time limit.

Because the format caught me by surprise, I wanted to map out exactly what the environment looks like so the community can prepare for it effectively.

• Role: Backend Engineer II (SDE-II)
• Duration: 60 Minutes
• Environment: Fully Proctored (Webcam, mic, screen recording, strict tab/focus tracking)

🛠️ The Test Format

This assessment completely abandons traditional, isolated LeetCode data structure and algorithm puzzles. Instead, you are dropped directly into a live, multi-file production repository with existing business logic, configurations, and data models.

You have 60 minutes to complete exactly two real-world backend engineering tasks:

• Task 1: The Feature Build – You are given a product requirement and must build a new business feature from scratch, writing and wiring the logic across multiple existing files.
• Task 2: The Bug Fix – You are presented with a broken module and a suite of failing unit tests. You must dive into the existing codebase, trace the logic flaw, and patch the bug to make the tests pass.

📋 What is Expected of You

The evaluation criteria mimic how you would actually be judged on the job. The hiring team is specifically looking for:

• Quality Over Speed: The assessment explicitly states that submitting one clean, 100% working, production-grade task is highly preferred over rushing to submit two incomplete or sloppy solutions. Quality is heavily prioritized.
• Architectural Literacy: You are expected to quickly read and understand someone else's code. You must adapt to the repository's established patterns (like the service-repository design) and write code that naturally blends into the existing file structure.
• Production-Ready Standards: Your solutions should feature clean, descriptive naming conventions, sensible error handling, and robust logic that treats the in-memory data store with care.
• Tool & Process Ownership: Because copy-pasting is restricted and the environment is highly monitored, you are expected to navigate the workspace independently, rely on the local unit tests to verify your implementation, and maintain full ownership of the logic you write.

💡 Quick Strategy Tip

Don't start coding immediately. Spend the first 3 to 5 minutes opening the files, reviewing the imports, and mapping out how the models and services communicate. Understanding the landscape first will save you from rewrites when the clock is ticking.