What kind of QA is this? QA responsibilities vary widely. Sometimes testing means manually clicking through an application and recording the result. Sometimes testing means test automation, ie writing code to test other code. Places that expect their test engineers to write code might use the SDET title: Software Developer Engineer in Test. I think the SDET title helps keep you marketable as a software developer. Eg "I provide business value by creating software; most recently the problem domain was test automation".
The first product at my last employer was a system and platform for front-end web application testing. This was in the QA arena, but it was most definitely about developing and delivering code. We later hired another dev who was focused on load testing. Here again, in the QA arena, but the day-to-day was writing code to deliver a product.
There will be some people who don't immediately understand this kind of QA experience. But you can market yourself. You learn how to talk about your skills to other devs, non-coders, and non-technical people. This is definitely anecdotal, but during my last job hunt I only talked to one person (a non-technical recruiter) who couldn't understand how a software developer might be part of QA. The other couple dozen or so (including all other recruiters) understood and valued my skill set.
Finally, some practical advice.. ask these questions:
- Is there any cross-over from QA engineers to product development? what does that look like? can I meet that person?
- Do product developers ever cross-over to QA? is that unusual? why?
- Are QA engineers expected to write code as part of the day to day?
- And don't forget the Joel test. Well, an updated version. Ask about CI/CD. Make sure you write code during at least one of your interviews. Etc