In Defense of LeetCode Interviews • Hacker News Board

Re: In Defense of LeetCode Interviews

#91

Post by wakawaka28 » Sun, Oct 13, 2024, 3:22 AM UTC

novok wrote: post #63

wakawaka28 wrote: post #54

Earlier quoted context omitted.

A lot of the kinds of questions you'd want to skip have no trick. Also, presumably, if the question is to be swapped then they will not demand a full answer before doing the swap. I think it's stupid to try to judge if someone has seen the question before. The only time it's wrong to have seen the question before is if someone tipped you off to that specific company's questions. I think that most people are not good…

You still need to be able to give a few sentence summary of the solution, trick or not and you will need to be able to give an answer that actually matches if you are going to say "ive seen this question before, [implying you know how to solve it]" while you actually have not and are lying. It doesn't matter if it is 'stupid', or 'wrong', or whatever other cope you want to invent, people will do it and if your caught…

>You still need to be able to give a few sentence summary of the solution, trick or not and you will need to be able to give an answer that actually matches if you are going to say "ive seen this question before, [implying you know how to solve it]" while you actually have not and are lying.

You would probably fail in an interview with me because you assume things that simply not stated. If someone says "I have seen this before" that does not imply that they know how to solve it. They might have seen the question and decided it was not worth their time, or they didn't actually solve it, or whatever. You CANNOT infer that they are lying if they follow up with "I don't know (or remember) how I (or anyone else) solved it." People have fallible memory. In a high pressure situation anyone can get mixed up, misread the question, etc. So, don't be a jerk.

>It doesn't matter if it is 'stupid', or 'wrong', or whatever other cope you want to invent, people will do it and if your caught in a lie because you do not even know the answer to that, you've disqualified yourself immediately and potentially get blackballed as a liar.

It's so trivially easy to get disqualified, that's stupid. If they really push you, you can say "Yeah I think I saw it a long time ago and I don't remember the solution. You decide if you want to switch." And that is probably the truth in most cases anyway. If someone would disqualify me over that then they're not my kind of people.

As for whether it is a "cope" to observe that these questions are counterproductive and pushed by a lot of smug and incompetent copycats, I think it is worthwhile for one's own sanity to recognize that solving leetcode questions is a separate non-work-related skill. Being good at those questions does not make you a good engineer, and vice versa. Yet, in some cases, your future may be decided by these pseudo-academic timed exercises, judged harshly by baboons.

>If I've caught such an immediate lie as an interviewer, I'd be a bit relieved on some level because I now have a legit excuse to end the interview series early and go do something else and save my coworkers from doing interviews, because for most interviewers, they are chores.

I think what you're really saying here is that you would rather hire a good liar over a non-liar, assuming they have equal leetcode skills. Because that's what you are selecting for if you don't allow people to comfortably say "I've seen it before and I don't recall the answer right now."

Re: In Defense of LeetCode Interviews

#92

Post by GuB-42 » Sun, Oct 13, 2024, 2:32 PM UTC

eesmith wrote: post #81

GuB-42 wrote: post #77

Earlier quoted context omitted.

I actually never did LeetCode interviews, but I did some competitive programming, same idea. And it tests more useful skills than FizzBuzz. I wouldn't recommend hard questions, as they usually require techniques that are not very useful for most jobs and that you have to specifically train for (ex: dynamic programming). But for easy to medium questions, in my experience, the bottleneck is usually misunderstanding the…

It seems in poor taste to respond to someone specifically criticizing LeetCode questions, by using your experience in non-LeetCode evaluations. I too did competitive programming. A team working together to prioritize from a list of programming tasks which cannot all be completed in time even by the best team is a far cry from a LeetCode interview problem.

There are different kinds of programming competitions. Some are about solving relatively easy problems individually and as fast as possible, which is most of what I did. The best candidates usually can solve all the problems and time determines the winner. Others are about solving hard problems, sometimes as a team, like in a hackathon. I was talking about the former.

I also did a mock LeetCode-style evaluation, which my company made me do as a benchmark. It was a lot like the kind of competitive programming I mentioned. But I don't count it as an experience because it was not a high-stakes, stressful situation. Note that I had no say on the recruitment process, they just asked me and other employees to do the test to see what to expect from someone of our skill levels, it also included some other, more knowledge-oriented questions.

Re: In Defense of LeetCode Interviews

#93

Post by argentum47 » Tue, Oct 15, 2024, 1:29 AM UTC

OnionBlender wrote: post #21

waythenewsgoes wrote: post #9

I have always seen LeetCode problems as effectively hazing rituals in a job interview setting. A high pressure interview situation simply won’t bring out peak problem-solving capabilities in many people. At best you get some superficial insight into someone’s problem solving methodology, but at worst you filter out otherwise excellent fits for not being able to solve an ultimately inconsequential problem under pressu…

I was looking at the Meta interview guide and it says: > Let us know if you’ve seen the problem previously and also: > In your tech screen, you’ll be asked to solve two problems in roughly 35 minutes. Practice coding solutions to medium and hard problems in less than 15 minutes each to help you be ready for the constraints during the interview. The only way I could solve two problems in 35 minutes is if I've seen the…

> Let us know if you’ve seen the problem previously.

It was one thing to practice this for hours, and now I have to tell them, yeah I saw this problem, so given me something that I never solved, and have a 50-50 chance of win.

So working at Meta would be like, oh we need an Auth layer, but we have already seen an Auth layer being used, So lets scrape that, and build a new one, but then we are not going to look the spec or the problems from before, because we want to do the same things again.

Re: In Defense of LeetCode Interviews

#94

Post by argentum47 » Tue, Oct 15, 2024, 1:54 AM UTC

This opinion might be a bit controversial, so correct me if I am wrong.

Going by the Think Fast Think Slow, most of the people who were great at what they did, could be categorized overall, in terms of how they put in their effort, where they put in, and when they started from. (Apart from luck)

I think of this in terms of traits. Big tech companies, they would want to avoid any form of engineering silos, giving so much power to a single/single set of engineers, that would halt their business. Which is why they have this process.

They want a whole lot of easily replaceable engineers, who (might work on different projects), but overall have the same kind of mentality. This way they know, if the candidates have done what they need to do, and talked about things a certain way, they on a fundamental level would be the same. So even if the person leaves, the style of work for the next incoming engineer wouldn't change, and everyone can go along with minimum friction.

Also, thinking a bit more, /^[FAANG]*/ companies would obviously try to cross-hire. Same as BIG4, same as /TCS,CTS,Infosys/ and likes. A good chunk of people who work in MNC's stay in MNC's. Infact sometimes the projects are transferred from one MNC to the other, and then the manager or TL or whatever leading the project is hired first, and then he/she brings his/her team from the previous org.

Although end of the day, there will be a few hits and misses, but given the plethora of people working there, on a large scale of things, it doesn't really matter. I mean in a group of 20 people, 2 leaves. Its barely anything to make a dent.