Design and Data Structures

The Code Design round hands you a real-world prompt with the method signatures already stubbed out, and you fill them in with code that runs and passes tests before the hour is up. Then the interviewer starts pulling on it: make this operation constant time, defend why you stored it that way, add a case it does not yet handle. The problems that recur here are not exotic. These structures keep a live product responsive. One is a counter that always knows its busiest and quietest label. Another is a cache that evicts by how often an entry is used, and the last is a game board that advances one step at a time. Each maps onto something Jira or Confluence does under load.

This lesson makes four of them runnable. The first three are class-ops problems you build against tests: a structure that keeps a max and a min key current at all times, a frequency-aware cache, and a snake board with a food queue. The last is a single function that ranks teams from a pile of ordered votes, a pure sorting-by-vector task dressed as a leaderboard. All four reward the same habit. Name the model and the complexity before you type, settle the edge cases with the interviewer, and drive all the way to green tests rather than stopping at an elegant sketch.

The Atlassian angle

Treat Code Design as pair-programming against a clock, because a working, tested solution is the grade and a half-finished elegant one is not. Atlassian says plainly it cares more about how you think than how fast you type, and that a missing line will not sink you. True, but it's also a trap. At senior levels two quiet failures sink strong coders: needing hints to reach something that runs, and not finishing. So narrate continuously, settle the signatures and the edge cases before you code, and reach green tests. What the interviewer wants to watch is you modeling a domain and then evolving it, which is the daily work of shipping into a codebase millions of teams depend on.