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

341–350 of 675 posts

Re: Stop Interviewing with Leet Code

#341

Post by sithlord »

nivenkos wrote: post #47
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…

I think it's fair to do two Leetcode Easys - ideally with problems that allow you to ask further questions about memory management (when are allocations triggered, etc.), recursion, stack frames, adjacent memory location for efficient reads and so on. The problem is that a take-home task can be impossible for some people already in a full-time job with kids, etc. and so has its own bias. And the "hire fast fire fast"…

Then part of the process should be to allocate part of the interview schedule to the take home. Say, 1 hour interview block, at minute 1 candidate is sent an exercise and at minute 45 a zoom call starts to discuss things.

That way, some of the pressure is off of coding with someone looking over your shoulder, and you still have time allocated off already.

Re: Stop Interviewing with Leet Code

#343

Post by UncleMeat »

sinop2 wrote: post #254
UncleMeat wrote: post #178

Earlier quoted context omitted.

Google doesn't allow any code on laptops. Everything is done via web IDEs or ssh into a linux machine. So nobody is using brew to obtain dependencies.

That seems unlikely, given that they’ve implemented an Xcode project generator for iOS apps built with their build system: https://tulsi.bazel.build/ No one’s running Xcode on the web or on a Linux machine.

The mac build system is wild. It is still all done remotely with a farm of macs running xcode. You still don't build code for running on macs on your local machine.

Re: Stop Interviewing with Leet Code

#344

Post by begueradj »

Such algorithmic tests are used by FAANG as a means to discriminate candidates based on age:

For example, if they want to get rid of old candidates, it's easier to do it by asking them to implement a BST algorithm which a freshly college graduate could do easier.

Re: Stop Interviewing with Leet Code

#345

Post by UncleMeat »

EdwardDiego wrote: post #215
sumeno wrote: post #213

Earlier quoted context omitted.

They are correct. Stuff like project zero is an extreme outlier. I've been using a MBP for 5 years and have never used homebrew on it.

Cheers for clarifying :) I'll admit that surprises me greatly, I can't see why it's considered more efficient, but hey, Google.

Google has a giant monorepo. It is too big for git. (Virtually) everything is built from source. Building a binary that just runs InitGoogle() is going to crush a laptop.

I believe that there are also a bunch of IP reasons for this policy, but from a practical perspective doing everything with citc and blaze is really the only option.

Re: Stop Interviewing with Leet Code

#346

Post by UncleMeat »

corrral wrote: post #332
UncleMeat wrote: post #176

Earlier quoted context omitted.

Google doesn't allow any code on laptops. Everything is done via web IDEs or ssh into a linux machine. So nobody is using brew to obtain dependencies.

You shouldn't use Brew to obtain dependencies. This is how you end up with people complaining about a brew upgrade replacing the version of Postgres their project depends on. You probably shouldn't be using dpkg or rpm for that, either, unless your CI and deployment targets are running the exact same version of Linux that you are, and even then—there are usually cleaner and more cross-platform/distro ways to do it, e…

That's fine, but almost nobody is running tools on their MBP. So for this sort of thing you'd be using the package manager distributed with glinux. And Google is also a really weird island where tons of tools are custom. You cant use some open source tool for git bisecting because Google doesn't use git. You cant use some open source tool for debugging because borg is a weird custom mess and attaching debuggers requires specialized support.

Re: Stop Interviewing with Leet Code

#347

Post by TrackerFF »

tomp wrote: post #308

> So What To Use Instead? > Deal with ambiguity, Reviewing code, understanding what it does, finding gaps, Testing, Code structure, Cleanliness, Learning new concepts Yeah, no. A lot of these are culture. I'm fairly confident I can teach someone smart and competent to write clean code, add tests, and properly modularise the project. It's called training (progression from "junior" to "senior"), I think more companies…

Why not just use some proxy-IQ test, if a big concern is to hire smart people? Aptitude tests are perfectly legal - and much harder to rote memorize / "game" than LC questions.

Re: Stop Interviewing with Leet Code

#348

Post by corrral »

UncleMeat wrote: post #346
corrral wrote: post #332

Earlier quoted context omitted.

You shouldn't use Brew to obtain dependencies. This is how you end up with people complaining about a brew upgrade replacing the version of Postgres their project depends on. You probably shouldn't be using dpkg or rpm for that, either, unless your CI and deployment targets are running the exact same version of Linux that you are, and even then—there are usually cleaner and more cross-platform/distro ways to do it, e…

That's fine, but almost nobody is running tools on their MBP. So for this sort of thing you'd be using the package manager distributed with glinux. And Google is also a really weird island where tons of tools are custom. You cant use some open source tool for git bisecting because Google doesn't use git. You cant use some open source tool for debugging because borg is a weird custom mess and attaching debuggers requi…

OK, that makes sense, thanks for the explanation.

Re: Stop Interviewing with Leet Code

#349

Post by gautamdivgi »

nvarsj wrote: post #306
gautamdivgi wrote: post #280

I hear this all the time. Don’t use programming tests, don’t use LC or HackerRank, etc. What do other professions that demand high skill do? As an example - medicine. How are doctors interviewed when they switch jobs? The beauty of LC type interviews is that it requires no validation by your existing employer or no public record or demonstration of work. In the absence of LC, I’m afraid we have to settle for some of…

Doctors are an interesting comparison, because they also have gatekeeping in terms of how difficult it is to get the credential in the first place. That early filter basically guarantees anyone with an MD has a certain level of competence. SW engineering doesn't have anything like that - it's a complete free for all, and the number of inadequate applicants vastly dwarfs the competent ones. Having said that, big tech…

I think Doctors are also at the mercy of their employer who must provide favorable references when they switch jobs.

Re: Stop Interviewing with Leet Code

#350

Post by tomp »

TrackerFF wrote: post #347
tomp wrote: post #308

> So What To Use Instead? > Deal with ambiguity, Reviewing code, understanding what it does, finding gaps, Testing, Code structure, Cleanliness, Learning new concepts Yeah, no. A lot of these are culture. I'm fairly confident I can teach someone smart and competent to write clean code, add tests, and properly modularise the project. It's called training (progression from "junior" to "senior"), I think more companies…

Why not just use some proxy-IQ test, if a big concern is to hire smart people? Aptitude tests are perfectly legal - and much harder to rote memorize / "game" than LC questions.

When I was interviewing I always hated IQ tests but liked doing interesting coding questions.
Post reply on HN