Build Task Management Through Records, Search, Assignment, and Completion

Design an in-memory task-management component that grows through the following four stages. Explain the data model and operations at each stage so later requirements can build on the earlier implementation. ### Part 1 — Read and write tasks Support creating or updating task records and retrieving them. Identify the task fields and error behavior that you need to clarify before implementing an exact API. #### What This Part Should Cover - Stable task identity and a map-based record store. - The distinction between creating a new record and updating an existing one. - Consistent handling of missing IDs and invalid updates. ### Part 2 — Search, sort, and list Add task search and sorted listing. Explain how matching, sort direction, and ties should be specified rather than relying on map iteration order. #### What This Part Should Cover - A declared search rule and explicit ordering key. - The cost of filtering and sorting, and the circumstances that justify an index. ### Part 3 — Assign a task Allow a task to be assigned to a user. Explain the relationship between a task and its assignment and what should happen when the task is assigned again. #### What This Part Should Cover - The source of truth for assignment state and any user-to-task index. - Validation of the task and user reference, plus an explicit reassignment policy. ### Part 4 — Complete work and check overdue items Add assignment completion and overdue checking. Explain which state becomes complete, how due times are represented, and which incomplete items qualify as overdue. #### What This Part Should Cover - Valid completion transitions and behavior under a repeated completion request. - A precise comparison with the current time and a distinction between current overdue work and work completed late. ### What a Strong Answer Covers - One consistent model across all four stages, with indexes updated whenever their source records change. - Explicit assumptions for task fields, search, sorting, assignment, and deadlines; the exact method signatures and output format are unspecified. - Complexity and tests tied to interactions between features, such as reassignment followed by completion or a due-time edit followed by an overdue query. ### Follow-up Questions - How would you prevent a user-to-task index from retaining an old assignee after reassignment? - What changes if overdue queries become frequent while tasks' deadlines are edited often?