The advice is not bad, just tailored towards someone looking for a good stable boring job, which is all ok. Therefore the chaos of startups is highlighted as a red flag. Might be good to add here that there are good learnings in the chaos of startups as well, for particular people, at particular times.

These seem like luxury questions.

For myself, prior to my next 'coding interview' I'd just like to ask what specifically the interviewer is hoping to learn, or achieve, with the coding interview.

Ideally yes, one would ask these questions. Practically, there is not enough time. You'd be lucky to get even 5 minutes to ask all these questions. Even if you have the time, you have to ask these questions in a diplomatic manner. Unless you are a well known hot shot in your field, a job interview is marred by power imbalance and any signal that you are cynical, confrontational, question authority etc. will count against you. So do ask these questions, but be careful how you frame them.

These questions can also be red flags for the company.

Might be a cultural thing, but I disagree with sibling commentors that being able to ask these questions is a luxury. I generally ask questions like this both because I want to know the answer _and_ to signal I’m someone who is aware of the tradeoffs and multidimensionality that goes into software engineering beyond just adding some LoC.

I don’t have the strict red/green flags mentality though. I’m more interested in why the company came to the current status quo. And a company that is struggling in some aspect might be the ideal company for me.

My 2 cents, especially in this tough job market.

1 - There are two phases of the interview process, where you’re selling them and where they are selling you. These questions are best asked in the latter. To get the most accurate answer, ask to talk to a few future peers after you get the offer in hand. Until you have that offer in hand ask softball questions that can’t be answered via the website, like “What motivates you to stay given all the opportunities in the market?”

2 - Be careful in how you ask, as you don’t want to signal you can only work in a high structure environment. So you can rephrase as “At company X I earned a reputation for fixing process Y. What software engineering processes could I help improve?” or “As you plan to grow 10X what aspects of culture and teamwork do you see changing to enable us to scale”

Leaders value engineers who help them improve over ones who require a perfect end state. So go after the answers you need, just be mindful on when and how you ask.

It's unfortunate, but I agree with the comments that say asking too many of these questions (and the way they are asked) can be a red flag for the interviewing company.

In my experience, the best way to get to something closer to the truth about a work environment is to do something casual (lunch usually, but even just a group interview can work) with your prospective peers. You can observe how they interact with each other - do they seem happy and friendly with one another? Or do they seem cowed into submission, afraid to open up about anything? The stories they choose to tell you often will reveal much more than you could get out of a formal list of questions. I've actually had people tell me that the boss was a jerk in one of these situations (and the whole group agreed, not just one disgruntled employee.) Or heard about the time some employees did some wildly inappropriate (and hilarious) things in a conference room. I ran away from the first situation, but would have gladly accepted a job at the second (not _because_ of the conference room thing - these people seemed to genuinely like working together and at the company.)

What's the right way to ask, "is my manager or supervisor taking Adderall?" I need a manager that can listen for two minutes, not one that's on a drug that compels them to speak in ten minute long stream of consciousness rants.

I usually have one question for them "what's the feedback mechanism on my work performance/quality ?"

In my experience, it's always been well received and helps you identify the maturity of the employer.

Some have well defined processes "1-on-1 meeting every two weeks..." other are puzzled by the question and don't have an answer for it which is usually embodied by "What do you mean by feedback mechanism?"

> Being on-call is part of the job.

Is it really? Am I being paid for those hours where I cannot leave the house?

I like to ask another question: what procedures do you have in place to drive the the fix so the incident doesn't happen again?

This is especially important in situations where devs are on call for systems they didn't write.