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

181–190 of 675 posts

Re: Stop Interviewing with Leet Code

#181

Post by bpicolo »

gitfan86 wrote: post #172
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 seems like a huge inefficiency in the economy that thousands of people are studying and practicing for an entrance exam that has no value in the real work that the companies actually do. But overall that may be a good thing for society. If Google fired all their leet coders and replaced them with real engineers they would not need as many. And the biggest problem may be that there is a limited number of real engin…

> replaced them with real engineers

nice gatekeeping. Shame on them for working to get a job they want.

Re: Stop Interviewing with Leet Code

#182

Post by shrimpx »

natly wrote: post #109

To be honest if I was an employer I probably would do leet code or similar. The logic would be that yes, many engineers are shy or nervous around people. But losing those is worth it since hiring someone bad that you have to fire (that wastes some months of productive time at the company) and then re-hire someone else is definitely worth that risk. Having made something impressive on github is somewhat fakeable since…

> get a lot of help from the internet

But this exactly what they’ll do on the job. Actually, searching for help and distilling what you’ve found into a clean solution is a skill in itself.

Re: Stop Interviewing with Leet Code

#183

Post by slig »

onion2k wrote: post #170
ushakov wrote: post #158

Earlier quoted context omitted.

startups need even more obedient ones those who will overwork, be on call 24/7, doing 10 men's jobs at once and can tolerate abuse from managers, because you want your stock options to vest

doing 10 men's jobs at once 10 what now?

Ten male humans.

Re: Stop Interviewing with Leet Code

#184

Post by sdevonoes »

hiq wrote: post #88
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…

> Someone who builds a truly novel technology solution involving hundreds of hours of effort This person should already have enough of a reputation to get a job at many companies, if their work is public enough. What do you suggest for the 99%+ other candidates?

> What do you suggest for the 99%+ other candidates?

To apply for the 90% tech companies out there. 10% of all tech companies out there are FAANG or FAANG-like. 90% of tech companies are normal tech companies (they'll care about your education and cv and the interviews are usually just a chat. No IQ tests)

Re: Stop Interviewing with Leet Code

#185

Post by myth_drannon »

ushakov wrote: post #158
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…

startups need even more obedient ones those who will overwork, be on call 24/7, doing 10 men's jobs at once and can tolerate abuse from managers, because you want your stock options to vest

That's why they hire only 10xers, so they CAN do a work of 10 men!

Re: Stop Interviewing with Leet Code

#186

Post by blueflow »

bpicolo wrote: post #181
gitfan86 wrote: post #172

Earlier quoted context omitted.

It seems like a huge inefficiency in the economy that thousands of people are studying and practicing for an entrance exam that has no value in the real work that the companies actually do. But overall that may be a good thing for society. If Google fired all their leet coders and replaced them with real engineers they would not need as many. And the biggest problem may be that there is a limited number of real engin…

> replaced them with real engineers nice gatekeeping. Shame on them for working to get a job they want.

After seeing all the unreliable and buggy software, i think more gatekeeping in IT would probably be beneficial.

You wouldn't let someone do surgery on you that hasn't been to medical school.

Re: Stop Interviewing with Leet Code

#187

Post by PragmaticPulp »

kanonieer wrote: post #152

Considering the normalization of spending hundreds of hours grinding LC questions and the industry built around whiteboard interview preparation, my (n=1) conclusion is that LC interviews is not about technical assessment at all. It's an assessment that's designed to find people who are ready to submit to an endless grind with little to no skepticism. Developers who question the technical usefulness of LC interviews…

> Considering the normalization of spending hundreds of hours grinding LC questions and the industry built around whiteboard interview preparation, my (n=1) conclusion is that LC interviews is not about technical assessment at all.

The “hundreds of hours” grinding LC is largely for juniors without experience. I don’t know any senior engineers who had to grind LeetCode like that for their FAANG interviews.

Re: Stop Interviewing with Leet Code

#188

Post by lentil_soup »

charcircuit wrote: post #25
bil7 wrote: post #18

Earlier quoted context omitted.

if the "simple questions" are realistic problems they might face day to day, fair enough. But the classic example in these articles is an exercise like invert a binary tree, which most people never have nor will need to do, making it a poor test.

>which most people never have nor will need to do That doesn't mean that someone would be unable to program it. Inverting a binary tree tests if you know how to traverse a tree. I may not traverse trees all day at work, but I can easily do a tree traversal if I needed to and I expect that to be true of most people who can actually program and not just talk the talk.

sure, I often have to do tree and graph traversals in my day to day but, I will 100% fail to do that under pressure with people looking at me and expecting me to "talk throught my thought process".

If you really really care about me traversing a graph, leave me alone with the task for a while, let me take my time, give me access to the internet even. Why do you care that I can write it on the spot? If anything that just proves that I memorised it just before the interview, not that I actually had to think much about it

Re: Stop Interviewing with Leet Code

#189

Post by throwaddzuzxd »

Doolwind wrote: post #104
throwaddzuzxd wrote: post #96

In my team we do technical interviews in three steps: - an algorithmic challenge. It's related to what we do day to day. I work in domain names so we ask to parse a domain name. There are oddities with domain names so we check multiple things: does the candidate know what basic string manipulation functions exist? do they ask questions to get more info? how do they react when we give additional info that break the co…

I really like the refactoring challenge idea. Any tips on what’s worked or not? Do you do domain specific code or try and keep it generic? I think having them not write code is particularly good way to handle this.

> Any tips on what’s worked or not?

- Showing code is optional. A bit of storytelling to set the scene is enough. So you can keep it generic, or you can add some details, as you wish! Just make sure that the candidate understands the scene. If you present something generic and feel they don't understand, tell it again with more details. If you think you've lost your explanation in details, start over with less details.

- Be sure to know what answer you want. The number 1 thing we want is for the candidate to talk about adding (non-regression) tests. But the candidate can talk about many different things: profiling, tracing, A/B testing of the new implementation, etc. If they don't talk about the #1 thing you want, try to subtly bring them to that point ("how do you ensure that the new implem works as well as the previous one?")

Not specific to the refactoring challenge:

- Ask for feedback. After each challenge, we ask the candidate their honest opinion on the challenge.

- Grasp a feeling of whether or not you'd like to work with this candidate. Try to challenge them, correct them, ask them to explain things in more details and see how they react.

- We do it with 2 interviewers: main and observer (watcher?). Both from the technical team (so 2 devs). We encourage anyone from the tech team to do it if they want, even juniors.

- We do the 3 challenges in 1 hour but that's a bit short. 1h30 would be better, if the candidate is ok with that.

Re: Stop Interviewing with Leet Code

#190

Post by Kaze404 »

mellavora wrote: post #60
seer wrote: post #38

Earlier quoted context omitted.

People who can do leetcode challenges are only roughly correlated with great engineers. The more I learn about software development the more I try to _not_ have leet code style parts in my code - in the very rare circumstances would I see something like that and say - yes there is _no_ other library out there that has a battle tested algo to solve this particular problem, _and I have to code my own_. Worse people who…

> c) but I've put a human being in a very uncomfortable position just to _test_ them. There _has_ to be a better way. > ... > Or even "hire fast fire fast" approach works too. Comment "c" shows a high level of care/concern for the candidate. "hire fast fire fast" does not. What if the candidate left an unsatisfying but steady job to join your company? And they get fired in the first few weeks. Now they are unemployed…

I believe the assumption here is that the candidate would be made aware of the circumstance.
Post reply on HN