Design an extensible poker-hand evaluator
Company: Rippling
Role: Software Engineer
Category: Software Engineering Fundamentals
Difficulty: medium
Interview Round: Technical Screen
Design and implement an object-oriented solution for a simplified 2-player poker-like game called **Camel Cards**.
## Game rules
- There are **two players**. Each player has a **hand of exactly 4 cards**.
- Card labels are one of: `9, 8, 7, 6, 5, 4, 3, 2, 1` (where **9 is highest**, **1 is lowest**).
- A hand is classified into **exactly one** hand type. From **strongest to weakest**, the types are:
1. **Four of a kind**: all four cards the same (e.g., `9999`)
2. **Two pair**: two cards the same + two cards the same (e.g., `2332`)
3. **Three of a kind**: three cards the same + one different card (e.g., `9998`)
4. **One pair**: two cards the same + two distinct others (e.g., `5233`)
5. **High card**: all cards distinct (e.g., `2345`)
> Note: This ordering is intentional (e.g., **any two-pair beats any three-of-a-kind**).
## Tie-breaking (ordering rules)
1. Hands are primarily ordered by **hand type** (stronger type wins).
2. If both hands have the **same type**, compare cards **from most recently dealt to first dealt** (i.e., **right-to-left**) **without sorting the hand**.
- Compare the rightmost card values; higher value wins.
- If equal, continue moving left.
- If all four positions are equal, it’s a tie.
## Task
Implement:
`evaluate(hand1, hand2) -> "HAND_1" | "HAND_2" | "TIE"`
Where each hand can be represented as a 4-character string like `"2332"` or an array/list of 4 card labels.
## Design requirement
In the future, many more hand types will be introduced. Design your solution to make it **easy to add new hand types** without rewriting the evaluator logic.
Quick Answer: This question evaluates object-oriented design and algorithmic problem-solving within Software Engineering Fundamentals, focusing on creating modular, extensible class hierarchies and comparator logic at the design/implementation level.