Notification Preference Resolver
Design and build the classes that decide whether a notification is sent.
Task
A product sends notifications by category, such as billing, marketing and security. Preferences exist at three levels: organization, team and user. Each level can turn a category on or off, set quiet hours and set a time zone offset, or leave any of them unset. Design and build the classes that take the three levels and one notification and decide what to do with it. The design is yours, and you will be asked to explain your code.
Requirements
- decide(preferences, notification) returns {action, decided_by} and does not change its arguments. preferences has up to three levels, org, team and user. A level can set rules (one per category, with enabled true or false), quiet_hours ({start, end} as HH:MM) and utc_offset_minutes. Anything missing or null is not set. notification is {category, at}, where at is a UTC timestamp such as 2026-03-01T21:30:00Z.
- On or off: the most specific level that sets enabled for the category decides, in the order user, team, org, and decided_by is the name of that level. When no level sets it, the category is on and decided_by is "default". A category that is off returns action "skip".
- Locks: an organization rule with locked: true is final. The action follows its enabled value, decided_by is "org_lock", and neither a lower level nor quiet hours can change it.
- Quiet hours: the most specific level that sets quiet_hours decides the window, and the most specific level that sets utc_offset_minutes decides the offset (0 when no level sets it). The window is in local time, which is the UTC time plus the offset. It includes its start and excludes its end. A notification that would be sent inside the window returns {action: "hold", decided_by: "quiet_hours", until}, where until is the UTC timestamp at which the window next ends. Otherwise the action is "send".
- Invalid input raises ValueError containing the word shown: a lock below the organization level, or a locked rule that does not set enabled (locked); enabled that is not true, false or null (enabled); at in any other format (timestamp); quiet hours that are not HH:MM (quiet); a category that is not a non-empty string (category).
How you are graded
- Decomposition 15%
- Prompting the assistant 15%
- Verification 20%
- Judgment about AI output 15%
- Correctness 25%
- Communication 10%
Scores use evidence from your session. A short or incomplete session may not provide enough evidence for every skill. See a sample scorecard
Interview guidance
Design and build the classes that decide whether to send a notification. Preferences exist at organization, team and user level, and the rules are in the spec. Use the AI assistant however you like. At the end I will pick a block of your code and ask you to explain it line by line. Before you prompt, tell me in words the order in which the levels are consulted.
- AI is allowed and expected: your own Claude, OpenAI or Gemini key, or the free in-browser model.
- You are graded on how you drive and check the AI, not on how much you prompt.
- Run the checks; read what fails.
- A new requirement will arrive partway through.
- Too little AI use is reported as “not enough to grade”, never as a fail.
You will answer 7 debrief questions at the end
- What did you delegate to the AI, and why?
- Name one AI suggestion you rejected or changed, and why.
- Choose one block the AI helped write. Explain what each line does and which test verifies it.
- What is still risky, and what would you test or ship next?
- Pick the block the assistant wrote that you changed the most. Explain the final version line by line.
- How does your code tell "off" from "not set", and where did generated code get that wrong?
- Which design decision did you make before prompting, and which did you leave to the assistant? Would you split it the same way again?