Just perusing Gayle’s [1] intro.
I am wondering about will Gayle write about when is a good time to transition from thinking about and designing a solution to a problem, and writing some code to test things out. i Think this interview style does actually relate to what lately i think about that design skills are really important to save time. But also, to be specific sometimes you can write some quick code that can really be faster than white boarding. but agree that your compute in your head can save you lots of time from going down the wrong path just by your intuition and not because you have actually worked out why.
I think that’s why python and its REPL have really token off!
But yea this is where math used to shine, because a long time ago, we did not have compute or computers, and whiteboards were the only way to compress a problem. During the manhattan project , I think there was the lost days of a very serious theoretical problem that was Solved purely with chalk. but maybe im wrong. Were simulations invented at this time?
When was the Monte Carlo method invented and why the name? is it about the gambling? Or is it about the place.
proofs were really important.
These days, we use a lot of data to substitute . This should probably go into the mercenary science blog post haha.
But also this connects to how do reasoning models make choices and do they really reason . the earlier reasoning models, try many things and take the average or the max. but they try them. But interestingly we might ask whats going on in your head when you think about a problem. youre still burning calories. you often cant resist putting stuff on paper. or a whiteboard. or discussing with a colleague. And of course most computers get damaged by water, but we know showers are where great epiphanies come about. Or baths, in Archimedes world if I have my Greek philosophy right!
Planning is harder in the heat of the moment
Recently I took a timed code test and although I was spending a bit of time lately, trying to get myself to slow down and plan out these kinds of self contained code challenges, when it became real and on the record, my prep went out the window. Of course it didnt help that I had a camera pointed at my face haha.
My sympathetic nervous system I think in retrospect, was calling the shots, which meant very little in the way of building a model around my problem definition on the screen. And my brain did instead sort of the greedy style of trying to hack towards a solution on the web terminal without deep thought. I think if I learned anything about this kind of thing, it is that it takes a few times to be calmer in high stakes environments . And you can get used to it. I have done this before of course but just not recently haha so I guess I got too comfortable! Looking forward to practicing calming down and ducking the adrenaline in the future !
References
- Gayle, “Cracking the Coding Interview”
- https://michal.piekarczyk.xyz/note/2026-03-04-prompt-driven-development/