I'm looking for all around stuff, tech questions, process, business etc.<p>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?
I've given hundreds of interviews, and here's some that have gotten real-talk answers out of me (both good and bad):<p>* What's one thing you'd change about <company X>?<p>* Tell me about the last time you worked past 7pm.<p>* How surprised were you by your last performance review?<p>* When's the last time you referred a friend to <company X>?<p>* Tell me how the last incident you responded to went.<p>* Tell me about a time you were able to work on something you identified and selected.<p>* What question is always tough to answer as an interviewer at <company X>?<p>The one I liked asking as a candidate was:
It's 2 years from now, and <company X> has failed. What happened?<p>I got some good real talk about that one, and some smoke and mirrors. It was a good baloney extractor.<p>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.<p>For example, with your question:<p>When interviewing perspective employees, does the entire team participate in the interview process and make a hire / no hire decision as a team?<p>I'd instead ask:<p>Had you talked with the most recent person who joined your team before they were hired?
Do engineers have root on their workstations?<p>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.<p>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'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.<p>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?<p>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.<p>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.
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?”).<p><a href="https://www.keyvalues.com/culture-queries" rel="nofollow">https://www.keyvalues.com/culture-queries</a>
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.
<i>does the entire team participate in the interview process and make a hire / no hire decision as a team?</i><p>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".<p>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 always ask, what are some things that can be improved in this company?<p>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.
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?'
Ask about on-call expectations.<p>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.<p>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.
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:<p>- 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.<p>- 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?<p>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?<p>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?<p>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
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?
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.<p>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.
1. "What do you like about <company X>?"<p>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.<p>- Some people say they like the autonomy given to them<p>- Some like the work enviornment<p>- Some like the technical challenges<p>- Some care about the impact the company is making<p>- Some like the money (not a bad thing, honestly)<p>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.<p>2. "What happens when something goes wrong?"<p>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.
As a JavaScript developer I tire of working around mental laziness and complacency. Here are my no bullshit questions:<p>Has the team ever produced a product without Angular, React, or similar MV*?<p>Does the team find state management challenging?<p>Do you conduct end to end test automation, including DOM interaction in the browser?<p>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)?<p>How up to date is your internal documentation?<p>What is the average timeframe for the team to move from receipt of business requirements to business approval of the completed work?<p>Are the business requirements design by committee or is there a single bus driver?<p>Which is a higher priority for the team: framework choice, available tooling, or accessibility?<p>Is there performance testing of the UI code?<p>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.<p>It doesn't necessarily raise a red flag, but it tells you a lot about the dynamic of the team/company.
Are you happy to work here?<p>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.
Q: As a senior software engineer, do I have to do paid "on-calls"?<p>A: Yes. Every team rotates on-calls among their senior software engineers.<p>Then I just leave saying "thank you for your time".
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.<p>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've found this repo to have a lot of useful questions, obviously you have to tailor based on what you value most. <a href="https://gitlab.com/doctorj/interview-questions" rel="nofollow">https://gitlab.com/doctorj/interview-questions</a>
“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
“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.
Grab a drink from the fridge.<p>If it's a vending machine or the interviewer tells you it's an honor system, you are at the wrong place.<p>EDIT : Why the downvotes?
I will ask something like these.<p>Do you provide free snacks for those who work late hours in this company ?
Is there referral bonus ?<p>Yes to anyone of those question is a red flag.
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]<p>[1] - <a href="https://www.nature.com/articles/srep22049" rel="nofollow">https://www.nature.com/articles/srep22049</a>