SystemOverflow
Learn→UML & Modeling→Sequence Diagrams→5 of 6
UML & Modeling • Sequence DiagramsHard⏱️ ~4 min

Interview Deep Dive: Common Sequence Diagram Questions

Common Interview Scenarios

Interviewers often ask you to draw sequence diagrams for critical workflows to verify your design handles edge cases and validates object interactions.

1. "Walk Me Through the Checkout Flow" (Library System)

What they're testing: Can you identify all participating objects, proper ordering of operations, and validation steps?

:Librarian → :CheckoutService: checkout(member, book)
:CheckoutService → :Member: canBorrow()
:Member ⤶ :CheckoutService: true/false
[if false] :CheckoutService ⤶ :Librarian: error("Max books reached")
[if true] :CheckoutService → :Book: isAvailable()
:Book ⤶ :CheckoutService: true
:CheckoutService → :Transaction: «create»(member, book, dueDate)
:CheckoutService → :Book: markCheckedOut(member)
:CheckoutService → :Member: addTransaction(transaction)
:CheckoutService ⤶ :Librarian: success(transaction)

Key points to mention: Validate member eligibility before modifying state. Check book availability before creating transaction. Update both Book and Member state atomically. Return transaction object for record-keeping.

Interview Tip: Always show validation before state mutation. If interviewer asks "what if member has overdue books," extend the canBorrow() check to include that logic.
2. "How Does Concurrent Parking Work?"

What they're testing: Do you understand synchronization and race conditions in shared state?

Two drivers request spots simultaneously:

Thread 1: :Driver1 → :EntryTerminal1: pressButton()
Thread 2: :Driver2 → :EntryTerminal2: pressButton()
:EntryTerminal1 → :ParkingLot: requestSpot(COMPACT)
:EntryTerminal2 → :ParkingLot: requestSpot(COMPACT)
:ParkingLot → :SpotManager: synchronized findAndReserve()
[atomic operation: find + mark occupied]
:SpotManager ⤶ :ParkingLot: spot101
:SpotManager ⤶ :ParkingLot: spot102

Discussion: Without synchronization, both threads might see the same spot as available. Solution: Make findAndReserve() atomic using locks, or use optimistic locking where markOccupied() fails if spot already taken, triggering retry. In interviews, acknowledge the issue exists but note that "full implementation would need thread-safety, possibly using synchronized blocks or database transactions."

3. "Show Me the Elevator Request Handling"

What they're testing: Can you model asynchronous operations and callbacks?

:User → :FloorPanel: pressButton(floor=5)
:FloorPanel → :ElevatorController: requestElevator(floor=5, direction=UP)
:ElevatorController → :SchedulingAlgorithm: findBestElevator(5, UP)
:SchedulingAlgorithm ⤶ :ElevatorController: elevator2
:ElevatorController → :Elevator2: addStop(5) [async]
:ElevatorController ⤶ :FloorPanel: requestQueued()
:FloorPanel → :FloorPanel: illuminateButton()
[... time passes, elevator arrives ...]
:Elevator2 → :ElevatorController: arrivedAt(floor=5)
:ElevatorController → :FloorPanel: elevatorArrived()
:FloorPanel → :FloorPanel: turnOffButton()

Key pattern: Asynchronous request-response with callback. addStop() is async (open arrowhead), control returns immediately. Later, elevator notifies controller via arrivedAt() callback. This shows understanding of event-driven design.

4. Machine Coding Variations
  • "Add payment processing to parking lot:" Extend exit sequence to include :PaymentProcessor, :PricingStrategy, and handling declined payments with retry loop
  • "Support reservation system in parking:" Show reservation creation, validation at entry (hasReservation()), and reserved spot allocation
  • "Handle elevator emergency stop:" Show alternative path where :SafetySystem interrupts normal flow, sends emergencyStop(), triggers :AlarmSystem
Interview Tip: When asked for variations, don't redraw entire diagram. Say "The main flow stays same, but I'd add a branch here where we check for reservation first before finding available spots." Use annotations to show delta.
5. Red Flags in Sequence Diagrams
Avoid These Mistakes:
  • Showing getter/setter calls explicitly (getPrice(), setPrice()) - assume property access
  • Having God Object that does everything - :System shouldn't orchestrate all operations
  • Missing validation steps - always check preconditions before state changes
  • Inconsistent state - if you markOccupied(), must later markAvailable()
  • Forgetting return values - show what data flows back, especially for queries
Follow-up Questions to Expect

After drawing sequence diagram, interviewers probe deeper:

  • "What if this operation fails?" - Show alternative error path or explain rollback strategy
  • "Is this thread-safe?" - Discuss synchronization needs for shared state
  • "What's the time complexity?" - If sequence includes search, mention algorithm used
  • "How would you test this?" - Talk about mocking objects and verifying message order
💡 Key Takeaways
✓Show validation before state mutations to handle edge cases
✓Use synchronous vs asynchronous arrows correctly for blocking/non-blocking calls
✓Include error paths when asked 'what if X fails'
✓Don't draw getters/setters explicitly, focus on business logic
✓Demonstrate thread-safety awareness for concurrent operations
📌 Examples
1Library checkout: validate member eligibility, check book availability, create transaction atomically
2Concurrent parking: synchronize spot allocation to prevent double-booking
3Elevator request: async request-response pattern with callbacks
4Payment processing: show retry logic for declined transactions
← Back to Sequence Diagrams Overview
Interview Deep Dive: Common Sequence Diagram Questions | Sequence Diagrams - System Overflow