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.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
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.