I would only balk at a couple of things, MATLAB, VBA, and extensive server-side Javascript being the main red flags of poor tech culture.

I have some additional skepticism about (a) shops that very quickly adopted Go and then display a cult-like dogma about how super perfect and awesome at all things networking that Go is and everything else isn't; and (b) shops that use Scala or Clojure purely as "better Java" and often have thin, entirely unfunctional layers wrapping bad legacy Java code -- in such places, the Scala and Clojure often exists specifically because they had a hard time recruiting people to be legacy Java maintainers, and having them do it through one layer of indirection, such as Scala, let them tap into a more vibrant labor market with a lot of people who just naively believed that e.g. usage of Scala == adherence to good quality standards.

The age of the language has nothing to do with it, and I actually quite enjoy C programming. I'm not a big fan of C++ code bases in which some of the more esoteric language features are greatly abused, but generally feel like C++ is a great tool and would in fact enjoy the chance to dig more into in a future job.

I also quite like code maintenance and legacy code extension, because when the company takes it seriously and values that kind of work, it involves a lot of cool abstraction, working with interfaces, design tests a la the Feathers book on testing in legacy code. I think that stuff is quite fun, and a healthy culture of refactoring makes it interesting to work on legacy systems.

While it's not an iron-clad rule, certain kinds of legacy choices, however, are not really compatible with a spirit of quality, legitimately valuing maintenance or refactoring, etc. MATLAB and Excel VBA are by far the strongest indicators that it's not a good situation.

The items above are just language choices, too. There are also many other things to worry about. For example, when a place uses MATLAB, it often means some of the work they do is scientific / quantitative prototyping. Do they enforce good code standards even at the prototype stage so as to minimize the distance between research prototypes and production? Failing to do this is a seriously gigantic red flag. It can mean that the management chain values the domain science more than the quality of the implementation, and often this means that domain scientists are allowed some of the following

- to manage their own working environments (leading to lots of awful "but it works on my machine" errors)

- to write every thing as giant, messy, linear scripts that start off with 200 lines of boilerplate data loading and model setup code that should be factored into a library but is instead copy/pasted and finish off with 200 more lines of custom plotting code that also should be factored into its own internal library for standardizing reports and charts

- to turn things into short-term fire drills for production programmers solely by virtue of them being "someone who uses MATLAB, not <some real language> that we use in production", and get management support for this.

- never bother to learn object oriented or functional programming principles -- google a design pattern and then just paste some ill-conceived bastardization of it wherever they feel, and then argue with production engineers that you can't refactor it "because it's a design pattern"

- ... I could go on.

When I see places that heavily use MATLAB or R for research systems, I break out in a cold sweat, since those languages are entirely unsuitable for professional software design. They are good for ad hoc linear algebra, optimization, model fitting, plotting, and statistics. But the software design underlying how those things are carried out in MATLAB and R does not translate at all to a system where the scientific code is maybe 1% and the business reporting code, customer-facing services code, etc., are the 99%. And putting the scientific code at 1% is generous even for a company that is solely about scientific computing or quantitative services.

Anyway, there is just a large difference between organizations that work from a systems engineering perspective first, and build that way, and mercilessly require non-programmer PhDs to get up to speed on actual, principled software development even for doing ad hoc domain specific work.