This is my favorite part of the job too - digging through weird, ancient spaghetti code and finding obscure bugs. Then either crafting a fix to the code, or creating some kind of migration path or workaround to mitigate the problem. Unfortunately in a lot of companies this kind of "maintenance mode" job is not well-paid or well-respected, and is given to the least-qualified devs. I keep finding myself promoted out of the position, or assigned to work on something that supposedly has more "impact" (read: increasing revenue and/or encouraging investment), even though from my perspective the most impactful work is helping loyal customers who already value the product highly enough that they're paying for support.

How did you deal with the "overqualified" problem, or did you switch early enough that it didn't matter? From my end, I have over 20 years of development experience, and I feel that often disqualifies me from consideration by a lot of employers.

Honestly this sounds like me

can you explain that role sound interesting ?

It's been a bit different in each of the companies I've had it, but fundamentally it's about using product expertise, general tech skills, and problem-solving to help the people who are using the product. Sometimes there are planned/scheduled/proactive projects, but the primary responsibility is responding to and helping with whatever issues customers are running into. This means the job can be unpredictable, because on any given day you don't know what's going to come up, but I like that - it keeps things new and interesting.

Support requests come in through whatever channels the team uses (every team I've been on has used email, some have also used Slack/phone/videoconference/etc.) and include things like bug reports, questions about best practices or how to do something with the product, and sometimes feature requests. As a support engineer, I take ownership of the support requests and do whatever is appropriate to drive them toward successful resolutions for the customer.

Because software products can change quickly, this often involves learning new features or systems. I often get support requests about tools or workflows I've never seen before (or that have changed significantly since the last time I looked at them) and have to quickly get up to speed on them. I learn best when it's in service of a goal, so this works well for me - I'm trying to help the customer accomplish their own goal and that motivates me to dig in and learn.

If it's a bug, I also investigate and try to reproduce the reported behavior. Sometimes the issue isn't what it appeared and the problem was that our documentation or UX was unclear, in which case I clarify things to the customer and file a ticket to fix the docs/UX. (Or just fix it myself - the amount of direct work I've been able to do in the docs/product has varied between companies, based largely on their size.) Sometimes it is a bug, in which case I'll try to come up with some alternate way for the customer to do what they are trying to do and then also file a ticket to get the bug fixed (with clear repro steps and getting as close to the root cause as I can, depending on how familiar I am with that part of the code base).

I also try to be proactive and serve as a customer champion - in most companies I've seen, product support has the broadest view of what issues are coming up for customers, and that can be valuable signal for the product team on how to prevent issues before they happen.

That's it in a nutshell. :) Always learning and applying expertise to help people succeed. I think it's a great fit for people who don't need to be in the spotlight but like knowing they've helped individuals and who work well in a rapidly-changing environment. (I think it might actually be kind of a dream role for technical people who have ADHD.)