HSBC

Like most financial work, the complexity is pretty straightforward compared to what one would be used to in non-finance fields (Games, Embedded Systems, Mobile Development).

If you're focused and working remotely, you generally need no more than one hour of time spent per day doing work (most of which is spent building/testing rather than actually coding).

The compensation, like most financial institutions, is great.

Systems are old and slow, with 20-year-old legacy codebases. Most tasks (90%) are reduced to small and simple changes, like adding a field to a structure, adding another thing of type X to a list of X's, or systems operation type deployments of services. Essentially, most of the work doesn't require much skill.

Builds are generally slow, taking minutes to build and test out changes, for things that Games industry workers would be used to <5-second code-build-test cycles.

In addition, projects and the build results are bloated, running into the 100s of MB, if not Gigabytes, for binaries of projects that are relatively small in their actual functionality.

This is a general issue at many, if not the majority, of financial institutions. The general management structure doesn't lend well to encouraging individual engineers to contribute their own ideas. So, projects tend to be very top-down, highly predictable, and monotonous.

The work doesn't give a sense of achieving much, unlike what you may be used to in other sectors of IT. It feels more like pushing a slightly complicated but mostly annoying button to get some nuts. This may suit certain mindsets more than others.

Encourage your engineers to contribute new ideas and innovations; many of them are very talented.

All companies and teams that refuse to innovate from within will progressively struggle to compete globally, so it's a flawed, short-term strategy.