[DoofusOfDeath]

At least in my case, there's a big difference between

(a) discussing an open problem with a colleague, and

(b) explaining what's going on in my mind as I'm attempting to solve the problem single-handed.

I'm very effective at (a), and it's a skill that I've used many times as a software developer and/or grad student.

But (b) is more typical in psychoanalysis sessions.

[Jemmeh]

May I ask what you feel the difference in the two is?

I often have to explain a problem to my coworker and vice versa. It's also really helpful when pair programming. Just curious about your experience.

[SomeStupidPoint]

There's a weird dynamic in interview questions you rarely, if ever, get in the workplace: the person who actually knows about the problem is staying quiet while the one just starting to reason through it is doing all the talking about it.

There's no back and forth -- you're not actually trying to help them solve anything -- it's someone who already knows the answer judging how much of it I can reason out in half-an-hour. I can't take 5 minutes to think it through, I can't stop talking for any significant amount of time without being told to narrate what I'm thinking about, etc. That's nothing like a workplace situation, where they'd be expect to hold up half the conversation, be providing input and thoughts on the problem, and I could just tell them I'd be with them in 15/this afternoon/tomorrow/etc.

It would be more realistic if the interview didn't get to see the question before the interview, either. (And why I think design questions work better than coding questions -- you can do something they're not expecting in the design, ask more kinds of questions about the spec, etc which cause an honest back-and-forth.)