[kybernetikos]

The argument seems to be that some people are worse at the standard questions in an interview setting than you'd expect because of outside factors (which I agree with) and that therefore we should use more STAR style questions. But I'm terrible at star style questions, my memory just doesn't work that way. I also think that they are not terribly correlated with most aspects of job performance.

Just as there are people unfairly bad at coding questions in an interview situation I think there are also people unfairly bad at star questions in an interview scenario.

[supriyo-biswas]

Also STAR style questions are terrible because of other reasons: usually have one expected answer; one that shows that you’re a person who likes to take initiative, solve problems etc. and you can just come up with an answer that makes you look good on paper without having done any of those things.

I also suspect their general vagueness can be exploited to weed out candidates based on “vibes” while still maintaining the impression that it’s a standardized question they ask everyone.

Just the other day, I was interviewing with a company that posted here in the “who is hiring” thread; and I was asked “Tell me about a time when you challenged a fairness or ethical issue”; I feel like regardless of how this is answered, this is just a way for them to project you as a person without backbone who seemingly goes along with anything, or as a complainer who loves impeding others with objections created out of thin air.

[doodaddy]

This illustrates the issue that I see with STAR-style questioning - the method encourages detail-rich storytelling about situations that don’t happen very often, or are simply a mundane part of work life.

“Tell me about a time when you challenged a fairness or ethical issue.” How many times is something like this expected to come up in a person’s career? And how often will the “issue” - outside of management roles - be of such consequence that you’ll remember all the details? And how often will the true answer be nothing more than “someone asked me to do X. I expressed discomfort over it to my manager while we were getting lunch. X did/didn’t happen”. But that answer, I doubt, will make a very strong impression.

Basically there is misalignment between the method and the line of questioning.

[commandersaki]

I'm not good at STAR responses. I'm also not good with them on the spot.

I recently interviewed with the public service for a technical position and was asked four questions. But they gave me the questions 15 minutes in advance of the interview, and the interview was only 30 minutes. So I typed a few notes on each how to respond, and weaved a response. At the start of the interview they encouraged STAR style responses but I just ignored that crap and weaved a response to each.

I advanced to the next stage pretty easily.

I don't know how I'd fare if the questions were given on the spot, especially given the tight timeframe. When it comes to interviews I have a pretty shot memory trying to recall projects, even large ones that I was primary contributor, if it wasn't in the last 3 months.

[btasker]

Much earlier in my career, I was in the UK public sector.

Internal interviews within the department were conducted using something that mixed STAR with a set of core competencies (external candidates were given a bit more leeway).

So as the interviewee, you had to reply in the style of STAR but also ensure that your answers tied back into those competences. To have a chance of success, you'd need to demonstrate as many competences as possible.

As a methodology it makes it extremely easy for the interviewer to assess suitability (especially for candidates trying to move up the chain - there used to be a qualification assessment for that too) and to do so in a way that can easily be explained/defended if a decision is challenged.

As an interviewee, though, it really was the most awful experience. The questions themselves weren't codified, so the interviewer could ask whatever they liked and you had to find a way to tie it back to a relevant competence in order for your answer to "count" and then explain using STAR.

The problem, in my view, is that there's a huge difference between what works for interviewers and what's likely to work for an interviewee. STAR makes it easy for an interviewer, but it's not the way that engineers normally communicate - just as coding challenges are often quite unnatural (like everyone else, I've had some awful technical interviews).

[CoastalCoder]

One downside for some of us describing a past project in detail is that all of our relevant work is covered by trade secrets, NDAs, or security classification.

That doesn't mean it's the interviewer's problem to solve, but it is a thing.

[RaftPeople]

> and that therefore we should use more STAR style questions

As an interviewer (multiple decades) I have an extremely low opinion of STAR style questions, to the point I have abandoned them entirely.

My first decade of interviewing and hiring was abysmal (when I look back on it), then I muddled for another decade or two with maybe 50% effectiveness. But more recently I've found a formula that seems to really works for me (success is well above 50%):

Engage in a relaxed conversation where I ask the interviewee to walk me through significant projects/tasks/home hobby stuff, anything with some meat regarding problem solving/approach/specific technical things I'm interested in.

I ask them to go start to finish, how did it start, what was problem being solved, why, what were the initial thoughts on how to solve, significant challenges, etc. It's easier for people to recall details when there is context and they are in a flow of information then just cold formula questions.

I interrupt with questions and dive deep into some areas that I want to know about (e.g. can you go into more detail on how you used technology X that you just mentioned) or just listen for a bit. You can pick up a ton of information by what is said, what isn't said, how it's said, etc.

I think you get more info with a relaxed open ended discussions sprinkled in with targeted relevant questions than with sets of formula questions that the person knows which type of answer is the "correct" answer.

[lapcat]

I agree, though this is not to defend coding interviews, which I'm terrible at, like the author.

The fact is that all job interviews are poor indicators. There is no "good" interview technique. Taking an arbitrary snippet of an hour or two out of someone's life/career is going to give you a misleading picture. The best indicator of future performance is past performance, i.e., experience. Granted, it can sometimes be difficult to evaluate past performance, which is why hiring is always a gamble. Hiring managers seem to believe that they can take the risk out of hiring, but that's a delusion.

The benefit of hiring based mainly on experience is this, which the author mentions:

> It’s already problematic how much company resources are consumed by these interviews. Worse, consider that for every hire, there are plenty of candidates who get filtered out, meaning organizations are taking extra time from people who likely have little to spare.

I often hear excuses for putting job candidates through the wringer, such as (1) it's difficult to fire people and/or (2) firing people is demoralizing to the team. However, (1) in the United States, with at-will employment, that's simply organizational incompetence, which is a bigger problem than bad hires, and (2) having to continue to work with an incompetent person is perhaps more demoralizing to the team than getting rid of the person.

The most perverse aspect of the software industry's devaluation of experience — besides age discrimination, of course — is that long-tenured engineers and fresh college graduates are pitted against each other for the exact same jobs. This should rarely happen and is a sign of poorly defined job roles. It reeks of the belief that engineers are simply cannon fodder, warm bodies who can type code, replaceable cogs in a machine. I suppose this same attitude is reflected in the belief that engineers can be replaced with "A.I.".

[aguaviva]

This "it's difficult to fire people" idea seems to be a meme that has caught on in recent years.

In the U.S. it's ridiculously easy to fire people (as pointed out above), once management has made the decision. What people seem to really mean is that it's sometimes difficult to get management to see the problem in the first place -- but by definition, this ultimately points to an issue with the management team, rather than the supposedly stealthily incompetent (or flaky/abusive) employee.

And also - when the right decision has been made, the team generally rejoices, and bemoans only the fact that it took so long. If the effect is seen as demoralizing -- it means the firing was likely political, or a result of team chaos / poor communication not specific to the employee. So again, the issue rests with management -- by definition.