How the interviewer opens it
“Design a system that detects posts that violate content policy and sends uncertain cases to human reviewers. Balance decision accuracy, reviewer capacity, and the time before a decision.”
The prompt is vague on purpose. The first minutes are for you. Reduce the prompt to the core features and agree on the numbers before you draw.
What to clarify first
- Content and scale
- Read and write mix
- Existing classifiers
- Review capacity
- Decision latency
- Accuracy and harm
- Consistency and availability
- Post edits and policy changes
- Durability and retention
- System boundary
The interviewer has the answers. In a SysRound round, Alex gives these answers, as a real interviewer does.
Scope of a strong answer
Core requirements
- Assess each new or edited post against the content policy
- Allow, block, or restrict a post while review remains open
- Route uncertain cases to qualified human reviewers
- Record decisions under the current policy and apply the correct visibility changes
Usually out of scope
- Build or train the classifiers
- Define the content policy
- Moderate video or private messages
- Build the feed or the post service
What interviewers ask about
- Decision quality
- Errors have different costs across policy categories. Human review covers a selected sample, which can hide errors in automatic decisions.
- Review capacity and delay
- Review arrivals can exceed a fixed workforce. A single queue can delay urgent cases even when the daily average fits.
- Post and policy changes during review
- Posts and policy can change while reviewers inspect a case. A late decision can expose unchecked content or apply obsolete rules.
- Posts during service failures
- The service crosses model calls, task storage, and feed visibility. A partial failure can lose reviews or publish content without a required decision.
Common mistakes
- Treats one confidence score as a complete policy decision.
- Ignores the fixed human capacity and promises every uncertain case an immediate review.
- Measures model quality only on cases that humans review.
- Applies a decision to a post ID without checking the content version.
- Treats a classifier timeout as either approval or a confirmed violation.
- Records a policy version without preventing an obsolete verdict from closing a case.
The bar by level
- Senior (L5/E5)
- Calculates review capacity and peak delay. Designs skill-based review, safe visibility updates, and recovery from partial failures. Prevents policy changes from racing with review closure. Explains quality checks beyond reviewed cases.
- Staff (L6+/E6+)
- Defines error budgets by harm and language. Sets policy release gates and explicit overload rules. Budgets reassessment work without starving new cases. Resolves conflicts between error costs, reviewer capacity, and deadlines.