[milesvp]

Funny this. Back when I had more time on my hands I liked to do project euler problems. I'd start with the dumbest brute force method to find the answer, and let that run. Then I'd see if I could figure out the math and implement it correctly before the brute force finished. I'd say I had about an 95% success rate at beating the dumb brute force (course it really depends on the problem search space).

What was interesting, is that implementing the brute force solution and running it probably saved me time in the long run, because it managed to turn off a part of my brain that worries about wasted time. As long as I knew the brute force was potentially making progress, I didn't care if I ended up with false starts, or took a long time trying to understand the math, so it was easier to focus on the smarter solution.

[tomlagier]

This is part of the reason why the software industry's decision to use algorithm problems as time-bounded interview questions is so frustrating.

Right away, you have to make a choice between doing it the reliable way (brute force) and taking a gamble on being able to out-smart the problem and doing it the math-y way. This adds a ton of pressure, no matter which path you choose.

If you choose to start with brute-force, you're stressed that you look stupid because you don't know the trick. If you spend precious minutes looking for the trick, you're stressed because there's no guarantee you'll crack it in the given time.

I've just gone through a gambit of software interviews and this is the biggest thing that determines whether I'll enjoy solving a problem or not. If they start with "find an efficient solution" or "the data set is in the millions" or something along those lines, I know I'm doomed if I don't recognize the form of the problem. If they encourage me to get to a working solution first, and _then_ figure out the trick, I'll typically do well regardless of whether the question is familiar or not.