Extensible card-hand ranking: three of a kind, flush, pair and a discard rule

Build a small card game in code. Each player holds a hand of cards; the program ranks the hands, decides the outcome, and returns a log of the whole process. The exercise is incremental: each part adds a rule, and further parts may follow, so the Part 1 design should leave room for later rules. The interviewer appeared to be assessing whether the object-oriented design extends cleanly to new requirements. You may build on a provided starter framework or write your own structure. Card ranks are integers, with jack, queen and king represented as `11`, `12` and `13`. Each card also has a suit, which Part 2 needs. Working assumption for practice: each hand has three cards, the smallest hand that can hold three of a kind. Confirm this, and the other open points below, with the interviewer. ### Clarifying Questions - How many cards are in a hand, and how many players take part in one game? - How is an ace represented, and does it rank low or high? - When two hands fall in the same category, how is the tie broken (for example, the rank of the triple or pair first, then the remaining cards), and can a game end in a tie? - What exactly should the returned log contain, and in what format: one line per step, or structured events? - Are the hands given as input, or does the program shuffle and deal from a deck? ### Part 1 — Three of a kind, pair, high card Implement hand evaluation and comparison with three categories, from strongest to weakest: three of a kind, pair, high card. Play one game: evaluate every hand, find the winner, and return the log of the process. ```hint Where will the next rule go? Before writing any comparison, ask what you would have to edit if a new category appeared between two existing ones tomorrow. Aim for an answer of one place. ``` #### What This Part Should Cover - A card and hand model that keeps ranks, suits and categories explicit - A comparison that orders categories first and breaks ties within a category deterministically - A log returned as a value and built as the game runs, not printed - A structure that anticipates new categories and new rules ### Part 2 — Add a flush Add a flush: a hand whose cards all share one suit. The new order, from strongest to weakest, is three of a kind, flush, pair, high card. ```hint Measure the change Count how many existing functions or classes this part forced you to edit. If the count is more than one or two, revisit the Part 1 structure. ``` #### What This Part Should Cover - Inserting a category between existing ones without rewriting the comparisons - How one flush is compared with another flush - Whether a hand can match more than one category, and how priority resolves it ### Part 3 — Add a discard rule Add a discard rule that is applied before hands are compared. In the version reported here, a hand that is not a pair is discarded, and that player drops out of the game. Other reports of this exercise describe a different discard rule for this part, so treat the rule as something that could change again. ```hint Rules that remove players This rule does not rank hands; it removes them. Consider whether it belongs inside the ranking logic or in a separate step of the game flow. ``` #### Clarifying Questions for this Part - Does a three of a kind count as "a pair" for this rule, or is only the pair category kept? - A flush ranks above a pair but is not a pair. Is a flush hand really discarded? - What happens when every hand is discarded, or when only one remains? - Should each discard appear in the log, and with what detail? #### What This Part Should Cover - Where the rule lives in the design, and how it could be swapped for a different discard rule - Correct handling of the edge cases the rule creates - Log entries that make each discard and the final result traceable ### What a Strong Answer Covers - A design in which each new category or rule is added in one place - Separation of the card model, hand evaluation, comparison, game flow and logging - Stated, deterministic tie-breaking and a defined result when no hand remains - Working code for all three parts within the interview time, with small tests at each category boundary - Clear communication of the assumptions taken where the rules were left open ### Follow-up Questions - How would you add a straight, and what would change if it ranked between flush and pair? - How would you let one game run under a different discard rule chosen at run time? - How would you test that adding a new category did not change how existing categories compare? - How would you make the log structured enough to replay or audit a game?