Task Management System

Question

A CodeSignal online assessment with no interviewer, five reports between January and August 2026 and a reply elsewhere naming it. Build one Python class across four graded parts (CodeSignal calls them levels); a part's tests must pass before the next unlocks. One report lists the four levels: basic CRUD, sorting by priority and creation order, user quotas and assigning tasks to users, and a history query. Another adds that Part 4 needs bisect and that the last requirement of Part 3 needs a careful read; a third candidate also lost Part 4 test cases. No report records a method name, signature or return value: the interface below is ours, written so the four reported levels can be solved and graded here. On the real OA, read the given skeleton and the sample tests first.

Part 1 — Basic CRUD:
- add_task(task_id, user_id, timestamp, priority=0) -> bool: create a task held by user_id with the given creation timestamp (an int). Return False and change nothing if task_id already exists.
- delete_task(task_id) -> bool: remove the task; False if it does not exist. The id may be reused afterwards.
- get_user_tasks(user_id) -> list[str]: the ids of the tasks the user currently holds, in creation order (ascending timestamp, then task id); [] for a user with no tasks.

Part 2 — Sorting by priority and creation order:
- update_priority(task_id, priority) -> bool: set the task's priority; False if the task does not exist. A task's priority is 0 unless given.
- get_top_tasks(user_id, k) -> list[str]: the user's k tasks, highest priority first; equal priorities are ordered by creation, earlier first. With fewer than k tasks, return them all. Creation order itself never changes, so get_user_tasks is unaffected by priorities.

Part 3 — User quota and assignment:
- set_quota(user_id, max_tasks) -> None: the user may hold at most max_tasks tasks. A user with no quota set may hold any number. Tasks already held beyond a new quota stay; only new additions are refused.
- assign_task(task_id, user_id) -> bool: move the task to user_id. False if the task does not exist or the target user is at quota; in both cases nothing changes. Assigning a task to the user who already holds it returns True and changes nothing. The task keeps its original timestamp, so it takes its place in the new user's creation order by that timestamp, not at the end.
- From this part on, add_task also returns False when user_id is at quota.
The report says only that the last requirement of Part 3 needs a careful read of the prompt; it does not say what that requirement is. Here the quota rules above play that role: apply them to both methods.

Part 4 — Historical query:
- get_tasks_created_between(user_id, t_start, t_end) -> list[str]: the ids of the tasks the user currently holds whose creation timestamp lies in the window, in creation order. The reference treats both ends as inclusive; no report gives the convention, and the tests on this page never place a task exactly on a boundary. One candidate says this part needs bisect, and both candidates who reported scores lost test cases here: keep each user's list sorted by timestamp and find the window with binary search rather than a scan.

Notes: described by one candidate as an OOP problem that needs no complex algorithm. Any language: a recruiter told one non-Python candidate that Python was not required. One candidate's recruiter email said "The project will be a toy simulation of an app"; the OA was still this question, and two replies had received the same line. Scores of 925 and 750 out of 1000, both with Part 4 tests failing, were followed by a call for the next round; one reply reported passing every test and being rejected three days later.

AceOffer · Accepted Answer

A CodeSignal online assessment with no interviewer, five reports between January and August 2026 and a reply elsewhere naming it. Build one Python class across four graded parts (CodeSignal calls them levels); a part's tests must pass before the next unlocks. One report lists the four levels: basic CRUD, sorting by priority and creation order, user quotas and assigning tasks to users, and a history query. Another adds that Part 4 needs bisect and that the last requirement of Part 3 needs a careful read; a third candidate also lost Part 4 test cases. No report records a method name, signature or return value: the interface below is ours, written so the four reported levels can be solved and graded here. On the real OA, read the given skeleton and the sample tests first.

Part 1 — Basic CRUD:
- add_task(task_id, user_id, timestamp, priority=0) -> bool: create a task held by user_id with the given creation timestamp (an int). Return False and change nothing if task_id already exists.
- delete_task(task_id) -> bool: remove the task; False if it does not exist. The id may be reused afterwards.
- get_user_tasks(user_id) -> list[str]: the ids of the tasks the user currently holds, in creation order (ascending timestamp, then task id); [] for a user with no tasks.

Part 2 — Sorting by priority and creation order:
- update_priority(task_id, priority) -> bool: set the task's priority; False if the task does not exist. A task's priority is 0 unless given.
- get_top_tasks(user_id, k) -> list[str]: the user's k tasks, highest priority first; equal priorities are ordered by creation, earlier first. With fewer than k tasks, return them all. Creation order itself never changes, so get_user_tasks is unaffected by priorities.

Part 3 — User quota and assignment:
- set_quota(user_id, max_tasks) -> None: the user may hold at most max_tasks tasks. A user with no quota set may hold any number. Tasks already held beyond a new quota stay; only new additions are refused.
- assign_task(task_id, user_id) -> bool: move the task to user_id. False if the task does not exist or the target user is at quota; in both cases nothing changes. Assigning a task to the user who already holds it returns True and changes nothing. The task keeps its original timestamp, so it takes its place in the new user's creation order by that timestamp, not at the end.
- From this part on, add_task also returns False when user_id is at quota.
The report says only that the last requirement of Part 3 needs a careful read of the prompt; it does not say what that requirement is. Here the quota rules above play that role: apply them to both methods.

Part 4 — Historical query:
- get_tasks_created_between(user_id, t_start, t_end) -> list[str]: the ids of the tasks the user currently holds whose creation timestamp lies in the window, in creation order. The reference treats both ends as inclusive; no report gives the convention, and the tests on this page never place a task exactly on a boundary. One candidate says this part needs bisect, and both candidates who reported scores lost test cases here: keep each user's list sorted by timestamp and find the window with binary search rather than a scan.

Notes: described by one candidate as an OOP problem that needs no complex algorithm. Any language: a recruiter told one non-Python candidate that Python was not required. One candidate's recruiter email said "The project will be a toy simulation of an app"; the OA was still this question, and two replies had received the same line. Scores of 925 and 750 out of 1000, both with Part 4 tests failing, were followed by a call for the next round; one reply reported passing every test and being rejected three days later.

Common mistakes: Missing two test cases on Part 4 was a reported outcome even for a candidate who scored 925/1000 and still advanced — so partial credit on Part 4 is survivable.; At least one candidate passed all test cases but was still rejected after a few days with no explanation, suggesting code quality or a code review score matters beyond just test passage.; Misreading the Part 3 requirements was a noted risk; one candidate specifically warned others to read the last part of that section carefully, without saying what it required.; Not using binary search (bisect) for Part 4, which one candidate says the part needs; that candidate still lost two test cases there.; Accidentally submitting Part 4 early before fully testing it (an accidental key press submitted it, one report)

Interviewer hints: Recruiter explicitly said Python is not required and candidates should use the language they are most comfortable with.

What passers do: Reading the Part 3 requirements very carefully was specifically called out — one candidate noted the last part of Part 3 requires careful reading of the prompt to get right.; Using bisect (binary search) for the Part 4 historical query, which one candidate says the part needs; both candidates who reported scores lost Part 4 test cases and still advanced.; Choosing a comfortable language rather than forcing Python was explicitly encouraged by the recruiter; a non-Python candidate was told to use whatever they were most comfortable with.; Passing the first three parts cleanly and getting most Part 4 test cases earns enough score to advance (925/1000 and even 750/1000 both resulted in HR call)

Why people fail: Passing all test cases in OA but still being rejected (code quality/score may factor in beyond pass/fail)

Edge cases probed: Part 3's last requirement needs a careful read (one report); what it is was not described; Part 4 historical query — one candidate failed two of its test cases, another passed only a few edge-case tests

Alternative approaches: Sorted list / heap for Part 2 (A heap gives O(log n) insertion but O(n) iteration; a sorted list (with bisect.insort) gives O(n) insertion but O(1) ordered access — both are acceptable at OA scale.); Event log + linear scan for Part 4 (Simpler to implement but O(n) per query; bisect on a timestamp-indexed log gives O(log n), and one candidate says the part needs bisect.); Heap / Priority Queue for Part 2 (A heap can keep tasks sorted by priority in O(log n) per insertion, but complicates updates and deletion; a simpler list with sort-on-query is often sufficient given OA constraints.); Brute-force linear scan for Part 4 (Scanning all history records is straightforward to implement but may fail performance-sensitive test cases; bisect is what the reports say the part needs.)

Task Management System

Problem Overview

Approach Trade-offs

What Reports Emphasize

Practice

Prepping for Anthropic with friends?

More Anthropic Questions

Every question in the Anthropic catalog gets this depth

Approach	Notes
Sorted list / heap for Part 2	A heap gives O(log n) insertion but O(n) iteration; a sorted list (with bisect.insort) gives O(n) insertion but O(1) ordered access — both are acceptable at OA scale.
Event log + linear scan for Part 4	Simpler to implement but O(n) per query; bisect on a timestamp-indexed log gives O(log n), and one candidate says the part needs bisect.
Heap / Priority Queue for Part 2	A heap can keep tasks sorted by priority in O(log n) per insertion, but complicates updates and deletion; a simpler list with sort-on-query is often sufficient given OA constraints.
Brute-force linear scan for Part 4	Scanning all history records is straightforward to implement but may fail performance-sensitive test cases; bisect is what the reports say the part needs.