How the interviewer opens it
“Design a weather application and its backend. It should get data from weather providers and stations, and let millions of users see current conditions and forecasts for a location.”
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
- product and geographic precision
- user traffic
- station ingestion
- forecast ingestion
- read:write mix
- latency and availability
- freshness
- consistency versus availability
- durability and retention
- 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
- Ingest station observations and provider forecasts
- Return current conditions and hourly and daily forecasts by latitude and longitude
- Expose source timestamps and distinguish fresh, stale, estimated, and unavailable data
- Keep weather reads working when an upstream source is delayed or unavailable
Usually out of scope
- Building a weather prediction model
- Severe-weather alerts and push notifications
- Historical weather queries
- Accounts, billing, and provider contract negotiation
What interviewers probe
- Geographic reuse without inventing local accuracy
- Caching exact GPS coordinates wastes reuse, but careless rounding or choosing the nearest station can produce misleading weather near coastlines, mountains, or coverage boundaries. Provider grids also do not necessarily match a convenient geohash.
- Late observations and honest freshness
- A recently received message may describe old weather. Replays, bad station clocks, and disconnected stations can otherwise make the application report stale data as current or move a station backward in time.
- Publishing forecast releases safely
- Forecast issue time and forecast valid time are different dimensions. An hourly release contains many future time slots, and partial downloads or overlapping processing can expose mixed releases or overwrite a newer prediction with an older one.
Common mistakes
- Spending the interview designing a weather prediction model instead of ingesting and serving provider output.
- Putting provider calls directly on the user request path.
- Treating all traffic as read-heavy while ignoring tens of millions of daily ingestion updates.
- Using cache TTL or ingestion time as the definition of weather freshness.
- Ignoring forecast issue time, partial publication, and older releases arriving late.
- Overbuilding a historical time-series platform or global transaction system when keyed latest-state reads meet the requirements.
The bar by level
- Mid-level (L4/E4)
- Scopes current conditions and forecast horizons, separates ingestion from reads, defines keyed latest-state storage, maps coordinates to reusable geographic data, and uses caching. Can explain stale-data responses and avoid calling providers per user.
- Senior (L5/E5)
- Quantifies both ingestion and read workloads, handles duplicate and late station events, distinguishes issue time from valid time, publishes complete forecast bundles safely, and protects hot locations and cache-failure paths. Gives concrete rules for freshness and station fallback.
- Staff (L6+/E6+)
- Defines the spatial and temporal correctness contracts before choosing mechanisms. Handles provider corrections, incompatible failover datasets, replay and partial rollout without unnecessary global coordination. Explains regional failure ownership, provider quota control, and which weather responses may degrade versus which future alert requirements cannot.