[collyw]

Exactly. 95% + of the work out there is more about plumbing and a doesn't design to plumb together. On the rare occasion when I have had anything algorithimc to do I Google for similar problems.

The last time I had a proper algorithmic problem, I was in an academic institute and we had a guy researching algorithms so I asked him (though he didn't come up with mush). It was basically a variation the stable roommates problem. I came up with a solution - brute force plus a load of optimization and it worked well enough for the purpose.

When I get that crap in interviews some of the time I get the answer, some of the time I don't. Its pot luck. Its says very little about my skill for the jobs I am applying for. Ironically I was way better at answering those things 15 years ago when I was fairly crap at building reliable robust systems.

[rambossa]

OP of the comment here... Actually, I had a production service centered around the stable-roommate-problem. It took me a week or two to develop something out and fit it into our codebase. It then took 1-3 more weeks to actually make it work for us and cover edge cases (Irving's algo quits after instability -- this isnt an option in the real-world). I had many deep-thinking sessions where I was mostly in my head, writing scratch on paper, collab-whiteboarding (sometimes arguing), or testing PoCs.

The success resulted from deep research and much trial & error. It was no magical "algorithmic skillset" that they expect in those type of interviews (I wonder if those are even a good filter for actual production algos).

Here is my simple write-up of SRP: https://medium.com/@rambossa/stable-matching-algorithm-and-h...