[Context: I run a video game development studio.]

Whenever I interview people I explicitly make a section of the interview where I answer the candidate's questions, just in case it doesn't come up naturally or the candidate is a bit meek in that department. I think this is an important part of the interview. But if a candidate asked a bunch of these questions, it certainly would harm my opinion of them. I do not recommend using these questions as a guide.

Why not? For one, a lot of them are petty and kind of annoying, so you will come across as petty and kind of annoying. (Oh my God, if someone asks "tabs or spaces?" that is a no-hire right there.)

But also, note that many of these are leading questions for which there is supposedly a definite right or wrong answer ("Do you regularly correct technical debt? Do you use MVC or similar code structuring?" [This second question indicates a serious no-hire.]) Either these questions are appropriate, which implies you know more than the company does about how to develop software, or are at least its peer, in which case why are you interviewing there in a non-executive role, or why are you not off starting your own thing; or they are inappropriate, in which case you are signaling that you are going to be second-guessing everything the company does all the time, in a Dunning-Kruger kind of way, which is not something that anyone wants to deal with.

Either way, the attitude here is that the applicant can stand in judgement over the company, comprehensively across all these categories involved in programming, from the outside, with no real knowledge of what happens there day-to-day. This implies that the company cannot have much to teach the applicant or offer in terms of knowledge and technique, because if it could, then the answers to many of these questions would be surprising to the applicant or would even come across as "incorrect". So you're signaling that you think you know as much or more than the company about how to develop software well -- but news flash, most projects developed even with positive answers to all these questions are trash fires anyway. But some projects are very successful, so clearly there are factors much more important than are covered by these questions. If you treat these questions as important, you are signaling that you don't really know there are more important questions (while also being annoying).

Lastly, note that a lot of these questions are about minimizing the impact of the job on your life, "work-life balance" kinds of stuff. And there's a paradox here. On the one hand, I am not a fan of crunch or any kind of overworking people, and I do think it's reasonable for many people to avoid jobs that put you into that kind of situation. On the other hand, doing good work, for many people, is a primary vector for finding meaning in life; if you are not interested in investing time, energy and effort into a job, it probably is not meaningful to you, so these questions are kind of a checklist for finding a hollow meaningless job, actually. And if you ask a bunch of these kinds of questions from an employer, even one that is very careful about providing "work-life balance" (btw a phrase I never liked, I think it's a deep misconception, but at least we know what we are talking about), the employer is going to notice you keep asking this stuff and is going to get the feeling that you are someone who doesn't want to work very hard, unless you actively signal something like, I intend to work very hard within company hours but clock out exactly at 5pm, or whatever. But if you don't carefully do this kind of balanced signaling, and instead just ask a bunch of the questions from this list, you'll be giving the impression that you are someone most people don't want to hire, because why are you so preoccupied with minimizing work? It's a job, you are supposed to want to work there.

Questions I would recommend in lieu of those on this list:

* Why is the work important? What do I get from this job besides money (in terms of skills or other experience)?

* How is the company deciding what is "good" or "bad" in terms of the software or the development process? Aesthetically, what is considered good, what is considered bad?

* What kinds of decisions do I have the authority to make, and what kinds of decisions am I expected to defer upward?

* How closely will I be managed? What size of problem am I expected to solve independently, and what size of problem should be deferred upward?

* How far can I rise in my field by doing this job?

* How much of my time do I spend programming, and how much in meetings?

Note that none of these are questions with a pre-known right answer (except maybe a little bit the meetings one). They are also reasonable questions that should help maintain a good impression.