| Sounds silly, it’s a shame you didn’t get past the initial screen. It’s a process that has to be humored and you could have added a lot of value just by joining and then patching their hiring process. When I was teaching in high school the deck-modelling thing is one that the kids come up with a lot especially when it came to doing their term project. I love the idea of being asked to implement a deck of cards using Java and inheritance! Here’s my implementation: SUITS = “♠♥♦♣”
RANKS = “A23456789XJQK”
deck = {(s, r) for s in SUITS for r in RANKS}
That’s about all you can commit to. Suits and ranks should probably be enums but we can start from these three lines and see how it goes.Sorting? Depends on the game. Value? Depends on the game, and some games give the same card two values. Inheritance? Shared behavior depends on the game and is orthogonal to the card itself and often is dependent on game state as well as what card you have. Are we even playing a game, or is this just for rendering poker themed wallpaper? Calling it a “deck” is probably wrong. A deck is ordered and may have duplicates… it depends on the game! This is more of a pack than a deck. It’s probably an amazing question for interviewing candidates in person to see how far they dig into the premise. As a take-home question, you could probably spend a minute on the code above and then an hour on implementing three different games. Maybe that was the original docx, but it didn’t sound like it. |
You wouldn't want to check whether a poker hand has a pair by using a bunch of instanceof's or getClass()-shenanigans. You also don't want to encode knowledge about poker into into the card object. That's just data.