In medical, you primarily need to be able to handle the bureaucratic processes imposed by the various standards. It may be these processes help with writing good software, but it's perfectly possible to have "compliant" software which is terrible. The problem is attempts to legislate for quality end up legislating for proxies for quality.

I've seen some of that in banking, where retail banks will have things like 15 levels of sign off (ok I jest but it feels like it) before any new release, because the financial bodies that govern them require there to be a set of compelling reasons and a huge doc-trail before anything happens.

But some banks (Starling in the UK) seemed to be able to work around that and have a decent CI/CD story, and as you say - it doesn't usually make the software any better, just adds bureaucracy.

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.

I think you’re right. My experiences in the Danish enterprise sector has been that banking and medical are very serious. But that can’t be taken as a universal truth.

I also think it depends on how you define quality. In terms of medical my qualification criteria is based around a 0 deaths or 0 failure rate over a lifetime, not so much what it was build with. Some people would likely disagree with that.

Serious, with a focus on quality, yes I guess that is there in finance. People's money is at stake so we need to have well designed standards, protocols etc.

But for who gets in the door for implementation work, it's still tech conversations and a bit of "who you know" that count over qualifications and hard tests, in my experience.

In my city the medical companies are always hiring devs. The same ones over and over. They have to be throwing bodies at the situation.