The autopilot point is the one I wish someone had told me earlier. A trick that helped me: before writing any code on a "familiar" problem, say out loud the one constraint that makes this version different (sorted input, duplicates allowed, streaming data, etc.). If you can't name one, ask the interviewer — that single question catches most of the subtle twists.

I'd add one thing to the time-allocation section: decide in advance what you'll do at the 50% mark if you don't have a working approach yet (usually: commit to the brute force, code it cleanly, and optimise afterwards). Having that rule removes the panic of deciding under pressure.

For the mental-coding phase, I also rehearse explaining my approach in a quick mock round; disclosure, I work on AI tool for job interviews which we use for that kind of practice. Great list, thanks for writing it up.