I've been asking interviewees, over at interviewing.io, to write a simulation of a two-player card game. It's an engaging question, revealing a lot...
For further actions, you may consider blocking this person and/or reporting abuse
I’d expect an interviewee to (hopefully) recognize that OOP isn’t that well-suited for this task, compared to a functional approach:
The sign of that number will tell you which player wins. The rest is window dressing.
As for a multi-player variant:
Note that if the goal was an actual, playable game, then things would be different. But the requirement here seems to be that we want to know which player wins the game (distilling core requirements is very valuable skill).
OOP works fine here, but you only need like 2-3 classes to group the data. No virtual functions, interfaces, nor anything else. I'm refering just to some basic encapsulation.
I'd not be opposed to a functional approach, albeit there is a caveat to it. Your algortihm deviates significantly from the source wording; having code that is mappable to source requirements is important. You might have a higher burden of naming in this approach to compensate.
I had one interviewee approach close to this way once. I don't penalize for it, but I add a requirement like emitting events as cards are dealt, or as they are turned up. That person didn't have much trouble changing their approach. That alone is a positive sign: they've shown functional design, but flexibility as well.
As you say, they've distilled a core requirement. Not many people actually ask for clarification as to what is allowed. For those that do I tend to imply it's a simplified program that would actually have UI.
I think it's why coding interviews need to be quite personal, with the interviewer having good knowledge of coding. It wouldn't be fair of me to accept only a rigid OOP structure. Sure, it's what I'd expect in a practical situation, but it's not the only option based on the stated requirements.
This was my initial thought too. As it's a simulation you can map the steps to functions that pop N from the list and determine the index of the player which wins.
That extends to as many players as you want without using classes (which in this test, YAGN...) and only becomes trickier in the later parts of the question where new rules are introduced.
At that point I can see myself preferring to defend my assumptions for a while before actually changing any code.
I love the functional approach! Thanks for sharing.
This is a great question. It's enough to get a feel for how a candidate goes about it, but is happily free of the usual algorithm pop quiz. I'll definitely steal this.
You mentioned something important that I think a lot of interviewers gloss over: prompting appropriately is not easy. I once bombed an interview because the interviewer kept hinting at something they wanted, but I wasn't getting the hint, and they really didn't want to go on until I did. I finally just said, "I'm sorry, I'm just not seeing what it is you're getting at. How about I carry on, and when I have a working solution we can circle back and talk about improvements." We did, and there was more vague hinting, but I never did figure out what they were after.
I think it's really important to have questions that actually call for the techniques you want to see. I love that a reasonable solution to this question might just be the initial
Gameclass with some local variables for players' hands and scores, but that the extended questions kind of turn up the pressure and make creating aPlayerclass, etc. It reveals something about the candidate's habits, and opens up an opportunity to talk about why they either introduced thePlayerclass right off the bat, or why they waited until it was more strongly called for.I'll definitely try to code it today to see if I can manage to do it in less than 45 minutes. Thanks for writing!
Let us know how you do.
I'm fairly disappointed with myself. Whilst it took me only 30 minutes to code the "core" solution, to code all functionalities I took almost two hours.
I was particularly stuck at how to determine a tie between multiple players... my final solution was not exactly "elegant" either, I used a bubble sort algorithm to order the players by score, so I would have a "ranking", then I compare their scores pushing them to a "winners" array until they aren't equal anymore.
I guess I would fail your interview.
By "core" solution you mean the 2-player version, and you got a bit stuck on the N-player parts?
Keep in mind that that in the interview I don't let people get stuck. When I see obvious struggles I'll give tips, or possible solutions. As long as it isn't excessive I don't count this against the people in the feedback. It's just a way to move it along and ensure I'm not evaluating people based on one block.
Things like sorting lists, and picking max/min, does some up a lot during interviews though, even the classic algorithm ones. It's also something that comes up quite often in day-to-day coding I find.
Not exactly. I built it already thinking it could be scalable to n players, I got stuck literally on the last function, the one that would display the winner, because I got carried away trying solutions to ties, but I guess I would be able to nail it in the 15 minutes I had left if you gave me a hint :P
"Only one person has made it this far, setting the gold standard for this interview question."
Ended up getting the job?
Yes, I like this. It's pretty simple and goes great length to show some skill. And it's actually fun too.
This is a screening/practice service. I naturally gave that person the highest rating and a positive feedback. I don't actually discover their final success or not. I assume it went well for them.
Now let's see if I ever get somebody who's seen this question online now. Should be easy enough to create variants.
How much time do you give to accomplish this?
About 45 minutes. I do about 5 minutes of talking about their history first. Though for college interviews I might drop that and just give them the full time for the coding part.
This is a really neat insight into what is going through an interviewer's head during an interview -- what things are important and what things don't really matter. Thanks!
This is a solid coding exercise for folks. How long do you usually give folks to complete this exercise?
About 45 minutes. Most people complete the basic code around 30 minutes I think, taking the rest to add N players. If they haven't completed the basic code by around the 35 minute mark I won't ask them to add N players, instead concluding the interview early.