Questions to ask a prospective employer during a job interview(nibblestew.blogspot.com)
nibblestew.blogspot.com
Questions to ask a prospective employer during a job interview
https://nibblestew.blogspot.com/2022/09/questions-to-ask-prospective-employer.html
119 comments
> "Does this team or any of the related teams have a person who actively rejects proposals to improve the code base?" is a BAD question to ask in an interview. What answer could an interviewer give?
If I was asked this, I'd respond with "can you give an example of what kind of improvements you mean?" and discuss from there.
I'd also ask something like "What's the experience you had that caused you to ask that question? What did you propose, and why did it get rejected? What would you do differently if you could go back and do it over?".
This kind of discussion is what gives me the most insight into a candidate. Things like: Have they grown, maybe even see things differently now? Did they dig to fully understand why it was rejected? Did they learn how to better interact with their team? Would they propose smaller, iterative changes? Did they figure out how to justify technical changes against business value?
Hint: an answer that is basically "my team was just idiots and couldn't see my brilliance" is almost certainly going to result in a "no hire" from me.
If I was asked this, I'd respond with "can you give an example of what kind of improvements you mean?" and discuss from there.
I'd also ask something like "What's the experience you had that caused you to ask that question? What did you propose, and why did it get rejected? What would you do differently if you could go back and do it over?".
This kind of discussion is what gives me the most insight into a candidate. Things like: Have they grown, maybe even see things differently now? Did they dig to fully understand why it was rejected? Did they learn how to better interact with their team? Would they propose smaller, iterative changes? Did they figure out how to justify technical changes against business value?
Hint: an answer that is basically "my team was just idiots and couldn't see my brilliance" is almost certainly going to result in a "no hire" from me.
It sounds like they're trying to identify whether there is an egomaniac or monomaniac with veto power on the team or not, which is a good thing to know, and a legitimate thing to want to find out before joining. I think the question is poorly phrased, because it leaves open the line of follow-up questioning you offered. It would have been better to ask something like "if I had an idea for how to improve the code base, can you describe the process for getting approval to implement it?"
This is one of those things where you set out to learn something useful but your question makes it look like you're a dick at your old job and that you lack the self awareness to realize it's your fault your coworkers are mad at you.
As someone who has interviewed easily a thousand engineers of all seniorities over the last 10 years (2-3 per week since 2012) my gut reaction would be "this candidate doesn't know how to work with others" - my next thought would be "I bet they allow code review to become architecture review and then get mad when people aren't happy with their code because they failed to get alignment first."
Now whether or not that's true of this particular candidate it drives the conversation negative pretty quickly and then they have to string together the right set of answers to follow-on questions to avoid this becoming a red flag. It also puts the interviewer in a mode of looking for other red flags they might not have even paid attention to. The candidate is now on the defensive instead of projecting a positive image as @gregmac pointed out.
I would re-frame this question something like:
> How do you think about the role of code review in your organization? Do you distinguish between code review and architecture review? Are ICs encouraged to obtain alignment before they get started? How would your team handle/resolve a situation where someone failed to get alignment in advance? Do you have an example of when this happened and how it was resolved?
To me this says "I've seen this happen before (+1) and it sucks (+2), do you have a culture of letting this happen (+5)?" not "my coworkers are mad at me (-5) but I haven't figured out why (-5) so it's probably their fault (-5)" haha.
[edit] I should say if I catch a candidate making an obvious mistake like this and they successfully clear that red flag, I will advise them not to frame their question like that in the rest of their interviews - but I doubt most interviewers are as friendly.
As someone who has interviewed easily a thousand engineers of all seniorities over the last 10 years (2-3 per week since 2012) my gut reaction would be "this candidate doesn't know how to work with others" - my next thought would be "I bet they allow code review to become architecture review and then get mad when people aren't happy with their code because they failed to get alignment first."
Now whether or not that's true of this particular candidate it drives the conversation negative pretty quickly and then they have to string together the right set of answers to follow-on questions to avoid this becoming a red flag. It also puts the interviewer in a mode of looking for other red flags they might not have even paid attention to. The candidate is now on the defensive instead of projecting a positive image as @gregmac pointed out.
I would re-frame this question something like:
> How do you think about the role of code review in your organization? Do you distinguish between code review and architecture review? Are ICs encouraged to obtain alignment before they get started? How would your team handle/resolve a situation where someone failed to get alignment in advance? Do you have an example of when this happened and how it was resolved?
To me this says "I've seen this happen before (+1) and it sucks (+2), do you have a culture of letting this happen (+5)?" not "my coworkers are mad at me (-5) but I haven't figured out why (-5) so it's probably their fault (-5)" haha.
[edit] I should say if I catch a candidate making an obvious mistake like this and they successfully clear that red flag, I will advise them not to frame their question like that in the rest of their interviews - but I doubt most interviewers are as friendly.
Does it at all strike you as weird that in the case where your process is giving a false signal you're suggesting how the other person should act differently?
You can't control the hiring company's process, who the company picks as an interviewer and you don't know what else is going on in their day/life - but what you can control are your questions so you can project a positive image no matter what. I'm helping you here. My reframe isn't just "how to sound less like a dick" - although there is that - it's also a way to demonstrate maturity and positive signal at the same time which helps ensure you're leveled appropriately too.
Interviewing may be a craps shoot, but you can always adjust the odds in your favor.
Interviewing may be a craps shoot, but you can always adjust the odds in your favor.
> You can't control the hiring company's process
You can. You're an interviewer. Lost of people on this site are interviewers.
I get that your advice is more useful to interviewers. I get the stuff about maturity, and so on. No reason to bring it up again.
What you don't seem to get is that every bit of your comments take the side of the interviewer as an immutable force that must be adapted to by the interviewee. If a few tweaks can have such a big impact on a classifying mechanism, maybe there's something wrong with the mechanism.
At the very least I just want to point out that you could have the reaction "This makes me realize the mistakes in my interviewing and how I will change and suggest others do." vs "Here's how candidates should act differently to not give a negative impression to important people like me."
You can. You're an interviewer. Lost of people on this site are interviewers.
I get that your advice is more useful to interviewers. I get the stuff about maturity, and so on. No reason to bring it up again.
What you don't seem to get is that every bit of your comments take the side of the interviewer as an immutable force that must be adapted to by the interviewee. If a few tweaks can have such a big impact on a classifying mechanism, maybe there's something wrong with the mechanism.
At the very least I just want to point out that you could have the reaction "This makes me realize the mistakes in my interviewing and how I will change and suggest others do." vs "Here's how candidates should act differently to not give a negative impression to important people like me."
> "Here's how candidates should act differently to not give a negative impression to important people like me."
I'm only important in the sense that my job is to obtain a fair and consistent evaluation of someone along a defined set of criteria - to see if there's a good mutual fit! I want a candidate to succeed once hired, so I'm looking for signals that they would succeed. A mis-hire sucks because getting fired sucks. That's why I'm also looking for signals they would not succeed. A lot of the time we try and avoid false-positives at the cost of false-negatives.
We're looking for certain things, and in the scope of just a 45m or 1h window it's really hard to get a complete picture of who someone is. This is also why have multiple interviewers ask many different kinds of questions.
I'm quite sympathetic to your position and I'm always super active in hiring wherever I work. I built our Mobile Staff+ interview loop at my current employer and trained up a most of the interviewers!
I do my best to make the process suck less for all involved, but folks like me won't always be on the other side. Even at employers you'd otherwise love! That's why I was hoping to provide some quick tips to eliminate potential roadblocks no matter who you find yourself up against.
I'm only important in the sense that my job is to obtain a fair and consistent evaluation of someone along a defined set of criteria - to see if there's a good mutual fit! I want a candidate to succeed once hired, so I'm looking for signals that they would succeed. A mis-hire sucks because getting fired sucks. That's why I'm also looking for signals they would not succeed. A lot of the time we try and avoid false-positives at the cost of false-negatives.
We're looking for certain things, and in the scope of just a 45m or 1h window it's really hard to get a complete picture of who someone is. This is also why have multiple interviewers ask many different kinds of questions.
I'm quite sympathetic to your position and I'm always super active in hiring wherever I work. I built our Mobile Staff+ interview loop at my current employer and trained up a most of the interviewers!
I do my best to make the process suck less for all involved, but folks like me won't always be on the other side. Even at employers you'd otherwise love! That's why I was hoping to provide some quick tips to eliminate potential roadblocks no matter who you find yourself up against.
He or she was offering an alternative approach to obtain the same information that is less confrontational.
As framed originally, the interviewee sounds like a dick.
As framed originally, the interviewee sounds like a dick.
He is impersonating one party and telling you how that person will clearly get a false signal from your actions. What do you expect him to do? To tell the party that isn't part of the conversation how to improve?
There is a name for this technique, but I forget the exact term. Something about Rabbis who always answer a question with another question. When two Rabbis discuss, this often ends in "question volley" ad infinitum. This has been humorously played upon in a game (called The Shivah) who used it as an equivalent to Monkey Island's Insult Swordfight, where if you failed to answer a question with a question you'd "lose" the point.
They seem fairly closed rather than open questions. They imply they are running a closed checklist for purpose of insta-rejection, as opposed to being curious or open minded or wanting to know more / initiate a conversation. At worst, it reads as simply a list of bad experiences.
And that's fair. Reading HN, impression (correct or not) is that a lot of folks are expert enough, highly paid enough, demanded enough, to afford to be arrogant aholes. And that's, again, fair enough!
On the other hand, some employers can also afford to do their own rejection checklist, and being an arrogant ahole may be on it. It ultimately always comes down to what your priorities are.
And that's fair. Reading HN, impression (correct or not) is that a lot of folks are expert enough, highly paid enough, demanded enough, to afford to be arrogant aholes. And that's, again, fair enough!
On the other hand, some employers can also afford to do their own rejection checklist, and being an arrogant ahole may be on it. It ultimately always comes down to what your priorities are.
To me, the fact such a question is seen as 'bad' feels very strange, when interviewers routinely ask questions of similar intent (read: questions which can be very open-ended, require the opposite party to be vulnerable and can be interpreted in many ways). If you as an interviewer would consider it a bad question, I would hope you hold the same standard for the questions you ask yourself.
I haven't personally been in any interviews where I was asked something so opinionated, like being asked "do you write bad code?" straight-up. These questions are very leading and direct, not open-ended at all - look at how limited the set of "right answers" is for most of them.
A question like:
> "Does this team or any of the related teams have a person who actively rejects proposals to improve the code base?"
is a flag because it implies that the person asking the question thinks their definition of "improve the code base" is the only one that matters. It also is asked in a way that suggests a lack of maturity around disagreement and communication.
"If someone sees something they think would improve the code base, what should they do to try to get that done?" would be a much improved version.
> "Suppose the team needs to start a new web service like a private Gitlab, add new type of CI to the testing pipeline or something similar. Could you explain the exact steps needed to get it fully operational? Please list all people who need to do work to make this happen (including just giving authorization), and time estimates for each individual step."
This one is less of a "bad question" if you're OK with filtering out places that don't work that way (a place that spins up random new infrastructure shit in a couple days super frequently seems like a terrible each-service-is-a-special-snowflake hard-to-maintain/hard-to-debug/hard-to-improve sort of hell, IMO) but if you're just more interested in process and bureaucracy, I'd suggest something more like "what are your thoughts on standardized shared infrastructure and tooling vs specialized things per-project?"
EDIT: actually, to borrow a page from some frequent advice for interviewers - for bonus points you can rewrite both of those "better" versions to ask for specifics, along the lines of "can you tell me about a time someone on the team proposed a code improvement change that was controversial." Only ask for the vaguer "philosophical approach" part if they can't give you a specific story.
A question like:
> "Does this team or any of the related teams have a person who actively rejects proposals to improve the code base?"
is a flag because it implies that the person asking the question thinks their definition of "improve the code base" is the only one that matters. It also is asked in a way that suggests a lack of maturity around disagreement and communication.
"If someone sees something they think would improve the code base, what should they do to try to get that done?" would be a much improved version.
> "Suppose the team needs to start a new web service like a private Gitlab, add new type of CI to the testing pipeline or something similar. Could you explain the exact steps needed to get it fully operational? Please list all people who need to do work to make this happen (including just giving authorization), and time estimates for each individual step."
This one is less of a "bad question" if you're OK with filtering out places that don't work that way (a place that spins up random new infrastructure shit in a couple days super frequently seems like a terrible each-service-is-a-special-snowflake hard-to-maintain/hard-to-debug/hard-to-improve sort of hell, IMO) but if you're just more interested in process and bureaucracy, I'd suggest something more like "what are your thoughts on standardized shared infrastructure and tooling vs specialized things per-project?"
EDIT: actually, to borrow a page from some frequent advice for interviewers - for bonus points you can rewrite both of those "better" versions to ask for specifics, along the lines of "can you tell me about a time someone on the team proposed a code improvement change that was controversial." Only ask for the vaguer "philosophical approach" part if they can't give you a specific story.
> is a flag because it implies that the person asking the question thinks their definition of "improve the code base" is the only one that matters. It also is asked in a way that suggests a lack of maturity around disagreement and communication.
The flag for me is that they routinely fail to get alignment from their co-workers before they begin potentially contentious changes. It's a sign of maturity to identify stakeholders, drive towards consensus and ensure alignment before beginning on any such project.
I highly recommend this [1] as a framework for resolving such issues - and also it's a super strong answer if you're asked how you personally resolve such issues within an organization during an interview. The core principle is that people care more about the decision maker hearing out their idea, and understanding it, than they do about their idea being picked. The focus is on hearing people out. IME it's very effective even with, er, prickly personalities.
[1] https://review.firstround.com/square-defangs-difficult-decis...
The flag for me is that they routinely fail to get alignment from their co-workers before they begin potentially contentious changes. It's a sign of maturity to identify stakeholders, drive towards consensus and ensure alignment before beginning on any such project.
I highly recommend this [1] as a framework for resolving such issues - and also it's a super strong answer if you're asked how you personally resolve such issues within an organization during an interview. The core principle is that people care more about the decision maker hearing out their idea, and understanding it, than they do about their idea being picked. The focus is on hearing people out. IME it's very effective even with, er, prickly personalities.
[1] https://review.firstround.com/square-defangs-difficult-decis...
I don't agree with the question, but take away the reason the author is asking them, and the question is far more open-ended to the one being asked. That's the problem: it's a direct question which has too many possible answers which helps neither the party answering (because what should they answer?) nor the party asking (because even the answers not 100% on the mark can be interpreted in many ways). Plus, it's a horrible premise to set the other party up for failure to begin with.
When you view it from that angle, the majority of questions in interviews are pretty similar. You can't tell whether the opposing party is expecting a perfect answer, or is lenient enough to take a chance with anything which isn't perfect.
The problem with your changes, however, is that you take away the very thing that the author puts in for a reason. Removing the directness means the opposing party is now given more of a chance to provide a complete nothingburger of an answer which is likely half-true, and half-"what the world is this place actually?" That's not necessarily an improvement when you take into account all other aspects of interviewing. The only definite benefit you gain, is not causing bad blood by appearing combative over collaborative.
Ultimately, what people want is transparency. That transparency is very hard to tell from the side of candidates. Formulating questions to allow 'best case answers' doesn't work as it allows the company to oversell itself. Formulating questions directly doesn't work because the interviewer gets a bad taste in their mouth. But the silly thing is, lots (the majority?) of interviewers certainly have their fair share of horrible practices which continue to exist today. The only reason they exist, is due to their power in the market.
When you view it from that angle, the majority of questions in interviews are pretty similar. You can't tell whether the opposing party is expecting a perfect answer, or is lenient enough to take a chance with anything which isn't perfect.
The problem with your changes, however, is that you take away the very thing that the author puts in for a reason. Removing the directness means the opposing party is now given more of a chance to provide a complete nothingburger of an answer which is likely half-true, and half-"what the world is this place actually?" That's not necessarily an improvement when you take into account all other aspects of interviewing. The only definite benefit you gain, is not causing bad blood by appearing combative over collaborative.
Ultimately, what people want is transparency. That transparency is very hard to tell from the side of candidates. Formulating questions to allow 'best case answers' doesn't work as it allows the company to oversell itself. Formulating questions directly doesn't work because the interviewer gets a bad taste in their mouth. But the silly thing is, lots (the majority?) of interviewers certainly have their fair share of horrible practices which continue to exist today. The only reason they exist, is due to their power in the market.
Where I disagree with you there is about the utility of directness vs concreteness.
"Does this team or any of the related teams have a person who actively rejects proposals to improve the code base?"
This leaves an unscrupulous interviewer a too-obvious answer: "no." They aren't going to want to admit someone "actively reject improvements" and lying in interviews is not uncommon.
Asking for a specific story raises the skill bar for an effective lie. If someone is smooth enough to come up with a convincing, compelling story on the fly you sadly will struggle to catch them out with any questions.
Fall back to a more open-ended discussion if they don't. This is less good, but a longer discussion, similarly, should make it easier to spot a liar than in a single-word "no." Every word the interviewer says is opportunity to gain more insight on what it would be like to work with them.
Even that fallback is information you gain, though. "Can you tell me about a time someone on the team proposed a code improvement change that was controversial?" If the answer is "I can't think of anything immediately, but I'd probably do something like...[whatever]" then that's curious - it could suggest a few things. Maybe the systems are so simple that nobody thinks its worth bothering with changing. That could be bad for a candidate looking for a challenge. Maybe nobody on the team is empowered to make suggestions and all design is coming top-down from the boss. That would also be bad. (And the original yes/no question misses this case too: nobody on the team might do that, because only the boss is making the calls, and nobody else has made those suggestions, but gives you less answer to follow up on.)
You can try to dig in more with additional questions, depending on which of those (or other) impressions you get from their answers.
"Does this team or any of the related teams have a person who actively rejects proposals to improve the code base?"
This leaves an unscrupulous interviewer a too-obvious answer: "no." They aren't going to want to admit someone "actively reject improvements" and lying in interviews is not uncommon.
Asking for a specific story raises the skill bar for an effective lie. If someone is smooth enough to come up with a convincing, compelling story on the fly you sadly will struggle to catch them out with any questions.
Fall back to a more open-ended discussion if they don't. This is less good, but a longer discussion, similarly, should make it easier to spot a liar than in a single-word "no." Every word the interviewer says is opportunity to gain more insight on what it would be like to work with them.
Even that fallback is information you gain, though. "Can you tell me about a time someone on the team proposed a code improvement change that was controversial?" If the answer is "I can't think of anything immediately, but I'd probably do something like...[whatever]" then that's curious - it could suggest a few things. Maybe the systems are so simple that nobody thinks its worth bothering with changing. That could be bad for a candidate looking for a challenge. Maybe nobody on the team is empowered to make suggestions and all design is coming top-down from the boss. That would also be bad. (And the original yes/no question misses this case too: nobody on the team might do that, because only the boss is making the calls, and nobody else has made those suggestions, but gives you less answer to follow up on.)
You can try to dig in more with additional questions, depending on which of those (or other) impressions you get from their answers.
You're only tackling what you gain from your changes, not what you lose.
Digging in requires people to spend more time. Most interviews are already massive and exhausting. Candidates in general aren't looking for longer interviews, they are looking for shorter interviews. Your changes propose even longer interviews when the number one complaint is the sheer length and volume of interviews.
Most candidates are not amazing at interviewing or figuring out people, let alone when they spend most of their time doing other things at the day/week of interviewing. The majority of candidates are either tired, inexperienced, or both. Increasing the volume of information isn't a strict gain under conditions which are true far too often, and can even be a loss.
Lying isn't uncommon, but I'd think twice about whether saying "no" is really that much easier than weaving an elaborate half-truth. At the same time, most candidates will be treading a fine line between not getting on the interviewer's nerves, and figuring out what is actually happening. Navigating social dynamics is difficult for a reason.
>it could suggest a few things
That's the entire problem. I reckon this is part of the reason why author is so direct in their questions. They don't want to deal with multiple possible answers and spending more time figuring out the answer. They want a 'is this company worth my time' checklist which doesn't take multiple hours to fill.
For obvious reasons, that checklist isn't going to work for the majority of people (you named several reasons yourself). But changing the questions isn't going to help reach the intended goal either.
Digging in requires people to spend more time. Most interviews are already massive and exhausting. Candidates in general aren't looking for longer interviews, they are looking for shorter interviews. Your changes propose even longer interviews when the number one complaint is the sheer length and volume of interviews.
Most candidates are not amazing at interviewing or figuring out people, let alone when they spend most of their time doing other things at the day/week of interviewing. The majority of candidates are either tired, inexperienced, or both. Increasing the volume of information isn't a strict gain under conditions which are true far too often, and can even be a loss.
Lying isn't uncommon, but I'd think twice about whether saying "no" is really that much easier than weaving an elaborate half-truth. At the same time, most candidates will be treading a fine line between not getting on the interviewer's nerves, and figuring out what is actually happening. Navigating social dynamics is difficult for a reason.
>it could suggest a few things
That's the entire problem. I reckon this is part of the reason why author is so direct in their questions. They don't want to deal with multiple possible answers and spending more time figuring out the answer. They want a 'is this company worth my time' checklist which doesn't take multiple hours to fill.
For obvious reasons, that checklist isn't going to work for the majority of people (you named several reasons yourself). But changing the questions isn't going to help reach the intended goal either.
While many on here complain about the length and amount of interviews I think that's because they get nothing from it. They already know how great they are!
Adding an extra 15 minutes at the end of a 7 hour interview process to find out if this is a place you might actually enjoy working seems like a no-brainier. I've also seen it make leaving much easier.
If you did ask (in a more polite and helpful manner than proposed by the OP) questions like these and the hiring manager lied to you moving on will _feel_ much easier.
Adding an extra 15 minutes at the end of a 7 hour interview process to find out if this is a place you might actually enjoy working seems like a no-brainier. I've also seen it make leaving much easier.
If you did ask (in a more polite and helpful manner than proposed by the OP) questions like these and the hiring manager lied to you moving on will _feel_ much easier.
Just because "interviewers routinely ask questions of similar intent" doesn't mean that it is acceptable or should be treated as the norm. It all heavily depends on how your company designs their interview process and guidelines for it.
At every company I've worked so far where I was involved in interviewing, leading and ill-intended questions like that were explicitly prohibited, and that was stressed plenty of times during the interview training. There might have been other things about the process as a whole that I thought could and should be definitely improved, but the "disingenuous questions from the interviewers" was never one of them.
But on the flip side, I've interviewed at plenty of companies (as a candidate) over the years, and I definitely was asked those types of questions at more than one place.
So you are correct, it is common, and it sucks to be on the receiving end of it. But doing that exact same thing back to them as a candidate isn't going to solve your problem. The solution is to not work for companies that are ok with their interviewers asking those types of questions (as much as you can afford to do so).
Think about it for a minute, what are you trying to achieve by asking back those leading and ill-intended questions? If you somehow still want to work for the company, then asking those questions back probably isn't the smartest idea. And if you don't want to work for them after they asked you those questions, then why waste energy on arguing back and trying to make some point.
A no is a no, your outcome of not working for them would be just the same, so why do the extra work[0]. It isn't like they are going to take that feedback earnestly and change anything for you. If you truly want to make something out of it, it would be much better to instead warn other candidates (aka your friends who might think of applying, if someone on HN asks about interviewing at the company, etc.) about it.
0. note: venting out your frustration is a valid enough of a reason.
At every company I've worked so far where I was involved in interviewing, leading and ill-intended questions like that were explicitly prohibited, and that was stressed plenty of times during the interview training. There might have been other things about the process as a whole that I thought could and should be definitely improved, but the "disingenuous questions from the interviewers" was never one of them.
But on the flip side, I've interviewed at plenty of companies (as a candidate) over the years, and I definitely was asked those types of questions at more than one place.
So you are correct, it is common, and it sucks to be on the receiving end of it. But doing that exact same thing back to them as a candidate isn't going to solve your problem. The solution is to not work for companies that are ok with their interviewers asking those types of questions (as much as you can afford to do so).
Think about it for a minute, what are you trying to achieve by asking back those leading and ill-intended questions? If you somehow still want to work for the company, then asking those questions back probably isn't the smartest idea. And if you don't want to work for them after they asked you those questions, then why waste energy on arguing back and trying to make some point.
A no is a no, your outcome of not working for them would be just the same, so why do the extra work[0]. It isn't like they are going to take that feedback earnestly and change anything for you. If you truly want to make something out of it, it would be much better to instead warn other candidates (aka your friends who might think of applying, if someone on HN asks about interviewing at the company, etc.) about it.
0. note: venting out your frustration is a valid enough of a reason.
Obviously I did not tackle it because of some ideal to fight fire with fire. I'm tackling it as people seem to forget something very obvious:
Most red flags are entirely dependent on your position in the market.
The less fortunate (people in careers with low demand, juniors, etc.) do not have the luxury to ask most of these questions, let alone vet for every red flag.
My point is to illustrate the absurdity most people face and how normalized it is from the employer's side. If devs are already ridiculed as Prima Donna's by their peers merely for proposing such a list, I'd expect those same people to think twice and critique the status quo too. Yet, developers are more often tone policing each other rather than handling the same standards for employers, from my experience.
Author wouldn't even be blogging this if they only had a portion of the power they have now.
Most red flags are entirely dependent on your position in the market.
The less fortunate (people in careers with low demand, juniors, etc.) do not have the luxury to ask most of these questions, let alone vet for every red flag.
My point is to illustrate the absurdity most people face and how normalized it is from the employer's side. If devs are already ridiculed as Prima Donna's by their peers merely for proposing such a list, I'd expect those same people to think twice and critique the status quo too. Yet, developers are more often tone policing each other rather than handling the same standards for employers, from my experience.
Author wouldn't even be blogging this if they only had a portion of the power they have now.
It's a fair point -- and there are plenty of standard interview questions which fall squarely into that bucket. E.g. "Tell me your greatest weaknesses" is a horrible question that I for one never ask.
The blog post makes it clear that there's an intended single correct answer to this question, "No, a person who does this specific thing does not exist." It doesn't give room for "Yes, and I think they're right to do so, and here's why" - or even "No, but there's a person who ships their own stuff without review all the time."
I think you could ask it in an open-ended way (though maybe phrased more like "What's the most difficult part of getting code improvements shipped" or "How does your team tend to balance the merits of making big changes" or "What is good and bad about your code review process") and it'd be a fine question.
I think you could ask it in an open-ended way (though maybe phrased more like "What's the most difficult part of getting code improvements shipped" or "How does your team tend to balance the merits of making big changes" or "What is good and bad about your code review process") and it'd be a fine question.
I'll articulate. The question is indeed asked with intent, but to the one answering, it comes across as something that can have a lot of answers as GP shows. At the same time, any answer can likely be interpreted in many ways, too. It opens up a lot of potential variations which, if you're looking for a specific answer and aren't very adaptable, sets the other party up for failure.
It's the same issue which many traditional questions asked by interviewers have. They are at best "okay" when asked with an open mind. At worst, they are beyond worthless and create bad blood, as the other party is set up to fail.
It's the same issue which many traditional questions asked by interviewers have. They are at best "okay" when asked with an open mind. At worst, they are beyond worthless and create bad blood, as the other party is set up to fail.
To expand on why I think it's a bad question, "Yes, and I think they're right to do so, and here's why" is probably the best response I could come up with, and makes the interview adversarial for no good reason. It becomes an argument about the premise of the question. Putting the interviewer _or_ the interviewee on the defensive helps neither.
Added: I realise I'm being adversarial myself here too :). You are correct, in that the questions could be reworded in better ways. Agree on that!
Added: I realise I'm being adversarial myself here too :). You are correct, in that the questions could be reworded in better ways. Agree on that!
Maybe there should be a person on each team who actively rejects proposals (can also be multiple people on rotation). The nemesis!
As a non-Googler I'm very curious how much Google lets you check out onto your dev machine. I'm assuming it's less than "oh, yeah, just clone locally that shard of the prod gmail DB to debug that weird thing," but I would love to know how much less.
Some of the companies I've worked that let me do the most with my machine were also the strictest about "real" work and data remaining off of personal machines in favor of remote (and non-admin) access to shared resources.
Assuming that developers can never be privacy, confidentiality, or other sorts of information security/compliance risks is silly.
I think a much better question would be "how are information security and privacy controls implemented" so you know if it meshes with how you want to work and what you think is appropriate for the sorts of data involved. Super-draconian policies for trivial data would be frustrating - but super-lax ones for sensitive customer personal information would be its own different red flag.
Some of the companies I've worked that let me do the most with my machine were also the strictest about "real" work and data remaining off of personal machines in favor of remote (and non-admin) access to shared resources.
Assuming that developers can never be privacy, confidentiality, or other sorts of information security/compliance risks is silly.
I think a much better question would be "how are information security and privacy controls implemented" so you know if it meshes with how you want to work and what you think is appropriate for the sorts of data involved. Super-draconian policies for trivial data would be frustrating - but super-lax ones for sensitive customer personal information would be its own different red flag.
Well, for starters there isn't just one dev machine :-) You at least have a laptop and a workstation. Possibly several of each. I believe there is no code at all stored on laptops, barring some exceptions.
I am not entirely sure 'check out' is an applicable concept to the tech stack. There's quite a lot of (public) information in this article in the 'Background' section: https://cacm.acm.org/magazines/2016/7/204032-why-google-stor...
In particular, look for the keyword 'CitC' in the article. The tl;dr though is that the tooling presents a view of the monorepo where 'everything' is available (excluding the protected sections) - while keeping the actual files off of workstations. (Although there's probably caching?)
Disclosure: I work at Google.
I am not entirely sure 'check out' is an applicable concept to the tech stack. There's quite a lot of (public) information in this article in the 'Background' section: https://cacm.acm.org/magazines/2016/7/204032-why-google-stor...
In particular, look for the keyword 'CitC' in the article. The tl;dr though is that the tooling presents a view of the monorepo where 'everything' is available (excluding the protected sections) - while keeping the actual files off of workstations. (Although there's probably caching?)
Disclosure: I work at Google.
But how do you actually edit files in your local text editor? The article mentions FUSE for Linux. Is this also used for macOS?
Usually, devs use one of Google's web-based code editors. No local editor at all. The web editors are pretty well integrated with the rest of the dev stack... and they just work.
CitC workspaces aren't mounted on laptops, so no MacOS support. I think sshfs is permitted if you want to use something like Emacs or Vim on your laptop rather than on your workstation. I've never tried at Google, but previous experience with sshfs tells me the performance probably wouldn't be great. Maybe some tweaks help.
Honestly, these days I'm much less willing to tinker endlessly to get the 'perfect' setup.
CitC workspaces aren't mounted on laptops, so no MacOS support. I think sshfs is permitted if you want to use something like Emacs or Vim on your laptop rather than on your workstation. I've never tried at Google, but previous experience with sshfs tells me the performance probably wouldn't be great. Maybe some tweaks help.
Honestly, these days I'm much less willing to tinker endlessly to get the 'perfect' setup.
When I was there, you could have whatever on your workstation inside the office. No source code was allowed on any mobile device, though. For a while I would use sshfs into my workstation when coding on my laptop. Google's version control system is pretty fancy, though, moreso than simply just storing files on your local filesystem (client in the cloud). At some point it became easy to write code in a browser based text editor, and I did that both on my laptop and on my workstation; it had the best code search integration.
[deleted]
> I think a much better question would be "how are information security and privacy controls implemented"
I don't work for Google, but if I was asked that question, I'd be afraid of giving an answer that would violate my NDA. You'd probably get a vague answer like, "Those policies and processes do exist, but I'm not at liberty to go into them right now. Why do you ask - is there something specific I can address?"
I don't work for Google, but if I was asked that question, I'd be afraid of giving an answer that would violate my NDA. You'd probably get a vague answer like, "Those policies and processes do exist, but I'm not at liberty to go into them right now. Why do you ask - is there something specific I can address?"
> I think a much better question would be "how are information security and privacy controls implemented"
Agreed, that's a great question to ask.
Agreed, that's a great question to ask.
> "Anything under 10 minutes is good" for running the CI pipeline (not true anywhere I've been at Google) or "The steps should be 'do a git clone...'" (also not true at Google).
Are these both true/common in the industry? At least where I work CI takes at most a couple minutes (depending on what all you're doing in your docker file) and likewise you can just pull and run CI locally on your machine for nearly any repo.
Are these both true/common in the industry? At least where I work CI takes at most a couple minutes (depending on what all you're doing in your docker file) and likewise you can just pull and run CI locally on your machine for nearly any repo.
Times above 10 minutes are very common and really unavoidable for some kinds of systems. You can mitigate the impact on the practical develop loop with effort (caching parts of the build, splitting off slower tests), but if you're building something like a database 10 minutes just isn't enough time to validate your change hasn't broken anything.
It can take up to an hour at where are work. Each commit requires a bumch of compliation for different targets and some unit tests
AND after the commit and all that there are many more tests at farms that can take a lot more depending size of queue
AND after the commit and all that there are many more tests at farms that can take a lot more depending size of queue
Our test suite takes about 30 minutes, but that's running across like 20 nodes. It's not practical to run locally, though individual test cases can be.
Does this team or any of the related teams have a person who actively rejects proposals to improve the code base?
On the basis that no one should have unilateral power to reject features, regardless of whether it improves anything or not, it seems quite of that the straightforward answer is a simple "No". If the candidate withdraws their application on the basis of that then both sides have won.
On the basis that no one should have unilateral power to reject features, regardless of whether it improves anything or not, it seems quite of that the straightforward answer is a simple "No". If the candidate withdraws their application on the basis of that then both sides have won.
I think it is better to have a person that says no to such large refactors, compared to a place where devs go wild with such "improvements". Most devs are not great at timeboxing themselves or at seeing full impact of their refactorings
This list smacks of a developer prima donna mentality and if you think most of those rationale explanations are reasonable, you’re more likely to be a liability to the organization and not a team player. Companies have numerous goals, responsibilities, and compliance requirements that you don’t get to ignore or avoid simply because Steve Ballmer chanted about “developers” on stage that time.
What would you think about a business person who thought testing was a waste of time because it slows down releases? Or they don’t want to use an issue tracker because it just easier to tell you something in the hallway? Those thing slow them down, so why bother?
What would you think about a business person who thought testing was a waste of time because it slows down releases? Or they don’t want to use an issue tracker because it just easier to tell you something in the hallway? Those thing slow them down, so why bother?
> This list smacks of a developer prima donna mentality
The reality is that the market for good developers is so competitive that they could just walk out and find 10 other places with better answers to these questions.
> testing was a waste of time because it slows down releases?
Not a single question is anagolous to this. Developers want a fast CI process (and testing can be fast, given adequate time allocated to improving CI) because developers are happiest when they are productive. What type of business person would say "no" to employees who only want to be productive? Apparently, the majority. The problem is when micro-management ends up prioritizing tracking work over doing work. It might help to listen to people who are passionate about shipping product, instead of shipping metrics.
Although it is a software concept, these questions guage the degree of accidental vs. essential complexity within an org.
The reality is that the market for good developers is so competitive that they could just walk out and find 10 other places with better answers to these questions.
> testing was a waste of time because it slows down releases?
Not a single question is anagolous to this. Developers want a fast CI process (and testing can be fast, given adequate time allocated to improving CI) because developers are happiest when they are productive. What type of business person would say "no" to employees who only want to be productive? Apparently, the majority. The problem is when micro-management ends up prioritizing tracking work over doing work. It might help to listen to people who are passionate about shipping product, instead of shipping metrics.
Although it is a software concept, these questions guage the degree of accidental vs. essential complexity within an org.
> The reality is that the market for good developers is so competitive that they could just walk out and find 10 other places with better answers to these questions.
Sure, but will that be a better place to work?
Ultimately there are many failure modes for software engineering teams, and grilling the interviewer with a series of highly-specific workflow questions is not likely to yield much insight. If the team is really as dysfunctional as the author fears, then you're not likely to get an answer that is on the same wavelength as you anyway.
You're better off asking things a little higher level and a little more open-ended and then reading between the lines. So for example, instead of:
> Does this team or any of the related teams have a person who actively rejects proposals to improve the code base?
You could ask:
> What are the biggest problems in the code base currently?
You can then engage in a dialogue and probe into details organically. This will yield much more fruit than asking a question to which the obvious answer is "no, of course not".
Sure, but will that be a better place to work?
Ultimately there are many failure modes for software engineering teams, and grilling the interviewer with a series of highly-specific workflow questions is not likely to yield much insight. If the team is really as dysfunctional as the author fears, then you're not likely to get an answer that is on the same wavelength as you anyway.
You're better off asking things a little higher level and a little more open-ended and then reading between the lines. So for example, instead of:
> Does this team or any of the related teams have a person who actively rejects proposals to improve the code base?
You could ask:
> What are the biggest problems in the code base currently?
You can then engage in a dialogue and probe into details organically. This will yield much more fruit than asking a question to which the obvious answer is "no, of course not".
> Sure, but will that be a better place to work?
If an employer doesn't give developers local admin rights on their machines, I'm quite certain it's not going to be a better place to work for me.
If an employer doesn't give developers local admin rights on their machines, I'm quite certain it's not going to be a better place to work for me.
I definitely agree with your ideas. I aimed only the refute the concept of "developer prima donna."
Just like any codebase will forever contain some amount of accidental complexity, so will any org. It's all about whether it is being tackled or embraced. While these questions may not be perfect, accidental overcomplexity can (probably will) make your job miserable.
Just like any codebase will forever contain some amount of accidental complexity, so will any org. It's all about whether it is being tackled or embraced. While these questions may not be perfect, accidental overcomplexity can (probably will) make your job miserable.
The reality is that the market for good developers is so competitive that they could just walk out and find 10 other places with better answers to these questions.
That may have been the case in certain parts of the world for the past few years. The next year or two might bring some rude awakenings for mid-to-senior devs who are only a few years in and have never seen things any other way.
I was trying to work out how many of these questions a candidate could ask me - with the attitude implied by the tone and phrasing in the article - before I immediately terminated the interview and no-hired them. They might get away with one or two of the ones with reasonable underlying points with the benefit of the doubt about the attitude problem but I doubt they'd get past that. If they really can get hired at 10 other places instead then good for them but somehow I doubt that would actually be true for this kind of person. No-one wants a toxic prima donna on the team.
That may have been the case in certain parts of the world for the past few years. The next year or two might bring some rude awakenings for mid-to-senior devs who are only a few years in and have never seen things any other way.
I was trying to work out how many of these questions a candidate could ask me - with the attitude implied by the tone and phrasing in the article - before I immediately terminated the interview and no-hired them. They might get away with one or two of the ones with reasonable underlying points with the benefit of the doubt about the attitude problem but I doubt they'd get past that. If they really can get hired at 10 other places instead then good for them but somehow I doubt that would actually be true for this kind of person. No-one wants a toxic prima donna on the team.
> reasonable underlying points with the benefit of the doubt about the attitude problem
So asking about CI times, code review process, admin rights, being able to run tests locally, and operating system choice would likely result in a terminated interview? I think the questions would be working perfectly in that scenario.
So asking about CI times, code review process, admin rights, being able to run tests locally, and operating system choice would likely result in a terminated interview? I think the questions would be working perfectly in that scenario.
The point here isn't the questions. Asking questions on those topics in a mature and professional way would be absolutely fine. Asking a series of questions with an almost accusatory tone and evident my-way-or-the-high-way attitude would not and that is the concern many of us here appear to have with the linked article.
Idk, not having admin rights is super annoying.
Well, I kinda like it -- less things to care about, more reason to leave at 5.
But it's counterproductive for the company, and some experiments a developer may want to quickly do will never be done at all. It kills a lot of creativity. The same holds, of course, for restricting internet access so a dev might never find out whether an interesting looking github tool really is good (for doing productive work!). Also, the company probably wants their products to run on a diverse zoo of machines and OS versions prior to release.
So why a company would take away such access on dev machines is a mystery to me -- probably misguided (and futile) attempts to keep in 'control'.
But it's counterproductive for the company, and some experiments a developer may want to quickly do will never be done at all. It kills a lot of creativity. The same holds, of course, for restricting internet access so a dev might never find out whether an interesting looking github tool really is good (for doing productive work!). Also, the company probably wants their products to run on a diverse zoo of machines and OS versions prior to release.
So why a company would take away such access on dev machines is a mystery to me -- probably misguided (and futile) attempts to keep in 'control'.
>less things to care about, more reason to leave at 5.
What do you mean?
What do you mean?
If it's not in your power to resolve an issue with your machine by the end of the work day, you should feel no pressure to stay late and fix it.
Even if it’s in my power to fix, why should I do this overtime?
Emergencies can happen where you need to stay an hour or two after EOD, but if it’s more than once a year I’m out, personally, local admin permissions or not.
Emergencies can happen where you need to stay an hour or two after EOD, but if it’s more than once a year I’m out, personally, local admin permissions or not.
I agree, but having them is also a huge liability. I’m always happy to have less privileges because it limits the damage I can accidentally cause. If someone competently manages my machine so that I can do my work without requiring root privileges, that works for me.
The actual question I’d be interested in is how do developer convenience and security stance balance against each other, and how are the inevitable conflicts resolved.
The actual question I’d be interested in is how do developer convenience and security stance balance against each other, and how are the inevitable conflicts resolved.
> What would you think about a business person who thought testing was a waste of time because it slows down releases? Or they don’t want to use an issue tracker because it just easier to tell you something in the hallway?
Massive red flags, take the job if you have to but keep looking and leave as soon as you can. I have actually worked for this business person, and wouldn't recommend the experience.
Massive red flags, take the job if you have to but keep looking and leave as soon as you can. I have actually worked for this business person, and wouldn't recommend the experience.
It's a matching process. If you as the employer feel this way, and the candidate feels these things are important, you're not right for each other. That's an appropriate thing to discover in an interview.
Personally, I work at an engineering-first company where management takes fairly seriously its task of providing us with a comfortable and productive environment. In this labor market, I wouldn't work somewhere that wanted me to be a "team player" about a shitty computer or micromanage my tasks. There are things to be a team player about, of course, but not the basic tools and structures for even beginning to get work done.
Personally, I work at an engineering-first company where management takes fairly seriously its task of providing us with a comfortable and productive environment. In this labor market, I wouldn't work somewhere that wanted me to be a "team player" about a shitty computer or micromanage my tasks. There are things to be a team player about, of course, but not the basic tools and structures for even beginning to get work done.
[deleted]
This list is asking about specific symptoms of larger problems about which they may be concerned. To which I'd just recommend - don't be coy. If you want to know what the experience is like being a developer there, just ask directly -- Don't symptom-check.
If I were asked these questions, I'd cut them off and ask them to tell me what they are afraid of - we all have our own fear and anxieties about starting in new environments, but I'm far more likely to hire someone who can open a dialogue about their concerns than someone who just picks aspects of past experiences and grills me about them. Not only will the interview get more directly to the point, such a conversation will show they are able to talk through whatever problems may arise in the future.
If I were asked these questions, I'd cut them off and ask them to tell me what they are afraid of - we all have our own fear and anxieties about starting in new environments, but I'm far more likely to hire someone who can open a dialogue about their concerns than someone who just picks aspects of past experiences and grills me about them. Not only will the interview get more directly to the point, such a conversation will show they are able to talk through whatever problems may arise in the future.
Agree, I would just replace all this with, “can you talk about the tech stack, developer experience, etc?” and then explain what I’m looking for in more detail but without the pointed questions or snark. Also, this is a “final interview” question, like the questions you ask once you know you have the nod and are now just trying to ensure it’s a good match.
A twenty-two-year-old version of this, the Joel Test: https://www.joelonsoftware.com/2000/08/09/the-joel-test-12-s....
1. Do you use source control?
2. Can you make a build in one step?
3. Do you make daily builds?
4. Do you have a bug database?
5. Do you fix bugs before writing new code?
6. Do you have an up-to-date schedule?
7. Do you have a spec?
8. Do programmers have quiet working conditions?
9. Do you use the best tools money can buy?
10. Do you have testers?
11. Do new candidates write code during their interview?
12. Do you do hallway usability testing?
It's interesting to reflect on how things have changed. Source control is not even a question anymore. Quiet working conditions, not a chance unless remote. Schedule? Spec? Testers? Never seen 'em. Do new candidates write code during interviews? Oh boy, do they ever.
1. Do you use source control?
2. Can you make a build in one step?
3. Do you make daily builds?
4. Do you have a bug database?
5. Do you fix bugs before writing new code?
6. Do you have an up-to-date schedule?
7. Do you have a spec?
8. Do programmers have quiet working conditions?
9. Do you use the best tools money can buy?
10. Do you have testers?
11. Do new candidates write code during their interview?
12. Do you do hallway usability testing?
It's interesting to reflect on how things have changed. Source control is not even a question anymore. Quiet working conditions, not a chance unless remote. Schedule? Spec? Testers? Never seen 'em. Do new candidates write code during interviews? Oh boy, do they ever.
As others point out, some of these are quite naive. (E.g. at many companies you have a large monorepo, so the "git clone" comment is silly, etc.)
What really gets me, though, is the tone. There's a nice way to probe for organizational problems like too much bureaucracy without coming across like a jerk. If someone showed this lack of self-awareness and basic social skills in an interview, I can promise they'd be a strong no hire.
What really gets me, though, is the tone. There's a nice way to probe for organizational problems like too much bureaucracy without coming across like a jerk. If someone showed this lack of self-awareness and basic social skills in an interview, I can promise they'd be a strong no hire.
Yeah the tone has some arrogance thats for sure. Maybe it would be a wet dream of some startup CTO but in some bigger, more stable and older corporations this would just trigger Next! response.
The author is clearly experienced in very narrow set of IT reality and not much more, he would fall into promising junior category if he would skip the arrogant part.
For each question, I would point out our massive set of existing rigid processes and give back immediately: how would you improve on that while still being compliant on them? Companies are not there to baby sit juniors with big egos, they have products to deliver that mostly uses IT just as part of the overall process. They like improvements, but only those that keep things working seamlessly, on budget and time.
The author is clearly experienced in very narrow set of IT reality and not much more, he would fall into promising junior category if he would skip the arrogant part.
For each question, I would point out our massive set of existing rigid processes and give back immediately: how would you improve on that while still being compliant on them? Companies are not there to baby sit juniors with big egos, they have products to deliver that mostly uses IT just as part of the overall process. They like improvements, but only those that keep things working seamlessly, on budget and time.
I agree that the way the answers are evaluated is too narrow and simplistic. That said,
> coming across like a jerk... lack of self-awareness and basic social skills
I see things very similarly, but from the other side of the table.
If an organization is uncomfortable with me asking direct-but-polite questions about potentially negative aspects of working there, and asking such questions gets me labeled as a jerk, that organization is too culturally dysfunctional for me to work for.
> coming across like a jerk... lack of self-awareness and basic social skills
I see things very similarly, but from the other side of the table.
If an organization is uncomfortable with me asking direct-but-polite questions about potentially negative aspects of working there, and asking such questions gets me labeled as a jerk, that organization is too culturally dysfunctional for me to work for.
The issue is not with being direct, but with instructing the interviewer to "please list the exact steps and time estimates for each." It smacks of self-importance and arrogance, and the way it's phrased strongly suggests the author thinks they are the smartest and always right.
By the way, I looked this guy up, and his experience looks like it's extremely limited to basically a couple of SMBs and some consulting. I have no idea where he gets the confidence to comment on the industry, having basically never worked in it.
By the way, I looked this guy up, and his experience looks like it's extremely limited to basically a couple of SMBs and some consulting. I have no idea where he gets the confidence to comment on the industry, having basically never worked in it.
I've had this type of person on my team before. Reading through the questions and rationales I can just picture that person asking the same questions and expecting the same answers. Technically capable and a pain to work with. Everything was their way only, no compromises. If you don't agree, then you're just too dumb or inexperienced. The cost to the rest of the team is simply too high.
I appreciate both this and the sister comment. I think it's perfectly valid to come to a new job with strong opinions, but they should be open to challenge and a discovery of limitations and context-dependence.
In my line of work, people with strong opinions are very rarely encountered. The tendency is overwhelmingly towards unquestioning conformity to the status quo. As a result, foundational decisions are etched in stone and impossible to revisit, no matter how much downstream pain they cause.
Personally, then, I welcome any suggestion that a person has a thoughtful preference after reflecting on alternatives. But maybe it is not that useful if it is just another form of mindless rigidity.
In my line of work, people with strong opinions are very rarely encountered. The tendency is overwhelmingly towards unquestioning conformity to the status quo. As a result, foundational decisions are etched in stone and impossible to revisit, no matter how much downstream pain they cause.
Personally, then, I welcome any suggestion that a person has a thoughtful preference after reflecting on alternatives. But maybe it is not that useful if it is just another form of mindless rigidity.
Heres where you should work based on the favorable/simple answers expected on those 10 questions.
8-10 : Start up
5-7 : Small Company
3-4 : Medium ($5B+)
1-2 : Large ($25B+)
0 : Very Large
Otherwise you are interviewing at a wrong company.
---
1. Do developers in your organization have full admin rights on their own computer?
2. Are developers free to choose and install the operating system on their development machines?
3. How long does it take to run the CI for new merge requests?
4. Could you explain the process one needs to follow to get that fixed and how long does it approximately take?
4. Could you explain the procedure needed to get a new USB?
5. Could you explain the exact steps needed to get the code built?
6. Can you build the code and run tests on the local machine as if it was a standard desktop application?
7. Does this team or any of the related teams have a person who actively rejects proposals to improve the code base?
8. How many different IT support organizations do you have. Where are they physically located?
9. Could you explain the exact steps needed to get it fully operational?
10. Do you have a mandatory web proxy that everyone must use and enumerate all pieces of security and tracking software you have installed on employees' computers.
</sarcasm>
8-10 : Start up
5-7 : Small Company
3-4 : Medium ($5B+)
1-2 : Large ($25B+)
0 : Very Large
Otherwise you are interviewing at a wrong company.
---
1. Do developers in your organization have full admin rights on their own computer?
2. Are developers free to choose and install the operating system on their development machines?
3. How long does it take to run the CI for new merge requests?
4. Could you explain the process one needs to follow to get that fixed and how long does it approximately take?
4. Could you explain the procedure needed to get a new USB?
5. Could you explain the exact steps needed to get the code built?
6. Can you build the code and run tests on the local machine as if it was a standard desktop application?
7. Does this team or any of the related teams have a person who actively rejects proposals to improve the code base?
8. How many different IT support organizations do you have. Where are they physically located?
9. Could you explain the exact steps needed to get it fully operational?
10. Do you have a mandatory web proxy that everyone must use and enumerate all pieces of security and tracking software you have installed on employees' computers.
</sarcasm>
What does “getting a new Universal Serial Bus” even mean?
If you read the article, you would know he left out the word "hub"
That is such a strange example. Whenever you get a laptop you usually get a docking station which is a hub. Desktops have plenty of ports.
OP should have mentionned something like a real world example instead of an example from the late 90's: a ram upgrade, something to improve ergonomics (vertical mouse, special keyboard, chair/desk) or the purchase of a new software do get the job done more effectively. A developer is more likely to wish a 5-10$ per month subscription to a software/service than a specific piece of hardware.
OP should have mentionned something like a real world example instead of an example from the late 90's: a ram upgrade, something to improve ergonomics (vertical mouse, special keyboard, chair/desk) or the purchase of a new software do get the job done more effectively. A developer is more likely to wish a 5-10$ per month subscription to a software/service than a specific piece of hardware.
Again, had you read the article, you would know it was meant to be a trivial example.
I think most of these questions are basically asking the same thing: how bureaucratic is this organisation? Which is not something you can ask directly, so these proxy questions are a good idea.
For example, I laugh at the crap my SO has to go through at their (larger) employer for simple things. The "fixing a typo in a log file" question is especially apt: it's essentially impossible for my SO because they're only supposed to work with the software as provided, despite being programmers themselves (they do scripting to add functionality to the software using a custom language, to adapt to customer's needs). My SO would have to answer something involving navigating multiple levels of management in another country. For my own employer, I would answer "the process is git clone, git commit, git push. You can ask someone for feedback on your typo fix if you want I guess?" I'd never think of asking such a simple but effective question.
But then there is "Does this team or any of the related teams have a person who actively rejects proposals to improve the code base?" Huh? What do you expect anyone to answer to this, "oh yes we have Steve, he's a real asshole and continuously rejects the best of ideas for no apparent reason"? The author even lists it as "Out of all the questions in this list, this one is the most crucial." I can understand that the author had a bad experience having to work with someone like that, but the odds of getting a real answer here are negligible, especially compared to the odds of the interviewer thinking worse of you for asking to throw someone under the bus before you're even hired. Would not recommend asking this 'most crucial' of questions.
For example, I laugh at the crap my SO has to go through at their (larger) employer for simple things. The "fixing a typo in a log file" question is especially apt: it's essentially impossible for my SO because they're only supposed to work with the software as provided, despite being programmers themselves (they do scripting to add functionality to the software using a custom language, to adapt to customer's needs). My SO would have to answer something involving navigating multiple levels of management in another country. For my own employer, I would answer "the process is git clone, git commit, git push. You can ask someone for feedback on your typo fix if you want I guess?" I'd never think of asking such a simple but effective question.
But then there is "Does this team or any of the related teams have a person who actively rejects proposals to improve the code base?" Huh? What do you expect anyone to answer to this, "oh yes we have Steve, he's a real asshole and continuously rejects the best of ideas for no apparent reason"? The author even lists it as "Out of all the questions in this list, this one is the most crucial." I can understand that the author had a bad experience having to work with someone like that, but the odds of getting a real answer here are negligible, especially compared to the odds of the interviewer thinking worse of you for asking to throw someone under the bus before you're even hired. Would not recommend asking this 'most crucial' of questions.
I find these much better questions to ask a prospective employer during a job interview: https://github.com/viraptor/reverse-interview
After working at a few startups and going through some failed ones that went down in unpleasant ways I started asking startup interviewers, when interviewed by a founder or someone else with a high stake in it: "how would you deal with your startup failing".
I will never forget the time one of them (the founder of the company) told me he would commit suicide. Let's just say that neither of us wanted to continue that interview series any further.
I will never forget the time one of them (the founder of the company) told me he would commit suicide. Let's just say that neither of us wanted to continue that interview series any further.
> I will never forget the time one of them (the founder of the company) told me he would commit suicide.
Wow
Wow
A lot of these are fine for web development jobs, but for other kinds of software EG AAA Games, Real Time, Control / Monitoring software with specific deployment environments, Payments processing etc.. these won't be applicable.
I am someone who's worked in a few of these industries over the years, let me list a few examples of the kind of places where the answers you get to these questions won't indicate goodness or badness of the employer.
"Do developers in your organization have full admin rights on their own computer?" For security critical applications, often no. For obvious reasons. For payments software, the company may be compliance mandated to not give you full permissions either.
"Are developers free to choose and install the operating system?" For games. Especially PC games, no. If you're developing for windows, you'll develop on windows, often with VC++. (maybe if you're using Unity, you're CI pipeline will produce builds for you)
"How long does it take to run the CI for new merge requests?" In game development, it's not unheard of for a full release build to take an entire day. Games are complicated, often requiring a lot of libraries that are cached, but still need to be downloaded onto a fresh instance where a build will take place. This takes a long long time.
"How many different IT support organizations do you have. Where are they physically located?" Mastercard has its IT support organization located in the US. Even for it's UK offices. Tickets still get solved quickly even at awkward times in the morning for GMT employees.
In short, most of these are only applicable to web development outfits. There's nothing wrong with that, web dev jobs are the majority of jobs. But just be aware that this is baised towards that.
I am someone who's worked in a few of these industries over the years, let me list a few examples of the kind of places where the answers you get to these questions won't indicate goodness or badness of the employer.
"Do developers in your organization have full admin rights on their own computer?" For security critical applications, often no. For obvious reasons. For payments software, the company may be compliance mandated to not give you full permissions either.
"Are developers free to choose and install the operating system?" For games. Especially PC games, no. If you're developing for windows, you'll develop on windows, often with VC++. (maybe if you're using Unity, you're CI pipeline will produce builds for you)
"How long does it take to run the CI for new merge requests?" In game development, it's not unheard of for a full release build to take an entire day. Games are complicated, often requiring a lot of libraries that are cached, but still need to be downloaded onto a fresh instance where a build will take place. This takes a long long time.
"How many different IT support organizations do you have. Where are they physically located?" Mastercard has its IT support organization located in the US. Even for it's UK offices. Tickets still get solved quickly even at awkward times in the morning for GMT employees.
In short, most of these are only applicable to web development outfits. There's nothing wrong with that, web dev jobs are the majority of jobs. But just be aware that this is baised towards that.
I asked two questions the last time I interviewed which are wholly unrelated to anything on this list, and they found me a place I was happy enough with that I haven't looked again in 5+ years.
To engineers - how do you feel about management / the practice of management at this company, especially compared to other places you've worked? I was looking for an answer that indicated that management wasn't just where they put engineers who wanted a promotion, and also that the company's processes realized that management was a skill you could be good or bad at just like engineering.
To managers - how is diversity on your team? The answer was universally some variant of "it could be better," but I got a lot of mileage from seeing whether it was a thing they were defensive about and whether they thought they actually could concretely make progress.
All the technical stuff follows from whether the company has reliably competent managers who believe both that they ought to make things better and that they are realistically able to. There are other specific questions you can ask to answer it; I just happened to use these two (and I certainly have no idea if they're the best, but they did work). Every bad technical answer can be fixed by people who want to fix it; at the same time, every good technical answer can go bad without people who care to keep things fixed.
To engineers - how do you feel about management / the practice of management at this company, especially compared to other places you've worked? I was looking for an answer that indicated that management wasn't just where they put engineers who wanted a promotion, and also that the company's processes realized that management was a skill you could be good or bad at just like engineering.
To managers - how is diversity on your team? The answer was universally some variant of "it could be better," but I got a lot of mileage from seeing whether it was a thing they were defensive about and whether they thought they actually could concretely make progress.
All the technical stuff follows from whether the company has reliably competent managers who believe both that they ought to make things better and that they are realistically able to. There are other specific questions you can ask to answer it; I just happened to use these two (and I certainly have no idea if they're the best, but they did work). Every bad technical answer can be fixed by people who want to fix it; at the same time, every good technical answer can go bad without people who care to keep things fixed.
> Suppose the team needs to start a new web service like a private Gitlab, add new type of CI to the testing pipeline or something similar. Could you explain the exact steps needed to get it fully operational? Please list all people who need to do work to make this happen (including just giving authorization), and time estimates for each individual step.
Time estimates for each step? What on earth?
Time estimates for each step? What on earth?
This question would be a big red flag for me. I don't wanna hire someone who goes and makes all these skunkworks projects under the radar without following standard good practice. The next thing you know, it's part of the infrastructure, and isn't backed up or documented, or contains private keys and nobody else knew about it
These feel like 'snapshotty' questions, whereas in my experience you want to know things are moving in the right direction. I.e. a company could be doing the right things, but just got taken over and those right things are slowly degrading. Or doing a load of wrong things, but working really hard to change that.
It is very hard to tell what it is like working for a company from an interview. And things change, who you speak to there might be fired/leave in 3 months and it's a different scenario. I've seen this.
That said real red flags in my opinion:
* The company is about to be taken over - generally that is gonna be bad for a software developer or any non-lawyer kind of role really.
* The company is struggling with cashflow
* The company has fired a lot of people recently.
* Unclear job spec.
* Disorganised or overly burdensome interview process.
* Strong bad gut feel about the people.
* Crappy office - for your definition of crap, (even if you are the WFH...)
* Secretive companies - avoid the trade-secrets obsessed "need to know basis" kind of affairs.
* Sexism, etc.
It is very hard to tell what it is like working for a company from an interview. And things change, who you speak to there might be fired/leave in 3 months and it's a different scenario. I've seen this.
That said real red flags in my opinion:
* The company is about to be taken over - generally that is gonna be bad for a software developer or any non-lawyer kind of role really.
* The company is struggling with cashflow
* The company has fired a lot of people recently.
* Unclear job spec.
* Disorganised or overly burdensome interview process.
* Strong bad gut feel about the people.
* Crappy office - for your definition of crap, (even if you are the WFH...)
* Secretive companies - avoid the trade-secrets obsessed "need to know basis" kind of affairs.
* Sexism, etc.
If someone clicked looking for a longer / less opinionated list, I'm collecting those at https://github.com/viraptor/reverse-interview
Free drinks and fast CI don't solve a broken company, product, & team. The former you can always fix on your own, but not the latter
Two+ years of your life have much more important questions than staging servers, such as:
* "Is the company profitably growing at > 50% YoY" <- is it winning?
* "What will it take for the next 100X in growth?" <- will it keep winning?
* "What happens if the next fundraising round doesn't land?" <- is it a wobbling VC trick?
* "For this job, what will I own, and what skills do I need to be successful at that?" <- will you succeed?
* "What percent of the team has been there more than 1yr, and more than 2yrs? Why do people stay vs leave?" <- is it a healthy environment?
Two+ years of your life have much more important questions than staging servers, such as:
* "Is the company profitably growing at > 50% YoY" <- is it winning?
* "What will it take for the next 100X in growth?" <- will it keep winning?
* "What happens if the next fundraising round doesn't land?" <- is it a wobbling VC trick?
* "For this job, what will I own, and what skills do I need to be successful at that?" <- will you succeed?
* "What percent of the team has been there more than 1yr, and more than 2yrs? Why do people stay vs leave?" <- is it a healthy environment?
> "Is the company profitably growing at > 50% YoY" <- is it winning?
> "What will it take for the next 100X in growth?" <- will it keep winning?
How do these exactly affect a software developer? Even if the company is going to grow 100x, you can still be laid off and it's highly unlikely you're ever going to have any part of the money.
How do these exactly affect a software developer? Even if the company is going to grow 100x, you can still be laid off and it's highly unlikely you're ever going to have any part of the money.
if the company keeps growing revenue ahead of hiring, they'll care more about retaining good people than losing them so they can keep growing. in this scenario, hiring a build engineer to fix CI becomes a reasonable thing to do: there's money, it's not a hard problem, and makes everyone else happier & more productive.
if the company is setting more and more money on fire, it's a dead company walking. you're hoping for an acquisition or exit before the house of cards collapses. in this scenario, instead of repurposing current hires to getting to profitability, a company that keeps hiring is compounding its risk. each new hire eats the runway that much faster and makes everyone's job that much more precarious.
folks are totally free to ignore whether their company is economically viable, and prioritize something like free drinks & CI b/c that makes their week better. but then they shouldn't be surprised when multiple rounds of layoffs happen every few months.
Note: it's totally fine if a company is losing money. but then the question is "how many more years of runway are there with the hiring plan?", and if the answer is 6-12mo... well. A scramble will start where stuff like build times won't matter.
if the company is setting more and more money on fire, it's a dead company walking. you're hoping for an acquisition or exit before the house of cards collapses. in this scenario, instead of repurposing current hires to getting to profitability, a company that keeps hiring is compounding its risk. each new hire eats the runway that much faster and makes everyone's job that much more precarious.
folks are totally free to ignore whether their company is economically viable, and prioritize something like free drinks & CI b/c that makes their week better. but then they shouldn't be surprised when multiple rounds of layoffs happen every few months.
Note: it's totally fine if a company is losing money. but then the question is "how many more years of runway are there with the hiring plan?", and if the answer is 6-12mo... well. A scramble will start where stuff like build times won't matter.
> in this scenario, hiring a build engineer to fix CI becomes a reasonable thing to do: there's money, it's not a hard problem, and makes everyone else happier & more productive.
In my experience, not necessarily. After all, the company is already making money without CI engineer so the management doesn't have any incentive to recruit one. It's a stable situation but not really enjoyable one.
In my experience, not necessarily. After all, the company is already making money without CI engineer so the management doesn't have any incentive to recruit one. It's a stable situation but not really enjoyable one.
“Is this Position a backfill for someone that left? If so, why did they leave?”
> Too slow of a CI means that instead of submitting small, isolated commits people start aggregating many changes into a small number of mammoth commits because it is the only way to get things done.
I don’t understand the point here.
1. `git commit` and `git push` are two separate steps, you can commit often, but you can push once every few hours, assuming your computer won’t catch fire in the meantime.
2. If your CI builds every single commit pushed to a branch (instead of just building at every push), that’s a very weird CI config.
3. Where is the slowdown? Is it because your commit is waiting in a queue behind other commits?
I don’t understand the point here.
1. `git commit` and `git push` are two separate steps, you can commit often, but you can push once every few hours, assuming your computer won’t catch fire in the meantime.
2. If your CI builds every single commit pushed to a branch (instead of just building at every push), that’s a very weird CI config.
3. Where is the slowdown? Is it because your commit is waiting in a queue behind other commits?
The fundamental problem with slow CI is developer's own context switch.
If CI notifies me an hour later that my changes fail CI, I have might have to abandon my flow, sort out the failure and commit/push again. Then get back into whatever I was doing. This can be very taxing for developer's time and mental well being.
If CI notifies me an hour later that my changes fail CI, I have might have to abandon my flow, sort out the failure and commit/push again. Then get back into whatever I was doing. This can be very taxing for developer's time and mental well being.
I think they mean isolated PRs. Been there, done that.
Meaning, PRs are generally bad to require to do a build?
In my experience it is a good idea to try and keep code reviews and pull requests short and sweet. It’s much easier to review small concise code than mega commits, it’s much easier to catch mistakes in them, and being set up to iterate small changes quickly tends to result in faster velocity (as opposed to people trying to avoid reviewing the mammoth, scary block of code that might take a half hour of reading to just read it, rather than review it.)
Really large tech companies with truly massive codebases (especially monorepos) often need custom tooling to build things, so “ Being able to build the project on your own machine is pretty much mandatory because if you can't build locally then e.g. IDE autocompletions does not work because there is no working compile_commands.json.” isn’t always true.
Facebook, for example, uses a highly custom version of VS Code (was: atom) that talks to a server for each developer. The devbox contains the repo and is mostly prebuilt because trying to check out and compile a codebase that is easily 20 times bigger than a linux distro just isn’t feasible on a laptop.
So long as there is a well resourced dev productivity team in the company, whatever they use for a huge codebase is likely fine.
Facebook, for example, uses a highly custom version of VS Code (was: atom) that talks to a server for each developer. The devbox contains the repo and is mostly prebuilt because trying to check out and compile a codebase that is easily 20 times bigger than a linux distro just isn’t feasible on a laptop.
So long as there is a well resourced dev productivity team in the company, whatever they use for a huge codebase is likely fine.
This post should be exhibit A on why software engineering/dev managers get paid so well.
Things like CI times and build process strike me as opportunities. If they're bad, there's a spot you can contribute and make it better.
A core piece of that is figuring out if they're open to spending times on improvements like these, and figuring out why they haven't: recognition of a problem? Expertise to fix it? Constant time crunch? No prioritization input from dev team?
A question might be something along the lines of "As a team would you spend 3x once to save x time for every subsequent sprint/release after that? What's the last example of where you did this?" This applies to CI/build process, unit testing, other automated testing, deployments, etc.
A core piece of that is figuring out if they're open to spending times on improvements like these, and figuring out why they haven't: recognition of a problem? Expertise to fix it? Constant time crunch? No prioritization input from dev team?
A question might be something along the lines of "As a team would you spend 3x once to save x time for every subsequent sprint/release after that? What's the last example of where you did this?" This applies to CI/build process, unit testing, other automated testing, deployments, etc.
As someone who doesn’t work in IT, that question about admin rights is huge. I work in finance - is it common to not be given admin right to your pc as a developer? I always assumed you folks did but maybe the lockdown is just as excessive for you.
At the large tech company I work at, we get two machines- one for day to day dev work and one for sensitive tasks. I get full admin on the day to day dev box and can do all sorts of email and collaboration on it, but I can’t do certain administrative functions or access some types highly sensitive data. The admin box is severely locked down, uses a different identity, but lets me edit shared services and access sensitive data. It can be annoying, but it feels about the right level of paranoia to me.
It depends on who in IT.
IT is big and broad and depending on the company you can have all sorts of folks -- even developers -- who never have an actual need to change admin-level stuff on their own machines. Not everyone in IT is doing systems-level stuff that needs admin rights.
Having as few people in a company with admin rights to their machine is very helpful for securing machines. Sure, some will need it, but limiting it to only those with an actual need, really reduces risk.
IT is big and broad and depending on the company you can have all sorts of folks -- even developers -- who never have an actual need to change admin-level stuff on their own machines. Not everyone in IT is doing systems-level stuff that needs admin rights.
Having as few people in a company with admin rights to their machine is very helpful for securing machines. Sure, some will need it, but limiting it to only those with an actual need, really reduces risk.
And there's proactive and reactive approach to it as well.
With reactive, you elevate your rights when you feel the need to, and your actions are recorded and then maybe reviewed by someone. It's not much more annoying unless you need admin rights frequently (which should not be the case, really).
With proactive, you need a ticket and only then, maybe, you get to use admin mode, or someone else is going to do things for you, maybe correctly.
With reactive, you elevate your rights when you feel the need to, and your actions are recorded and then maybe reviewed by someone. It's not much more annoying unless you need admin rights frequently (which should not be the case, really).
With proactive, you need a ticket and only then, maybe, you get to use admin mode, or someone else is going to do things for you, maybe correctly.
Yep, exactly. Reactive is really not that bad, and most software to manage it can also have a preapproved whitelist of actions that automatically get elevated.
It definitely takes planning and management and monitoring, but it can be done, and it very much does help Enterprise-type management.
It definitely takes planning and management and monitoring, but it can be done, and it very much does help Enterprise-type management.
1. What happens in a day/week in the life of this job?
Generally interviewers cant think fast enough to lie convincingly in answer to this question, by giving you a rose-tinted fantasy. Here is where you hear that the _real_ duties dont match the job description they are handing out.
2. What did the last guy die of?
Similarly, throws interviewers (assuming this is not a newly created role). They will find it hard to deflect or lie convincingly under pressure. It doesn't matter what they say (to some extent) what matters is how they handle the question. Keep it breezy, smile, don’t be afraid of silence while they sweat.
Some of these questions are phrased as expensive compliance interrogations... as if they're coming from the kind of bureaucracy and authoritarianism that the questioning seeks to avoid.
I have had to answer a lot of these questions before, but not for a potential hire. These are the kinds of questions auditors tend to ask during due diligence of a software org (especially the “give me time estimates” type questions). Usually in an audit type setting these answers aren’t readily available because there are limitless ways to ask these questions and supporting data to request. An organization isn’t typically going to spend that level of effort to satisfy one obviously pretentious candidate.
Most of the questions are valid but first, it's unlikely you'll get honest answers and second I think most (maybe all?) employers would cut the interview short after the third or fourth question.
I always ask a direct question about ethics. Something like, "tell me about the kinds of ethical problems that this team is faced with and how you handle them." Good answers involve speaking up about the problem right away & not try to hide anything and being transparent with relevant entities. Bad answers are things like "there haven't been any ethical problems," because that most likely signals that ethical problems are being ignored or overlooked.
What kinds of ethical problems do teams suffer in your experience?
> Suppose the team needs to start a new web service like a private Gitlab, add new type of CI to the testing pipeline or something similar. Could you explain the exact steps needed to get it fully operational?
What does this question even mean? Like implementing a new CI service? Or creating a new ci/cd piepeline for the new application?
What does this question even mean? Like implementing a new CI service? Or creating a new ci/cd piepeline for the new application?
Just the first question gives me shivers. The end user device is an entry point into any organization, of extremely high risk. PAM solutions, with proper logging and time bound limits to what needs to be done as root, exist and should be leveraged. Not everybody is Google, for better or worse.
Full admin is a non-starter for regulatory reasons in some industries (e.g. finance). Also, at Google, developer laptops are essentially untrusted - all code lives in the monorepo target than being cloned locally, so there's nothing of much value on the device.
That's not true, what's a non-starter is giving developers direct access to production data and production systems.
You can do that without removing LOCAL admin rights.
You can do that without removing LOCAL admin rights.
Nope - even local admin is generally a non-starter as it can serve as a gateway to further attacks (e.g. install a keylogger, wait for a coworker to need to check email and offer to let them borrow your laptop, run pen test tools from with the network to probe for weaknesses). Banks actually have to prove to their regulators that unauthorized software can't be installed.
> Any other answer means that support requests take forever to get done and are a direct and massive drain on your productivity.
Timezones matter more than countries. If I am in London and support is in Dublin, this is usually better than being in NYC with support in SF.
Timezones matter more than countries. If I am in London and support is in Dublin, this is usually better than being in NYC with support in SF.
[deleted]
My go to is always "What are your most and least favorite parts about working here?"
I think that some of these questions are quite important. However, I think that all of them could be interpreted as “missing the forest for the trees” sort of questions. Therefore, I don’t tend to ask them in interviews.
If you do ask these questions, at what point in the interview process (or within a given interview) do you ask them?
If you do ask these questions, at what point in the interview process (or within a given interview) do you ask them?
[deleted]
i'd like to read the code our team is responsible for, can you give me a list of pointers to all of it?
[deleted]
Being slightly less snarky, this is a very prescriptive list that includes questions which, were I asked them as an interviewer, I'd consider red flags. "Does this team or any of the related teams have a person who actively rejects proposals to improve the code base?" is a BAD question to ask in an interview. What answer could an interviewer give? Yes? No? It depends? An example: a junior engineer comes in, says we should rewrite the server in kotlin, starts working on it, then is shot down by a senior engineer. Is the senior engineer "actively rejecting a proposal to improve the code base"? Arguably, yes. Are they wrong to do so? Again, arguable. It depends. Code health is a means to an end, not the end itself...