How do you simulate real interview conditions during practice?

I simulate real interview conditions by deliberately removing the tools I normally rely on and adding time pressure. Here's what I do: I set a strict 45-minute timer on my phone and place it across the room so I can't pause it mid-session. Instead of coding in IntelliJ with autocomplete, I use a shared Google Doc with plain text or a physical whiteboard in my room—no syntax highlighting, no error underlining, no IDE hints. Before I write any code, I force myself to verbalize my approach out loud, explaining the logic and edge cases as if I'm talking to an interviewer. I also follow a hard rule: no Googling during the timed session, even if I forget a method signature. If I can't remember how to sort a list, I write pseudocode or a comment and move on—I can look it up during the 15-minute review after time expires. This constraint-based practice taught me to think through solutions more carefully before coding. In my first few whiteboard sessions, I realized how much I relied on the compiler to catch syntax errors, so now I mentally trace through my code line by line before considering it done. The key mistake I avoided was practicing only in comfortable conditions. A lot of freshers solve LeetCode in their IDE with unlimited time and think they're ready, but then they freeze when the real interview strips away those supports. By training under harder conditions than the real interview, the actual interview feels easier by comparison.

For example, in a 45-minute mock on merging overlapping intervals, I spent five minutes clarifying inclusive endpoints and empty input, explained the sort-and-scan approach aloud, coded without autocomplete, and used the final five minutes to trace nested and touching intervals. The review showed that I understood the algorithm but lost time recalling comparator syntax, which became a precise item for the next practice session.