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.
public enum Color {
RED, BLACK
}
public enum Suit {
Diamonds(RED, '♦'),
Hearts(RED, '♥'),
Clubs(BLACK, '♣'),
Spades(BLACK, '♠');
Color color;
char symbol;
public Suit(Color color, char symbol) { this.color = color; this.symbol = symbol; }
}
public enum Rank {
Ace('A'),
Two('2'),
//...
}
public record Card(Suit suit, Rank rank) {
// ...
}
The question is fundamentally broken because data objects shouldn't be inheriting anything. That's in almost all cases bad design that demonstrates only that you have no clue how to write sensible object-oriented code.
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.
Nice. Very thorough, that’s a more positive take than what I was presenting, though I feel we are both (rightly) being standoffish on the whole inheritance requirement.
Some other things you could do with a deck of cards to add useful functions.
Shuffle
Draw
Deal
Cut
Pile
Turn
Now imagine you have pinocle uno and cribbage as games. they each start with a different set of cards, but can use the functions above. The fact that it’s a 52 card deck with suits and ranks isn’t stated by GP, and there’s also the optional jokers.
For a real game, you’d probably need the back of cards as well for animation, and maybe you implement card designs to give the game some customization - now the deck needs some more properties or methods.
After all of that, think of whether the generic deck could be used to play magic or pokemon by using inheritance.
For lastpass, the closest parallel they might have to a deck is a password generator. Implementing that would seem like work. The deck stuff is all premature optimization for a single game, but they are checking your knowledge of inheritance, so just go along with it.
To be fair, none of the functions you listed, as far as I can tell, need to know anything about what they're operating on. You can implement all but the last on a generic list of objects.
The last I'd probably implement as a container object Turnable<C> that adds an orientation state to any parametrized type, including Reversi disks.
I feel the card itself should be immutable as far as possible. It's state: orientation, owner, location and whether it's dog-eared should be kept separately.
Many card games have a reduced deck - e.g. lots of French card games use a 36-card deck. Some card games use multiple decks mixed together (e.g. Canasta). Some have extra cards (jokers are common, there are others); some have entire extra suits (e.g. games that used to be played with various forms of tarot decks).
All this stuff needs to be parameterised, and suddenly you have an enterprise-worthy class hierarchy and a ton of complexity before you've even really started on game-specific stuff.
It’s important to be solving an actual problem. Modelling a deck of cards is probably not the problem — what are we actually solving? Building a new hearts.exe? Rendering a custom deck for a laser cutter? Tracking casino fraud?
Those would be better questions which could start off with a discussion about the general solution, followed by a quick “how would you model the cards part of this?” component.
When applying for a senior role, yes. Part of a senior developer’s job is to push back against “requirements” that don’t further business needs; in this case, an accurate, maintainable, and useful model of a deck of cards.
> 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.)
I did a take home for Walmart Labs once and they completely ghosted me. What a complete waste of time.
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:
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.