I work as a senior developer for one of the largest banks in the US at the moment, and have also worked for a subsidiary of the largest medical provider in the city. Neither of these companies had particularly challenging interviews. Generally, if you are IT, the interviews are simple.
The only people who I have met who turn the interview process into a gamut of algorithm puzzles, are people who happen to be very good at them. These also don't tend to be the people running things at banks, let alone large ones.
Maybe because these companies see the coding part as almost mechanical and try to tackle the complexity with (often overboarding) design and processes? Problem is that those assume that a tree like divide-and-conquer will reduce complexity in the "leaf-nodes", but as soon as you have a lot of cross-cutting dependencies everybody is shaking that tree.
The problem with "artisanal developers" is that they tend to overestimate their proximity and underestimate how much of a "system" they actually should build. Most of the time they lack domain knowledge, too.
If you can identify the cross-cutting interactions that will result in the biggest risk for the project, and put how to handle those in a design that is communicated well, you can leave freedom how to do the rest and the craftsmen will be appeased. But that needs a good deal of domain (and people) knowlege.
The only people who I have met who turn the interview process into a gamut of algorithm puzzles, are people who happen to be very good at them. These also don't tend to be the people running things at banks, let alone large ones.