Live data from Hacker News

Stop Interviewing with Leet Code

fev.al

371–380 of 675 posts

Re: Stop Interviewing with Leet Code

#371
post #327

Earlier quoted context omitted.

Have you heard of Amazon's "LP" interviews? It seems to be a little bit like that. The challenge there is to tell a number of well-rehearsed stories.

I'm going through job interviews now (not with Amazon, but others). The whole thing feels like well-rehearsed regurgitation. Well, and a smidge of acting, obviously, because you don't want it to come off as well-rehearsed. But they know exactly what they want to hear and you're competing with other candidates who see the same writing on the wall and are doing their own rehearsals. I thought it was just the leetcode,…

No it’s totally right. Going in cold is basically impossible. You have to be ready to regurgitate leetcode answers, “approved” system designs, STAR stories about your career that show various BS story arcs. And of course pretend like you’re not just regurgitating for… reasons. It’s all a bizarre cargo cult acting session at this point. Big companies even send you a study guide these days ffs

Re: Stop Interviewing with Leet Code

#372

I once failed a leet code graph problem because I solved it with a genetic algorithm. The problem wasn’t that I was incapable of solving the problem, it was the narrow view of possible solutions. The interviewer was looking for the CS101 solution. My biggest gripe with leetcode is they tend to filter diversity of thought.

Yes, this is one of my big complaints- I've presented solutions as efficient as the interviewer's, but got dinged because it wasn't the one they were looking for.

Re: Stop Interviewing with Leet Code

#374

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…

I haven't thought about the bigco tech interview process like this. But now you put it out, it makes perfect sense :) I tried white board interviews about 10-12 years ago with big companies and failed miserably. Then I decided never to take a white board coding interview again which I haven't done yet. However, after working for startups and a few acquisitions later I ended up in a silicon valley big company without doing a white board coding interview. I'm not sure where I went with the story, may be to show that there are alternatives if you don't want to do white board coding.

Re: Stop Interviewing with Leet Code

#375

Earlier quoted context omitted.

To me a real engineer is good at engineering, what you described sounds like a good HR manager.

I don't think HR is usually on that level. For example, suppose your team generates and shares some kind of data. You want to change the wire format. You could just go ahead and do it, letting the chips fall where they may, but I think that's bad engineering/engineering management. It'd be better to coordinate with the folks consuming the data. Can you make their migration easier? While you're making a breaking chang…

All of those things are people management, and I agree people management is an important skill to have if you want to work in a big company in particular it isn't related to engineering. A guy who is completely non-verbal but makes a solar panel that is 5% more efficient is a great engineer, perhaps not liked by those around him but still a great engineer.

Terry Davis was a great engineer and he had the worst commutation skills you could imagine.

Re: Stop Interviewing with Leet Code

#376
post #335

Every time this comes up, lots of people start with the assumption that coding problems have a large amount of false negatives. Because of this perceived "truth", I had the same worry when we started to implement a coding problem. Rather than guess, we decided to measure it: for the first six months, we used a wide filter (50% pass rate, actually like 65-80% of people who didn't cheat). What we found was that there w…

The amount of false negatives really depends on where the bar is for passing the interviews.

If the bar is "it looks alright and the person knows the language they're using," it's probably not generating a whole lot of false negatives. If the bar is "the candidate comes writes the optimal solution to a complex algorithmic problem in 45 minutes," then that's highly noisy and tends to filter for people who have done a very similar problem recently.

Unfortunately, too many interviewers use the latter bar for passing or failing candidates.

Re: Stop Interviewing with Leet Code

#377
post #364

Earlier quoted context omitted.

Took me about 5 years to get even modestly proficient with medium-level leetcode questions. I'm a slow learner.

I never did a CS degree so much of the learning was decently useful but it also took me years

I only took 1 CS class in college- Cybernetics with Huffman. I failed! So clearly, that was a strong predictor for my future 12 year career at google (where I failed to do quicksort, or virtual ants problems). Nowadays I take a lot of extra time to come up with questions that aren't in leetcode, are easier than leetcode, and give far more signal than any leetcode would, for anything except for a 10X Staff Engineer.

Re: Stop Interviewing with Leet Code

#378
After hundreds of interviews for a FAANG I'm become more and more weary of this format. Particularly I find the the leetcode style "problem solving" question to have the higher rate of false negatives. It's common for candidates to bomb that question and do well on the rest.

My favorite way to judge candidates now is by asking a “clean code” question. This doesn’t refer to Uncle’s Bob Clean Code, but to code that is simple, maintainable, and extensible. I give candidates a simple and slightly ambiguous problem statement, usually revolving around “write a library that does X”. I expect candidates to ask questions and clarify the ambiguities, then proceed to define the APIs and finally write the code. The implementation is straightforward, with no tricks or logical puzzles. Only use simple structures such as lists, hashmaps, and loops. Then I ask one or two follow-up questions for more requirements, such that they need to modify or extend their code. Depending on how this is organized this might be trivial or very complicated.

I feel this format is the closest to on-the-job work and gives me a good feeling of what it would be like to work with these people. Also has a lot of freedom and allows one to peek inside the candidate’s mindset. How do they deal with ambiguity? How do they approach API design? how do they handle incorrect values? Do they care about corner cases? It is also mostly devoid of what developers hate most e.g. trick questions and obscure algorithms.

Re: Stop Interviewing with Leet Code

#379
post #366

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 are factually wrong. Not only that, you're conflating several different processes and team rules. Many googlers use brew to install applications on their laptops. This not against policy. Other googlers work with code stored directly on their laptop. There may even be developers who are obtaining deps (for their own builds) from brew. The problem with the brew author is that he had every opportunity to make himse…

You need a full Santa exemption with business reason to use brew. The average person working on some server that deploys to borg does indeed use their Macbook as a thin client. Who's obtaining deps for their builds from brew? If you're building stuff on Mac, it's via bazel and all your deps are in source control.

Re: Stop Interviewing with Leet Code

#380
Leetcode tests how is your math, and math is hard because handwaving and virtue signalling does not work with it.

Algorithms should be not memorized but derived on the go from well known mathematical models.

This is what good schools like MIT used to teach.

Post reply on HN