Hacker News Reader

Comment by ketzo | Hacker News Reader

I know you think you’re making a “cynical but rational” kind of argument here, but man, this comment is a huge fucking bummer.

You’re acknowledging that you have the both the ability and the knowledge to change (your small part of) a shitty system, and instead you’re pulling up the ladder behind you. That sucks.

You should not let yourself feel good about that, even if it’s “economically rational” or whatever.

You’re making things just a little worse for everyone but yourself — actually, even for yourself, too — and trying to excuse it with “well, that’s just the way things work!”

View on HN

You'll feel better when you see some of my other comments. I'll paste it here for you:

> What’s your suggested alternative? In my experience, any alternative to leetcode provides a better signal-to-noise ratio. You are better off asking trivia questions.

Additionally, this is the common narrative among leetcode advocates - "If no leetcode, then what?" As a hiring manager, you think harder and do better, that's what.

> Please remember that while some of us would do well and prefer some live pair programming or debugging sessions, it stresses the hell out of some folks and penalizes them unfairly.

So does leetcode. And a candidate that is truly a good fit for the role would be more at ease with the interview than if they saw a leetcode question they haven't seen before.

> Take home tests penalizes people with families and other responsibilities...

So does studying for leetcode for hours.

> ...and probably has a racial bias as well in countries where different races have different societal loads.

Share some sources before making a claim this ridiculous.

> In the end, even if these coding challenges might not reflect the actual work you do, they might still be predictive of success in the job, as much as any other method can be when we look for unbiased markers.

In my 6-ish years of experience, this is false. I have actually tested this theory in practice, and through my anecdotal experience, leetcode is a poor signal for job performance.

I can usually usually accurately screen a candidate for success in about 45 mins. And, unlike leetcode, you can't pretend like you haven't seen the question before, bc I can push the candidate to their limit, which is where you will find hire / no-hire signals. I love talking about this stuff, but I find that my peers engineering peers do not give a shit and would prefer to stay in leetcode hel

What do you suggest instead?

Make the pie bigger.

I mean, I don't even have to suggest; I can let the OP suggest instead.

> Having an interview process that is artificially arduous

Make your interviews less artificially arduous.

> way outside the expectations of the job duties

Re-design your interview questions to be more in line with the actual job.

> leetcode monkeys who can barely deploy and manage k8s cluster on AWS

See previous suggestion.

If you want my personal suggestions on interviewing better:

- Interview for problem-solving process, not just for correctness. A candidate's ability to solve an algo problem in 45 minutes is much less important than their ability to calmly, thoroughly, and clearly explain the way that they think.

- Tune interviews to the role at hand. This should be obvious, but for some reason full-stack web devs still have to pretend like dynamic programming is a big part of their daily work.

- More systems interviews. I find that it's much harder to bullshit/memorize here, at least not for very long.

- Interviews based on actually building stuff. "Hey, here's a super simplified version of a feature someone in your role built last month. Can you walk us through how you would build the same thing?"

Interviewing is hard. It's not that fucking hard. When someone is out here complaining about what they see as obvious flaws in their process, and then decide that the best course of action is to "gatekeep as long as others play too," it just reeks of laziness and self-interest.

This does not get better unless individuals decide to start making it better. That's my biggest suggestion, really; don't become a cog in the machine. Every single interview that you, personally, conduct has a small but meaningful impact. It's up to you to have that impact be positive or negative.

> Tune interviews to the role at hand. This should be obvious, but for some reason full-stack web devs still have to pretend like dynamic programming is a big part of their daily work.

This personally hurt :)

Completely agree with you on everything you've written.

> leetcode monkeys

I hate this from someone who manages interviews. They are leetcode monkeys, because they are not dumb and this is what gets them rewards and jobs. If he changes the criteria, they will change what they spend time on.

But, instead, he chooses to insult them ... for doing exactly what he rewards.

This means all salaries go back to 100k. The salaries in silicon valley normalize with india.

I don't hate leetcode, but I'd really rather do interviews in one of these ways

1. Rely on referrals from people I trust. If somebody I've worked closely with and respect highly says that Person X is awesome, then just hire Person X. This obviously has massive problems with creating an insular culture and only works for people with a sufficient professional network, but it is incredibly high signal.

2. Have a long conversation with the candidate. Discuss their prior experience and war stories. This can be gamed, but I suspect is harder to game than leetcode.

Both of these options have a big problem as they scale, which is that interviews do not transfer. You need the hiring manager to do this interviewing. Making every hiring manager at a 100,000 person company do their own sourcing and interviewing is going to be a mess. Megacorps want to allow anybody to interview and then once somebody passes those interviews, they'd be able to join any team. I have mixed feelings about this approach.

So the best option IMO is two 2-3 hour pairing sessions. Refactor some code, develop a feature, and diagnose a bug. Have the person comment on the architecture of the code or system they used and describe large scale changes they'd make to improve it or prevent it from arriving at this state.

This requires more pre-work since you need to create an entirely working fake system and environment. And since there is a huge incentive to practice for these things, people would definitely sell knowledge about the fake system. It is also higher variance when there are new interviewers, since they represent a larger portion of the total interview panel.

Reply on news.ycombinator.com