[paulgb]

The best interview experiences I've had have started with whiteboard coding but turned into a discussion about the code, assumptions, requirements, theoretical possibilities vs. practicalities, etc.

The worst have been ones where it was clear the interviewer had pulled questions out of the company's interview playbook and didn't have the depth of understanding to discuss them.

[jpdoctor]

> The worst have been ones where it was clear the interviewer had pulled questions out of the company's interview playbook and didn't have the depth of understanding to discuss them.

I'd argue that also belongs under the "best" list, because it told you exactly the level of the people you'd be working for/with.

[paulgb]

Very true.

In one such interview, I was asked for a way to implement Rock Paper Scissors in OOP without using a conditional. I came up with a neat way to do it with modulo operations and array lookups, but that wasn't The Right Way. So I came up with a way to do it with exceptions, but it wasn't The Right Way. Finally I came up with the solution the interviewer had in mind, which used Java's method overloading (my background is not Java).

I'm not sure if I "passed" the interview, but it certainly didn't make me want to.

[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.