Debug and extend an expense reimbursement reporting codebase with an AI coding assistant

This onsite round is an AI-assisted coding exercise. You are given the codebase of a simple internal system for managing employee expense reimbursements, with features such as monthly expense reports and budget reports. The repository has far more files than you can read in the time available, so you work through an AI coding assistant: it reads and edits the code, and you direct it, check its work, and answer for the result. The round has three tasks, followed by a discussion of the code the assistant wrote. ### Constraints and Clarifications - The codebase itself is not reproduced here. For practice, assume a typical shape: each expense records an employee, a department, an amount, a category, a status, the date on the bill (when the expense was incurred) and the date the reimbursement was submitted; budgets are set per department per month; and report code totals expenses by month. - The repository has an existing test suite that you can run. ### Clarifying Questions - Which date should decide the month an expense belongs to in each report: the date on the bill, the submission date, or the approval or payment date? - Are amounts stored as floating-point numbers, integer cents or decimals, and in one currency or several? - Which expense statuses count toward a report: approved and paid only, or pending as well? - Is the assistant allowed to modify tests, or only application code? ### Part 1 — Debug the monthly report Users report that the monthly report numbers are wrong. For example, an employee submits a reimbursement in February for a bill dated in January, and the expense lands in the wrong month's report. More than one defect contributes to the wrong numbers. Find and fix them. After the assistant proposes fixes, the interviewer asks whether you think its fixes are correct. ```hint Reproduce before you fix Turn the reported example into a failing test with exact dates before asking the assistant to change anything. ``` ```hint Every path to a month Find every place the code turns a date into a reporting month or a date range. A fix in one report can leave another one still wrong. ``` #### Clarifying Questions for this Part - Should reports for past months that were already generated be recomputed after the fix? #### What This Part Should Cover - Reproducing the reported case as a failing test - Locating the root cause in how a date is mapped to a reporting month, and hunting for the other defect systematically - Judging the assistant's fix against the intended business rule and every affected code path - Regression tests at month boundaries ### Part 2 — Add a feature to the report Next, add a new feature to the report. Tests that describe the expected behavior already exist in the repository, and the goal is to make them pass. The specific feature was not reported; for practice, assume it is a budget-versus-actual view that lists, for each department and month, the budget, the amount spent, the amount remaining, and whether spending exceeded the budget. ```hint Tests are the spec Read what the tests assert before generating code, so you can tell whether the assistant built the feature or merely satisfied the assertions. ``` ```hint Reuse the month rule The new view depends on the same date-to-month rule you fixed in Part 1. ``` #### What This Part Should Cover - Reading the tests as the specification and noticing the gaps they leave - Implementing within existing patterns and reusing the corrected month logic - Verifying beyond green tests, for example departments with no budget or no spending - Reviewing the assistant's diff before accepting it ### Part 3 — Prepare the system for production Suppose the system is going to move to production. Brainstorm the features it would need, decide which matter most, and have the assistant implement at least one of them. ```hint Money and access Think about who may see and change which expenses, and what goes wrong when amounts are stored or summed carelessly. ``` ```hint Late paperwork Consider what should happen when a bill for a month that has already been reported arrives late, as in Part 1. ``` #### What This Part Should Cover - A prioritized list of production features spanning correctness, security, auditability and operations - A justified choice of what to implement first - An implementation with tests - Awareness of data migration and rollout concerns ### Part 4 — Explain and optimize the assistant's code Finally, the interviewer points at several functions the assistant wrote during the session and asks whether you understand what each one does, and how you would optimize it. ```hint Say it in your own words For each function, be ready to state its inputs, outputs, edge cases and complexity before suggesting any change. ``` ```hint Look for repeated scans Report code often recomputes the same totals. Look for loops that scan every expense once per group. ``` #### What This Part Should Cover - An accurate explanation of each function, including its edge cases - Complexity analysis and identification of the real bottleneck - Concrete optimizations, such as single-pass aggregation or pushing aggregation into the database with a suitable index - The trade-offs of each optimization against readability and correctness ### What a Strong Answer Covers - Directing the assistant with precise tasks and checking its output against tests and business rules - Root-cause debugging of month attribution rather than patching one symptom - Test-driven feature work that reuses shared logic - Sensible production priorities for money, access and auditability - Ownership of assistant-written code: explaining it and improving it ### Follow-up Questions - How would you stop the assistant from making tests pass by editing the tests or special-casing their inputs? - Finance also wants a cash view that groups expenses by payment date. How would you support both views without duplicating report logic? - How would report generation change if expense volume grew by several orders of magnitude?