How the interviewer opens it
“Design a service that shares a user's screen with remote participants. Keep text readable and delay low when network capacity changes.”
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
- Session size
- Scale and clients
- Screen content
- Traffic mix
- Delay
- Network limits and quality
- Geographic scope
- Consistency and durability
- Privacy and access
- Exclusions
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
- Share a selected screen or application window
- Let authorized participants view the active share
- Adapt screen delivery to each viewer's network limits
- Stop screen delivery when the presenter ends the share
Usually out of scope
- Audio and camera video
- Remote mouse and keyboard control
- Recordings and playback
- Calls across continents
- End-to-end encryption
What interviewers ask about
- Text quality
- Text needs sharp edges, but motion consumes much more bandwidth. A policy that favors smooth motion can make the shared screen unreadable.
- Different viewer networks
- One source serves viewers with different network and decode limits. A slow viewer must not create long delays or reduce quality for everyone.
- Viewer growth and recovery
- Viewer growth increases service traffic without changing the source screen. New viewers and failed media servers still need a complete, decodable image.
- Screen access
- A screen can expose private data immediately. An open media connection can outlast the permission that allowed it.
Common mistakes
- Treats the screen as a file stream with no limit on frame age.
- Lowers resolution before frame rate, which can make text unreadable.
- Assumes an SFU can create readable media at a lower rate by removing arbitrary packets.
- Budgets media bandwidth but ignores extra source layers and TURN traffic.
- Stores screen frames without a requirement or a privacy policy.
- Checks access only when a viewer joins.
The bar by level
- Senior (L5/E5)
- Separates control from media. Defines rate control for each viewer, bounded queues, and recovery from missing frames. Budgets source upload, media fanout, and relay traffic.
- Staff (L6+/E6+)
- Defines a client support policy and measurable quality goals. Resolves conflicts between text quality and delay. Handles revocation failures and regional recovery. Justifies the cost of extra encodes and spare media capacity.