Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Stop Interviewing with Leet Code

fev.al

Post reply on HN
Print view View original

141–150 of 675 posts

Re: Stop Interviewing with Leet Code

#141

Post by skeeter2020 »

bruce343434 wrote: post #129
okeuro49 wrote: post #120

Earlier quoted context omitted.

I have over a decade of experience, including driving big technical change at one organisation, and was filtered out by a timed leetcode test. I put together a repository of leetcode practice, as I had a feeling that I would have bad luck on the day. They didn't look at this. The internal recruiter said it kept happening for seniors and people with a lot of experience, but his hands were tied, as the leetcode process…

>it kept happening for seniors and people with a lot of experience Why would this be? Old brains not being as "flexible" to think up novel solutions?

You think LeetCode problems require novel solutions? It's the exact opposite: they're great for new grads who just spent 4+ years cramming for exams.

Re: Stop Interviewing with Leet Code

#142

Post by aitchnyu »

djstein wrote: post #2

I've decided I'm going to start interviewing with a set of PR's per each role we hire for. each PR will have obvious mistakes, complicated logic problems, as well as code that could be "refactored" once the whole PR has been read. this provides a few things; it gives us an ability at how the interviewee problem solves. next we can see how they respond too obvious fixes (would they be someone you'd want to send a PR t…

I once a test with badly written code and gave my comments. A bot immediately asked me to implement those changes, but I assumed a human would respond. I made a YAGNI change, trying not to disturb existing code too much. They responded saying the comments raised during PR were good, but writing a big switch statement for all subclasses violates Liskov Substitution Principle.

Re: Stop Interviewing with Leet Code

#143

Post by skeeter2020 »

Not arguing that LC problems are a poor, degrading way to filter but every single post HN about how "interviewing is broken" assumes the process is targeted at the applicant's experience. I don't hear HR departments making this complaint.

Re: Stop Interviewing with Leet Code

#144

Post by bigpeopleareold »

Dowwie wrote: post #75

Someone who builds a truly novel technology solution involving hundreds of hours of effort gets filtered out of an interview involving contrived scenarios. You may have built the next generation X, but given an array of strings and a fixed width, can you format the text such that each line has exactly maxWidth characters and is fully justified -- in the next 30 minutes? Maybe you should have cultivated that skillset…

I don't do leetcodes because I am not really into programming puzzles (or parlor tricks :D ), but I roughly tried to do what you described. ~45 minutes it took, deciding in the middle to not worry about the algorithm. Guess I won't get the job ... shrugs.

Re: Stop Interviewing with Leet Code

#145

Post by revskill »

My favorite style of interviewing is through reviewing existing codebase, then ask question on it. Then i'll ask candidates how to improve their codebase (or someone else code).

If possible, i'll let them code some small functions and ask them how they gonna do the unit test.

To me, refactoring skills is a must, as most of engineering work is on refactoring.

Re: Stop Interviewing with Leet Code

#146

Post by l-lousy »

UncleMeat wrote: post #139
pojzon wrote: post #136

Earlier quoted context omitted.

This reminds me of creator of „brew” who got declined by Google because he couldnt write a reverse binary tree search in 1h. Dont mind that half of Google is using his work for free.

That wasn’t actually true. He later said that he wasn’t asked to invert a binary tree. Also, nobody at google is using homebrew for work.

Anyone using a Mac for tech related jobs has a high probability of using brew. That includes a lot of googlers

Re: Stop Interviewing with Leet Code

#147

Post by ChrisMarshallNY »

sdrothrock wrote: post #21
lbriner wrote: post #13

These articles always seem to have an underlying assumption that really great people are being denied access to jobs because they can't get through these interviews but it is implying that the people who do get through these are not also great but are less hassle, easier to measure their ability and so what if they have swatted up on LeetCode to help their application? That means they are driven, that they have learn…

> I am also not sure of any good alternatives because someone will always object to any alternative which they cannot achieve for some reason. When I was on the market, a couple of companies actually gave me a variety of options, which I appreciated. I don't want to spend hours on a take-home and I also don't want to do leetcode, but an open question/answer plus some code review and live debugging was an acceptable c…

> When I was on the market, a couple of companies actually gave me a variety of options, which I appreciated. I don't want to spend hours on a take-home and I also don't want to do leetcode, but an open question/answer plus some code review and live debugging was an acceptable combination for me.

That sounds excellent!

This would allow the company to determine what the applicant believes is their strongest suit.

Then, when it comes time to sit down as a team, and review all the "top shelf" applicants, people can decide, based on a number of criteria.

If an applicant avoided technical challenges, but spoke well, then some managers might like that, but others, might not be comfortable. Maybe they might devise a technical challenge, customized to the applicant, and using real-world problems.

The main deal, is that the vetting has been done. The chaff has been filtered out, so more attention can be paid to the wheat.

At my old corporation, headcount was something I had to fight like crazy to get (I was a manager). We seldom hired, so it was well worth it to spend a great deal of time on each candidate, as they would be responsible for important work, and would have a great effect on the corporate bottom line.

That sounds like a lot of small startups, to me. BigCorp (MAANG, et al) hires thousands of engineers per year. They need to have a cookie cutter system. Smaller companies do it, simply because they want to be like the Big Boys.

Also, and this is neither here, nor there, but binary tree tests are a great "young-pass filter."

Re: Stop Interviewing with Leet Code

#148

Post by brhsagain »

All of these supposed "flaws" of leetcode are by design. Big companies want people who are smart enough to do the work, but obedient enough to put up with all the bullshit that comes with working at a big company. What person better matches that than someone who's able and willing to study for and pass a tech version of the SAT? Every anti-leetcode article I read is some version of "leetcode is bad because it measures the wrong things." No, we all know it measures those things, and those are exactly the things the measurers want to measure.

You might ask, so why do startups do leetcode too? I heard startups are supposed to be, uh, innovating, developing new technology, and working on hard, meaningful problems? Shouldn't they want brilliant, super effective people, instead of smart-enough, obedient workers? Apparently not. Apparently they want the same workers bigcos want. The implication of this is left as an exercise to the reader.

Re: Stop Interviewing with Leet Code

#149

Post by TrackerFF »

nivenkos wrote: post #22

It's much better than the alternative and ideally only one part of the interview process. Ultimately the proof is in the pudding, I've had loads of candidates that could barely code and Leetcode-style problems are a great filter against that. Otherwise you risk just getting PM-style bullshitters as engineers, who talk persuasively about projects that other people actually implemented.

There's quite the distance between FizzBuzz and LeetCode medium/hard questions. If you want to filter out candidates that barely can't code, just have them walk you through a small code-base containing bugs.

What does the code do? Does it work? How would you get it working? How do you test it? What is the complexity? etc.

Re: Stop Interviewing with Leet Code

#150

Post by koonsolo »

quickthrower2 wrote: post #94
gspr wrote: post #89

Earlier quoted context omitted.

Exactly. Give a simple coding task that the candidate does on their own time (but not one that's too complicated, it's rude to waste the time of people who aren't even working for you), and then, crucially , have them briefly explain their solution during the interview. The task can be so easy that reasonable solutions are just 10-50 lines of code – my experience has been that people's explanation of their own work v…

What if that test was done once by an external company, and then the stamp of approval is good for a year of job interviews. That would save the candidate and interviewer a lot of hassle!

I agree. You would expect that from a bachelor or master degree. But nowadays you have a lot of people coming out of coding bootcamps, and their level can vary a lot.

A hole in the market!

Post reply on HN