When I was more junior, one of my favourite questions to ask a company was "Can you give me a day in the life, or a week in the life of this job/role?".<p>The reason being, job descriptions are very often a fantasy. An aspiration. What the company wishes its people did, not what they are actually doing. Often the reality is much less attractive than the job description you think you are interviewing for. Faced with this "week in the life of..." question, very few interviewers can conjure up a detailed fantasy of fictional projects concluded, smooth running operations, and friction-free collaboration on the spot. They are more likely to say what the person will _actually_ be doing. This is typically a lot less attractive. Only then you can really start "talking turkey" for the remaining minutes.
Treating the interview as two-way is good, and how it should be. A couple points:<p>> <i>When people struggle to answer it you still reap the rewards of letting them know that you’re not just looking for a job, you care about being successful at their company.</i><p>If you publicize that in a Medium post targeting HN-like audience, aren't you just increasing the number of people will ask that question just to "reap the rewards" of signalling (falsely) something they think is positive?<p>> <i>Ask questions like: “How is the company responding to challenges from disruptors like X and Y in this space?” or “What are your thoughts on potential regulation?”</i><p>If you've been having a pretty candid conversation, these questions can trigger rehearsed public/investor-facing talking point answers, which is fine, but might also knock the person back into a less-candid mode.
The three questions:<p>“There’s an IC sitting out there who just had an amazing idea for a new feature/product. What happens?”<p>“Tell me about your last major migration. How long did it take and how long did you say it was going to take before you started?”<p>“Let’s say I’m the person you hire. 6 months have gone by, what’s different?”
Last time I was on the interviewing side I used to ask engineers something like "If you weren't interviewing me today, what would you be doing instead?" to try and get a better idea of this person's day-to-day. Or sometimes phrased as what they were doing earlier in the day / planned to do later in the day. Got some good details of the actual work being done from it, e.g. once it was just lots of bug fixing / test writing / test fixing and no new features.<p>On the interviewer side, I usually left 5-10 mins for such questions for them to ask me. (I always think it'd be funny if more time was scheduled for candidates to hit interviewers with their favorite "can you actually code" style questions, like is the team they're expecting to join even any good...) It's a bit disappointing when the candidate has nothing to ask, asking something is better than nothing... A type of useful question I got and used to ask as well was simply why I myself had joined the company/how long I'd been there. Sometimes you get a sort of cookie-cutter HR style answer, but sometimes you get something more revealing (in a good or bad way). Engineers tend to be (often too) honest.
“There’s an IC sitting out there who just had an amazing idea for a new feature/product. What happens?”<p>in a company with more than 10 staff, they should talk to a product manager, sorry. you can't build a sustainable company by adding new features willy nilly whenever some dev has a Great Idea.
I usually try to ask these<p>What are the bad things about this job?<p>What's the average tenure on the team, how many people have left the team recently and why?<p>How does this team & company compare with other places you've worked?<p>(second or third round) How many other people are being interviewed and how do I compare?
i don't care about most of the questions being raised here.<p>a slow process to get changes accepted, long build cycles, bad legacy code, irrational business decisions, whatever.<p>what i care about is how the team works together. how supportive the people i get to interact with are. how i can get help when i am stuck. if i can ask dumb questions without repercussions. if people compete or cooperate to solve problems. if they share code ownership. both on the individual and on the team level and beyond etc.<p>if i am in a team that works well together with a supportive manager or leader then i don't care what we are working on. as long as our superiors feel that we are contributing something, even if the end result is nonsense, i'd rather do that than suffer people who are unfriendly or uncooperative or bother each other in other ways, while working on something that saves human lives.
> Let’s say I’m the person you hire. 6 months have gone by, what’s different?<p>What's wrong with "you’ll be here and doing the job"? The point of hiring someone is that there is a job to do, if you are hired and get to stay for 6 months, then you will be doing the job, if someone else is hired, he will be doing the job instead, if no one is hired, and there is no internal restructuration, then the job will not be done.<p>For the details, just look at the job offer. I don't understand the point of asking this, even after reading the article. Why not just ask about the job directly, instead of resorting to some cryptic roundabout question?
Interviewing the Interviewer: Questions to Uncover a Company's True Culture<p><a href="https://news.ycombinator.com/item?id=41243278">https://news.ycombinator.com/item?id=41243278</a><p>2 weeks ago, 221 comments
Not sure the author realized this, but there's an interesting contradiction here.<p>> In hiring, we standardize questions to help mitigate bias and make more accurate comparisons across a group of candidates.<p>> The people on the ground, close to the problem are often your best bet, but organizations find it difficult to handle anything they can’t standardize and normalize.<p>Standardizing is more fair, but at the cost (or benefit) of minimizing interesting outcomes.
> “There’s an IC sitting out there who just had an amazing idea for a new feature/product. What happens?”<p>Man, I bet my answer and my VP's answer to that are gonna be rather different.
This is one of those few “social engineering” pay-walled click-bait articles that I’m very happy IS pay-walled to reduce its cogent thought pollution.<p>This is not wisdom. This is over-fitting industry/era/role-specific individual experience to generic candidate advice.<p>Do none of these things.
1. The offer is good. I was aiming at 12% more, though. Can we work it out?<p>2. Is on call mandatory?<p>3. Are there any plans to move away from 100% remote work?
A lot of times the questions I ask are literally about the job, since interviewers are so focused on trying to ask candidates things that they forget that it's a matching game, and the job has to be explained too.<p>I'll try to "turn the table" early on in the interview. Ask what they are building, ask questions, say how you might design it (or have designed it in the past). All the fluffy stuff people can lie about, but getting into a good technical discussion can I think prove that both people are on the same level and can work well together.<p>The other question I like to ask is "why are you hiring for this job?" This can be a real teller. Is it a group expanding due to new responsibilities? Did the last person leave in a huff? Figuring that out can really help explain the org you're about to go into.
The first question is absolutely spot on, but I don't like the second two. Those last two tend to generate answers that are purely administrative and without substance, such as: <i>We will perform your first mid-year review!</i>. WTF, so what?<p>Here are some better questions (repeating the first one from the article first):<p>1. <i>“There’s an IC sitting out there who just had an amazing idea for a new feature/product. What happens?”</i><p>That question is solid because it indicates they actually give a damn about employee contributions beyond what they populate on a Jira board. Its a telling sign if they are hostile to initiative.<p>2. <i>"How do you measure things related to your product and what do you measure?"</i><p>The answer to that questions addresses multiple concerns. Everybody claims to value product quality, but most places I have worked at really don't give a shit, because its just too much effort. If they aren't measuring things they have no idea how slow their product is, what kind of user engagement they achieve, their defect trajectory, and on and on and on. On a more primitive level if they aren't currently measuring things it also provides an indication of whether or not they actually want to, but maybe don't know how. The point here is you can use questions like that to cut through their bullshit and determine their level of current capability and also their level of honest versus conservatism.<p>3. <i>"What is your average build time?"</i> or <i>"How do you perform test automation?"</i><p>Most places care more about their tech stack than actually writing software. That should send all kinds of warning flags. When developers just waste time all day staring at the ceiling while software goes through a bunch of build nonsense that indicates developer time just isn't as valuable testing alternatives. its great to have 90 minute builds when the business is healthy and you can go out and go bowling, or whatever, but the moment the employer becomes unhealthy those undervalued developers will find themselves unemployed.<p>As a bonus if you ask tough questions during the interview and the challenge makes the hiring manager uncomfortable consider they will remain as uncomfortable if you end up working there. That is really bad, because shit rolls down hill and their discomfort eventually becomes your problem.
These are ok generic questions, but not great. And I would encourage people to do learn as much as possible about the org/team they are interviewing for. If there's not much public info, then this is where you ask the questions to find out if this is work you're going to enjoy or if you're gonna end up in another round of interviews in 6 months.
<i>“There’s an IC sitting out there who just had an amazing idea for a new feature/product. What happens?”</i><p>Sounds like a good question, but the answer doesn't really matter, because it depends on whether the business actually wants to implement the idea. And if they do, it needs to sound like it's coming from an executive, because if it's not, they'll be embarrassed and try to crush the idea. So if the dev really wants the idea to get into product, they should be funneling the idea through their manager or through a product or sales back-channel.<p><i>“Tell me about your last major migration. How long did it take and how long did you say it was going to take before you started?”</i><p>Bad question, because they always take longer than they expect and always run into problems, and if they don't they were just lucky. You're asking them to either embarrass themselves to you in the interview, or lie. Not going to give them great feels to remember when they think about your candidacy. Maybe ask them about migrations to see how often they do them, but don't lead them to tell you something specific.<p><i>“Let’s say I’m the person you hire. 6 months have gone by, what’s different?”</i><p>> You’d be surprised how often I ask this question and the answer I get back is something like “you’ll be here and doing the job”<p>Yeah, because this is a really bad question. It's not their job to make you have an impact. It's <i>your</i> job to make an impact. That's why it's <i>a job</i>. The question should be them asking you what <i>you</i> will do in those 6 months to make a difference.
These fucking braindead articles about hiring. Holy mother of god. You go to a company to work in a specific field and get money for it. End of story. You do not give a flying fuck about that company until you are in. You might give them ideas and more of your time if the people and the atmosphere is AOK there.<p>The interview process is just plain nonsense. Multiple rounds, you have to start from scratch every time. They don't even have a common platform where they can evaluate your language and other basic skills. You have to prove every time that you are able to speak in whatever language, can code, although you have 20+ years of experience. Some even want to see what you code and how you do it. And they make you do tricky things, that you will never fucking ever do in the role.<p>And they ask you if you have any experience of tightening screws. Well, you're not a trained monkey, you're an engineer who has to fasten all kinds of screws, but they ask if you've worked with stainless steel screws and if you haven't, then sorry, they can't employ you.<p>The HR process is laden with layers and layers of bullshit. Most of the HR people and their process is all about control, to make the expert go down on all fours (yeah, humiliate the person) and do circus stunts, so they can insert you into their braindead process and evaluate your stunts based on their totally braindead metrics. All of this, so that HR can exist as a "profession".<p>For example you are someone who is an expert in a specific field and yet you have to learn this completely useless, filler bullshit, because who knows what the HR might think. Well, fuck them peasants. They are nothing more than gatekeepers. Very dangerous ones, because they are who decide in the first place who gets in who gets rejected. So if the HR is compromised they send the company the saboteurs and reject the proper people. Abolish HR monkeys and their idiotic hiring process.
> In every round, the interviewer should leave with the impression that you answered their questions as honestly as possible because you’re looking for the right fit, not just a job.<p>This is precisely what I despise about "job interviews". What you ask in the "Do you have any questions?" section of the interview should be irrelevant. I don't want to have to ask questions when I don't care about the answers just because that's what "top candidates" are supposed to do. What you're actually measuring is how much the person you're talking to is willing to read articles like this to come up with fake questions to ask as part of a fake performance so you'll hire them.
> These days, the roles I consider are in leadership so if we lack vision and a clear understanding of our value I’m usually empowered to fix that. If you’re interviewing for a more IC role, your hiring manager and teammates being unable to communicate expectations and success criteria is obviously a bigger concern.<p>So, the author doesn't seem to consider IC role a leadership role. I see, ok.