LinkedIn·Software Engineer·Onsite - System Design / Architecture·Senior

SeniorPrefer not to say

May 2026

Summary

System design round at LinkedIn for a software engineer role. The whole session was one big question about building a multi-timezone calendar, which sounds contained but unravels fast once you get into recurring events and DST.

Questions Asked (1)

Design a calendar system that supports users across multiple time zones, including one-time and recurring events, schedule queries over a time range, correct timezone handling, and daylight saving time edge cases.

System DesignData ModelingTechnical Trade-offs

Author's notes

I started with the API and data model which felt safe, but the recurring events piece is where I started to lose the thread.

Create a free account to read the full note

AI HintsAI Generated

Suggested Approach

Start by clarifying requirements and scale, then design a data model that stores events in UTC with timezone metadata, and finally address querying and DST edge cases. Emphasize trade-offs between storage, query performance, and correctness.

Pro tip: Always store timestamps in UTC and convert to local time only for display; this avoids DST ambiguities and simplifies cross-timezone queries. Also, consider using a library like IANA tz database for accurate timezone rules.

1. Clarify Requirements and Scale

Ask about expected number of users, events, query patterns, and whether events are private or shared. Determine if recurring events can have exceptions and how timezones are assigned to events.

2. Design Data Model

Propose a schema for events, users, and timezones. Store event start/end in UTC, along with the event's timezone ID. For recurring events, store recurrence rules (e.g., RRULE) and handle exceptions.

3. Handle Timezone and DST Edge Cases

Explain how to convert UTC to local time using timezone libraries, and address DST transitions (e.g., events during skipped or repeated hours). Consider storing local time for recurring events to preserve wall-clock time.

4. Design Query API and Indexing

Define APIs for querying events over a time range, with timezone conversion. Discuss indexing strategies (e.g., on start time) and how to efficiently retrieve recurring events that may span the range.

5. Discuss Trade-offs and Scalability

Compare storing UTC vs. local time, and the complexity of expanding recurring events at query time vs. precomputing instances. Address scaling with sharding and caching.

Key Points to Mention

Store timestamps in UTC and convert to local time for display to avoid DST issues.
Use IANA timezone database for accurate timezone and DST rules.
For recurring events, store recurrence rules (e.g., iCalendar RRULE) and handle exceptions.
Consider storing local time for recurring events to maintain wall-clock time across DST changes.
Index events by start time in UTC for efficient range queries.
Discuss trade-offs between precomputing event instances and expanding on the fly.

AI-generated suggestions, not part of the candidate's original notes. May be inaccurate — verify before relying on them.