Extend a Log-Processing Codebase: Priority Classification, Tests, Time-Window Query

In this round you receive a long requirements document and several existing source files, and you extend that code with log-processing features while an AI coding assistant is available. The original files are not reproduced here, so assume a small codebase that already parses each log line into a record with a timestamp, a priority level and a message, and keeps the records in memory. The work came in three parts: classify the logs by priority, where the priority levels have a defined order; write tests for what you implemented; and, given a time, return the logs that fall in the corresponding time window. The level names below are illustrative; the real exercise defined its own levels and their order. ```text 10:00:01 INFO cache warmed 10:00:03 ERROR payment call timed out 10:00:04 DEBUG retry scheduled 10:00:09 WARN queue depth above threshold 10:01:15 ERROR disk write failed assumed order, lowest to highest: DEBUG < INFO < WARN < ERROR ``` ### Constraints and Clarifications - The round looks at how you work in an unfamiliar codebase with an assistant: understanding the requirements, the existing code structure and your own plan before generating code, and checking that what the assistant produces is correct. - Not given: the actual priority names, the exact meaning of "the corresponding time window", whether records arrive in time order, and how many records there are. Ask, or state your assumptions. ### Clarifying Questions - Does "classify" mean grouping every record under its priority, returning the records at or above a chosen priority, or both? In what order should the groups, and the records inside a group, be returned? - What should happen to a record whose priority is missing or is not one of the defined levels? - Is the time window the fixed-length period ending at the given time, a period centred on it, or the calendar bucket (minute, hour) that contains it? How long is it, and are its endpoints included? - Do records arrive in timestamp order, and can two records share a timestamp? - Will the time query run once or many times on the same records, and should the new code extend the existing classes or sit beside them? ### Part 1 — Classify logs by priority Add the classification feature to the existing code. The priority levels have an explicit order, and the feature must respect it. ```hint Keep the order in one place Decide where the ordering of the levels is defined, so that comparing two levels, or adding a new one, never means editing a chain of string comparisons. ``` #### What This Part Should Cover - A plan formed from the requirements and the existing code before the assistant is asked for anything - A single definition of the level order, and a stated policy for unknown levels - The order of the returned groups and of the records within each group - Running time for n records ### Part 2 — Write tests Write tests for the functionality you implemented, and extend them to the time-window query once Part 3 exists. ```hint Aim at the likely bugs List the inputs where an ordering mistake or an off-by-one error would show up, and make sure each test would fail against a plausible wrong implementation, including one the assistant might write. ``` #### What This Part Should Cover - One focused test per behavior, with fixed fixture times instead of the current clock - Edge cases: no records, a level with no records, an unknown level, equal timestamps, window endpoints - Tests that check behavior instead of restating the implementation ### Part 3 — Return the logs in a time window Given a time, return the logs that fall in the corresponding time window. ```hint Look at how the records are stored Check whether the records are already ordered by time, and how many queries will hit the same records, before choosing between a scan and something faster. ``` #### What This Part Should Cover - The window definition and the endpoint rule, agreed before coding - A query that does not scan every record when the records are sorted or queried repeatedly - Records that arrive out of order, and records with equal timestamps - The order of the returned records ### What a Strong Answer Covers - Understands the requirements and the code structure first, and gives the assistant specific, scoped requests instead of asking it how to solve the task - Integrates the features into the existing types and conventions rather than building a parallel implementation - Reads and tests every generated change, and catches the assistant's mistakes - Explicit, consistent rules for the level order, unknown levels and window endpoints - The complexity of each operation, and how the design would change as the volume grows ### Follow-up Questions - A new priority level is added between two existing ones. Which code and which tests change? - Callers now want the records at or above a given priority within a time window. How do you serve that efficiently? - The records no longer fit in memory, or arrive as a continuous stream. How do classification and the time query change? - With little time left, how do you decide which parts of the assistant's output to trust and which to rewrite?