← Better.com Interview Insights

Better.com·Software Engineer·Technical Phone Screen·Intermediate

Intermediate
May 2026

Summary

Got a system design question at Better.com that was more database-heavy than I expected. One question, schema focused, pretty straightforward interview overall.

Questions Asked (1)

Q1

How would you design a relational database schema for a calendar application?

Data ModelingSystem DesignTechnical Trade-offs
Author's notes

I started with users and events tables, then realized mid-explanation I hadn't thought about recurring events at all.

Create a free account to read the full note

AI HintsAI Generated

Suggested Approach

Start by clarifying the core requirements and scope of the calendar application, then propose a normalized schema with tables for users, calendars, events, and attendees. Discuss key design decisions like handling recurring events, time zones, and conflicts, and explain trade-offs between normalization and performance.

Pro tip: Mention that recurring events are often stored as a separate table with recurrence rules (e.g., iCalendar RRULE) and exceptions, rather than generating individual event rows, to balance flexibility and query performance.

1. Clarify Requirements and Scope

Ask questions to understand expected features (e.g., recurring events, sharing, reminders) and scale. This ensures your design addresses the actual needs.

2. Identify Core Entities and Relationships

Define main entities like User, Calendar, Event, and Attendee, and their relationships (one-to-many, many-to-many). Sketch an entity-relationship diagram.

3. Design Tables and Columns

Propose specific tables with primary keys, foreign keys, and essential columns (e.g., event start/end times, time zone). Normalize to reduce redundancy.

4. Address Special Cases

Explain how to handle recurring events, time zones, and event reminders. Discuss storage strategies for recurrence rules and exceptions.

5. Discuss Trade-offs and Optimizations

Talk about indexing for query performance, denormalization for read-heavy workloads, and potential scaling considerations.

Key Points to Mention

  • Normalization vs. denormalization: balancing data integrity and query performance.
  • Handling recurring events with recurrence rules (e.g., RRULE) and exception tables.
  • Time zone storage: using UTC with time zone identifiers or separate time zone columns.
  • Indexing strategies on event start/end times and user IDs for efficient range queries.
  • Many-to-many relationships for event attendees and calendar sharing.
  • Scalability considerations: partitioning by date or user, and caching frequent queries.

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