Since I wasn't present, I can't really comment on the actual answers the person gave. If at all, they seem a bit flippant to me, which may or may not be a red flag. Bosses are human too, and it isn't even clear if that will be your superior at all.
In my company (which is a not so small "full stack" IT company), I never interview candidates for one specific task, project or customer. I always look for people with certain skillsets or characteristics. In my own team, I could onboard anyone who basically does technical IT work with a strong focus on container/cloud or CI/CD based technologies. I would in fact take anyone who has strong skills or convinces me due to character or other good impressions. I of course select strongly on intersections with the technical topics that interest myself and which I am good at myself - i.e., if I'm a Unix guy, I would send .NET/C# specialists on to my colleague who revels in that. That said, people occasionally ask me what their first job would be if they accept, and I never can answer that.
In my case, we have lots of people and plenty of projects; people and projects are matched on skills primarily, organizational units only secondary if at all. There is a constant movement of people between projects; and projects come and go as well. The employment process usually takes at least three months here (due to people generally having a three month notice period in my country), and lots of things could change in that time.
In my experience it's best if they understand all of this from the get-go; some people thrive in such an environment, others really want to know what concrete product they are responsible for. Those may be best served not to apply at a job with a generic IT company, but maybe try to get into the IT unit of, say, a medium-sized engineering firm; in this case it would be clear that they are working on product X of that company.
From your question, I have the impression that they were hiring people for a generic "application management service" team - those support arbitrary applications for customers (and often many of them at the same time), and really do not care which individual applications those are.
In those operations circles, "closing tickets" is indeed often not just a tongue-in-cheek joke, but actually quite high on the list of priorities; unlike in more development/project-oriented teams, there are often service level agreements where it can cost real money if tickets are not closed quickly; and often closing the ticket quickly (while staying just within some contractual ruleset) is more important than improving the actual software. There may be separate change processes to fix root causes, but the first line support teams need to work quickly to get customers running ASAP. In my company we manage certain applications where certain problems incur real-world costs of upwards of 100.000€ or more per hour.
In contrast, the mindset in (agile) development often is more along the line of trying to plan the workload so that it has a realistic chance to be fulfilled in time - it is (hopefully) not event/ticket based. This is quite important for many developers (rightfully so), and putting such a person in a time-critical application management team might be the worst you can do, for everyone involved...