Ask HN: Questions to ask a company to know you don't want to work there?
97 コメント
I've given hundreds of interviews, and here's some that have gotten real-talk answers out of me (both good and bad):
* What's one thing you'd change about <company X>?
* Tell me about the last time you worked past 7pm.
* How surprised were you by your last performance review?
* When's the last time you referred a friend to <company X>?
* Tell me how the last incident you responded to went.
* Tell me about a time you were able to work on something you identified and selected.
* What question is always tough to answer as an interviewer at <company X>?
The one I liked asking as a candidate was: It's 2 years from now, and <company X> has failed. What happened?
I got some good real talk about that one, and some smoke and mirrors. It was a good baloney extractor.
I think an important thing is to ask interviewers to pick a concrete instance of a thing you're interested in, such as poor work/life balance, and talk about the most recent one. It's easy to say "oh, we have great work life balance," but that's different for everyone, and frankly it's just too easy to gloss over. Ask them why they worked late the last time they worked late.
For example, with your question:
When interviewing perspective employees, does the entire team participate in the interview process and make a hire / no hire decision as a team?
I'd instead ask:
Had you talked with the most recent person who joined your team before they were hired?
* What's one thing you'd change about <company X>?
* Tell me about the last time you worked past 7pm.
* How surprised were you by your last performance review?
* When's the last time you referred a friend to <company X>?
* Tell me how the last incident you responded to went.
* Tell me about a time you were able to work on something you identified and selected.
* What question is always tough to answer as an interviewer at <company X>?
The one I liked asking as a candidate was: It's 2 years from now, and <company X> has failed. What happened?
I got some good real talk about that one, and some smoke and mirrors. It was a good baloney extractor.
I think an important thing is to ask interviewers to pick a concrete instance of a thing you're interested in, such as poor work/life balance, and talk about the most recent one. It's easy to say "oh, we have great work life balance," but that's different for everyone, and frankly it's just too easy to gloss over. Ask them why they worked late the last time they worked late.
For example, with your question:
When interviewing perspective employees, does the entire team participate in the interview process and make a hire / no hire decision as a team?
I'd instead ask:
Had you talked with the most recent person who joined your team before they were hired?
This is a great take and a good set of questions. I totally agree on being more concrete and specific to get, at least, closer to the responses you are looking for. I feel like I have asked some more open ended questions, which can be good, but for finding specific info quickly (as time is limited in interviews), putting a sort of spin on those questions makes sense.
Do engineers have root on their workstations?
I think this is a proxy for a lot of culture. "Enterprise," bureaucracy, trust, social status of developers, corporate IT mindset vs. Silicon Valley mindset.
I work at a big company. We are public. We have groups that handle PCI data. We have groups that handle HIPAA data. We all have root on our Macbooks. So it is definitely possible, even as a Serious Business with compliance requirements, if you care enough about developer experience to make it happen.
I think this is a proxy for a lot of culture. "Enterprise," bureaucracy, trust, social status of developers, corporate IT mindset vs. Silicon Valley mindset.
I work at a big company. We are public. We have groups that handle PCI data. We have groups that handle HIPAA data. We all have root on our Macbooks. So it is definitely possible, even as a Serious Business with compliance requirements, if you care enough about developer experience to make it happen.
Cannot upvote this one enough, I once worked for a company where not only did you not have root, you had to remote desktop to a jump box, to remote desktop to your in-datacenter workstation (which so happened to be a standard image that every developer got so no deviation) They did this under the misguided notion that this limited the chance of software IP theft. Best part they wrote antiquated CBTware for college campuses.
A tangential question would be, if I need a piece of hardware or software what is the process from purchase procurement to it being installed on my machine? This can sniff out several red flags, from there is a lot of bureaucracy to get software on your machine, to we are the type of company that will pay a person a decent developers salary and then just let them sit there because we will not buy a $100/$500/$1000 tool to make them more productive.
A tangential question would be, if I need a piece of hardware or software what is the process from purchase procurement to it being installed on my machine? This can sniff out several red flags, from there is a lot of bureaucracy to get software on your machine, to we are the type of company that will pay a person a decent developers salary and then just let them sit there because we will not buy a $100/$500/$1000 tool to make them more productive.
Yes. I am not sure I have ran into this problem in a super major way before, but I remember not being able to do some things at previous gigs. I could not imagine having to ask to install software or config to just get my job done. In the past, we have also dealt with HIPPA data, and it was nice to be trusted with that as well.
I work at a fintech company, and you have heard of us.
Be forewarned. My company is "woke" and gives you `sudo` access on your mac. However, this mac is useless. The firewall rules prevent us from running a local kubernetes cluster, and most open source software is iffy on it because of JAMF. `root` is not enough. I want control over my workstation. I refuse to give it up just because IT is worried about some people who watch porn on office laptops. I am not those people, stop penalizing power users just because others flaunt your rules or are unable to grok them.
Edit: I'd kill to join a company that says BYOD and you can use Linux (any flavour).
Edit: I'd kill to join a company that says BYOD and you can use Linux (any flavour).
I'm curious to hear how JAMF makes open source difficult. As far as I can tell it mostly just allows provisioning and preventing you from running certain apps, so it's about the config you put in place and not JAMF itself.
Yeah we have JAMF and it’s not intrusive. Crowdstrike causes performance problems sometimes.
Awesome question to ask.
Anecdotally in the financial industry, the corporate IT mindset is rampant even at supposedly “cutting-edge” algo trading shops. IT draws very bold boundary lines (no root access, unable to use new third-party libraries without a song and dance with InfoSec, locked down Windows machines that must SSH into Linux hosts for dev work, etc) and it sets the entire engineering culture.
This question will tell you about the culture as a whole, beyond how smooth/frustrating your developer experience will be. A good gauge for how modern or stale the stack is, whether continuous deployment exists, how top—down or bottom-up the culture is, etc.
Anecdotally in the financial industry, the corporate IT mindset is rampant even at supposedly “cutting-edge” algo trading shops. IT draws very bold boundary lines (no root access, unable to use new third-party libraries without a song and dance with InfoSec, locked down Windows machines that must SSH into Linux hosts for dev work, etc) and it sets the entire engineering culture.
This question will tell you about the culture as a whole, beyond how smooth/frustrating your developer experience will be. A good gauge for how modern or stale the stack is, whether continuous deployment exists, how top—down or bottom-up the culture is, etc.
Great question. Cuts to the core and answers so many other questions without being vague like "what's the culture like? Do you feel empowered?".
I've gotten lots of mileage out of "How do big decisions get made at this company?" And you want to turn it into a conversation - probe their answers, ask for examples, etc.
You learn about how each interviewer experiences the decision-making process. How are the decisions communicated? Who decides? Do initiatives steamroll people and teams? Are people able to filter up suggestions or start their own initiatives? Can decisions get made team-by-team, or do they have to be made for the whole company? Do they change their mind when they get new evidence? Do people change their mind too much? Do they have trouble saying "no"? If they want to tell you "no," do they actually say it? Are they too afraid to make decisions that can change the culture, and just kinda drift?
As an IC engineer, this is what I have the least control over (and can find the most frustrating). So I want to hear exactly how broad change happens. It helps me imagine how it'll feel to spend four years in the environment.
This is the kind of question that you need to ask everyone. You won't get a good answer from one person. You want to ask a few people and see if their stories line up.
You learn about how each interviewer experiences the decision-making process. How are the decisions communicated? Who decides? Do initiatives steamroll people and teams? Are people able to filter up suggestions or start their own initiatives? Can decisions get made team-by-team, or do they have to be made for the whole company? Do they change their mind when they get new evidence? Do people change their mind too much? Do they have trouble saying "no"? If they want to tell you "no," do they actually say it? Are they too afraid to make decisions that can change the culture, and just kinda drift?
As an IC engineer, this is what I have the least control over (and can find the most frustrating). So I want to hear exactly how broad change happens. It helps me imagine how it'll feel to spend four years in the environment.
This is the kind of question that you need to ask everyone. You won't get a good answer from one person. You want to ask a few people and see if their stories line up.
This is great. I’d also like to ask about how fast the decisions are made.
One good way to move people out of platitudes is that if, say, an IC says that there’s no problem with initiatives getting accepted more broadly - ask them for a specific example they were involved with.
One good way to move people out of platitudes is that if, say, an IC says that there’s no problem with initiatives getting accepted more broadly - ask them for a specific example they were involved with.
I’ve found Culture Queries to be a good resource for this. Helped me avoid questions that led to boilerplate answers (“do you have work/life balance?” -> “How responsive are people to emails/Slack over the weekends and after 6pm?”).
https://www.keyvalues.com/culture-queries
https://www.keyvalues.com/culture-queries
Yes. Just asking about work life balance always tends to get boilerplate answers ("Of course we do!"). This is a great way to get that same info without making them produce those selling point ones.
That and asking a specific question let's you find out what they actually consider W/L balance to be - i.e. I assume a group of 25 year olds probably see their jobs differently to people twice that age with kids (I'm reminded of Lex Fridman asking Jim Keller what his greatest achievement was, and him basically saying I have kids or something to that effect)
I've found "How centralized is decision making in the company?" to be illuminating. The specific answer doesn't matter, but it probably hasn't been asked before and the answerer will have to think about the answer. If they give an easy, enthusiastic answer, that is a good sign - if they give a slow convoluted corporate speak answer that is a bad sign.
This is a great question I hadn't thought of before.
As I think about it, it might not even matter much what the answer is - outside of personal preference, of course. Clear decision-makers can be good. Having a lot of autonomy can be good. Not being sure if you're allowed to do X or not, or even who to ask about it, never is.
As I think about it, it might not even matter much what the answer is - outside of personal preference, of course. Clear decision-makers can be good. Having a lot of autonomy can be good. Not being sure if you're allowed to do X or not, or even who to ask about it, never is.
> The specific answer doesn't matter...
I disagree with some nuance, but generally agree.
For large, multi-geography firms, I want to know and work WHERE the central pockets of power are located.
I disagree with some nuance, but generally agree.
For large, multi-geography firms, I want to know and work WHERE the central pockets of power are located.
This became at a game at one of my old workplaces.
The company was in the business of buying up smaller companies, and naturally every manager wanted to stay a manager. So there was like 8 layers of management.
If we asked for money, time or resources we would take guesses as to how far up the chain it would get before it got rejected.
And it SO often got rejected, because a random manager was feeling less important and wanted to assert their power they used to have.
The company was in the business of buying up smaller companies, and naturally every manager wanted to stay a manager. So there was like 8 layers of management.
If we asked for money, time or resources we would take guesses as to how far up the chain it would get before it got rejected.
And it SO often got rejected, because a random manager was feeling less important and wanted to assert their power they used to have.
Yes. I think this is a great one. Teams should make decisions together. Every time there has been grumblings about a decision made at places I've worked, it has been made without input. Sometimes people will not like something regardless, but at least they would have got a chance to let their voice be heard if decision making is shared.
does the entire team participate in the interview process and make a hire / no hire decision as a team?
Is this a good thing or a bad thing? I've heard people at Bloomberg in London complain about this in the past; people have said to me they've found good candidates but because one person on the team said no, it's a no hire, and they ended up hiring someone whose distinguishing feature is "nobody actively disliked them as a candidate".
I guess it's a good thing if nobody has an individual veto; I understand in the case above anyone on the team could individually veto.
Is this a good thing or a bad thing? I've heard people at Bloomberg in London complain about this in the past; people have said to me they've found good candidates but because one person on the team said no, it's a no hire, and they ended up hiring someone whose distinguishing feature is "nobody actively disliked them as a candidate".
I guess it's a good thing if nobody has an individual veto; I understand in the case above anyone on the team could individually veto.
I think there is value in getting feedback from the team, but ultimately it should be the hiring managers decision (modulo input from HR to make sure that people aren't introducing discriminatory practices).
In a previous role we followed this, and for most hires we waited until we found a candidate that had the right skills and the right fit, however there was one prominent candidate that several folks on the team rejected.
This candidate didn't interview particularly well with me personally, but had stellar technical interviews with two people on the team, and came with impeccable references from two folks in the team she would be working with. Because of that I circled back with the folks who rejected her, and in chatting with them, discovered they felt she wasn't a good fit for the team, but would be able to do the work. I spoke to my HR folks, and my own manager, and we agreed to overrule the team and hire her.
Straight up, best decision on hiring I have ever made.
In a previous role we followed this, and for most hires we waited until we found a candidate that had the right skills and the right fit, however there was one prominent candidate that several folks on the team rejected.
This candidate didn't interview particularly well with me personally, but had stellar technical interviews with two people on the team, and came with impeccable references from two folks in the team she would be working with. Because of that I circled back with the folks who rejected her, and in chatting with them, discovered they felt she wasn't a good fit for the team, but would be able to do the work. I spoke to my HR folks, and my own manager, and we agreed to overrule the team and hire her.
Straight up, best decision on hiring I have ever made.
I think vetos only work when everyone is being a team player with them. Sure there are going to be cases where a candidate does something particularly offensive that might warrant an actual veto, but it's almost always better if the team come to a consensus together based on everyone's input.
I agree. There really needs to be a team first sort of culture to produce the best outcome of giving individual members more say. It is probably hard to ensure that always happens, but I think if you hire people who generally want the same things and work hard amoung other things, then you'll get there most of the time.
The person who owns the results and has to clean up bad outcomes (ie fire someone) needs to have autonomy to make those choices. He or she would be silly to not take the team's thoughts into account: why have someone on an interview loop if you aren't going to listen to the results. But nonetheless, the manager owns the outcome and so owns the hire choice.
I think this is generally a good thing. Teams should make decisions together, but I could see the above point as a downside of that if taken to its max. I think that decisions should be made generally as a team, but there probably should be some extra emphasis on key decision makers that are the leaders of the team to allow them to make the perceived best decision even if one or perhaps more people give a no hire. If there is also some sort of tie, then someone has to be the tie-breaker.
It is good when someone from the team is in the interview loop. Everyone? We’ve accomplished this in the past with group lunches. It is a pain to organize in larger companies. I agree, it is the hiring manager who should have the final say. We have one caveat: we have a “bar raiser” interviewer who is not on the team who ensures we are not just filling seats.
Is this equivalent to hiring-by-comittee, as practiced by FAAN[A-Z]*G?
Not necessarily. I think sometimes those committees are composed of people who never will work with a perspective employee. That isn't bad, but I think a team should have its on sub-culture and be able to make decisions for itself most of the time. I really only have experience with smaller? teams 5 - 10 people.
The risk with that is, that you create a lot of island and switching between teams becomes difficult. Also, bias tends to crank up if it gets personal. (you literally see people judging sense of humor of the candidates, if they know they'll work with them closely). In general I think it's best to interview not knowing if the candidate will end up in your team/
I always ask, what are some things that can be improved in this company?
Flipping the "what are your weaknesses?" back at them. You have weaknesses and so do they. If you can accept these "flaws" then you're one step further in the right direction. Or if they give you a bunch of nonsense, you know there is a bad culture hiding under there.
Flipping the "what are your weaknesses?" back at them. You have weaknesses and so do they. If you can accept these "flaws" then you're one step further in the right direction. Or if they give you a bunch of nonsense, you know there is a bad culture hiding under there.
I agree. Usually, I tend to think that things can only really be improved if there is a culture that allows it. I can't count the number of times that someone had legit improvements, but they just stall after some initial effort as real change isn't really embraced.
Can I talk with the staff I will be working with. It is not enough that they want you, and feel they can work with you, you also need to feel you can work with them. When talking w the staff, discuss what a typical day is like. What are their frustrations and joys. My last question is usually 'So why have you not moved on to something better?'
That's a good one. Interesting perspective as a lot of companies (in my area at least), you more than likely will not meet who you are actually working with until you start.
I'd hope you'd be being interviewed by those staff.
Sometimes I had, often it was just supervisor, manager, team lead. A couple of times it was a panel, which included co-workers, but in a panel you cannot expect to hear their true feelings. One on one with co-workers is best.
Best is if you have a friend already working there who can give you the low down.
One job I ended up not interviewing at, was because of their glassdoor postings. Those in most departments loved the place, but all of the IT posting were how miserable it was. Dodged that bullet.
Best is if you have a friend already working there who can give you the low down.
One job I ended up not interviewing at, was because of their glassdoor postings. Those in most departments loved the place, but all of the IT posting were how miserable it was. Dodged that bullet.
I had two companies reach out last year before finding current role that wanted me to take three coding tests before even talking to the recruiter/gatekeeper.
Noped out of both.
Noped out of both.
Ask about on-call expectations.
How often do you go on-call. Does everyone participate. How is the documentation handled for resolutions. How often are there problems that you would get called for.
These tell me a good deal about how management prioritizes things, if they value creating stable systems with good documentation, and if they treat everyone equally.
How often do you go on-call. Does everyone participate. How is the documentation handled for resolutions. How often are there problems that you would get called for.
These tell me a good deal about how management prioritizes things, if they value creating stable systems with good documentation, and if they treat everyone equally.
Clarifying what the duties of an On-Call person are supposed to be would be helpful, too.
Our "on-call" engineer was originally only supposed to handle system-down emergencies, but more and more stuff has continued to pile onto their realm of responsibilities ("Oh, this thing is supposed to happen at 4 AM that no one wants to do? The on-call engineer can handle that!"), to the point that it now feels like an unpaid overtime shift.
Our "on-call" engineer was originally only supposed to handle system-down emergencies, but more and more stuff has continued to pile onto their realm of responsibilities ("Oh, this thing is supposed to happen at 4 AM that no one wants to do? The on-call engineer can handle that!"), to the point that it now feels like an unpaid overtime shift.
Assuming you're from the US, how common is unpaid on-call there? Why would anyone even accept unpaid on-call?
Doing on-call is directly a no-go for me.
Unless a boat will sink, a plane will fall out of the sky, an unstable chemical will detonate or someone will die or lose a limb, there is nothing in the software world that necessitated me being on call. Oh the systems are down and we are loosing billions of dollars, ok share some of those billions and you will have people lined up to be on call. Tell me it's part of my regular salary and I am nope'ing on to the next opportunity. I am totally in agreement with you on this one. If I am attached to a phone that can disrupt my life at any moment I expect compensation for every hour I am attached to that phone, whether it rings or not, it is surprising how many companies think that is an outlandish expectation, but don't bat an eye at the fact that being on call literally robs a person of their free time and don't see that doing that without further compensation is not an outlandish request.
Other types of salaried jobs with on-call expectations actually pay overtime. It would be great if software did too.
100% agree with these comments. I will never do unpaid on-call, a gas engineer is paid for being on-call, software shouldn't be any different. Its most likely because their are many people in software who will work on call for free, I see it first hand at my current company.
Stay away from companies who don't let you talk to the lowest-ranking members of the team.
Ideally you'd get to talk to people who used to work there, though it's hard to see how that would work.
I know back in olden times I'd always look at the "Help Wanted" ads, and would note that certain companies appeared to have constant employee turnover. I took that as a bad sign.
Probably not as valuable a metric if the company is growing rapidly. Also people tend to job hop a lot more nowadays.
I know back in olden times I'd always look at the "Help Wanted" ads, and would note that certain companies appeared to have constant employee turnover. I took that as a bad sign.
Probably not as valuable a metric if the company is growing rapidly. Also people tend to job hop a lot more nowadays.
I totally agree. Their perspective and thoughts also matter. This kinda goes along with the whole "Do they allow their entire team in interviews".
Ask about how changes make it to production / shipped product, and how long the process takes / what are common exceptions to the process. Lots of people have pretty strong opinions about that kind of stuff; I'd need a lot of incentive to work somewhere that's far from my ideal process, but others would need a lot of incentive to work with my ideal process.
I started asking these:
- What's the roadmap for this year? This gives me a lot of insight on what I could be working on, and also if the company is a bit clueless about their direction.
- What would I do in the position I'm being interviewed for? This completes the picture, similar to the previous one, but different perspective.
- What's the roadmap for this year? This gives me a lot of insight on what I could be working on, and also if the company is a bit clueless about their direction.
- What would I do in the position I'm being interviewed for? This completes the picture, similar to the previous one, but different perspective.
Let's say I'm working on a project and am blocked by technical issues that I don't understand. What do I do next?
What is the channel for client feedback to reach the dev team? Can you give me an example of how this has worked in the past?
If I'm working on a feature and discover technical debt that will make it more difficult to implement, how do I decide whether to focus on that debt or the feature? Can you give an example?
The reason interviewers like to ask for examples is that it's easy to bullshit when speaking abstractly, but people are less likely to lie to your face. Use that to your advantage
What is the channel for client feedback to reach the dev team? Can you give me an example of how this has worked in the past?
If I'm working on a feature and discover technical debt that will make it more difficult to implement, how do I decide whether to focus on that debt or the feature? Can you give an example?
The reason interviewers like to ask for examples is that it's easy to bullshit when speaking abstractly, but people are less likely to lie to your face. Use that to your advantage
Yes. I think this is especially important if you are a more senior person or work more independently than a lot of product companies.
[deleted]
How supportive is the company of unionization efforts?
Here's another one:
Do employees actively try to recruit their friends and people they respect in their industry for reasons besides a referral bonus?
I think a good tech one that is a bit opinionated is:
Does a project(s) build, and run (fully, without problems) in 5 or less steps?
I've been working this one out in my head, but I think that the above is generally a good indication of the quality of the code / project docs and thoughtfulness with on-boarding and making projects that people want to work on.
Questions about tests. I have found consistently that when an interviewer does not know what the test coverage of their codebase is, more likely than not they don't care about such trivialities.
No matter how respectable the company might look on the outside, the codebase is an incorrigible mess built by cowboys and they will expect you to maintain it.
No matter how respectable the company might look on the outside, the codebase is an incorrigible mess built by cowboys and they will expect you to maintain it.
I'm going to just say that making a codebase testable increases the complexity by a couple of orders of magnitude. Certainly it's great for some things. For other things it's a net negative.
Test is a small part of the whole picture. They might have lots of test but the system might still suck.
1. "What do you like about <company X>?"
By far, I found this to be most useful question to ask an interviewer. It tells what is the company doing well, and what things does the interviewer value. I have got various answers here.
- Some people say they like the autonomy given to them
- Some like the work enviornment
- Some like the technical challenges
- Some care about the impact the company is making
- Some like the money (not a bad thing, honestly)
For each answer you can ask for follow ups and examples. If they give a fluff answer like "I like the fast paced enviornment", its a red flag. If they have difficulty answering the question, its a red flag.
2. "What happens when something goes wrong?"
This is to know how the organization handles failure, also if you ask examples it tells you what does the organization defines as failure. Ideally you want an organization which has a no blame culture and which handles failures gracefully. Also this is the place you want to ask about on-calls.
By far, I found this to be most useful question to ask an interviewer. It tells what is the company doing well, and what things does the interviewer value. I have got various answers here.
- Some people say they like the autonomy given to them
- Some like the work enviornment
- Some like the technical challenges
- Some care about the impact the company is making
- Some like the money (not a bad thing, honestly)
For each answer you can ask for follow ups and examples. If they give a fluff answer like "I like the fast paced enviornment", its a red flag. If they have difficulty answering the question, its a red flag.
2. "What happens when something goes wrong?"
This is to know how the organization handles failure, also if you ask examples it tells you what does the organization defines as failure. Ideally you want an organization which has a no blame culture and which handles failures gracefully. Also this is the place you want to ask about on-calls.
This is assuming, your interviewer will be your teammate after joining the company.
As a JavaScript developer I tire of working around mental laziness and complacency. Here are my no bullshit questions:
Has the team ever produced a product without Angular, React, or similar MV*?
Does the team find state management challenging?
Do you conduct end to end test automation, including DOM interaction in the browser?
How many dependencies does your team require, ballpark, to perform basic simple automation on the terminal with Node (simple count of packages in the flattened node_modules folder)?
How up to date is your internal documentation?
What is the average timeframe for the team to move from receipt of business requirements to business approval of the completed work?
Are the business requirements design by committee or is there a single bus driver?
Which is a higher priority for the team: framework choice, available tooling, or accessibility?
Is there performance testing of the UI code?
By what metric(s), on paper, do you rate developer competence?
Has the team ever produced a product without Angular, React, or similar MV*?
Does the team find state management challenging?
Do you conduct end to end test automation, including DOM interaction in the browser?
How many dependencies does your team require, ballpark, to perform basic simple automation on the terminal with Node (simple count of packages in the flattened node_modules folder)?
How up to date is your internal documentation?
What is the average timeframe for the team to move from receipt of business requirements to business approval of the completed work?
Are the business requirements design by committee or is there a single bus driver?
Which is a higher priority for the team: framework choice, available tooling, or accessibility?
Is there performance testing of the UI code?
By what metric(s), on paper, do you rate developer competence?
Is it a new position or are you replacing someone? If the former, are there other people being hired and what's the plan for onboarding all those people. If the latter, what's the churn rate.
It doesn't necessarily raise a red flag, but it tells you a lot about the dynamic of the team/company.
It doesn't necessarily raise a red flag, but it tells you a lot about the dynamic of the team/company.
The churn rate is an effective question. In places with revolving door cultures interviewers get rather uncomfortable when asked such a question.
Are you happy to work here?
Not asking if they're happy with their life/job/etc, but whether or not they find value in the work they do. What the nature of that value is should be in the answer. And the answer will invariably touch upon a lot more than job satisfaction, so you don't have to ask so many questions if your time is limited. Doesn't always work on the phone (I find people are often guarded and overcompensating), but in person this question can be disarming and quite revelatory.
Not asking if they're happy with their life/job/etc, but whether or not they find value in the work they do. What the nature of that value is should be in the answer. And the answer will invariably touch upon a lot more than job satisfaction, so you don't have to ask so many questions if your time is limited. Doesn't always work on the phone (I find people are often guarded and overcompensating), but in person this question can be disarming and quite revelatory.
I always ask how much overtime is paid and in what form, it usually allows me to learn _A_LOT_ about company culture and work-life balance just looking at how defensive they sound.
I understand in the US it is an odd question because for some reason you have not a max amount of hours per week specified in the contract.
I understand in the US it is an odd question because for some reason you have not a max amount of hours per week specified in the contract.
Yes. It is probably a rare thing, but some companies that I know of actually pay overtime willingly (to a degree) to get more good work done. I think the tradition thoughts that a lot of companies have that overtime is the worst thing. Overtime isn't bad, but you should compensate your people accordingly.
Most work in the US, at least in my experience, is "at-will" and salaried. At-will means that employees can quit at any time for any reason and employers can fire employees at any time for any reason (except certain things like race, religion, etc). Salaried means you get paid $X per year and the amount you work depends on the company; could be 35h/week, could be 80h/week, but it doesn't change how much you get paid.
I've found this repo to have a lot of useful questions, obviously you have to tailor based on what you value most. https://gitlab.com/doctorj/interview-questions
“If I were to come by the office on a Wednesday at 8pm, how many people would still be at their desk?” Any answer other than “oh boy, hopefully zero!” then run. If they say “maybe a few, but they do it because they want to”, run even faster
Did they shut down during the start of the pandemic. Were employees paid if so?
“What are your team/company goals?”
If they don’t have any you will probably be miserable as it is hard to set goals for yourself or truly work toward a common objective, especially across an entire company.
No kidding. I feel like this happens a lot. It is nice to have both individual and team goals and hopefully they also align in a few ways.
What type of firefights have you had to deal with? How often do they occur? What did you do to make sure your last firefight never happens again?
What's the biggest mistake you've made on the job, and how did your team/management respond to it?
Another one that I like to ask product companies is if they use their own products and like them!
...if you find out after you started that the company is not for you, how long do you stay?
how often do you do standups?
Grab a drink from the fridge.
If it's a vending machine or the interviewer tells you it's an honor system, you are at the wrong place.
EDIT : Why the downvotes?
If it's a vending machine or the interviewer tells you it's an honor system, you are at the wrong place.
EDIT : Why the downvotes?
I will ask something like these.
Do you provide free snacks for those who work late hours in this company ? Is there referral bonus ?
Yes to anyone of those question is a red flag.
Do you provide free snacks for those who work late hours in this company ? Is there referral bonus ?
Yes to anyone of those question is a red flag.
Every place I've ever worked has offered a referral bonus. How is that a red flag?
Potentially incentivizes rushing someone into the company because you'll be cut a check. Not because that person is going to be a great fit.
I see the potential, but if they’re not you’ll damage your reputation and you won’t help your work either. Of course, if you don’t care, they made a hiring error in getting you, and it’s metastasizing. Which could happen.
It’s way cheaper for them than the external recruiter fee which has the same incentive problem too.
It’s way cheaper for them than the external recruiter fee which has the same incentive problem too.
Yeah, one of the best companies I worked for had a referral payout. It was primarily because they were growing so rapidly and were having trouble finding good people.
The referral only got paid out after the person passes the 3 month probation period.
The referral only got paid out after the person passes the 3 month probation period.
it’s 6 months at my work
[deleted]
Ask about skip-level one-on-ones, open door policies, watch their facial expressions when you ask. If they look away, make note of what direction their eyes move. You can read up on what various facial expressions may signify. [1]
[1] - https://www.nature.com/articles/srep22049
[1] - https://www.nature.com/articles/srep22049
If you're not trained and experienced in this sort of thing, with positive results, I would strongly advise against trying to make decisions in a job interview based on what directions you think the interviewer's eyes moved.
I could see that. I guess a better way to say it is just to pay attention to their overall body language.
I've actually never had a skip-level one-on-one. What do you think you get the most out of them?
It is a test of the level of trust of managers in a company. If you are working for a micromanager or a lesser experienced manager, they would never imagine you talking to their boss, ever. If anything they might even threaten to fire you if you "go above them".
I could see that. I think there should be routine talking up and down the chain of command. I once worked at a place where most people actually kind of feared talking to a VP. I always thought it was very strange.
I'll go first: When interviewing perspective employees, does the entire team participate in the interview process and make a hire / no hire decision as a team?