Asana·Software Engineer·Onsite - System Design / Architecture·Intermediate

IntermediatePrefer not to say

Jun 2026

Summary

Asana software engineer interview that went deep into object-oriented design, specifically around a jigsaw puzzle game. More involved than I expected for what I thought would be a standard coding round.

Questions Asked (1)

Design an object-oriented model for a jigsaw puzzle game in a real programming language. Your model should include a Puzzle class composed of Pieces, each with a position in the solved image and edges that can be flat, tab (outward), or blank (inward). Pieces should be placeable on a board with valid interlocking logic, support rotation, snapping of connected groups, and a solved-state check. Walk through your class hierarchy, key data members, the edge-matching algorithm, and how you'd unit-test piece compatibility.

System DesignData ModelingTechnical Trade-offs

Author's notes

I spent the first few minutes just staring at this because I kept second-guessing whether to start with the edge type enum or the board class.

Create a free account to read the full note

AI HintsAI Generated

Suggested Approach

Start by clarifying requirements and assumptions, then present a clean class hierarchy with Puzzle, Piece, Edge, Board, and Group. Walk through the edge-matching algorithm and rotation handling, emphasizing how groups merge and how solved state is checked. Finish with a unit-testing strategy that covers edge compatibility, rotation, and group snapping.

Pro tip: Demonstrate maturity by discussing trade-offs: e.g., using enums for edge types vs. classes, and how to handle rotation efficiently without mutating shared state. Also mention that you'd write tests first for the edge-matching logic to ensure correctness.

1. Clarify requirements and assumptions

Ask about puzzle size, rotation support, user interactions, and whether pieces can be placed anywhere or only in valid positions. State your assumptions clearly.

2. Design class hierarchy and data members

Define Puzzle, Piece, Edge, Board, and Group classes. Specify key fields like edges (list of 4 Edge objects), position, rotation, and group references.

3. Explain edge-matching and rotation logic

Describe how to compare edges (tab vs. blank) considering rotation, and how to check compatibility between adjacent pieces on the board.

4. Describe group snapping and solved-state check

Explain how connected pieces form groups, how groups merge when pieces snap, and how to check if the entire puzzle is solved (e.g., all pieces in one group with correct positions).

5. Outline unit-testing strategy

Propose tests for edge compatibility, rotation, group merging, and solved-state detection. Include edge cases like flat edges on borders and invalid placements.

Key Points to Mention

Edge representation: use an enum (FLAT, TAB, BLANK) and store edges in a fixed order (top, right, bottom, left) to simplify rotation.
Rotation: implement rotation by shifting the edge list; ensure pieces can be rotated 0, 90, 180, 270 degrees.
Edge-matching algorithm: for two adjacent pieces, check that the touching edges are complementary (TAB matches BLANK, FLAT matches FLAT only on borders).
Group snapping: use union-find or a graph structure to track connected components; when a piece is placed, check all four neighbors and merge groups if compatible.
Solved-state check: puzzle is solved when all pieces are in a single group and each piece's position matches its solved position (or all edges match).
Unit testing: test edge compatibility with various rotations, group merging, and solved-state detection; use mocks for board and pieces to isolate logic.

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