I am sick of LeetCode-style interviews

And because they ask pretty irrelevant questions, the 6 weeker will do better then the recent Stanford PhD who has been studying a specific problem for 5 years or the multimillionaire who spent the past 10 years building and selling successful software companies.

Those people will fail and your 6 weeker who's never heard of cmake, diff or gdb will pass.

When I see there's leetcode as the hiring process I presume the place is full of bozos because the process actually strongly preferences them.

I do work in a team where majority was hired by puzzles of sorts. All of them are smart. They are not software engineers and it shows massively.

But it's entirely pointless.

I've seen this reasoning, but I'm wondering if this is actually true, especially if you also believe the other myth in hiring: most people applying are not qualified for the job. Since most hiring actually requires you to fill the position in the end (in other words, you can't leave it open indefinitely if no one qualifies as eventually the pressure to hire mount up), every false negatives does increase the odd of you hiring a false positives as well. Just take the example at the extreme, if there is only ever one person on Earth qualified for your job and you got a false negatives on him, there is no other way but getting an idiot in the job.

I've never been through the "regular" IT hiring process myself, but I've interviewed several candidates for an Android developer position. I liked asking questions and looking at how the person thinks. I didn't expect exact correct answers for every question, I just wanted to see whether they have a fundamental understanding of Android. After that, they had to build a small app at home (not my initiative) to show their skills.

“Trick” questions are dumb, but you want to get an idea of if the candidate knows their stuff (and let the candidate know what we’re like — interviewing is a sales process in both directions). If someone asks a question like “is it ok to modify the argument” (or says “I’ll assume I can’t modify the argument”) that’s great (or says “I can’t remember if strlen includes the 0 byte so I’ll add 1 — normally I’d look it up”) - again, no trick questions.

When I say “simple” it’s something like atoi or “shuffle a deck of cards”: basic, but not 100% trivial like fizzbuzz.

On of our best hires was a guy who made a fundamental mistake — when we asked him if it world work as intended he said “I’m a fucking idiot” and fixed it. You’re not supposed to talk like that in an interview I supposed but we read it as a strong positive signal.

We had one candidate who insisted that parsing a string and returning an integer was an unreasonable question because there was already a library function for it. “But what if you have an embedded system and no library?” (an actual situation for us, for part of our system). He was adamant — honestly that was a failure of the phone screen: had it been caught it would have saved us, and him, from wasting time.

this would make sense if they filled these positions in 2,3 weeks tops. But that's the insane part; I hear of interviews going on for 6-7 stages now, lasting almost 6-10 weeks. At that point I feel you are no longer avoiding false positives, but simply hiring the most desperate programmers willing to jump the hoops. The best candidates will get an offer mid interview at that rate.

>But just don't! It's fine! just move on,

I've been "just moving on" for some 9 months now. There's only so much morale in a tank, no matter how BS you know the whole process is. I just wanna move on in life, not be bogged down on how many permutations you can color an N x M grid with.

Best tests are simple and common computer science problems in algorithms and data structures with no tractable solutions. There is no facile answer, you truly have to reason from first principles for any particular scenario because there is no alternative.

Well leetcode interviews do not measure the candidate's ability to learn new tech either, do they?

What's super interesting is I have actually had people pretty much fail the basic stuff (which was probably nerves) and then go on and kill the code review section in ways that shows their serious expertise.

IMO interviews are pretty bad at demonstrating people's ability to work, but if you can zoom in and out on a problem and do good enough on the coding stuff its usually a win.

Many companies have question banks that are specially designed to be fair/have some contextual relevance (ideally) to some "realistic" problem. Or at least, many of the companies I've interviewed at follow this model. I consider these coding questions to be "leetcode" style because at the end of the day they are an isolated coding problem, even though they may not be a problem from leetcode verbatim.

Companies that execute on that style of interview well are generally fairly pleasant interviews, at least in my experience. Good companies/interviewers will gauge more than just the final code to determine a hire or no hire. And a large portion of companies also have hiring ratings on a scale to make it less binary.

Suppose there was a SWE union and the union has to create their own reference compensation bands. Would the union again lean towards leetcode or some other standardized test? Or just use years of experience and maybe past projects?

When weighing the “effectiveness” of leetcode interviews, it’s important to weigh that thus far SWEs have failed to effectively unionize despite e.g. the past class-action no-poaches clearly showing C-suites should be paying engineers a larger share.

The reality is, fizz buzz got us 75% of the way there. It turns out when pressed, a lot of people can't write code. Yes, there's false positives, but there's also people brute focing their way through via copy & paste.

This doesn't manifest as a person who can't do any task, just as a person that's slow, delivers weird abstractions, and would take a lot of your time to get anything useful from.

But those people are also making those arguments, because, as you said, there's hundreds of thousands of dollars in it.

For those wondering what the alternative is to leetcode: a work sample test. Take a real problem your team solved recently, distill it down to remove internal-specific knowledge, and give candidates 3x the time to solve it compared to what it takes an internal dev to solve. Bonus points for having a rubric guide the scoring.

- Input from the interviewer reflects communication ability, cultural fit, and so on of the candidate.

- Input from the blind grader reflects ability of them as a team.

- Low grades count against the interviewer as well.

Bingo; now both are stakeholders in success.

If you want to earn top money, you gotta play the game. This is true in every profession, you think lawyers that want to work at top law firms have it any easier?

There's a lot of valid criticism with respect to today's tech hiring practices (especially because it doesn't only affect top paying companies), but I don't feel like "I can't get ridiculously wealthy without selling my soul" is a particularly compelling one.

I don't think this is an issue of bad luck, its quite probably to get difficult interviews especially if you're applying to the popular names.

But that would dramatically increase worker mobility, for one thing. So they don’t do that.

(“No it’s because they don’t want you to be able to test prep” that makes no sense because 99% of the way to prep for these is… exactly like test prep)

higher education, even job experience is no longer considered a sufficient barrier to entry.

reminds me when the guy who wrote homebrew failed the apple interview. if i recall.

ironic because they use brew so much internally.

Well, that and how almost nobody who successfully finds employment after "grinding" leetcodes wants to remove the barriers for entry.

I think Leetcoders can't envisage a better way to assess someone than by subjecting them to the same kind of hoop-jumping you get made to do in university. They're not interviewing you for a job as there's no module on interviewing candidates on the CS curriculum, and don't have much professional experience outside of academics or software engineering. They're simulating a dissertation defence, because that's how they were assessed for their competence.

That's my charitable interpretation. If I'm being cynical, it's elitism - a way of making sure you're "one of us" (read: obnoxiously academic, Type-A personality, "logic over feelings").

I prepared thoroughly for all four main questions and any other plausible ones I could think of. I practiced writing solutions to ensure I was fast enough for the interview. Additionally, I pre-prepared ideal answers for each question in case I got stuck.

When the interview came, I got a total curveball: a question that was significantly harder than the usual ones. It didn't fit the round's theme (it was a DSA question, but I'd already aced the DSA round), was obscure enough not to be on LeetCode, and required writing a solver for a hard variant of a known algorithm. I panicked, copied the prompt into ChatGPT (despite being instructed not to use it), transcribed the result, and pretended I had recently studied the relevant algorithm.

I passed the round, nailed the other interviews, got the offer, and accepted. Later, I found out that interviewers are instructed to pick one of four specific questions for that round, and the one I got wasn't in the list.

I'm left wondering if the interviewer was trying to sink me or was just bored with the usual questions. The whole experience raised several questions for me:

Is it cheating if I already had pre-prepared answers for the questions they were supposed to ask? What's the difference between using pre-prepared answers and using Google or ChatGPT during the interview?

If the interview had gone according to plan, what was I actually demonstrating? My ability to use Google?

When the interviewer asked an impossibly difficult question, I would have failed if I answered it legit, even though I'm a good engineer. Failing such an unfair interview round doesn't serve the company's interests.

What is this interview process meant to demonstrate? My true value as an engineer lies in my ability to communicate clearly, think outside the box, identify and address technical tradeoffs, mentor juniors, and propose technical solutions that meet requirements while minimizing risks. Yet, I'm expected to solve a hard variant of the Traveling Salesman Problem in 45 minutes or I don't get the job? Why?

The whole process seems broken, but I'm not sure how to fix it.

If Google engineers all wore pink robes and top hats while interviewing then we'd see that everywhere.

If this was just FAANG I wouldn't even mind it. Bigger compensation means bigger hoops to jump through, artificial or otherwise. At least those bigger companies come with interview guides.

But I've been dropped Leetcode mediums on some Unity game dev jobs barely paying 40/hr with minimal benefits. Game interviews already have an absurd number of topics to try and guess you'll be quizzed on. (last interview wanted low level C memory/bit manipulation question... the one before that did Unreal Engine trivia... then the one before that decided to give me vector math and ray intersection questions), adding in random string manipulation questions when you will barely use more than concatenation on the job doesn't help with studying.

See, this is true eventually. But it's _definitely_ not true in 45 minutes.

However, we do require a base level of competency. We give out a 40-ish minute assessment. Two multiple choice and three coding problems.

And they’re easy. One of them is essentially “John has a 5 gallon bucket and 3 gallon bucket, how many buckets does he have?”. All you have to do is rewrite the clearly labeled circuit diagram as a Boolean expression.

Not a single person this round has passed. Several have failed the simple ones.

So while grilling people on the minutiae of a language or asking them to solve the traveling salesman is not beneficial, neither is nothing.

We should be testing floors, not ceilings

For companies this is very rational, you want non-distracted employees who can work over time.

with all due respect I believe this is about as far from the truth as it gets. I believe the issue is that people think they have to work at FAANGs in order to be paid REALLY well which is just nuts.

I know many people making (very) high 6 figures working at places most have never heard of. instead of looking for FAANGs people should be looking at companies that have been in business for 20+ years (if publicly-traded company the easiest "measure" would be whether you would invest your own dough into that company) and then make your self indispensable there (this is much easier than it sounds) to a point where you are more valuable to the company they company is to you. This is un-achievable at FAANG but this should be everyone's career goal. once you are worth more to a company then company is to you, compensation-wise sky is the limit :)

Why don't you list them here to illustrate your point?

That depends very much on your world view. If you get the job, it would imply you've just cost a lot of other people $100ks. That simply can't be true, because there's a small number of such jobs.

The only way this can possibly hold is if you hold that only the "best" candidate should get the job, and by "best" you mean: the one that gets most of the leetcode questions right. But then there's no us.

Edit: I'm not in favor of leetcode interviews, and I do understand that there's a bias in interviews (which won't go away when you drop the leetcode).

Leetcode is lazy, easy.

I do not know how hiring is done at megacorps; but on the few occasions I participated in tech interviews, we were looking for candidates to join the team that I was on. So, what I was interested about the candidates was how well they were prepared for the kind of work our team does; and how much I would like to work with them. I am sure this second question introduces all sorts of subjective biases; but then, hey, aren't you going to spend countless future hours with that person? At least the first concern incentivised us to make sure candidates were sufficiently competent. BTW, we didn't ask leetcode-type questions.

> but to the individual, this is costing us 100s of thousands of dollars, because there’s only a handful of companies that pay well and they all have the same interview process

I am not sure I am following the argument. If there is only a handful of companies that pay well, and if you only consider companies out of that list for employment, isn't it reasonable to predict that there will be lots of other candidates who want the same, far more than the number of available positions at those companies. How, then, should those companies select from such a pool of candidates?

If what Google search tells me is true the average SWE tenure is only a couple of years or so.

I might need a month or two of study (or more!) to be able to handle the harder Leetcode problems, but if I was expecting to have to do this every couple of years or so I'd consider taking some steps to maintain that knowledge between jobs.

That would probably be considerably less overall effort than forgetting it and having to cram for months every couple of years.

One time in a technical interview I realized a quadtree would solve the problem they were asking. I also happened to be reading SICP and practical common lisp on the plane on the way over to the interview. (specifically the sql sdl macro chapter) Unfortunately this gave me an idea. I narrated, sketched out and pseudocoded a plist based quadtree on the whiteboard and felt pretty good about myself.

I turned around to see my interviewers were not impressed. Actually they thought I was an idiot. They didnt know what a quadtree was, and they were quite upset I used "tuples".

I assured them its very efficient, and that the compiler would take care of "the tuples".

They failed me. Moral of the story don't use common lisp in a javascript interview.

  > A way to suppress wages
  > A way to mask bias
  > Same gender? Same race? 
  > someone you don’t like

The shit soup presented at a coding interview, leetcode or take home style ones are a result of wholesale cargo cult stupidity than malice.

There's no incentive at any level in BigCo. Margins are too big for top level to care. its hard to measure, middle management layer can easily fudge metrics while driving the org effectively into the ground. Lower layer that made it through the filter, sick of this grind and are busy filing tasks sipping free coffee.

The elephant in the room is that you cannot make hiring a process driven activity.

This is org level dysfunction. There's more such exhibits - DEI, promo criteria, ERGs, re-org politics, vendor selection to name a few.

They say As hire Bs and Bs hire Cs . . . and to combat that we've added more leetcode to the interview process.

Ask the candidate to build a known quantity like say, a calculator, calendar, whatever or give them a bunch of code and have them modify it in some way or discover a bug.

Something closer to building software. Leet code is too far away from it and the performance on it too poorly correlated with actual suitability.

It follows that better leetcode scoring is a good indicator of who can be replaced with LLM.

Yeah, right. Why would companies truly care about this issue and put any effort into making their hiring process feel less hostile when they still have loads of candidates who are more than willing to go through whatever tests they get asked during interviews? It's a leaky bucket and they're happy with the status quo while developers keep grinding away... I doubt it will change anytime soon, but I'm glad I can afford to put my foot down and refuse to do such interviews when I need to find new jobs.

The CEO chased me out into the parking lot and begged me to tell him what I saw and why the interview went awry. He was legitimately shocked that an interviewee could make such a decision, mid-interview .. All I could tell him was that it wasn't going to be a great fit, the culture didn't seem aligned, and the people who were brought in to the interview seemed desperate and hostile to each other - and that simply wasn't the way I had hoped that the company operated.

People forget that job interviews are a two-way street.

I realized that day that I have every right to inspect all aspects of a company that I might work for, and that I don't really have to make compromises if I see something negative during the process. It was the right decision because the very next day, at another competing firm, I met folks who have continued to be good, close friends and colleagues, whom I actually really enjoy being around.

This profession is fun. But when the fun gets farmed and exploited, its enslavement like any other.

My main concern is that with the allegedly rampant cheating on take-home assignments, the number of employers willing to use them may drop precipitously.

Leetcode questions can by definition never come close to real life problems - they are simply out of context. Working on a project even a few weeks will grant a smart person any insights he might actually need. The kind of out of the blue puzzle problem a leetcode presents is more akin to crosswords in old leisure magazines.

This isn't working hard. And you are competing with the people that are working smart. Such as people having a separate computer/screen to either look up the answer to a problem or ask an LLM to regurgitate some code you can transcribe. It selects for people that are dishonest.

> 2. Are you smart (i.e a person who doesn't do any leetcode but knows the fundamentals and can sythesize past knowledge well enough to answer a new question)

See above. A lot of the problems have nothing to do with real world coding scenarios. Do I need to pull out memoization and know how to work with grammar rules off the top of my head? Or the functionality of quad trees and how it applies to partitioning? No; I've literally never used them in my career and likely never will. What I do need as a software engineer is understanding the high level concepts and when to apply them and refresh myself on the use case when and if appropriate.

It leaves out looking at the engineering skills it takes to put something past the finish line on budget.

It's at best, an adjacent sideshow and at worse a proxy for ageism to preference people closer to 19 and less capable at getting quality software out the door.

And maybe that's why the industry has such a damn hard time getting quality software out the door.

Maybe.

Here's a far better idea. Give them a broken build or crashed code or some other failure and ask them to fix it. If they can navigate around a system, diagnose a defect, find the cause, offer a patch, and match the coding/commenting style etc, that's an actual player you need, not someone who can still solve an algo question from their CS101B midterm exam at 37.

This version can go deep as well. You can have separate branches and an issue tracker, maybe with the conversation of the bug already going. Maybe the comments have a patchfile that needs to be manually applied. Maybe the patch has a new bug in it ... Perhaps it's a red herring and addressing a similar but unrelated issue. Maybe it's a closed bug and a regression and nobody wrote a unit test for it. Maybe the unit test is there and it's up to the candidate to discover it or the unit test is out of date, buggy and useless.

This is the real stuff.

Get them to communicate after. Saying something like "the unit tests were broken" versus "I was unable to understand how to get them to work right so I moved on" ... That's a huge difference in attitude - only one of them is a team player.

I'm sorry but it's incredible hubris to think you'll come up with say Dijkstra's algorithm during the interview from the first principles. The only reason you can do it is you studied it before.

Most people applying already have a job. And if they work hard its actually quite uncommon for them to have ample energy to do leetcode questions on the side. So you might get the opposite - you'll get candidates who aren't great performers in their current roles but used their extra energy to grind leetcode.

Even worse: it misses out on the hire people with no formal training too busy to waste time on skills with little use outside of the interview (in the real world, they'd use a library).

when does this start? I'm over 8 years in and I'm tired of being told to make a dang NxM Bingo solver in 30 minutes.

>Leetcode is not meant to magically select for the best engineers.

I'd agree with you in 2022. in 2024, I'm being way more filtered out for questions that I get right but didn't solve fast enough, or with zero hints. I was never a leetcode savant (too many other things to study for, and LC is maybe 20% of my interviews) but I don't feel that much worse than 2 years ago. Companies just have sky high expectations and are on a bargain bin for 15+ year roles paying 5 year salaries.

What is a better capitalistic company hiring programmers:

>Lots of smart similar people who believe in correct answers

>Lots of random skilled people

If you said the latter, you are idealistic and your opinion genuinely doesnt matter. Nature will replace you with someone smarter and realistic.

https://github.com/emilybache/GildedRose-Refactoring-Kata

in their favorite language. Has been a very effective filter

The (best) seniors just use a library. The good candidates roll their own, but can explain the tradeoffs. The juniors get the test to pass and stop.

Eclipse does not without me having to even look at it. IntelliJ does the same. In what situation these people had to import it by hand? They had no ide available or what?

Not sure it's a satire about interviewer stereotype or...

I think this is silly. On its own, you could imagine a kid in college who had just seen an example of HashMap in Java remembering what the import was.

But this isn't the only thing you need in a program. There's going to be many things that are trivial that your program needs, all of which would need to be memorized in your world.

> If you need to multiply 562 * 1041, you should use a calculator. If you need to reach for a calculator to tell me how much 3 * 7 is, I will doubt that you are an expert.

The strange thing about this is, I would expect you to know how to calculate 562 * 1041, in other words the principle of how it works. You might mess up the calculation, but you can't mess up the idea of how long multiplication works. In that context, it is perfectly permissible that you have forgotten some entry in the times table, like 3 * 7.

After all, you are a programmer, you organize calculations, you do not work them out yourself, the computer does that.

> If you need to study graph-traversal algorithms in order to pass, it's probably too leet.

This I agree with. You should know where to find the solution to whatever the issue is, you don't need all the solutions to hand.

I think more likely though are the accidental favoritism in the industry where engineers submit resumes of other engineers they know who are looking for a job who, surprise, are also white males.

I don't believe it is either racist or sexist however. It's just "who people know". Nonetheless, you're going to build a hive-minded team if you don't go out of your way to break these patterns.

Perhaps similarly leetcode interviews come about from engineers who were leetcode interviewed. Again, no need to jump to ageism as the cause.

(And if anything I think it may have turned a corner where the older devs may have more experience with interesting algorithms that, I don't know, might not be taught any longer in CS?)

Feeling a bit triggered by this - but also curious how you escaped :)

How generous. One job I asked for an update a few days after my assumedly last interview, 1 week afterwards, and then 3 week afterwards (right before the holidays)... even by the last response the recruiter simply said "we are still evaluating the best project to put you on" or something to that effect.

That was 8 months ago now. Going through 5 rounds of interviews into a rejection sucks, but at least be straight with me.

Nice belief, but good luck proving it.

I imagine the people grinding LC are harder working/more innovative than people who watched TV instead.

Not specifically that but give it your own twist.

If they are confused remind them that getting along with people and fitting the team is at least as important as the ability to do work. The work is the least of your concern. It will probably involve dusting off some old skills and learning some new things.

> I don't understand when companies try to give test assignments to senior developers.

I think this is perfectly valid, though. When I interview candidates, I start with the conversation and I can tell you that more often than not it goes very well: talking about software design, architecture, what they think about various frameworks, etc.

But you would be surprised how many people can talk their way through the interview, and then get totally blocked on a simple syntax error in the code. (Stress being accounted for).

I agree, though, that the questions should be fairly designed before the interview and be consistent with the level of the expertise expected for the position. I would never ask a senior developer to implement a FizzBuzz. We'd rather sketch an architecture for some piece of software with some specific constraints, discuss the choices of the language and libraries and argument them, etc. And yes, eventually code something: just sketch some core domain logic. I would never hire a software developer, whatever the level, without seeing them coding first.

It doesn't help that so many companies think they have slick ways to root out better qualified people when most are just a waste of time.

My best received interview question was for a bug/firefighting team. Based on a real bug we had, here is a sanitized repo (perl or python, our languages at the time) with some sql and data. We gave them three made up support tickets about some settings values being incorrect causing $issue. Dig into the utility script, find bugs, fix the data.

Even folks who didn't pass complemented the task

But having experienced leetcode-style interviews on the candidate side, it's clear to me that they are no longer about figuring out and coding a solution on the spot. Interviewers expected a solution FAST, and to match that you need to have studied and learned the answer beforehand.

But that "something" doesn't have to be leetcode. There are much better (and less abusive) ways of doing the same thing. All it takes is a programming problem that they've not seen before. That's it.

I'm guessing this works better for consultants than for regular employees, due to employment / tax laws.

Memorize that and you'll pass them all and won't be able to deal with 1,000,000 SLOC code bases in the slightest

Regarding “cheating” with an LLM, there is not unanimous consensus on that either. I’ve been in technical interviews where the collaborative coding tool had an LLM built right in, and I was encouraged to use it. If thats what I’m going to do at the company then demonstrating problem solving that way is useful.

The problem with this (and with grinding leetcode) is that it's not symmetric. If I'm in an interview, and you're wasting my time, you're also wasting your own. So the employer has some incentive not to waste my time. With a take home, though, they can feel free to waste my time, because it doesn't waste any of theirs. (And leetcode is the same. Yes, asking it in the interview takes their time as well. But all the time I spend grinding in preparation, they do not spend.)

For one special job that I really wanted to get, sure, I'd do a take home. For your average job for average pay? No. Your job isn't worth it. Don't waste my time.

I disagree. It’s supposed to be that, but the reality of the interview is that there isn’t any time to problem solve so you need to learn the problems and just regurgitate the solution.

That doesn’t put you in the top 0.1%, it ensures you’ve spent dozens of hours practicing questions.

You understand how this goes completely against the very purpose of the interview which is to evaluate how they think about the problem rather than about the final outcome, right?

I couldn't care less about whether your code compiles or not if you were able to figure out the perfect solution, walk me through it, explain why it is the best, and looked like you had some experience writing code when it came to that part.

The goal of coding interviews is to probe the candidate, have them explain their thought process, and see how they interact with you. Are they able to formulate the problem? Gather specs? Are they able to consider constraints?

The last thing I want is some automated system where you have no idea how the applicant came to their answer, what their thought process was, etc.

If that was the goal, then just bring back brain teasers, or better yet, just use thinly veiled IQ tests.

We've been going in circles for 20 years.

I am starting a company, and I need smart people; I do not care how good they are at programming language X, or technology T - all the skills my employees will need can be learned on the job.

I want to optimize the time it takes for an arbitrary hire to become independent, to have learned the basics, and to make meaningful contributions. They would write code at most 20% of the time, and the job has many other nuances.

In your opinion, what would a process that you wouldn't refuse look like? Would a learning interview (I present something that you have not seen before, act as an oracle, provide docs, evaluate how quickly you pick up concepts) be so insulting?

Probably. Most LC interviews are in the early to early-mid career stages and are often at large headcount shops where problems are often solved by throwing man-numbers at a problem. As a result, the shops think: "Why don't we hire more really intelligent people to throw at these problems?" They have lots of postings and then get a lot of applicants. LC then serves them 2 main purposes; 1) a proxy for "intelligent people" that can solve these kind of extremely generalist problems, and 2) a way to cull the herd.

Once you actually need specificity in your hiring, then LC style questions are effectively useless outside of some very unique contexts. That they are so endemic is reflective of how bad almost all companies are at hiring.

a) The 90% of applicants who literally cannot code. Although I filter out 99.9% of those by screening CVs and a short telephone interview.

b) They can be a point for more discussion.

It's silly to give someone, in an interview setting, an exam question style problem and to make that a key factor in the interview. It's up there with giving someone tasks which could potentially take them an evening just for an interview.

I've tried everything and I've had the best results by talking, digging into the details. Not only do you get a better idea of the person but it's really easy to rat out those who are less capable (especially those who've studied hard for exam questions but fail at everything else).

I also observed starting a process with easier questions still filters out the bad candidates (80%+). Once a candidate 3-4 rounds more open ended questions seem to be much more discriminative anyway.

Furthermore, asking (senior) engineers arbitrary and esoteric CS questions that

A) They may have never seen before

B) They will likely never encounter

Seems like a good way to lose out on competent candidates

If I hire an experienced electrical engineering project manager, I don't ask them to analyze convoluted circuits or random differential equations on the whiteboard.

I’m in a mentoring group that includes a lot of people looking for jobs and studying LeetCode. Two themes that come up over and over again:

1. People overestimate the difficulty of practicing LeetCode. Reddit and other sites make it sound like you need to take 3 months off to grind LeetCode full time, but most people can do 1-2 problems per day in their spare time, lunch break, or other small window of time. You don’t need to do rote memorization of every problem on some list found on the internet.

2. Actual LeetCode interviews are rarely as hard as people expect. People think they’re going to get LeetCode Hard problems that require obscure tricks, but the vast majority are Easy and Medium.