Backend interviews increasingly include a debugging round: you are handed a slow endpoint, a wrong number or a flaky test in an unfamiliar codebase and asked to find out why, out loud. The questions in this section so far test what you know about Django. This lesson points you at the place where you practice what you do when something is broken.

What a debugging round actually scores

Interviewers rarely care whether you find the bug in the first minute. They watch the process: do you reproduce the problem before touching the code, do you form a hypothesis and test it with a measurement, do you fix the cause instead of the symptom, and can you explain what you changed and how you know it works. A candidate who says "the query count grows with the number of rows, so I will look at where the page evaluates related objects" is already ahead of one who starts adding caches.

Practice on realistic, broken systems

The Production Debugging course gives you exactly that practice. Every lab is a small e-commerce Django app in a browser IDE with a real git history, a database, logs and a ticket written the way support or an on-call engineer would write it. A hidden test suite and behavioral checks grade your fix, and you finish with a short incident write-up. Start with these three, chosen to match what Django interviews probe most:

• The order list page is slow for repeat customers (easy): an N+1 query pattern. Practice counting queries and using select_related and prefetch_related.
• Evening orders land on tomorrow's report (medium): time zones and where the conversion from UTC happens.
• The last unit is sold twice (hard): a lost update under concurrent checkouts, fixed atomically in the database.

Browse them in the debug lab catalog, or open the Production Debugging course from the course list.

How to use the labs for interview prep

Do each lab twice. The first time, solve it. The second time, narrate: say what you are measuring and why, as if an interviewer were watching, and write the INCIDENT.md in five sentences you could say out loud. The write-up (symptom, how you reproduced it, root cause, fix, prevention) is exactly the structure of a strong debugging answer.