How the interviewer opens it
“Design a login and authentication system for a large website. Users should be able to sign up, log in, stay signed in, and recover access if they forget their password. We also need to protect accounts from takeover.”
The prompt is vague on purpose. The first few minutes are yours: narrow it to the core features and agree on the numbers before you draw anything.
What to clarify first
- Clients and identity
- User scale
- Traffic and read:write mix
- Latency
- Consistency and availability
- Passwords and takeover protection
- Session behavior
- Sign-up and recovery
- Durability and deployment
- Scope boundaries
The answers stay with the interviewer. In a SysRound round, Alex answers them as an interviewer would.
Scope of a strong answer
Core requirements
- Sign up with a unique, verified email address
- Log in with a password while resisting credential stuffing and account enumeration
- Validate sessions, log out one session, and log out all sessions
- Reset passwords through email and revoke existing sessions
Usually out of scope
- Social login, enterprise SSO, and building an OAuth identity provider
- Application permissions and business authorization rules
- Building an email delivery service
- Manual identity recovery after loss of the email account
- Active-active operation across regions
What interviewers probe
- Password verification under credential-stuffing attacks
- Password hashing must be deliberately expensive, but attackers can invoke it without owning an account. A defense that protects servers by locking accounts can instead let attackers deny service to victims.
- Fast session validation with bounded revocation
- Hundreds of thousands of peak checks per second favor caching, but a stolen session must stop working after logout or reset. A cache or self-contained token can silently violate that guarantee during failures.
- Recovery and credential-change races
- Recovery is an alternate login path with the power to replace credentials. Concurrent link use, delayed emails, and logins already verifying an old password can undermine an otherwise correct reset flow.
Common mistakes
- Treating JWTs as the architecture without defining revocation, storage exposure, or browser behavior.
- Designing the successful login path but ignoring enumeration, credential stuffing, recovery abuse, and account-lockout denial of service.
- Using weak password hashing or choosing KDF parameters without estimating verification capacity.
- Making reset tokens single-use only in application code rather than through an atomic database transition.
- Revoking cached sessions eventually without a measurable upper bound, or ignoring replica lag.
- Introducing several databases and queues before showing why a relational store, a cache, and a delivery outbox are insufficient.
The bar by level
- Senior (L5/E5)
- Separates cheap session validation from expensive password verification, sizes both paths, and designs layered abuse controls. Gives a concrete bounded-revocation strategy and failure behavior. Handles concurrent reset consumption, invalidates sibling links and sessions, and closes the login-versus-reset race.
- Staff (L6+/E6+)
- States security invariants across database, caches, replicas, and asynchronous delivery, then tests them under partial failure. Balances account availability against abuse without allowing attacker-triggered lockout. Explains recovery-channel trust, safe credential/KDF migrations, cache-cold capacity, and how tighter revocation or a second region changes ownership and availability.