Camel Cards / Poker OOD

Compare two simplified poker hands. Classify four-card hands by extensible hand types, break ties without sorting, then handle partial hands where network loss makes the result win / loss / tie / unknown. Requirements Each hand has four cards labeled 9 through 1; 9 is highest. Some sessions deal five cards instead of four — clarify the hand size before coding. Implement evaluate(hand1, hand2) returning HAND_1, HAND_2, or TIE. def evaluate(hand1: str, hand2: str) -> str: ... # hand1, hand2 are length-4 strings; each char is a digit '1'..'9'. # Returns "HAND_1" if hand1 wins, "HAND_2" if hand2 wins, "TIE" if exactly tied. # Compare hand type first; on same type compare cards right-to-left without sorting. # First differing original position decides; if all four positions match → "TIE". Hand types from strongest to weakest: four of a kind; two pair; three of a kind; one pair; high card. If two hands have the same type, compare cards from most recently dealt to first dealt. Do not sort the hand for tie-breaks. Design for easy addition of new hand types; OOP / Strategy pattern is expected. Follow-up: one or both hands may be incomplete due to network loss. Return a definite result only when the known cards prove win / loss / tie; otherwise return UNKNOWN. Examples 9999 is four of a kind. 2332 is two pair. 9998 is three of a kind. 5233 is one pair. 2345 is high card. Same-type tie-break: evaluate("2332", "2442") → "HAND_2" — both are two pair; scanning right to left the last card ties (2 == 2) before 3 < 4 decides. First-dealt decides last: evaluate("2345", "1345") → "HAND_1" — both high card; the right three cards tie and only the first-dealt 2 > 1 breaks it. Notes The published ordering has two pair above three of a kind; follow the prompt rather than normal poker. The prompt is adapted from the canonical "Camel Cards" puzzle, but with three deliberate twists: four cards instead of five, simple 1-9 labels instead of face cards, and tie-break by most recently dealt card rather than left-to-right. Reusing a memorized canonical solution without rewiring those three points fails the basic cases. A clean design separates classify(hand) -> hand_type_rank from a tie-break key that reads the original hand right to left under the custom rank order; comparing (type_rank, tie_break_key) tuples then handles both stages uniformly. For the partial-hand follow-up, compare each player's best possible completion against the other player's worst possible completion. If the lower bound of one hand still beats the upper bound of the other, the result is known. A concrete unresolvable case: 9999 (already four of a kind) against a hand showing only a single 9 — the second hand could still complete to four of a kind, so the comparison returns UNKNOWN. Interviewers care less about card-count code golf and more about whether new hand types can be added without rewriting a giant conditional. Preparation Implement a HandRule interface with matches, rank, and optional tie-break payload. Write tests for every hand type plus same-type card-by-card tie-breaks using unsorted input order. Practice the partial-information follow-up by enumerating possible completions for small hands, then discuss pruning if the deck model is specified.