it&#x27;s also interesting that (anectodally, talking to people I know) the longer one&#x27;s career is the more unlikely they are to want to switch jobs just based on having to deal with interviews, which of course makes it more likely they don&#x27;t go for that cool interesting job they might flourish even more in, and makes it also harder for companies to hire as there are less available people around than there would be otherwise.<p>It&#x27;s like, yes, you&#x27;ve spent 20 years in progressively more architectural roles, however the decision to hire you or not is based on whiteboarding algorithms you last had to legitimately write out years ago in university and crammed on for a few weeks before this interview.<p>While I was in university 20 years ago for fun I wrote an iterative AVL tree library in C (everybody else seemed to do it recursive), it was difficult but rewarding, but not something I am very likely to do nowadays and if you ask me to whiteboard the rotation logic I am not very likely to do it correctly and would have no impact whatsoever on my ability to do the job at hand (because in a working environment if somebody asked me to write for production say a red black tree from scratch I would not trust my memory but take out my Cormen book and go from there, or look at AOCP)<p>When I have interviewed in the past, I&#x27;ve always tried to ask more about the candidate&#x27;s past and whys of certain decisions, if somebody put on their resume that, say, they designed an API for something, I might ask them what they did for versioning, for schema, what about atomicity, do they expose txns or not, drawbacks for each, and then branch out towards general concurrency and so on and on, you can learn a lot more about how somebody thinks by drilling down from something they worked on than by hazing them on algorithms 101