How the interviewer opens it
“Design a system that classifies incoming email as legitimate, spam, or phishing. The system must adapt to new attacks while it limits mistakes on legitimate mail.”
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
- Scale
- Data size and read:write mix
- Latency and availability
- Routes, consistency, and durability
- Class distribution and quality
- Labels and attack response
- Available evidence
- Privacy and sample lifetime
- Scope boundaries
- 45-minute interview plan
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
- Classify incoming email as legitimate, spam, or phishing
- Route messages to the inbox, spam folder, or quarantine
- Accept user corrections and restore messages
- Update detection as attacks change
Usually out of scope
- Outbound spam detection
- Mailbox search
- A new SMTP server or antivirus engine
- A new model architecture
- Removal of prior sample influence from existing model weights
What interviewers ask about
- Mistakes on legitimate mail
- Rare errors still affect many users at this scale. Spam preferences vary by recipient, while phishing can cause direct harm.
- Changes in attacks
- Attackers change messages faster than reliable labels arrive. They can also manipulate the feedback that the system uses for updates.
- Delivery during failures (optional)
- A saved verdict does not prove that the mailbox applied its route. Retries can conflict with a later user correction.
- Sample copies and deletion (optional)
- Private samples reach review tools, derived datasets, active jobs, and backups. Deletion must remove retained content, not merely hide its source.
Common mistakes
- Uses overall accuracy despite class imbalance and unequal error costs.
- Treats successful sender authentication or missing reputation as proof of safety.
- Uses unreviewed feedback or leaked test data to justify model releases.
- Measures errors only through user reports.
- Blocks the initial decision on remote analysis without a time limit or failure policy.
- Spends the interview on infrastructure details instead of classification quality and attack changes.
The bar by level
- Senior (L5/E5)
- Owns both primary deep dives. Selects thresholds against both quality targets and explains the evidence needed for release. Handles delayed labels, biased reports, campaign leakage, and hostile feedback. Defines bounded classification work, emergency policy changes, staged releases, and rollback. States delivery and deletion contracts without exhaustive protocols.
- Staff (L6+/E6+)
- Meets senior expectations and quantifies harm and measurement uncertainty. Defines review selection and release gates when reliable labels arrive late. Separates personal preferences, global threats, and attacker claims through explicit trust boundaries. Assigns authority for emergency changes and explains how the team detects harm from those changes. Detailed delivery recovery and deletion mechanics remain optional.