Predict first: never read the solution before committing to an answer in writing.
Say the rule: every correct answer should trace to one concrete language/tool rule.
Re-derive on a whiteboard with no simulator — interviews have no compiler.
Track misses by theme so you know which gotchas keep catching you.
Whether you reason from semantics (types, scheduling, solving order) instead of intuition.
Whether you can predict exact output, not just 'it depends'.
Whether you can explain the trap clearly and propose the fix.