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

661–670 of 675 posts

Re: Stop Interviewing with Leet Code

#661

Post by mbrodersen »

dekhn wrote: post #481
cadr wrote: post #408

Earlier quoted context omitted.

I agree liking to ask simpler stuff first. But what about this more complicated stuff? My problem is that when we talk about stuff having more "signal" - how are we determining if those questions are giving us more signal?

My question is fairly open and allows me to continue asking significantly more complicated questions. So far, nobody has (for example) asked enough clarifying questions to determine that a bloom counting filter could potentially solve the problem- most people just store ASCII string keys in a hash table, which wastes tons of memory and requires a lookup for every string. So usually I end up after 45 minutes finding t…

I hope you realised that your questions are extremely narrow and in no way filter for competent developers. Imagine yourself going to an interview and being asked similar narrow specific questions but in a different area you have no previous experience in. You would probably fail. For example: how would you represent a lambda closure when compiling a functional language to machine code? It is a super easy question for me but I know most people would fail. So I don’t ask questions like that when interviewing.

Re: Stop Interviewing with Leet Code

#662

Post by mbrodersen »

dekhn wrote: post #588
lazyant wrote: post #573

Earlier quoted context omitted.

The problem with this question is that outside the junior people who won't understand the hints, many good programmers would pass or fail just based on whether they have seen a similar problem or know what a Bloom filter is. CS is so broad that you may have been working for many years and never come across one topic that the interviewer deems standard.

I don't fail people who don't suggest a bloom filter. What I meant was: knowledge of probabilistic data structures and knowing this is a situation where they could be used is a sign of a more experienced programmer (likely one who's worked in clickstream processing). If all you do in my interview is know that a hash table or other associative data structure is good for maintaining counts, that using a full ASCII byte…

I am 100% certain that your questions are not giving everybody a fair chance to shine. You have to start with the area of expertise they have already worked in and not the area that you happen to have experience in or be interested in. I could (for example) ask “simple” dynamic optimisation questions that are “easy” for me and I know that 95% of great experienced developers would fail. So obviously I don’t do that. I want to hire smart developers who can learn. Not developers who happens to have the same experience/interest that I do.

Re: Stop Interviewing with Leet Code

#663

Post by akhmatova »

dekhn wrote: post #397
cadr wrote: post #387

Earlier quoted context omitted.

Can you share what kind of things these are that give far more signal?

To be honest? every programmer needs to be able to pass FizzBuzz. Beyond that, I add some more basic work around byte representations of data (I have 4 symbols... how many bits do I need to encode a symbol?). I will typpically also include one major bug in a piece of code and ask the user to identify it (with hints). I once interviewed a guy- a CTO at a biotech- and he wouldn't answer the question "I have a million D…

I once interviewed a guy- a CTO at a biotech- and he wouldn't answer the question "I have a million DNA sequences and want to count the number of occurrences of each sequence" (could be hash table, could be any number of other solutions; he just balked and exited the interview).

Maybe he's just been around the block a sufficient number of times to have gotten tired of the standard SV "here's a hoop, jump through it, now do it again, and again and again" ritual that it likes to call "interviewing" for some reason.

Seriously - your questions are fine for junior or mid-level roles, but beyond that, you should have more important thinks to talk about. And both of you should be able to tell if the other is a bullshitter and/or a lightweight within about 30 minutes at most (and often far quicker than that) of a normal, focused technical conversation -- without having to specifically grill the other person, or otherwise put on the pretension that you're one whose bona fides are established beyond question, and they're the one who needs to jump through a sequence of hoops to prove that they are worthy of your time and attention.

Just cut the crap, get down to brass tacks, and talk what needs to be done as if they're a peer. That's all you have to do.

Re: Stop Interviewing with Leet Code

#664

Post by akhmatova »

jboy55 wrote: post #359
jmvoodoo wrote: post #244

Earlier quoted context omitted.

I wonder which came first? Did they hire those people because they implemented leetcode style interviews, or did they implement those interviews because they originally hired or were founded by ex-bigco folks that simply did what they knew?

Perhaps there's another collectively shared work experience that also created leetcode style interviews. That is dealing with someone who has a degree, can speak well of what it takes to code, but who cannot code to save their life. I have known more than a dozen such "engineers". That's the reason you code during an interview, I think the emphasis on optimal O(N) is just a set of engineers who don't believe it shoul…

I will google it for you if you don't remember the syntax.

You might as well just stand behind them and breath down their neck for added effect.

Seriously, that's way too claustrophobic, and not to mention a huge practical annoyance -- for the added latency of having to ask you to google stuff for them and then give you the result somehow, instead of just letting them do it themselves, when all they want to do is get past this trite exercise and start having a real conversation.

Re: Stop Interviewing with Leet Code

#665

Post by akhmatova »

moduspol wrote: post #207
brhsagain wrote: post #148

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 measure…

It'd be a fun social experiment if one of the big tech companies replaced the leetcode-style rounds with something arbitrary. Let's say: The "jumping jacks" round. You have to turn your webcam on and do 100 jumping jacks in 60 seconds. Only then will you potentially advance to the next round. The person watching on the other end can evaluate how far over 100 you got, whether or not your form matches best practice, an…

I like that idea. It pretty much performs the same basic function that LC advocates say that it does -- "Okay maybe it doesn't really measure useful skills, at least not in proportion to how they're actually used, but hey, it at least measures their determination to get the job, and their willingness put up with utter nonsense, which is of course hugely important to us" -- and is much quicker. At at least gets you out of your chair, and your circulatory system refreshed and oxygenated.

Re: Stop Interviewing with Leet Code

#666

Post by charles_f »

throwaway0x7E6 wrote: post #549

that's an engineer's opinion about things beyond his understanding 75% of fresh grads are below mediocre, to put it very mildly. 50% of candidates with a seemingly OK employment record or portfolio are too. leetcode filters them out right away. that's the purpose it serves. it's not there to get you good candidates, it's there to make sure that you only spend time interviewing potentially good candidates. I would agr…

That's a Microsoft engineering manager's opinion formed over his understanding over his past 10y of hiring. Leetcode doesn't act as an efficient filter. If you want actual talent you need to put effort into it.

Re: Stop Interviewing with Leet Code

#667

Post by charles_f »

bena wrote: post #270

> All starts with showing some code, a class that does some stuff and its corresponding tests. The code is not glaringly bad, but it’s also not great on purpose. [And all that follows] This is worse than LeetCode in my opinion. Because all it is, is a shallow copy of LeetCode. You've constructed a puzzle by laying out a picture and cutting out particular pieces. It's "find the differences" between what you've given t…

> And the landscaper will walk. They will not work for free. They'll give you references, they'll show you pictures of work they've done before, but they won't do work for you.

I didn't make this one up. That's how one of my friend got interviewed for his current job as a landscaper, he actually worked with the company for a day.

Re: Stop Interviewing with Leet Code

#668

Post by charles_f »

skeeter2020 wrote: post #143

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.

I'm making the complaint as a hiring manager that this gives bad results.

Re: Stop Interviewing with Leet Code

#670

Post by democracy »

lkrubner wrote: post #249
brhsagain wrote: post #148

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 measure…

The idea that companies are using leetcode tests for rational reasons goes against everything I've seen and experienced or read about. What I have seen, working at startups for more than 20 years, is irrational, self-destructive behavior, over and over and over again. I've worked with many entrepreneurs who have a few million dollars in the bank, and they have a great idea, but they self-destruct due to two big reaso…

Thanks for recommending "How to Destroy a Tech Startup in 3 Easy Steps" - loved it!

edit: sorry, just realised you are the author!! (lack of sleep - not work related ))). Great reading, really enjoyed it. "Sital" gonna be used as a nickname )) Thanks mate! :praise

Post reply on HN