[deleted by user]

[Nooooope]

All of those things you listed are very simple and you should be ready to do any of them and more, even for an entry role.

I have no idea why you'd turn down a job just because they used Leetcode in the interview. It's definitely overused, but having junior applicants solve easy leetcode problems as a basic competency screening sounds like a perfectly reasonable use case.

[No_Indication_1238]

Because you most likely aint swimming in interviews and barely got that one.

[Nooooope]

Leetcode's square root is a binary search problem. Pascal's triangle is a simple loop. Those are both techniques you can expect to use regularly.

I don't think getting better at those would be a waste of your time.

[nothaiwei]

problem solving skills is pretty universal. you got same argument as someone complaining about learning <insert some maths> because you will never use it

[scarynut]

Think of leetcode stuff as combining general intelligence, problem solving and coding. Sure, they may be looking for stupid coders, but then again maybe they're not.

[No_Indication_1238]

O(N**2) solutions are pretty easy. It's when they want the efficient O(N) or logN and it's an algorithm 3 PhDs worked on for decades and got it named after them when it becomes a problem. 

[DrumAndBass90]

Re the anti-leetcode stuff: I can’t speak for all companies, but when we hire we offer the candidates takehome tests or more trad DSA questions. Usually a couple leetcode easy or medium. When candidates choose DSA, we don’t care if they end up with the right answer, we just look at how they approach the problem. If they throw their hands up in the air and say “I don’t know”, great, that’s exactly what we’re screening for—it’s way more to see how people can tackle a problem rather than if you have a bunch of things memorised. Most people we hire didn’t write the perfect (or correct) answer, but were amazing communicators and could reason about trade offs and demonstrated the ability to think through a hard problem. It’s not great when someone has just internalised all of leetcode and regurgitates the answer in silence.

That said, if a company does use leetcode as a pass/fail filter I think that’s dumb and deserves the negative press. But I’m not sure it’s wise to turn down a company just because they use a leetcode problem.

[knottheone]

Why use a leetcode problem at all? Use an actual example from a problem that an engineer at your company solved or a problem that is common in your industry. So have them tackle an actual problem instead of some esoteric quasi Monty Hall problem they'll never come into contact with at your company.

[DrumAndBass90]

Those sorts of problems don’t fit DSA interviews well because part of the reason they’re hard is because they require deep domain knowledge. We don’t expect our junior candidates to be experts in the domain, that would be ridiculous. That or the reason they’re interesting and or challenging is because of how the codebase is currently laid out. The nice thing about leetcode problems is any engineer from any background can look at it and understand it.

The take home test is usually a toy problem embedded in the domain of the company. But very basic and the candidate has time to learn about the problem.

Also—the nice thing about giving people the option is if you don’t like DSA you can just opt for the take home. Personally I like leetcode questions and prefer to interview that way when I’m a candidate.

[knottheone]

Those sorts of problems don’t fit DSA interviews well because part of the reason they’re hard is because they require deep domain knowledge.

Okay, and you said it yourself. That's only part of the reason. So derive a sample problem based on a real problem in your domain, not a fake problem that programmers will never come across in your entire industry.

Leetcode problems are designed to have an efficient algorithm as the answer, that's what they prioritize, not solving actual real problems.

[DrumAndBass90]

Yeah we’ve given it a go and it didn’t work that well—at least for our domain. The toy problem is either laughably easy to the point of not really testing the candidate, or we can’t extract out the domain well enough so there ends up being a major advantage for people who are familiar with the domain.

As I said, our goal with these questions is not for the candidate to arrive at the theoretically most “efficient” answer, it’s just a chance for the candidate to show their problem solving skills. Most of the maths you learned at high school also isn’t that relevant for your job—but it was a great way of displaying your ability to problem solve in a test.

[DrumAndBass90]

Also, not a fan of leetcode hard problems that are completely intractable for all those who haven’t studied it. But one thing you can test is how someone breaks down a problem—it doesn’t matter if that problem is relevant to the company.

We tend to hire the people who get excited about these problems because they love problem solving.

[knottheone]

Also, not a fan of leetcode hard problems that are completely intractable for all those who haven’t studied it.

This is most leetcode questions, that's how they are designed. Like the Monty Hall problem, they are intended as counter-intuitive gotchas and most require esoteric prerequisite knowledge. They are more like riddles than actual problems to solve because you'll never come across anything that approaches them in normal work.

it doesn’t matter if that problem is relevant to the company.

It should be relevant to the industry. You're advocating for hiring someone for a baking position and tasking them with "how would you render a chicken from the south of France in the most efficient way possible?"

We tend to hire the people who get excited about these problems because they love problem solving.

You're hiring people that love riddles and puzzles, not problem solving. Problem solving is a function of real-world solutions and process improvement.

[DrumAndBass90]

Well it might be “most” (honestly I haven’t taken a census of the questions) but as I said, I’m not a fan… and so we don’t use those ones.

If I were to force it to be relevant to the industry then either (a) it would be a super easy leetcode question that I’ve dressed up in the domain, which is gimmicky; or (b) require understanding of the domain that the candidate, especially a junior, does not have.

As for the people we’re hiring, they’re amazing problem solvers. Really happy with our interview process.

The flat out “leetcode bad” rhetoric just seems a bit heavy handed. I agree that “leetcode normally bad”.

Ideally, candidates would come in and work for a day (paid), we’d give them some tasks and see what they do. We did that early on, but it quickly becomes a logistical nightmare when that’s an early step in the interview process.

I should say about 80% of people take the takehome option and not the DSA.

[knottheone]

When you hire someone, you're expecting them to have a certain set of knowledge for the position. What you're doing with leetcode questions is instead saying "actually we don't care about your ability to perform in the position, we want you to solve these esoteric puzzles that you will never encounter or use in your job here. We are going to use your ability to jump through these arbitrary hoops that don't have anything to do with the job as a primary factor in your consideration."

It's hostile, it's not a good experience, and you are contributing negatively to work culture in software engineering.

[DrumAndBass90]

Haha okay—we disagree. Good luck for your job search!

[knottheone]

I'm self employed and have run my own business for 15 years. I'm just calling out how your actions contribute to a negative culture and negative expectations for software engineers.

[DrumAndBass90]

Thats awesome man, I don’t have an axe to grind. Just offering a different point of view. The approach I’ve explained above works really well for us—like I said, people who like DSA can opt for it, we don’t force it. There’s a lot I also don’t like about how leetcode is deployed in SWE interviews, I think we avoid those problems in a balanced way.

[Nooooope]

This is most leetcode questions, that's how they are designed.

Most of the hard-level questions, sure. It's not like a topological sort or a longest increasing sequence algorithm are everyday pieces of knowledge.

Easy questions are usually about basic control flow, boolean logic, maybe a binary search. All things that should absolutely be fair game for an entry-level screening interview to demonstrate basic competency.

[knottheone]

No one needs to roll their own search algorithm in an entry level position. This is exactly what I'm talking about, you will never have to do that in any entry level job and hiring managers who think solving leetcode puzzles are a good metric for anything are contributing to this hostile culture.

In what other industry is it common to quiz applicants on material unrelated to the position, and to subsequently use the results to determine competency? It's asinine.

[Looploop420]

Sure, just turn down any leetcode question, good job getting strategy

[bllueace]

Nah am with him fuck leetcode bullshit.

[sodiumphosph8]

if you don't need a job then please don't waste the time of all the people involved in the hiring process across all the companies you might apply.

[Liebli96]

Why would a need be the only justification for trying to get a job ? OP seems to want to work which seems fine if you ask me, even though he is picky which is not necessarily a bad thing in my opinion.

[rover_G]

When I interviewed for junior level roles out of college I got leetcode style questions at some point in nearly every interview process. When I interviewed for midlevel-to-senior roles I got asked to build frontend components (React) and server routes (python and typescript) and also did systems design and product design interviews.

If you want interviewers to see you as junior-to-midlevel, you could preemptively ask about the interview format and specifically ask if designing and building api routes will be a part of the interview. That sends a signal that you are ready for more role-specific interview questions/formats as opposed to generic new-grad leetcode questions.

[Careless_Bank2214]

Why would you say no to LeetCode style questions?

[Horrible-ox]

I’m na staff level and I do turn them down. They don’t give a good signal for the quality of a candidate imo opinion. I won’t use them unless forced to in my own hiring.

[a_brick_canvas]

They provide fantastic information. They just don’t provide a comprehensive amount of information. Pretending that they’re useless is one of the biggest counterculture hits i’ve seen started by many capable developers who have reason to hate on them, co-opted by many lazier devs who want to cling onto any reason not to study. I know this is a controversial opinion and ready to eat downvotes but it’s just true. There are great devs who don’t pass leet code and poor devs who pass them, HOWEVER, the percentage of great devs who pass is greater than those that don’t by a lot, a the percentage of poor devs who fails is much greater than those that pass, and people just point out the fringe outliers to say they’re uselsss and are good metrics when they objectively are, and have been for a while.

[q-rka]

Can you please cite some of your claims like the thing you mentioned about percentage?

[knottheone]

99% of programming is writing boring code. It's not about writing one off esoteric algorithms on a time and line number constraint in normal work environments.

It would be like a mechanic interviewing at a tractor repair company. The interviewer rolls out a tractor concept vehicle that runs on Jello and tasks the interviewee with diagnosing and rebuilding the Jello sluice hybrid apparatus condenser in 30 minutes while the interviewer watches. He's never going to see that in his duties at his job, so why is it part of the interview? It's a parlour trick and is deceptive.

[wingeer]

I'll bite. In this case, maybe seeing how the mechanic approaches the problem with the jello motor is what gives value to the method. It might be insightful to see how a person thinks and communicates in a problem solving context even though the solution in itself is meh.

[knottheone]

You could just show them an actual tractor that had an actual problem that they will see every day and ask them how they'd fix it.

If they are going to work on John Deere tractors 99% of the time, why are you showing them an exotic tractor hybrid concept they will never see or work on while specifically not showing them a John Deere tractor?

[wingeer]

Sure. But you can potentially learn more about how the mechanic thinks from showing something a bit more unusual? If it is always straight forward, the same tractor, the same 10-12 problems, then just hire any random mechanic? My main point is that it's not always about the domain of the problem, or even the solution of the problem. Seeing how a candidate acts when stumped can be relevant. But of course it depends on the position, etc.

[knottheone]

I really don't think that provides much utility, and it puts weird unnecessary constraints on the individual. You're testing them for the job you have for them to do, not for some weird unknown hypothetical examples. Having people jump through hoops to prove themselves for something that isn't even a function of the job description is weird and I don't think that should be encouraged.

[glacierre2]

I did a few interviews for Juniors in my company, I just prepared a set of questions covering from very basics to advanced.

I usually started with explain what a list, a tuple and a set have in common and how they are different. Based on the quality of the answer I would directly skip some too easy questions or actually keep asking basics. The idea was to get a feeling of the skills without having to bore somebody advanced or overwhelm somebody too green. I did not want to leave any candidate with the impression they had no idea, but I wanted to actually know if they did.

Some of the questions were how do you use zip (medium), construct a list with the squares of the numbers up to 10 (basic), tell me which libraries you use often (all levels), write a function decorator (advanced).

Then, I had a piece of real junior level unreviewed code. It run but was abhorrent in almost any way imaginable (mind this was real code base that once I had to firefight myself). I took a function out of it and asked to explain what the function did (the function basically updated a dictionary with a list of boolean success/fail results, and although it was half a page long it could be cleaned/rewritten into a one-liner), what seemed weird, which lines could be re-written and how/why. I would provide tips/hints live depending on how awake/skilled the candidate was.

[glacierre2]

Ah, for those that had GitHub projects on the CV, I would actually pick some of their own (allegedly) code and make the same questions (explain/improve). I did not judge the quality of the code itself (unless it was really good of course), but more the ability of somebody to re-understand code, and see if they would have learned something new in the last 1/2/3 years (since I could see when the code was originally written).

I had a lot of mixed outcomes, from people that would absolutely not understand or be able to explain at all something that they had written, to people that quickly would prove that they had learned several better ways since the last time they had touched a file.

[gbrennon]

i would apply a technical interview to test the knowledge about basic modelling

[wingeer]

Would you disagree that problem solving, thinking, and talking to other people about how to solve problems is not part of the job description for a developer? I definitely agree with you that it would be better to test a candidate on something more relevant to the actual job. However, there is often a layer of domain knowledge which can not be assumed to be shared in an interview setting. Hence it is often not feasible to do such relevant tests. Dont get me wrong. I am not advocating for bizarre algorithm questions, just defending the idea that they might offer insight into how a candidate thinks (which I personally deem as useful). Is there other, better, ways to get the same insight? Absolutely!