Three questions to turn the table during technical interviews
bellmar.medium.com
bellmar.medium.com
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 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.
> 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.
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.
“There’s an IC sitting out there who just had an amazing idea for a new feature/product. What happens?”
“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?”
“Let’s say I’m the person you hire. 6 months have gone by, what’s different?”
"Three, six months in, what signs are there that you made the right choice with your candidate?"
It almost comes across as a pessimist's "what's the f point".
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.
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.
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.
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.
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.
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.
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).
What are the bad things about this job?
What's the average tenure on the team, how many people have left the team recently and why?
How does this team & company compare with other places you've worked?
(second or third round) How many other people are being interviewed and how do I compare?
> 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.
I have found it acts as a decent proxy for how strong/weak I have done. But it also allows me to get some feedback to improve for future interviews.
There has been at least one job that me asking this question directly resulted in an offer as well.
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.
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.
I don't think that's true. During times I've been an interviewer, I've been open about the bad parts of the job.
And if everyone tells you nothing, then that in itself is valuable information - that they're all fucking lying to you.
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
A softer way to word this:
"What are some of the biggest challenges for this role?"
It won't get into all the dirt, but should give you some insight into things that aren't great.
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 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.
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.
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.
https://www.joelonsoftware.com/2001/12/25/getting-things-don...
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?
https://news.ycombinator.com/item?id=41243278
2 weeks ago, 221 comments
> 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.
Man, I bet my answer and my VP's answer to that are gonna be rather different.
This is not wisdom. This is over-fitting industry/era/role-specific individual experience to generic candidate advice.
Do none of these things.
If the interviewer is not, you'll be given falsehoods and platitudes.
2. Is on call mandatory?
3. Are there any plans to move away from 100% remote work?
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.
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.
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.
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.
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.
- “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.
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.
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.
It’s like in school every TA uses the same rubric yet they all grade differently.
Do you truly not care to learn anything about the company you will spend the next 2,3,5,10 years with?
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.
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.
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.
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.
> "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.
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.
sure you want to make sure the company isn't really bad but mostly you need a check-
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.
So, the author doesn't seem to consider IC role a leadership role. I see, ok.
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)