Task Management System: Priorities, Name Search, User Quotas and Expiring Assignments

Implement an in-memory task management system in an online, four-level progressive coding assessment. Each level adds requirements on top of the previous ones, and code written for earlier levels must keep working as later levels are added. The report gives one sentence per level. The exact method names, signatures and return formats were not reported, so define a small interface yourself and state the rule you choose for anything left open. ### Clarifying Questions - Are task IDs generated by the system, and in what format, or supplied by the caller? - Does every operation receive a timestamp, and are timestamps guaranteed not to decrease from one call to the next? - What should an operation return when it refers to a task or user that does not exist: a failure value, an empty result, or an error? - Is priority a number where a larger value means more important, and how are ties broken when listing? ### Part 1 — Level 1: add, update and retrieve tasks The system must support adding a task, updating a task, and retrieving a task. ```hint Choose the record first Decide which fields a task carries and which of them an update may change before writing the three operations. Later levels will attach more state to the same record. ``` #### Clarifying Questions for this Part - Which fields does a task have at this level (for example a name and a priority), and may two tasks share a name? - Does an update replace every field or only the ones supplied? #### What This Part Should Cover - A task record and a primary index by ID. - Well-defined results for missing tasks and invalid input. - An interface that later levels can extend without breaking. ### Part 2 — Level 2: search by name and list by priority Add searching tasks by name and listing tasks sorted by priority. ```hint Pin down the order Hidden tests compare exact output, so every listing needs a total order. Decide the tie-breaker before you write the sort key. ``` #### Clarifying Questions for this Part - Is the name search an exact match, a prefix match or a substring match, and is it case sensitive? - Should the listing be limited to the top N tasks, and in which direction is it sorted? #### What This Part Should Cover - Name search semantics and the order of its results. - A deterministic sort key with an explicit tie-breaker. - Whether an index is worth maintaining or a scan is enough at the expected scale. ### Part 3 — Level 3: users, quotas and expiring assignments Add users with quotas, and time-based assignments of tasks to users that expire automatically. ```hint Make time an input Expiry happens between calls, so the system has to bring its state up to date at the timestamp of each call before answering it. ``` #### Clarifying Questions for this Part - What does a quota limit: the number of tasks a user may hold at the same time, or the total number of assignments ever made? - Does an expired assignment free up quota immediately? - Can a task be assigned to several users at once, or to the same user again after an assignment expires? - Is an assignment that expires exactly at the query timestamp still active? #### What This Part Should Cover - Data structures for users, quotas and assignments with start and expiry times. - Consistent expiry semantics at the boundary timestamp. - Quota checks that count only what the chosen rule says should count. ### Part 4 — Level 4: completion and overdue reporting Add completing an assigned task and reporting overdue assignments. ```hint Keep expired history If Level 3 deletes an assignment when it expires, nothing is left to report as overdue. Revisit what expiry does to an assignment's record. ``` #### Clarifying Questions for this Part - Is an assignment overdue when it expired without being completed, and can a task still be completed after its assignment expired? - Does completing a task release the user's quota? - Is the overdue report for one user or for everyone, and in what order? #### What This Part Should Cover - An assignment status model (active, completed, expired) that supports both completion and reporting. - Rules that reject completing a task that is not actively assigned to the caller. - A deterministic overdue report. ### What a Strong Answer Covers - Each level extends the previous data model instead of rewriting it. - Every open rule is stated explicitly and implemented in one place, so it can be changed quickly if hidden tests disagree. - Deterministic ordering and exact handling of the expiry boundary. - Complexity awareness for search, listing and expiry processing, and a sensible choice between simple scans and indexes under time pressure. ### Follow-up Questions - How would you make expiry processing efficient with millions of active assignments? - How would you support history queries, such as a task's assignment log as of a past timestamp? - How would you make the system safe for concurrent calls from several threads? - How would the design change if quotas applied per time window, such as a maximum number of assignments per day?