Coding Interview — Backend

Candidate clarifies requirements, discusses multiple approaches with trade-offs, identifies edge cases (empty input, duplicates, overflow), and states the complexity of their chosen approach before coding.

Candidate jumps into coding without understanding the problem, cannot articulate their approach, or ignores edge cases entirely.

Candidate selects optimal data structures with clear justification (hash map for O(1) lookup, heap for top-K, etc.). They understand time-space trade-offs and can adapt when constraints change.

Candidate defaults to arrays and nested loops for everything, cannot analyze complexity, or chooses data structures that make the problem harder than necessary.

Candidate writes modular, readable code with descriptive naming. Functions have single responsibilities, error handling is present, and the code works on first or second attempt with minor bugs.

Code is a single monolithic function with cryptic names, no error handling, numerous bugs that the candidate cannot debug, or fundamentally incorrect logic.

Candidate proactively identifies edge cases (null/empty input, single element, maximum values), traces through their code manually, and writes or describes test cases without being prompted.

Candidate declares the solution 'done' without testing, cannot trace through their own code, or misses obvious edge cases like empty input.

Candidate narrates their thinking clearly, takes hints productively and builds on them, asks good clarifying questions, and treats the interview as a collaborative problem-solving session.

Candidate codes in silence, ignores or rejects hints, becomes defensive when asked questions, or cannot explain the code they just wrote.