Hacker News Reader

Comment by mynameisash | Hacker News Reader

My beef with the leetcode interviews is that, IMO, they're in no way reflective of what you're actually going to do, and yet the interviewer often acts like it's a perfect barometer. One misstep or quibble and you're out.

I remember when a former colleague wanted my input on his interview question which was basically, "Write the algorithm for product recommendations." (eg, like Netflix's movie recommender.) Despite repeated warnings, he went ahead with that question only to come back and admit, "Yeah, that wasn't at all good." Imagine what the poor guy or gal on the other side of the table had to go through.

I don't know what the right answer is to interviewing, but my take is that I would prefer to work with someone who I can get along with, have real human conversations, and become good collaborators -- even if they're not ace coders. That measurement seems glaringly missing from too many interviews.

View on HN

I've consulted with quite a few companies on their interview process. Almost all of them had adopted Leetcode style interviews. My first question to the team always is: what exactly are you evaluating when you interview someone?

And I rarely get an answer that makes sense. Instead I get mostly rationalizations for Leetcode. The thing is I recognize those rationalizations because I was certainly guilty of it in the past ("We're evaluating intellectual curiosity" is one I cringe at now).

The real problem from my perspective is that most teams have never taken the time to really think about and identify the underlying principles about how they want to work. We go through a process of defining those principles and all of a sudden the interview gets a lot clearer. Do you value the highest quality code? Do you value getting things into the world quickly and then iterate towards the final solution? Is security always at the front of your mind?

Getting really specific about what exactly being "excellent" means to a team is really critical.

Because then you can design an interview process that actually selects for those things. I've never had a team define "the ability to solve leetcode problems under pressure quickly" as an endpoint they actually care about. Some teams continue to use leetcode, but only as a small part of the process with problems that ARE actually directed at what they care about. Having been through a bunch of interviews in my 25 year career I instantly know when a team has actually done the work to design a good interview process (which has been far too rare in my experience).

My company has an incredibly detailed rubric for what is meant to be evaluated. It still sucks.

It’s hard to admit that they don’t actually know how to evaluate people well and instead implement an absurd level of inefficient gatekeeping. The same reason some jobs only hire people with degrees even if it’s not necessary or the degree is irrelevant.

It's not just that they don't know how to evaluate: often they don't even know what they are looking for.

Yes! This is exactly it. Very few teams that I've worked with had actually defined what is even important to them.

Leetcode interviews don't test if you're a good software developer, they test whether you're capable of becoming a good developer. The skills required to succeed at leetcode basically come down to 1. willing to spend 100 hours studying/practicing 2. Baseline critical thinking skills. Throw in some behavioral to make sure they can communicate and those are basically the skills needed to become a decent developer.

That actually sounds like quite an interesting and fun interview question, why did it go so badly?

Wasn't there also an issue with companies trying to interview people and asking them questions like that, not as a way to hire anyone but as a free way to get smart people to solve some of their software problems?

or trying to glean proprietary information out of others?

> Wasn't there also an issue with companies trying to interview people and asking them questions like that, not as a way to hire anyone but as a free way to get smart people to solve some of their software problems?

It's a struggle between fitting the interview to real-world situations vs making it seem like the candidate is doing work for the company.

I feel like a good situation might be actual problems previously encountered with the technology being assessed during the interview that would've required you to have collaborated with someone who is also experienced in that technology to help you solve them.

Maybe the best way to do this is when the situation is proposed to the candidate, make it clear that the answer is already known and put it in an envelope (physical or digital), which will be referred to when it's solved or the candidate hits a dead-end.

I don't think anyone cares if you can actually solve the problem. They are looking to see how you perform under pressure (not because the job is necessarily stressful, but because we can learn a lot about a person's true personality when they are under pressure), how good you are at problem solving, whether you actually know anything about coding or are just BSing, etc.

This is the ideal, and the original point of such questions (I was at a FAANG and interviewing candidates when they started becoming popular), but the inevitable result is that the test becomes interpreted more literally as it becomes more common.

"but because we can learn a lot about a person's true personality when they are under pressure"

Do you have a source for this? I can't help but think about the person in this clip: https://www.youtube.com/watch?v=LlCEmPF4-V0. You think you can learn much about her from that interaction?

This is such a perfect distillation of the problem.

While what you say is the ideal situation, I think being able to get the optimal solution and giving at least a halfway decent explanation about why it works is the #1 most important thing (along with just plain old not being a jerk).

I acknowledge there are some situations where you might pass the interview even without arriving at the optimal solution, but those are probably the exceptions.

But, why? I've never seen one of these questions that mimics an actual real world work problem.

Just being IN the interview to begin with is likely to be higher pressure than any sane or sustainable working environment would be.

I've interviewed people who didn't know the answer to some of these tech questions, and honestly, I was more impressed by them calming saying "I'm not sure on this one, I would probably need to go look it up".

I used to be quite stressed-out by job interviews, until I realised a small crucial thing... If you're interviewing while employed (which, to be fair, is not a luxury everyone has), the absolute WORST outcome of that interview is "I am given an offer".

Why worst? If you're not given an offer, nothing changes. You've spent somewhere between 45 minutes and a day, got some interview practice and all is basically status quo. But, if you're given an offer, you are now faced with having to weigh the pros and cons of accepting it.

Different people will experience different levels of pressure. Interview pressure is not the same as deadline or project pressure

Reply on news.ycombinator.com