Design Calendar Event CRUD with Unit Tests

Quick Overview

This Ramp software engineering question asks candidates to design calendar event CRUD behavior with unit tests. It is useful preparation for interviews that value API shape, validation rules, edge cases, and a testable implementation plan.

Design Calendar Event CRUD with Unit Tests

Company: Ramp

Role: Software Engineer

Category: Software Engineering Fundamentals

Difficulty: hard

Interview Round: Technical Screen

Design and implement a small calendar application that supports creating, editing, and deleting events. The interviewer expects unit tests and clean state management rather than a full production calendar. ### Constraints & Assumptions - A single-user in-memory calendar is enough unless clarified. - Events have id, title, start time, end time, and optional metadata. - Overlapping events may be allowed or rejected depending on requirements. - Persistence is out of scope for the first version. ### Clarifying Questions to Ask - Should overlapping events be allowed? - Can events repeat? - What fields are editable? - Should delete be hard delete or soft delete? - What time format and timezone should be used? ### What a Strong Answer Covers ```premium-lock What a Strong Answer Covers ``` ### Follow-up Questions - How would recurring events change the model? - How would you add availability search? - How would you support multiple users? - How would persistence affect test design?

Quick Answer: This Ramp software engineering question asks candidates to design calendar event CRUD behavior with unit tests. It is useful preparation for interviews that value API shape, validation rules, edge cases, and a testable implementation plan.

|Home/Software Engineering Fundamentals/Ramp
Ramp logo
Ramp
Jul 2, 2026, 7:02 PM
hardSoftware EngineerTechnical ScreenSoftware Engineering Fundamentals
23
0

Design and implement a small calendar application that supports creating, editing, and deleting events. The interviewer expects unit tests and clean state management rather than a full production calendar.

Constraints & Assumptions

  • A single-user in-memory calendar is enough unless clarified.
  • Events have id, title, start time, end time, and optional metadata.
  • Overlapping events may be allowed or rejected depending on requirements.
  • Persistence is out of scope for the first version.

Clarifying Questions to Ask Guidance

  • Should overlapping events be allowed?
  • Can events repeat?
  • What fields are editable?
  • Should delete be hard delete or soft delete?
  • What time format and timezone should be used?

What a Strong Answer Covers Premium

Follow-up Questions Guidance

  • How would recurring events change the model?
  • How would you add availability search?
  • How would you support multiple users?
  • How would persistence affect test design?
Loading comments...