+1 This is the definitive answer, you need to decide if you are serious about moving jobs - if so you are going to have to build in time for the recruitment process.

It's the recruiter's job to match up potential candidates with positions. Part of that job is facilitating communication between the (potential) candidate and the appropriate people in the company. It's also part of the recruiter's job to resolve, or at least determine if it's possible to resolve, any gating (reasonable) issues which a potential candidate has. If the potential candidate has an explicit (legal and legitimate) question/requirement which is a gating issue, then it's the recruiter's job to find out that information and communicate it to the potential candidate.

In other words, it's the recruiter's job to have or get an answer to that question, even if they have to write it down and explicitly ask the hiring manager. Yes, both the candidate and the company are the ones which are ultimately responsible for determining that their needs are met by the employment, but resolving this sort of thing is the reason for the existence of a recruiter. The recruiter is not being paid to waste everyone else's time by presenting a candidate that could be easily excluded by communicating the answer to a single, simple question. They are paid to save that time.

100% agree with @Makyen, while everything in this answer is correct it seems to presume that recruiters are incapable of taking the question of concern and bringing it to a member of the org that can answer it. In that respect, I feel like the OP might use the knowledge in this post to refine the question: “Thank you for your interest. I’m only interested in working with a specific tech stack and I won’t consider moving unless this is possible. Would it be possible for you to share the exact stacks being used by the teams you’re recruiting for?”

I also agree with @Mayken. If a question is ignored by the recruiter, the recruiter is worth ignoring as well. If necessary make it explicit to the recruiter: "Find out the answer to my question, or don't call me again."

The recruiter in the question did take the question of concern and bring it to a member of the org that could answer it. In fact they offered to introduce the OP to the person who could answer it in detail. But the OP decided not to take that meeting.

@Makyen It is the recruiter's job to put you in contact with someone who can answer that question. Otherwise the room for mistakes is large (confusing Java with JavaScript, C# with C++). In the OP's case, the recruiter offered this, and the OP declined the meeting.

@DJClayworth: The recruiter could have relayed the question to the hiring manager (or whoever could have answered it) and relayed the answer back. The recruiter decided not to do that, and as a consequence, OP walked away. IMHO that's the recruiter's problem. Particularly in software engineering, there is an extremely low tolerance for meetings and wasted time during the hiring process. Recruiters are in a position to know that, and to do something about it. If they choose to ignore the problem, it is going to hurt their metrics.

@dan.mwasuser2321368 Yes, the recruiter could put the candidate in touch with the hiring manager, if the candidate has passed at least a first level of weeding out, and the recruiter can't answer a question. However, for a software development job, the tech stack which will be used is a basic, common question. The recruiter is quite literally being paid to do the legwork of finding and communicating with potential candidates so that the hiring manager/company doesn't have to do that work (or the candidate do that work if the recruiter is working for the candidate, which is less common).

Not buying this. My company rarely even interviews for a single specific position, but if somebody asked "I'd really like to work with X technology using Y language. Would this position be that?", he would explain our process clearly, but say that he will inquire with our leads if we have any such work available and ensure that they are scheduled to interview with someone on that project.

@Kevin As a hiring manager, having a candidate say "I only want to work with XYZ technology" is a big negative. "I only want to work with a cool technology" is only a bit better. I'm looking for candidates with the skills to do the work in whatever technology is necessary. It wouldn't worry me that the recruiter let this one go.

@DJClayworth: That's the whole point. The OP wants to filter you out just as you want to filter the OP out. There are plenty of startups that only work with technology XYZ who will be happy to hire OP, but first they have to not waste too many vacation/sick days talking to you. If the recruiter's response to "will I be working with technology XYZ?" is "I don't know, let's set up a meeting," that's already a dealbreaker for OP, because the ultimate answer is likely to be that someone like you says "we don't want to hire OP anyway."

Then everything is working fine and there is no problem.

We once had a recruiter throw out an application of a potential job candidate because they listed having experience in Fortran. In the job advertisement, we listed C as being a requirement. Most programmers would realize that if you work in one compiled language, you can probably figure all of them out. The recruiter, however didn't know any better.

@DJClayworth so isn’t it better to answer the question via the recruiter and not waste your own time, at least? They exist precisely to filter out these mismatches in personal style between candidates and organizations.

I've had many non-technical recruiters be able to give me extensive technical details about a role, and a few of them even reached out to the company to get my questions answered if they didn't know the answer. Now of course they can't answer everything, but I would generally consider a recruiter who requires this much effort to simply get an answer to the one singular simple question of whether a role involves using some technology to be a bad recruiter, if not an absolutely terrible one.

An important part of why a recruiter might not also tell you the stack is that, on top of having multiple possible job options available, they're also not sure if any given team is going to give a new person to the team access to that specific part of the tech stack. If, for example, they have a project that uses Apache, most of the developers won't be senior enough to directly mess with Apache settings, and onboarding will involve the software language written to run on the Apache server.

Or to put it another way - maybe you want to work with Java, but while the software works in Java, you'll also be working within a SQL variant, and they want to make sure that if you insist on Java, you won't bail because the job sometimes involves SQL. EDIT: Or possibly a Python script maintenance part as well as the Java base.

@DJClayworth After going along with a phone call and then a lunch meeting only because of a promise of an answered question and that promise being unfulfilled on both occasions, why do you believe the third meeting would answer the question?

@AlexanderThe1st Not a big issue, though, since the main time savings here is going to be the recruit cutting the application process short very quickly in (likely more frequent) cases where the company does not use the stack in question.

@Makyen That would be perfect. Unfortunately, often it's not how it works for a reason. Often recruiters don't even have access to the hiring team. They are usually employees of a head-hunting company which signs a contract with the hiring company to deliver a set of filtered candidates. They just receive the role description, or several role descriptions, and try to find candidates that are somehow relevant. They don't really have tools to clarify the job offering details. At least that's the usual business procedure. Perhaps there are head-hunting companies that operate differently...

...and companies which want to use their services, and wish the recruiters would contact them several times asking many questions, but that's a rarity. Most hiring companies want to just get a list of candidates, and then handle them themselves.

Also (potential) employees don't know how hard recruiting is. For each role usually multiple unfit candidates apply. It's a lot of work to filter them out. The unfitness sometimes is based on technical merit (lack of required skills), but more than often is based on soft aspects. Employers want to filter out candidates that are unprofessional, unstable, undependable, coming late to work, lying, disrespectful, aggressive, immature, non-creative, not-good-team-players and so on. That's about 90% of the work. At that step of filtering software stack is irrelevant.

@ciamej I would think filtering out people who have no interest in the role would be as important as the ones you mention

@mattfreake I guess if the recruiter was (1) a technical person, (2) worked for only a single hiring company at a time, and (3) the hiring team had enough time to explain to the recruiter their work in detail, it could work. It would be best if the recruiter was a member of the hiring team. Unfortunately, recruiters are not technical, they work for 100+ clients at a time, and the hiring teams do not have time to explain to the recruiter (one of many) what the role really is about.

And even if the teams tried to give as many details about the role, the recruiter being non-technical could not comprehend it and could easily mix something up. Especially with so many open roles from so many different clients.

Basically, the whole process of recruiting IT personnel by recruitment agencies is a low effort and low quality endeavour.