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.

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.

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.

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.

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.