I'm running into a common theme here. This is mostly regarding facebooks format for coding interviews. Which is an intro and two coding problems within 45 minutes.

1. With a greeting and TWO coding problems, is there time for clarifying the question, pseudo code it, “ASCII diagrams” (like a tree), example walk through of inputs and coding it? I love doing all those things but when I’m on a 20 minute clock my reflex is to go straight to code as fast I can.

2. Several times, in real and mock interviews, my approach was correct, but the interviewer wanted to steer me towards their way (which they got from say leetcode or something). This is a great communication opportunity, I love communicating and understanding how others think, but not when I’m on a 20 minute clock and I’ll get a fail if the code isn’t done. I’m struggling with priority. Do I stop and learn the interviewer's approach (through hints) or focus on coding it up a way I’m confident in, but could be not optimal (sometimes).

So is pseudo code worth it? Yes, it's quicker and easier to adjust. But I can code almost as fast as pseudo code (or my foolish brain think's it can ;) ) Is walking through a tree problem with 8 nodes recursively (drawing in ASCII) worth the time before getting to code? To see if the solution works and risk not even getting brute force code done?

How do you deal with the interviewer needing as much time to understand your approach vs you taking the time to learn theirs. In real job, I'd absolutely want to do both, then solve the problem. But in a time constraint interview what do you do?

It's kind of like having two engineers in a server room and the system is melting down, loosing a million customers a minute. And 1 engineer says, I know how to fix it and can do it in 1 minute. And the other engineering says how is that gonna fix it and wants to discuss it for 10 minutes. Oh, and you had 10 million customers :) So you worked out the best solution and went for a beer but you have no customers left.