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 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.
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.