[sreque]

Well, you basically showed that you don't understand OOP. That may not be important to you, but the interviewer probably successfully found out what he was looking for.

The most important aspect of OOP is message passing, and in Java, message-passing is implemented via non-final methods. OOP is a model of computation, just as FP and imperative programming are, and certain jobs require that you understand that model of computation well.

[rlt3]

Well, if he eventually came up with the right solution, I would assume he understands OOP and overloading, as there usually isn't a way to just stop an interview and teach yourself core-foundations of a trade before answering questions.

I think the point was that, outside of specific cases, programming has many solutions. The fact that Paul gave two correct answers before getting to the 'right one' says that this was one of those cases.

Perhaps method overloading was not on the forefront of his mind that day.

A simple question of 'Why did you do it this way instead of using method overloading?' would've sufficed in figuring out whether or not they had a grasp on OOP and wouldn't have insulted the interviewee with open-ended questions where they were looking for one answer.

That would be the same as asking what is another way to write 49 and expecting only the squareroot of 2401.

[untog]

But that highlights exactly the problem. He wasn't asked to demonstrate message passing in OOP, he was asked to implement Rock, Paper Scissors. There are numerous OOP-y solutions to that, but there's no way for him to know what they're actually looking for.