I will f(l)ail at your tech interviews, here's why you should care (opens in new tab)

What sort of companies are testing you with leetcode. Faang or other types of companies? I have very rarely encountered these types of questions in my own experience but maybe that's a function of where I live

Maybe they don't want to hire experienced engineers but prefer smart juniors they can teach their own specific ways of doing things?

And yet it's still not clear that the standard anxiety-driven interview process is in any way helpful for sussing out actual performative ability in the former category.

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.

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.

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).

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.

> 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.

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.".

This is nonsense. Yes, given a prediction method that produces a probability, there is a tradeoff between false negative and positive. (Your example doesn't exhibit this though). But of course you can decrease your rate of false negative without affecting your fake positives: If you change your prediction method!

This is literally the first image in the relevant Wikipedia page:

https://en.m.wikipedia.org/wiki/Receiver_operating_character...

At a given acceptable level of false positives, different predictors have different rates of false negatives.

> that was an old book, people used irons to make their clothes smooth

I mean, er, while I don’t personally own an iron, myself, I’m fairly sure anyone who regularly wears shirts and things _still does_.

I would argue that a brief conversation with a senior developer provides as useful information as any coding test or fancy interview question. The only way to really know if someone is going to be a good fit for your organization is to hire them and work with them for a couple weeks. After just a couple weeks, you know everything you need to know about the candidate. Unfortunately, most of the world makes a hiring someone for 2 weeks difficult. If you want to fix something about the hiring process, find a way to let people work together for a couple weeks before hiring them as full-time employees. I've done this with contractors in the past and it works wonderfully. I still hire people and fire them if they don't work out after a couple weeks. I also tell people I will do this during the hiring process.

Exactly. This is the same as it is with hiring musicians. If you're hiring a musician, you don't need to have them play an instrument for you so that you can hear and see them play.

Take them out to lunch, they can describe their playing style, talk about what they are able to do or not do on the instrument and you will get absolutely all the information you need.

If you pay close attention, by the time they order their meal you should be able to tell whether they are actually proficient or not. Sometimes you can even tell a musician won't be a cultural fit by paying attention to them on the way to the restaurant before you even get there.

... and how do you arrange the trie to be able to just use a for loop to search? Surely that is the interesting part.

Part of the problem is not just the questions themselves, but that you're asked to solve them under time pressure, with a bunch of people watching.

I've had trouble with "write a function to remove duplicates from an array without losing order". This is fairly trivial and I can write this with my eyes closed, but if you're so nervous that you can barely think straight ... yeah, then it gets tricky.

I have lots of anecdotes of stuff I failed during interviews that know I can do because I've literally done it before or since. I'm one of those senior developers who failed to write a for loop during interviews.

If you think technical interviews are just made up garbage, you should see how bad CVs are, or how shockingly good some people are at talking about things they can't actually do to any level of competence.

If you've never tried to hire technical people it can be surprising how difficult it is. I have not come across any foolproof method but the normal shape of the technical interview is the way it is because it is trying to solve a genuine and difficult problem.

Now some organisations do it in ways that are objectively wrong, but everyone knows that even when you're doing it right you'll have false negatives and that is the price for trying to squeeze the false positive rate down.

Failing an interview shouldn't make you feel bad, because there are all kinds of reasons you can not be progressed that aren't that you are objectively bad at what you do, but it can be a good moment to think about if you could communicate your skills even better next time and what that would take.

You should also always try to get feedback about what they didn't like. Nobody likes to give that feedback, but it's surprising how often a candidate will have the wrong idea about why they didn't progress, and it's bad manners for a company to use that much of your time and not give at least minimal feedback.

> HR can use later as collateral against anti-discrimination lawsuits

This is a myth. There's almost no reality to job candidates filing frivolous lawsuits. Hardly anyone looking for a job has the time or money for this, not to mention the likely prospect of getting blacklisted entirely from the industry for filing a lawsuit.

HR should not be evaluating coding skills. Senior developers should evaluate their future peers.

I've thought about giving people an old Fortran project with a few small compile errors, and asking them to fix that. We're not using Fortran of course – it's just a test of pragmatic skill of Getting Shit Done™ without hand-holding.

Inspired because I had to do exactly the above a few months ago. I don't really know Fortran. I don't even know exactly why it failed to compile, but my fixes work (and verified to work correctly), so whatever. I just read the compile error, copied what other bits of the code do. Basic stuff really, but it would probably filter out the worst of it. I haven't put this theory to the test yet though.

Putting every candidate through rounds of coding tests is actually the least efficient, worst possible response to getting lots of candidates. As the article author said, "It’s already problematic how much company resources are consumed by these interviews."

> learn to show yourself before the marriage even if that’s no use afterwards

It's not a marriage. Both the employer and the employee can terminate employment at the drop of a hat.