I will f(l)ail at your tech interviews, here's why you should care | Hacker News Reader

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

fraklopez.com

63 pointsrom1638463 comments

If the point isn’t to finish the task and you just want to assess their problem solving, wouldn’t you still naturally rate the person that breezes through it over the person that has to clunk through it solving it? This means this will be biased towards someone who HAPPENS to have dealt with this same problem (or memorized it).

After a few leetcode interviews this is now my technique. I just braindump style memorise problem / solutions from neetcode.io videos without attempting to solve them outright. Sure it might be enlightening to grind through the problem solving aspect, which I've tried before, but you're probably going to miss the mark trying to find the optimal solution, and memorisation is far more effective in practice, especially when faced with a unhelpful interviewer.

I've been told that this is a mark of a "bad" software engineer (even here on HN) for taking these shortcuts. While yes being a decent software engineer matters, I just don't see how these hazing ritual style interviews have a bearing on you as a developer. Memorising leetcode to pass interviews is just an application of opportunity cost.

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

I encountered it at Activision a few years ago.

Nearly a decade ago, Google was. In recent years I've experienced this with Amazon, Microsoft, and TikTok.

Smaller companies have done real time programming assessments but they are not leetcode-esque.

If I was given a l33t code problem in an interview I would stand up, make some sort of silly comment, and walk out. That's not a company I want to work at.

At least where I live, the LC companies offer more interesting work, lateral movement, better staff amenities, and, of course -- are far more lucrative. I'd probably walk if it's just a run of the mill company trying to cargo cult the hiring process.

Financial shops and pretentious startups tend to be quite fond of these kinds of problems as well.

I was way more likely to succeed the faang tech interviews coming straight out of university than I do now after working for 10 years.

But I do think I'm a way better software engineer now than back then. So something is broken with that interview process.

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

Juniors often lack the experience to make good long term decisions which has consequences for the maintainability of the software. However, the uncharitable interpretation of this behavior is usually that a junior is easily fed a narrative about career growth that seniors may not be so willing to accept.

What if people came up with other, better ways of doing things? What if they're just straight up doing something very wrong and very inefficiently and they don't know that because they've hired a bunch of ignorant people who accept the status quo? That doesn't seem a very open minded approach.

The vast majority of choices are between things that are roughly on par with each other if used by people with similar experience in them, respectively.. But then you don't have shared experience for when someone is on vacation if everyone is doing the better way in their opinion, or you lose a ton of time on the arguments to choose the best way when it doesn't matter, retrain the majority on the least experienced engineers suggestion as they can offer no negative critiques of their solution, etc.

Very tolerant senior engineers are basically what you want, opinionated juniors are who apply to senior roles and make people seek out juniors who apply to junior roles.

On the other hand, the choice might have bad in the beginning but it is hard to go the better route now, meaning a rewrite to switch to the better way would cost way too much time and resources.

In this case ignorant people would be way better for the company because they wouldn't care. I've gone into a job that was like that and it bothered me a lot that I had to work with a shitty foundation but there was nothing to do about it so the job sucked for me while a junior was just grateful for the opportunity

Yes, and the job itself is not that challenging or important compared to minimizing friction between people.

Maybe selecting the people who memorized their algorithms labs also selects for people who are self-effacing and accommodating to what the seniors in the organization expect of them?

I agree, at least the one FAANG company I worked at didn't hire like it want experienced, well-rounded people. Instead it hired a bunch of "brilliant in a vacuum" type people who proceeded to do brilliant-in-a-vacuum things create impressive projects that ultimately were far inferior to the industry norm because those projects never had a input from designers, customer support, the interoperability/standardization of the best-in-industry tools that were out there.

So ultimately I think it was largely to their detriment -- they reinvented everything and by and large I'd say most of what they built in-house was inferior to the industry-norm.

I think it’s simpler than that. They just don’t know what they are doing.

Or smart juniors that don't know enough to demand a decent work/life balance, even when offered FAANG money.

The issue is we don’t actually recognize that there are two very different careers that fall under the “software” umbrella.

One is developing hard software, software that needs to be performant on a hardware level. Like operating systems, low level libraries, embedded software, databases. The ability to quickly identify and apply data structures and algorithms leetcode style is very important in hard software.

The second is soft-software, which needs to be performant on the organizational budget/timeline level. This type of software engineering is more about glueing together hard software in the right way to solve business problems. Leetcode style interviews make no sense here, because the glue is usually bash or Python and it isn’t really doing much besides orchestrating hard software and delegating work to it.

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.

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.

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.

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.

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

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.

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

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.

The more you try to decrease false positives, the more you get false negatives, this is something taught in any intermediate Statistics class. Different people may have different opinions on what rate of false positives is acceptable but only ignorant can claim that you can eliminate false negatives "for free", without getting hit with more false positives.

The example given in my stats textbook was going on an expensive cruise and, as you ride to the port, you realized that you might have left an iron on (that was an old book, people used irons to make their clothes smooth). If you turn back then you miss your ship and take a loss on your whole cruise. But if you don't and the iron is actually on then you lose your house. So, do you want to take the false negative (the iron is off and you lost few grand you paid for the cruise) or the false positive (the iron is on and lost few hundred grand you paid for the house but, as a consolation, you enjoyed a cruise)?

Apparently businesses do not suffer from their preference to false negatives and there are not many (or any) companies with an easy interview process, which are also attracting many applicants, so the avoidance of false positives does not seem irrational.

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

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.

This is what we get for replacing education with googling... Are you suggesting replacing interviews with some other metrics?

He is suggesting that better methods of interviewing could increase “area under the curve”, improving both fase negative and false positive rates at once.

I understand that. But even if you come up with a classifier that gives better false positives and false negatives rates than the existing process, it's still going to be tuned towards minimizing false positives and leaving false negative to grow freely. My point was that only companies that do that became successful enough to attract a whole lot of applicants who fail interviews and complain about them on social media.

A good senior developer should be able to go out to lunch with a candidate and determine if they are a good fit. No need for coding tests. No need to sit in a small room and work out problems on a whiteboard or chat about your most difficult problem at your last job. Just get lunch. Any good developer can evaluate another developer after a few minutes of conversation, and you can tell if it's a reasonable cultural fit. Just lunch. That's all you need.

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.

This sounds rather holistic, and avoids many pitfalls of the "leetcode hazing" approach.

I do want to point out that anyone trying to line up their next job while staying employed, would probably not be able to take 2 weeks off their existing job. It would then come down to "quit your job and take a leap of faith".

Agreed, the requirement for currently employed people who have to take a leap of faith is the main issue with our hiring dynamic, IMHO.

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.

I love this analogy!

This year my employer started using Hacker Rank as a "step in the interview process". During the first dozen or so of interviews, most candidates ended up running out of time and "failing". Well it turns out, if you look at the data for that particular question from HR most candidates also failed. It was a terrible prompt with too much code to write. In our subsequent rounds, we told the recruiters to change those questions out, and regardless of someone passes let us review with them. We told our recruiting team if someone refuses to do let code/HR, that's okay if they have some code they're willing to share and discuss instead.

You write that you can’t do an O(n) search in 30 mins? Bro that’s just a single for loop.

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

As someone who is good at technical interviews, I am really confused by the assertion that they are checking if you have memorized the solution. In my experience, the problems have been either A) easy and I’ve never seen them before, where the goal is genuinely to solve it on the spot (“write a function to validate what a sequence of moves is a legal tic-tac-toe game”), or B) impossible to solve on the spot but I have the answer memorized because I’ve solved the problem many times in the past as part of the experience listed on my resume (“Dump a valid PyTorch training script for a simple MLP from your memory without consulting documentation” “Here is an obscure CMAKE error, explain what discontinuation caused it”)

How common in practice are these questions like “find the median of a list of sorted lists” that are both too obscure to get memorized in the course of day to day work, yet common enough that you could, if you wanted to waste time, memorize the solutions to all of them?

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.

Technical interviews are usually just made up, no science, no system, just a vague guess as to what to ask.

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.

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

Very good point.

A lot of bullshitters out there

Oh hey, it's me!

Don't get me wrong, I don't think I'm terrible at my work or anything, just slightly above average, while I'm a good order of magnitude better at interviews.

I don't know why, I just love them and I'm really good at weaving a story about myself and my fit with the company. (Don't worry, I'm never lying, just accentuating the commonalities.)

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

To be honest, most of the times when I did get feedback I found it varying levels of patronizing, bewildering, or even downright rude. Most: not all. There are exceptions. But as a general rule, I think candidates are better off without feedback because most of the time it's just going to be garbage.

Other than this fairly minor point I agree with you. Over the years I've worked with several senior developers who have needed hand-holding every step of the way, sometimes for the most basic of stuff, on everything they do. Furthermore you don't just want to filter out the incompetent but also the assholes, which is an even harder problem.

The intractable problem is there is a vast, opposed gulf between "interviews that are measurable, that HR can use later as collateral against anti-discrimination lawsuits" and "interviews that are effective at hiring a person for a role".

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

I'm not saying they're frivolous.

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

I'm not saying they do or should. I'm saying they apply pressure to standardise evaluation, for not terrible reasons, but probably at the cost of finding worse candidates than the best possible ones that could be found with more bespoke/hard to standardise interviewing.

We need solutions, an alternative

I actually haven’t seen algorithm questions a lot lately, so that’s progress, but even building something live can trip you up

Reality is that 45 minute speed trial would be given several days in sprint planning

We should simulate the sprint ceremonies and repository management more than code. Make their commits break because of a poorly documented linter they have to get around. That will fix their code along the way

My brother and I came up with an interview process for help desk positions many years ago. It was sort of an open-book exam. He set up a computer and a network printer. I believe he purposely misconfigured something with the networking of the network printer, possibly one other issue too.

They had 1 hour, utilizing any resource on the internet they wanted, to correctly configure the network printer. If they completed it, great, if not, he'd go through and see what their troubleshooting process was, what they researched, etc.

This type of interview worked really well for hiring help desk staff, but obviously hiring a software engineer and evaluating them is much more difficult.

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.

Hiring in many companies ranges from suboptimal to fully broken but in the (macroeconomic) situation when each opening gets lots of candidates it is unlikely to change, unfortunately.

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

Lots of rounds and coding tests have two disadvantages - they consume a hiring company resources and they put-off good candidates. And about 2nd problem companies care less now because they still can find good candidates even if some of them will not jump though all hoops. Hiring being a big resource drain is still a problem of course.

I have some idea who I’m connecting/interacting with and how they communicate. I have some knowledge of the problem space, how we got here, and why we are solving this. It is unlikely this is the first time hearing of this issue. I know the team and/or technologies which will likely support the solution. I know the broader org goals and direction that might affect choices. I have safety to ideate, iterate, and draft solutions.

This is basically “hire me and you’ll see”. Well, the perspective of an employer is that 80% of candidates say so and only 20% of them are worth anywhere near their desired comp. I understand the sentiment, but learn to show yourself before the marriage even if that’s no use afterwards.

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

Reply on news.ycombinator.com