[roflmyeggo]

I've thought about this often and the only solution I can come up with is to disallow myself to think quickly when solving problems, even when I believe that I should reliably be able to do so[0].

I've noticed that when I take the time to think slowly through problems, although the initial activation energy is higher, that I end up saving time in the long run. Also, I tend to end up with a higher percentage of correct answers. This trend tends to increase with the complexity of the problem.

Yes, you probably lose some time on the easy problems, but I look at it as a method of gaining net time over days, weeks, etc.

This, unfortunately, is tough to stick with. It's tempting to skip the easy steps along the way (and let our System 1 do all the work, leaving System 2 to collect dust).

[0] - This is still a working hypothesis that I will undoubtedly go back and forth on for the years to come.

[logn]

At least for those problems, I don't think it's about trying to slow down. It's about trying to poke holes in your answer and make sure it holds up to some testing.

The intuitive answer to the first problem is $.10 but if you take time to double check and add a dollar to that, you see it's wrong.

I don't think this is too different from programming... the time you take to re-read some code you just wrote and think like a compiler and mentally execute the edge cases, etc.

[collyw]

For me it was a case of reading the question properly, rather than skimming it and assuming you knew what it was asking.

[thirdtruck]

I just wish we'd learn to appreciate this in the software/startup world and stop expecting people to come up with code/answers as quickly as possible. This is exactly why whiteboard coding is so bad of an interview metric.