Text Editor Undo/Redo — OOD Interview Walkthrough

Phase 1: Requirements & Use Cases

Interviewer: "Design the undo/redo functionality for a text editor."

Candidate: "Let me confirm scope. I'm designing the undo/redo subsystem for a text editor — the mechanism that lets users reverse and re-apply editing operations like typing, deletion, copy-paste, and formatting. This is a class-level design problem, not a full editor implementation. I'm focused on the model that tracks operations and restores state, not the rendering layer. Does that match?"

Interviewer: "Yes. What are the core use cases?"

Candidate: "Core use cases:

1. User performs an edit operation (insert text, delete text, replace text)
2. User presses Ctrl+Z (undo) — the last operation is reversed
3. User presses Ctrl+Y (redo) — the most recently undone operation is re-applied
4. After a new edit following an undo, the redo history is cleared
5. Undo/redo stacks have a maximum depth to bound memory usage
6. The editor can report whether undo and redo are currently available"

Interviewer: "What about undoing across multiple sessions — persistent undo history?"

Candidate: "I'd scope that out. Persistent undo requires serializing operations to disk, which involves storage formats and session management. I'll design so operations are serializable in principle (they're value objects), but I won't implement persistence. The core model is in-memory."

WHY: Persistence adds complexity in serialization and file format versioning that's orthogonal to the OOD pattern being tested.

Interviewer: "What about compound operations — like a macro that runs 10 steps as one undoable action?"

Candidate: "Great edge case. I'll support…