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?".
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.
I welcome this question from interviewees and sometimes offer up the information without being asked.
I work in a small business where we do hardware, software, help the marketing folks, and do a little IT work where needed. I want someone who is curious, energetic, and enjoys taking on whatever challenge presents itself. They'll start in a pretty well-defined role in a well-defined domain, and I'll give them support in that role. But they will have every opportunity to branch out from there, and I believe the kind of employee I seek—as well as the company—will benefit if the employee fits this technical culture. I want to scare off people who want to be pigeon-holed and fed repetitive tasks.
To that end, I also like to discuss with candidates projects they've worked on in the past, rather than offer up new challenges I present to them. Our normal work week doesn't involve isolated puzzles or single activities that one finishes in an hour. Finishing a project takes a long time & requires acquiring new knowledge, skills, and understanding, so I want to explore in depth something the candidate had a long time to work on where this process did (or did not) transpire.
My POV is that I want to find a postdoc (or someone who could grow into this paradigm), not a clever parrot.
I ask this question every time I interview and the answer is always useless, something like “Well, it varies”. For some reason companies never want to say what they’re working on, like it’s state secrets or something. I guess that’s a signal too though.
Treating the interview as two-way is good, and how it should be. A couple points:
> 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.
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?
> 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?”
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.
I think interviewer answer candidly when they care about the candidate actually thriving once they join, instead of spending a "I'm not job hopping" sacrificial year and get out as soon as they can.
Seeing how they react to the current company strategy is a valuable in that respect, and it will be better for both of them bail out during the interviews and not after signing the contract.
The article is paywalled but I'm not a fan of suggesting particular questions in general. Unless it's relevant to the team I'm on or the candidate is genuinely knowledgeable and interested in the field then it comes across as not genuine. I've never actually mentioned that sort of thing in interview feedback but I would prefer a candidate asks what they are actually interested in knowing.
I asked this question once. The interviewer basically revealed that they didn't know what <that role> actually did or would be contributing. I didn't get an offer, and I'm grateful
Not a bad question in principle, though I have to say there's something quite disconcerting about it's phrasing/tone, which I can't quite put my finger on.
It almost comes across as a pessimist's "what's the f point".
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.
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?”
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 don’t like the wording of the question but saying “talk to a product manager” is a red flag answer that would be the exact wrong answer an engineer would be looking for.
A good manager coaches their engineers on how to package (one pager, demo, talking to partners etc.) and present their ideas to get buy-in from leadership, these types of managers are the ones hackers like.
A bad manager is one who gives a dismissive “talk to a PM” answer, who doesn’t coach through the politics/process of the company and simply dismisses your ideas outright. If you hear this type of answer it gives the impression of those “just do your job and keep your head down” sort of workplaces with management that’s bad for growth.
> build a sustainable company by adding new features willy nilly whenever some dev has a Great Idea.
This is hilarious because it seems to place some kind of value on a stable interface, but that is something that companies / product managers have themselves systematically destroyed over the last decade or so in pretty much every arena. Only software for professionals is even slightly immune to this (IDEs/CAD/etc). Pretty much everything else has auto-updated churn that you can't opt out of, on everything from UI to core features.
Putting devs in charge of inserting features "willy nilly" would likely result in a much more consistent experience than what we usually get, because they'd be willing to declare something "finished" eventually. Product managers want the churn, because they can boost fake metrics like engagement, and it gives them stuff to do.
> Putting devs in charge of inserting features "willy nilly" would likely result in a much more consistent experience than what we usually get, because they'd be willing to declare something "finished" eventually.
I have seen both, but at my most recent role, this was entirely the opposite of the case. We built integrations between different systems (ETL-like). Before the company adopted any "product principles", our integrations were haphazard and sporadic. Engineers would only build what was needed for current customer pain or in response to support saying "this entity doesn't sync".
So what, you say? Why build things you don't need? Because then the next customer says "I need X" and you say "Well, crap, that's going to be a lot of work because of how we wrote W", and either it's a lot of work, or they do some shoehorning and overload tables (my favorite was "'Location' in ERP A and 'Cost Code' in ERP B share much of the same columns, so we can use it for both and just change the label based on which ERP is in use." Then along came ERP C, which supported 'Location' AND 'Cost Code', and threw a spanner in the works.)
I am not saying product managers are a panacea. And I will acknowledge my 'bias' here - I am a PM, after spending a decade in the devops/SRE space.
But deeply embedding PMs and Eng is the key to success, I believe. My conversations with Eng Leads and EMs are happening 'all day every day'. I don't flit in, drop a bunch of stories in the backlog for Eng to refine, and then vanish to my meetings.
My job is to paint a broader picture of not just where we are now and what's next, but the grander and longer term vision.
This way, when designing or architecting things, there can be an awareness of that, and hopefully less "painting yourself into a corner". And with that comes a conducive atmosphere where Engineers do come up with Great Ideas, AND have a lower friction pathway to getting it in, because they know we can always discuss it.
Yup. Which is why this question can give some good insight into how the company runs. Is it chaotic? Suffocatingly rigid? Or is there a pipeline to triage and introduce new features in a sustainable and beneficial way?
Yep I agree, one of my last jobs a few years ago was like that - 1 PM for every 2 engineers. The entire time was PMs fighting with each other of scarce development resources, completely toxic culture
There needs to be some cat herding and not all ideas are great but on a strong team the devs know their product very well and understand their users very well. Amazing product managers also do that but they are a very rare beast.
There's nothing wrong per se with "talk with the product manager" but is that where good ideas go to die or is that a productive/creative/innovative environment where teams build great stuff.
A ton of stuff you use every day is "software developer had great idea". Even from really large companies. (p.s. using "IC" can already be a red flag - we don't use this terminology in the large company where I work).
It's why I prefer working in startups. Less money but the amount of crippling BS you deal with is vastly less. Basically, you are the only thing on the critical path to delivering anything. A lot of what I do in startups is ruthlessly getting rid of anything that blocks me that I can't control.
I do some consultancy on the side with bigger companies that are stuck in exactly the way you describe. Because the elephant in the room is usually that product managers vary widely in quality and I've seen them be a bottleneck in quite a few places. There's this weird dynamic where you get non technical product managers act more like a CTO and CTOs act more like a VP of engineering in some companies.
Since I come in and advice at that level, I get to see this dynamic up close. Good ideas don't stand a chance in such companies and they actually end up paying me to tell them to stop doing stupid things that they already know they shouldn't be doing to begin with. A lot of companies are not long term sustainable because they fight themselves into corners like that. That's why consulting can be so lucrative. You just relay what engineers in the company are saying anyway to their managers. All you need to do is listen and talk authoritatively.
A good company would have a culture of being open to sound engineering and be empowering people to make things better. Steve Jobs famously encouraged that in his people and got rid of people that tried to prevent that. Elon Musk apparently does similar things. Neither are/were particularly pleasant people to report to but there's a pattern in their behavior that they encourage and insist on creative and critical thinking around them. A weak manager does the opposite. Weak managers are the reason consultants like me get lucrative gigs to tell them what they should already know.
Startups can also have know-it-all product management. Ask me how I know. It's possible to have the best and the worst of all worlds, i.e. get paid more and be in a fairly functional environment or get paid less and be in a less functional one. The only startup where you're more or less guaranteed not to put up with bs is your startup. I've worked in pretty nice startups as well but also in good larger companies.
I like the middle two questions a lot, and I try to ask them as well. I think the other two are flawed, though:
> What are the bad things about this job?
Too vague. Most interviewers won't be ready to shit talk their employer with this question and will say "nothing." A better question would be some variation of "What would you change about the way your team works if you could?" Frame the question properly so that they don't set the parameters themselves.
> How many other people are being interviewed and how do I compare?
Comes off very insecure and gives you no useful information. It will only reflect poorly on you.
> Most interviewers won't be ready to shit talk their employer with this question and will say "nothing."
I'm not sure that's really true. I ask, verbatim, "what sucks about this job?" to everyone in the interview loop and I frequently get high-signal responses from it. What you're saying might be true in some places and for some (probably earlier-career) roles, but that's signal too.
> Comes off very insecure and gives you no useful information.
This one is true to a point, and probably depends on how it's asked (and whether you actually are insecure). Working mostly in smaller companies and startups, interviews have generally ended up at the CEO level, and a "what's your funnel look like for this role?" has never gone poorly while getting me pretty clear signal on whether I should toss this one in the trash or not.
> "what sucks about this job?" [...] I frequently get high-signal responses from it
That's fair, it is your experience, but I think it's about whether you're on the same wavelength about what level of corporate suck is standard and acceptable. I don't love the framing of this being specifically an "earlier-career" issue but I'm an IC and ICs are not a borg that I have assimilated into (yet), so some have internalized varying amounts of corporate suck relative to me.
For example: I find in some places, low-autonomy is just considered par for the course, and when asked "what sucks?" certain ICs might respond "this job is the best one I've ever had, I have no complaints." But, if asked "what part of project delivery is most frustrating?" or another more specific question they might say "requirements change sometimes arbitrarily and we're expected to respond to any changes without changing the delivery target." The point I was trying to make is specificity helps to get higher signal answers when you don't understand your interviewer's baseline. One man's yuck is another man's yum or whatever.
> "what's your funnel look like for this role?"
I think this is a fine question to ask. It is fairly corpo-speak sounding, but it doesn't communicate the same "Do you like the others better than me?" vibe as the question you contrast it with. It communicates that you are evaluating them, not asking them if their evaluation of you is going ok or not. If you're interviewing with the C-levels then they also have enough information to give you a clear response, and the answer will give you details about how long it will take to reach a hiring decision.
"Bad" is relative. Someone may believe that something is industry standard and not worth talking about e.g. crunch time in games. Also, plenty of people internalize the bad bits of their jobs and won't think to discuss them unless you ask specifically. It's like asking for feedback from colleagues to their face, unbounded requests for criticism are psychologically hard for humans to answer.
Plus any professional place will obviously have processes and rules in place to not discuss other candidates with a candidate. Sure you might be curious to know, but that is a waste of breath to ask an interviewer during a technical interview. Ask the recruiter if you must.
Asking for feedback at the end of the loop is great. A bunch of mega corporations are specifically instructed to give you absolutely nothing, but it's always worth asking.
I don't ask what is bad, I ask: if you had a magic wand and could fix something here, what would you fix and why?
It gives me insight into their recent frustrations and often company going-ons or culture. It then opens for a potentially interesting discussion on how changes are made at the company which is particularly relevant to working in leadership roles
I had 3 different Engineers mentioning "X person who left" in the interviews of a company once, which triggered all sorts of red flags. Digging a bit deeper, the company had a major merger and it seemed it had gone from a super-nice environment where devs were trusted and empowered to a top-down, strict structure where they were all now fighting to stay hired.
i don't care about most of the questions being raised here.
a slow process to get changes accepted, long build cycles, bad legacy code, irrational business decisions, whatever.
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.
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.
I've worked at a place like you describe. Supportive team, cooperation, understanding, etc. Despite whatever disagreements it was pretty great. For about 2 years.
Then the stuff like irrational business decisions, difficulty getting people on board to address issues, all this institutional inertia, people saying no to everything that could possibly improve things internally. It weighed down so much that I just couldn't handle working there anymore.
> “…i'd rather do that than suffer people who are unfriendly or uncooperative…”
I assume if you had interview questions to root out cooperative groups you would have shared.
So maybe the next question would be, What management or leadership practices are indicative of a better group dynamic?
Otherwise, in my experience, the group dynamic is an interpersonal dynamic— the result of quality of work the group achieves and the synergies of individuals in that process—unpredictable.
to be honest, how to discover these issues in an interview is really the question. i have no idea what to ask to get that that. i mean, asking if i'll get help from my team mates is surely going to be answered with yes, whether it is true or not. same if dumb questions are ok. etc. i think you'll really have to spend a day with the team to get an even just an idea.
at best in a coding interview i can find out if the interviewer is helpful when i am stuck there. or as in one interview i had, the fact that i was allowed to do the tests in a language that i was familiar with but nobody else in the company knew, at least showed that they were open minded and would accept me as an experienced programmer despite not being as experienced in the language they were using.
> Let’s say I’m the person you hire. 6 months have gone by, what’s different?
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.
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?
It's kind of the inverse of questions like "why do you why to join this company", where most interviewers would be put off by the truth, which is "because you'll pay me"
The point isn't necessarily to get an accurate rendition. It's to see how they answer. What they emphasize. What they don't mention. Most of the questions I ask when being interviewed are like this, ones that give me a sense of what the environment and the people are like.
Not sure the author realized this, but there's an interesting contradiction here.
> In hiring, we standardize questions to help mitigate bias and make more accurate comparisons across a group of candidates.
> 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.
Standardizing is more fair, but at the cost (or benefit) of minimizing interesting outcomes.
Maybe the question could be sharpened: "Can you tell about some examples where an IC in your company had a good feature idea, and what ended up happening?"
The problem there is that there's always ONE example. If you ask this in a Google interview, I guarantee they will tell you that "GMail started as a 20% project."
To me, a better signal is a set, repeatable process in place. Does it happen often enough that people know what to do?
When they tell you a story, they probably will minimize the gauntlet the innovator had to run.
This isn't social engineering, these are actual things I want to know about a company if I'm going to spend a few years there. I typically ask much more than this.
Good questions for a recruiter, less so for an interviewer who just gave you a technical interview (and is probably an engineer themselves). The article is questions to turn the table during technical interviews.
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.
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.
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: We will perform your first mid-year review!. WTF, so what?
Here are some better questions (repeating the first one from the article first):
1. “There’s an IC sitting out there who just had an amazing idea for a new feature/product. What happens?”
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.
2. "How do you measure things related to your product and what do you measure?"
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.
3. "What is your average build time?" or "How do you perform test automation?"
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.
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.
“There’s an IC sitting out there who just had an amazing idea for a new feature/product. What happens?”
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.
“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?”
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.
“Let’s say I’m the person you hire. 6 months have gone by, what’s different?”
> 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”
Yeah, because this is a really bad question. It's not their job to make you have an impact. It's your job to make an impact. That's why it's a job. The question should be them asking you what you will do in those 6 months to make a difference.
> 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.
Isn't this exactly the kind of answer that the question is meant to tease out, so that the candidate can know ahead of time that the company is more interested in executives' status than in innovating?
I'm trying to figure out why you're framing this as a reason to not use the question instead of a great example of its utility.
> Isn't this exactly the kind of answer that the question is meant to tease out, so that the candidate can know ahead of time that the company is more interested in executives' status than in innovating?
This is like asking if sharks like the taste of blood. Any answer other than the obvious is a shark looking for a meal.
Executives only exist because they are obsessed with status/power, the share price, the market cap, competition, winning. That is their purpose in life. If they cared more about innovation, they wouldn't be executives, they'd be engineers.
It's not impossible for an engineer to get an idea into a product. But they have to know how to swim with sharks.
This makes me sad for the companies you worked for. I'm at the director level at my company, and I make sure to both give credit to whomever does good work, and to enable them to do it. I do enough good work of my own that I don't need to steal credit to be successful.
I mean more like C- and V-suite. Their priority is the company, and their own promotions. In order for both to excel, they need control, and to encourage the path they are trying to go down, and not side quests. This includes their reports and so on. There is a natural order to the hierarchical work of giving the upper-class what they want. As my last boss was very fond of reminding me: "this is not a democracy."
Yea these questions aren’t great but if you want to ask these type of questions a better version would be:
- “Can you tell me about the last time an IC on your team turned an idea into a feature/product? What was the process?”
This can pinpoint whether the manager has a record of helping their directs get their own ideas into the product.
- “Tell me about the challenges you ran into in your last major migration, how did you decide what technical debt falls below the line?”
All migrations end up being late due to unknown unknowns, but you probably want to learn a little bit about how they managed the situation and how they decided to cut scope to still meet the new deadline. Or you could go with something like “tell me about the first 6 months of your most recent hire.”
The “6 months have gone by, what’s different?” Is just a bad question. If what you’re trying to figure out is how you’ll transition from onboarding to full team member why not just ask about that directly?
Also if you wanna social engineer the interview with this type of strategy, you probably should ask questions that are less focused on what they will do for you and more focused on how you can impact the organization.
I agree with your first and last answer. This is why most people can't make an impact. Even if you _could_ make one, too many layers of permission often kills the potential, or just as worse, the idea is greenlit and some other engineer with seniority leads the project; robbing you of the chance to make an impact.
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.
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.
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.
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".
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.
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.
The interesting stuff that will make an employment unpleasant is not going to come out in an interview. That stuff comes out over time. To boot, I can think of quiet a few lies/half truths from interviewers. It is like dating, nobody says they are actually a lazy slob and the codebase is a POS on the first date.
For somebody who's unemployed, especially somebody who's been unemployed a while (very common in this market), the main thing you care about is getting employed again.
I imagine somebody who's currently employed wants to know that the company is better than the place they're currently at before they'd accept an offer. But sometimes "better" can be a very low bar to clear because their current company might be awful.
In other words, evaluating the candidate by their questions is just bias towards those who are already in good situations. Somebody being unemployed or employed in a toxic environment doesn't mean there's anything wrong with them especially in an economy where companies continue to lay people off at random.
> In other words, evaluating the candidate by their questions is just bias towards those who are already in good situations.
It sucks for the employee, but the unfortunate truth is that filtering for someone who's already in a good situation is actually a really good filter for the employer. As you say, it doesn't necessarily mean there's something wrong with them, but being unable to find a job for an extended period of time—to the point where you'll look for anything and not try to filter workplaces at all—is correlated with undesirable traits. Meanwhile, being steadily employed in a chaotic market and asking questions that show you're not desperate and are evaluating me as a hiring manager are both correlated with positive traits.
Again—not that any specific candidate is problematic or good because of those situations, but you will tend towards better hires overall if you watch those cues.
The hiring process sucks and it sucks that this method of filtering works, but it does work.
> The hiring process sucks and it sucks that this method of filtering works, but it does work.
How do you know this? (That this is not just sampling error, survivor bias, and/or confirmation bias)
I speculate that a good hire is almost random. Context matters as well. I worked with someone that was horrible, to later find out they were the other dev that I was going to work with later on a contract job. The different environment was night and day.
That being said, I do think the signal of a horrible hire can more often than not be detected during an interview. Otherwise, IMO, there is too much noise that it is close to random.
This filter works because people that are really good at what they do naturally tend to actually care about the surrounding tools/processes involved. Someone that has no opinions at all about those tools/processes is just showing up, and people that are just showing up are not usually as good as people that are passionate about the work.
That said.. it is stupid/insulting/weird to interview assembly-line workers as if you're looking for skilled artisans. Most companies/interviewers completely lack the self-awareness and ability to reflect on which category of worker they actually need/want, and may not even realize there are 2 categories.
I take you are referring to a different filter. I was responding to:
> "the unfortunate truth is that filtering for someone who's already in a good situation is actually a really good filter "
Be what it may, the "caring about tools/process" filter I also think is fraught with issues. (1) candidate might have already been described what the tools/processes are several times already. Perhaps even up front in the job description. (2) I've learned that tools and processes need to be evolved, gently suggested. It does not go well to say, yeah, drop scrum, do fewer CRs and only when important, add an auto-formatter and all these things. Secondarily to that, those things are not necessarily that important. It is work about the work there, better often to just do the thing then to spend too much optimizing the effort to do the thing. (3) a candidate should be asked what they would change in tools and process. Volunteering that can show a lack of "business focus". (4) any issues in tooling/process might be pitched as opportunities for impact that the candidate could have. In reality those things get political and it might not be a position that is empowered to really change much. So why deep dive into that during an interview - the person is being hired to do a thing, not to just do tooling (unless it is a tools efficiency job of course!)
At the same time, I would agree that someone with no opinion likely has no breadth in the process aspect of development. Yet, does that matter? It is more important for a team to get along than to try to 10x itself by going full bore on process efficiency. The latter is a myth. Focusing on that myth likely is going to be endless meetings/discussion about process and not business problems.
What is more, tools and process are context dependent. What works at a big shop (eg: FB, amazon), or the last shop - might not work at all at the next shop.
I'll emphasize as well that tools/process are best evolved with focus on areas of greatest need. That is a learning and discovery process. Getting a clear signal during an interview of whether someone understands that, or have just followed the scrum guide without much thought could be a real challenge. Asking someone even if they follow the scrim guide is nebulous, many have not read it, they might say they have but clearly have not. Yet more, the saying of "if you're still following the scrum guide a year later, your process is not agile"
Ergo, I suspect the "cares about tools and processes" will be a noisy filter. Caring too much creates discord on a team and ultimately is distracting. Sussing out willful indifference vs indifference due to business focus (eg: "I really don't care, just point me at the business problems and the rest is bullshit that I'lljust have to suffer through"), vs just shows up. I believe differentisting that alone is a big challenge (and potentially susceptible to a variety of biases). Yet more, is that the most important thing to focus on during an interview, is that really a valuable filter? I'm not sure. Sometimes having a few people not care is good, less bikeshedding.
> For somebody who's unemployed, especially somebody who's been unemployed a while (very common in this market), the main thing you care about is getting employed again.
Rather than seeing this phase of an interview as a chance to "conform even harder" and show smiling engagement in what is already an unfair / coercive farce, try thinking of this as an opportunity to exercise your curiosity.
I mean sure you don't really care, you just need a job. But it's possible to be curious about lots of things you don't really care about. Look at that bird, I wonder where it's flying from/to. Hey it's a car parked on the street, I wonder how many people had sex in the back. Look it's a manager at a company, I wonder how they handle product ideas in that company. Being curious is easy, usually it hurts nothing, and it's a kind of muscle that benefits from flexing. Besides, especially if you've got a long drive or a long interview.. well you're stuck with it, and what else are you going to do.
Yes, your current situation does make a difference in what is important to you and which questions you have. And it also influences the balance at the interviewing table. I can imagine that it is frustrating to feel being evaluated against candidates who have the luxery of saying ‘no’ to a new job and can think critically if they want to work at the new place. Sometimes you have more freedom to say ‘no’ then you think. It can make a difference between night and day.
My impression has always been that very little information given in either direction in an interview is relevant to the next year, let alone the next ten.
In theory it’s irrelevant in practice although companies try to make the process quantitative it is ultimately qualitative because it’s a human rating on a qualitative rubric. The impression you leave on the interviewer always makes a difference in how they represent you in their feedback and panels.
It’s like in school every TA uses the same rubric yet they all grade differently.
If you don't have any interest why do you want to work at that organization? You just want a check? That's not a good way to spend half your waking hours during the work week.
If you aren't already wealthy, you're probably working because "you just want a check". Even if the job you want is to own your own company, you still have to work until you have enough savings. This is how the world has always worked for most of the population in every human society that has ever existed.
If your skills are in demand you can get the check from many employers.
That said, if you want to run a business, and you don't like/want to do anything else, then you're kind of stuck. Unfortunately not wanting to do the job you want to get isn't generally what makes you a great hire but wanting to do a different job without having any skills also doesn't make you a great hire. Owning your own company is easy, go register it and you own it. Getting a check out of that is a little harder.
Yeah. When I’m interviewing folks at my current company, and the Q&A portion begins, I tell them they can ask whatever they want or just reclaim the time; my notes are sealed. More interviewers should operate like that.
You can tell them that, but I don't think I'd believe it as a candidate. I'll assume that every interaction I have with you up until an offer is extended is going to influence your perception of me, whether you're taking notes or not.
> 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.
So, the author doesn't seem to consider IC role a leadership role. I see, ok.
I think you're being unfair. It's clear what the authors intention is. They aren't speaking "down" regarding ICs, they're just making their intention clear in terms of the role they're in search of. Yes, ICs can absolutely be leaders in an organization (and _should_ be) but that doesn't change what the role of a leader is or what the author wants.
that isn’t mutually exclusive with leadership. ICs lead by example and mentorship. the fact that they’re not managing people doesn’t preclude being a leader at a company. the way i’ve heard it put for staff+ engs that i like is that they’re managers without reports.
but to speak to GP’s point, they are being a bit overly sensitive. “leadership” in the context of the article likely means C-suite or director level, which usually IS mutually exclusive with an IC role. (and maybe that’s what you meant, sorry for ‘splaining if so)
