Live TDD Pairing: Grow a Multiset Class One Test at a Time

This is a pairing exercise rather than a solo coding problem: the interviewer types, and you drive by describing what test to write next and what the simplest implementation change is that makes it pass. Together you build a Multiset class (a collection that can hold the same value more than once and remembers how many times) in small, test-first steps.

Pick any language you're comfortable narrating in -- Python is assumed below, but the exercise works the same in any language the interviewer is willing to type. The guiding principle is "write the smallest implementation that makes the current failing test pass," and the interviewer will push back if your proposed implementation does more than the tests currently require. For example, while only an emptiness check has a test, a single boolean field is a legitimate implementation -- nothing yet forces you to store actual elements.

Assume a minimal starting surface for the class: an emptiness check, adding an item, counting how many times an item appears, removing one occurrence of an item, and a total size. Confirm this list and each method's exact behavior with the interviewer before writing the first test -- in particular, whether remove on an item that isn't present should raise, silently do nothing, or return a status value, and whether two values are considered "the same" by equality or by identity.

There typically isn't time to finish every method in depth, so prioritize covering the core behaviors breadth-first rather than exhaustively testing one method. The session closes with a verbal discussion: if you had another hour, what would you add next (iteration support? a generic/typed version? thread safety? a way to list distinct elements and their counts?), and how would you test each addition before writing it.

What's expected

• A sensible order to introduce tests in, where each new test forces exactly one small, well-motivated change to the implementation.
• Comfort replacing an earlier "simplest possible" implementation (like a boolean flag) with a more capable one (like a counting map) once a later test genuinely requires it, rather than over-building from the start.
• Clear, test-first communication: stating the test, its expected result, watching it fail for the right reason, and only then describing the code change.
• A short, concrete plan for what comes next if the session had more time.