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.

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.

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.

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