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.

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.

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

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.

With math questions, just keep practicing slow thinking to solve the problems. You know a shortcut formula to solve something? Don't use it, do it the long way. That will help you understand the nature of the problem, and most importantly, remember the fundamentals so you can easily recall them when needed.

A habit to work on is to make it a rule to verify your solutions, and especially the "fast" ones.

It's ok to do "fast thinking" if you verify, and go back and think through it properly if you fail (and hopefully over time learn to recognise what type of problems you know well enough for them to be worth making a "fast" attempt at first vs the ones you should just think through slowly from the outset.