Allow switching between multiple whiteboard pages during an interview #445

Motivation

Consider a candidate explaining an algorithm on the whiteboard. Halfway through the discussion, they think of a different approach and want to illustrate it separately. Later, they realize the original approach could also be improved and want to return to that drawing.

In a physical interview, the candidate could simply use another sheet of paper, then return to the previous one without redrawing everything.

CodeTrial currently provides Clear and Undo, but these operate on a single editing history. Exploring a new idea without losing the previous drawing requires working around that history.

Supporting multiple whiteboard pages would let candidates explore alternative ideas and revisit earlier reasoning naturally, without introducing advanced diagramming tools.

Current implementation

The existing architecture already provides most of the drawing functionality:

• web/whiteboard.js: createBoard() manages vector strokes, Undo/Redo, Clear, and an operation journal.
• web/interview.js: initWhiteboard() maintains one board model. recordBoardOps() records operations, while queueBoardPublish() synchronizes the current board image.
• src/livekit/board.rs: The server retains the latest board image for the AI interviewer and manages phase checkpoints used in reports.
• web/replay.js and web/recording/recording.js: Both currently reconstruct a single board from recorded operations.
• docs/recording-contract.md: The existing replay format does not identify individual whiteboard pages.

The main challenge is therefore preserving consistency across drawing state, AI synchronization, and recording/replay rather than implementing the drawing tools themselves.

Proposed implementation

Keep a separate createBoard() instance for each page while reusing the existing canvas, painter, and drawing tools.

The initial implementation would:

• Start with Page 1 and provide a page selector and a New page button.
• Create a blank page and switch to it immediately.
• Preserve each page's strokes and independent Undo/Redo/Clear history.
• Allow candidates to return to earlier pages and continue drawing.
• Keep drawing tools shared across pages.
• Apply the existing editing restrictions to page creation and switching.
• Limit the feature to Whiteboard Interview Mode without changing the coding interview drawing area.

This reuses the existing drawing model rather than introducing a new frontend framework or external drawing library.

AI synchronization

The AI interviewer would continue receiving the currently displayed whiteboard through the existing image delivery mechanism.

Switching pages would synchronize the newly selected page, including an empty page. Returning to an earlier page would resend its current image.

This approach preserves the existing read_board interface and allows candidates to revisit earlier drawings with the interviewer.

It does not introduce automatic cross-page retrieval or comparison by the AI.

Recording and replay

The existing replay format records drawing operations without page identity. Simply adding page controls would cause operations from different pages to be reconstructed on the same board.

Replay events therefore need to identify the relevant page and preserve page navigation.

The proposed approach is to extend the recording contract with page-aware events, update both replay renderers, and share the page-state logic where practical.

Historical single-page recordings must remain compatible. Existing recording quotas, consent requirements, and retention rules would remain unchanged.

Report behavior

There are two possible approaches to preserving drawings after an interview:

Option A: Preserve the existing reporting behavior.

The report would continue using phase checkpoints and the final displayed board. Recorded page navigation would allow earlier pages to be revisited through replay, without changing the report structure.

Option B: Include all whiteboard pages in the final report.

This would make reviewing alternative solutions more convenient, but would require additional report handling and potentially affect AI assessment inputs.

I favor Option A for the initial implementation because it addresses the main use case while keeping the change focused. Option B could be considered separately if preserving every page in the report is important to the intended workflow.

Validation

The implementation should verify that:

1. Drawings and editing histories remain intact across page switches.
2. Undo, Redo, and Clear affect only the selected page.
3. Page switching synchronizes the correct image to the interviewer.
4. Recording and replay reproduce page navigation and drawing operations correctly.
5. Existing single-page recordings remain readable.
6. Existing drawing restrictions, shortcuts, and checkpoint behavior are preserved.

Related work

• Add a whiteboard interview mode #65 and Add the whiteboard interview mode #72 introduced Whiteboard Interview Mode and its recording behavior.
• Add an example drawing area to coding interviews #255 and Add example drawings to coding interviews #262 added drawing support to coding interviews.
• Add keyboard undo and redo to whiteboard interviews #352 and Add whiteboard undo and redo shortcuts #366 established whiteboard Undo/Redo shortcuts.
• Repaint only the stroke being drawn on the board #361 improved the existing drawing renderer.

This proposal focuses on preserving and revisiting multiple ideas during a whiteboard interview, rather than introducing advanced drawing tools.

The analysis is based on source code and contract inspection; no implementation or runtime validation has been performed.

I would appreciate feedback on the proposed scope, particularly whether the existing report behavior in Option A is sufficient for the initial implementation.