How the interviewer opens it
“Design a system that lets employees ask questions about the company's Confluence content and get useful answers. Walk me through the high-level architecture.”
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
- User experience
- Corpus and users
- Traffic and read:write mix
- Source integration
- Freshness
- Authorization, consistency, and availability
- Latency
- Durability
- Model and data boundary
- Out of scope
The answers stay with the interviewer. In a SysRound round, Alex answers them as an interviewer would.
Scope of a strong answer
Core requirements
- Ingest and refresh current Confluence page content, including updates and deletions
- Answer employee questions using relevant page content and cite the sources
- Respect the requesting employee's current access rights throughout retrieval and generation
- State when accessible evidence is insufficient to answer
Usually out of scope
- Editing Confluence pages or taking actions on the user's behalf
- Attachments, images, OCR, and comments
- Training a foundation model
- Replacing Confluence's identity or permission system
What interviewers probe
- Authorization through retrieval, generation, and caching
- A correct final link is not enough: restricted text can already have leaked through model context, snippets, cached answers, or logs. Confluence access can change through an ancestor restriction or group membership without a page edit.
- Keeping page versions and deletions correct
- Pages produce multiple chunks, source events are unreliable, and index writes are not necessarily atomic across a page. A late retry can restore old text or a deleted page unless version transitions are explicit.
- Retrieving useful evidence from messy company documentation
- Internal questions combine exact project names and error codes with vague language. Duplicated pages, stale guides, and access filtering can leave apparently relevant results that do not actually answer the question.
- Grounded answers under untrusted source text
- Confluence content can contain misleading instructions, conflicting claims, or material unrelated to the question. A fluent answer and plausible-looking citations do not establish that its claims are supported.
Common mistakes
- Drawing an embed–vector database–LLM pipeline without an update, deletion, or permission story
- Using vector similarity alone for exact internal names, codes, and identifiers
- Treating chunk size and top-k as arbitrary constants without connecting them to evidence quality and token budgets
- Using model instructions as the access-control or prompt-injection boundary
- Ignoring source API limits, initial backfill, and model token quotas while overengineering database sharding
- Measuring only generated-answer fluency rather than retrieval coverage, supported claims, citations, and abstention
The bar by level
- Senior (L5/E5)
- Owns the full request and ingestion lifecycle: effective permissions and fail-closed behavior, versioned idempotent updates, deletions, hybrid retrieval, bounded context, and measurable answer quality. Uses the workload estimates to budget source calls, model throughput, latency, and cost rather than adding infrastructure by habit.
- Staff (L6+/E6+)
- Defines precise security and freshness contracts, including authorization-check boundaries and in-flight request limits. Explains inherited-permission changes, repair after missed events, safe degradation, and permission-sensitive caches or conversation history. Prioritizes improvements using evaluation and bottleneck data, and adapts the design to larger corpora or stricter isolation without weakening its guarantees.