Katkat
Back

Design Blackjack Hands, Splits, and a Multi-Deck Shoe

PinterestSoftware Engineer · Technical Screen
MediumSoftware EngineerTechnical ScreenSoftware Engineering Fundamentals

Last updated

This problem tests object-oriented design principles, specifically the ability to model a card game with multiple decks, complex state transitions (like splitting), and encapsulation of game rules.

Problem Statement

Design the core object-oriented system for a Blackjack game engine. The system must support the following requirements:

  1. The Shoe: A container that holds a configurable number of standard 52-card decks. It must support shuffling and drawing cards.
  2. The Hand: A collection of cards that can calculate its own value (accounting for Aces as 1 or 11). It must support hitting and, if the first two cards have the same rank, splitting into two separate Hand objects.
  3. Game State: A mechanism to track the player's hands and the dealer's hand throughout a round.

Requirements

  • Provide a class structure (e.g., Card, Deck, Hand, Shoe, Game) using Python-style pseudocode.
  • Ensure the Hand class correctly handles the "soft" vs "hard" total logic.
  • Define how the split operation modifies the player's set of hands.

Example

# Expected interaction:
shoe = Shoe(num_decks=6)
player_hand = Hand([Card(rank='8'), Card(rank='8')])

# Splitting should result in two hands
hands = player_hand.split(shoe)
# len(hands) == 2, each hand now contains one '8' and one new card drawn from the shoe

Constraints & Edge Cases

  • What happens if the Shoe runs out of cards?
  • How do you handle the state transition during a split where a new card is immediately dealt to each new hand?
  • How do you represent a "blackjack" (21 on first two cards) vs. a total of 21 achieved after multiple hits?

Hints

Hint 1

Use a composition pattern where the Shoe contains Deck objects, and the Hand is a collection of Card objects.

Hint 2

For the split operation, verify that the Hand contains exactly two cards of equal rank before allowing the split to proceed.

Hint 3

Implement an observer or a state-manager pattern to handle the transition from the player's turn to the dealer's turn once the player stands or busts.

Follow-up questions

  • How would you integrate a betting system into this model without violating the single-responsibility principle?
  • If this were a multi-player game, how would you design the API to handle concurrent player decisions?
  • How would you unit test the Hand value calculation to ensure edge cases like multiple Aces are handled correctly?