In "traditional" engineering, there are a lot of old code bases still in use that few people (if any) have a solid understanding of. I've seen code comments dating to the 70s. Often the code was "documented" in internal reports. Many of these reports are now lost. These reports are often incomplete or unclear when they can be found. Plus, what you read in the ancient reports may not be current.

The job ad will probably not directly say anything about code archaeology. If the job ad mentions some sort of in-house simulation software, and the organization is 50+ years old, I'd say it's a coin toss as to whether you'll have to be this sort of software archaeologist from time to time.

If you're a strong technologist, ideally with some reverse engineering experience, and you befriend a bank CTO, you will probably be offered a job that is part this and part saving projects that are trying their best to jump off a series of cliffs.

Just make sure to set it up as a consulting gig and never, ever, work for a bank.

>what sort of role/position would that be?

Go work a normal engineering job for a bank or government on something close to whatever was the core system 30 years ago. You should see the signs when you get close enough.

My only-mostly-joking answer is that you can go work for a typical Silicon Valley style technology company, and stay around for two or three four-year vesting periods. Most of them have Google-influenced design doc processes, and few if any have a process for documenting what actually got built, much less what it eventually turned into.

One of my hobbies is feeling dumb for not understanding something, being willing to ask, realizing _nobody_ knows the big picture, and trying to document it.

tbh though I have also occasionally fantasized about finding a job that was _only_ software archeology.