I do not know if the following advice will work well for you, but it has worked well for me so I will describe it.
I use an algorithm for this:
For each "issue" that I have as a deal-breaker, I make sure to ask at least one question about that issue that will help me to know if the company handles it in a way that is "acceptable" / "might be acceptable" / "unacceptable" to me.
If anything sounds unacceptable, I always try to ask at least a few more questions to probe whether a compromise can be made. Stay positive when asking these questions. Instead of saying,
"Why on earth do you use crappy Tool XYZ?"
rephrase it as
"Walk me through the history of this team in the company. What was the origin of the current approach with Tool XYZ? Has there been any initiative in the company to try a different approach? I've heard of some places having good results with Tool ABC..."
Think about how the answers from 2 feel in your gut. Do they smell like phoney baloney excuses? Do the reek of endemic bureaucratic dysfunction? Or do they seem like reasonable evaluations? If any of your deal-breaker items results in an answer that doesn't sit well in your gut, then confidently reject to continue in the process and be happy that you are saving yourself some time.
If you pass through step 3 and nothing feels like a gut-wrenching issue, then there is at least some reason for you to explore the potential offer and working situation you may receive if you succeed in the remaining interviews. In that case, you probably will want to do the next interview and try to repeat these steps in more detail.
Consider the costs of future interviews (including study time, stress felt leading up to the interview, and the actual time and structure of the interview itself). If you determined that there is some reason to care about further interviews, next try to weight how much that matters to you against the cost of doing it. Keep in mind that interviews will give you more practice at explaining yourself and presenting your qualifications, so it's good to err on the side of accepting further interviews, if only just for the practice. However, if the interview is extremely onerous, like a 5+-hour series of technically challenging interviews in one day, only do it if you really do think it is likely that the company can provide you with feedback which will reduce your concerns from steps 1 through 4. If you assess that to be really unlikely, don't stress yourself over a very extensive interview for it.
An example (which @JeffO mentioned) for me personally is cubicles. During a first interview, I will always try to make time to ask about the work environment. I will say something like
"One issue which I am interested in is the working environment. Like most programmers, I tend to be more productive in a quiet and private environment where I am able to control the lighting. How does your company handle these sorts of workplace features that contribute to programmer productivity?"
I get a wide variety of answers. Here are a few examples, including the ways I might evaluate them.
"Actually, our organization is special because we need programmers to communicate in real time with other segments of the business. We can't structure our internal work in a way that gives developers segments of uninterrupted time to do their work, and so open floor plans and cubicles make the most sense."
In this case I would reject immediately, because none of those things are true about any business that relies on programmers. You can always re-organize the way software workflow happens to separate teams in a way to allow each team to be most productive for the business's bottom line. Over 30 years of software productivity literature contradicts this point of view, so it raises a lot of questions about the competence of whomever made this decision. Normally, in this case, what it really means is that the company is being lazy about how they use software developers. A lot of the work tends to resemble pseudo real-time tech support, which is very inefficient. Often, because your regular work day is Swiss-cheesified with random interruptions, you are forced to work longer hours or work on weekends to make up the time. In this case, the office actively works to impede progress, rather than serving its function as a location that facilitates getting work done.
"You are quite right that privacy and quiet could help our developers be more productive. Unfortunately, higher level managers have decided the company policy about offices, open floor plans, and the specific work space allocated for this team. It is just one of those things that you have to get used to and accept as part of the job."
I would have a lot more respect for a manager who said this. However, I might also suspect that the manager feels trapped by bureaucracy. The manager might be competent, but forced to implement things in an incompetent way to adhere to bureaucratic decisions coming from on high. It suggests that this manager is not able to secure the necessary tools for her team, and cares a lot that her subordinates have a "I'll do whatever I am told without questioning it" attitude. That's a hallmark of mediocrity, so I would probably reject straight away. However, if absolutely everything else about the job was exceptional, I would consider it. The likelihood of that is utterly tiny, though, since bureaucratic dictation of cubicles implies lots more bureaucratic dysfunction once you finally see how the sausage is made.
"While we don't have dedicated office space, we recognize that different employees reach productivity in different environments. We try to be as accommodating as we reasonably can be. It's easy for us to let you work from home whenever needed -- just check with your manager for approval. You can also book conference rooms and take a laptop in there to get some private programming time and the managers won't kick you out. We just can't offer dedicated private space at this time, but it's something we will consider in the future."
This signals that the manager and the company have had non-trivial thoughts about the issue and recognize its importance. They don't want to let legacy choices, or bureaucratic opinions that shouldn't inform a view on programmer workspaces, effect the quality of the people they can hire or the quality of their work output. So they try hard in all the ways they can to find a solution. Even if there are a few things I don't like about this job, I might be willing to work really hard for them, so it's surely worth doing more interviews to see.
At that point, I would pause to evaluate how onerous the follow-up interview would be. If their answer was like Number 3 above and I felt the interview wouldn't be too stressful and would allow me to ask enough questions, then I probably would do it. If they answered with Numbers 1 or 2, which register with a gut-level "eww, get away get away" reaction to me, I would surely not agree to do anything remotely stressful as a follow-up interview.
At any rate, this is just an example to highlight how you might evaluate the subtle indications of different management answers. You should obviously think about the issues that matter to you, read about them, and determine your own rubric for how you will evaluate answers. Let those consistent guidelines determine when to reject early versus when to stick it out to learn more.