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.
Eng Director here: 100% True. And I'll take it a step further:
> Ask this: “How does a project go from an idea to a ticket? Specifically, at what stage are engineers brought into the conversation; when the problem is identified, or after the solution has already been decided?”
The root of this question is great. The way it's phrased would be a flag for me.
I'd coach someone to ask it this way: "Can you tell me about how bugs and feature requests go from known to implemented/deployed? I want to know how it maps to my previous experiences/workflows"
This is the same question effectively. You will get your answer, and can ask a clarifying follow up if needed.
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.
As an interviewer I always leave plenty of time, usually 15-20 minutes, for the candidate to ask open questions about the company and culture. I emphasize that they will be asking an actual engineer (ie. me) rather than a manager / HR person, and I'll give them as far as possible (within legal bounds) truthful answers.
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.
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.
Is it? the "green" answers mentioned on-call and crunch periods.
I'd say these questions are simply about enquiring about a sustainable pace and humane practice, the ones you find to actually be the most important with seniority.
And you can totally have those in a startup environment; may I argue that the successful ones more often got those right than not (and also often get internally enshittified later on as they grow into the Dead Sea effect)
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?"
My only caution would be that this is probably a manager-only question. A lot of good engineers at places with well defined processes don’t really think of things this way.
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.
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.
Eng Director here: 100% True. And I'll take it a step further:
> Ask this: “How does a project go from an idea to a ticket? Specifically, at what stage are engineers brought into the conversation; when the problem is identified, or after the solution has already been decided?”
The root of this question is great. The way it's phrased would be a flag for me.
I'd coach someone to ask it this way: "Can you tell me about how bugs and feature requests go from known to implemented/deployed? I want to know how it maps to my previous experiences/workflows"
This is the same question effectively. You will get your answer, and can ask a clarifying follow up if needed.
> 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.
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.
As an interviewer I always leave plenty of time, usually 15-20 minutes, for the candidate to ask open questions about the company and culture. I emphasize that they will be asking an actual engineer (ie. me) rather than a manager / HR person, and I'll give them as far as possible (within legal bounds) truthful answers.
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.
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.
Is it? the "green" answers mentioned on-call and crunch periods.
I'd say these questions are simply about enquiring about a sustainable pace and humane practice, the ones you find to actually be the most important with seniority.
And you can totally have those in a startup environment; may I argue that the successful ones more often got those right than not (and also often get internally enshittified later on as they grow into the Dead Sea effect)
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?"
My only caution would be that this is probably a manager-only question. A lot of good engineers at places with well defined processes don’t really think of things this way.
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.
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.
These questions can also be red flags for the company.
If a question like these are a red flag to a company, that’s a big red flag itself and I personally don’t want to work there.