I am self-taught and I can't do these leetcode problems if my life depended on it.

I still deliver high quality software on time, and on budget, and have a solid grasp on my career.

I wouldn't worry about this too much. It depends on what you are going for.

Sure, if you want to pass a FAANG interview where you are going to get these types of questions, go for it. To solve day to day business problems, you rarely need this stuff. You just need to learn how to write quality, performant, correct code that results in solutions.

The best way to do this is develop experience in the industry over the years.

My 2 cents.

The only job I've ever had to do any kind of test for wasn't leetcode - just a practical demonstation that I could write a basic CRUD app. Was actually a pretty good test to weed out people who were just completely useless.

I'm also finding that experience matters. It's just tough to get that across up front.

I think this is a totally reasonable way to weed out applicants, particularly if they allow you to do it during the interview time. I've been through several interviews (though, to be fair, they were well over 15 years ago, since that's how long I've been with my current employer) that used a similar exercise. One interviewer just sat me down at his workstation, and told me to build a quick crud with their tech stack (which, of course, I knew going in). Nothing was off-limits (web searches, etc).

I ask because as a startup founder, I would significantly prefer to try working with someone for 3 months instead of doing useless least-common-denominator interview questions. It's a bad fit, it's better to quickly part ways. But getting fired or asked to resign is a big emotional blow for many people, and I'm not sure if they would rather face that than the Leetcode grind.

I'm fairly confident in my ability to deliver value in the first couple of weeks on a project, so would much prefer this to having to spend time grinding leetcode puzzles that I'm not innately good at.

Note: a large part of this perspective is the privilege of feeling like I could get another job pretty easily, and having a sizeable emergency fund that I could draw from to continue the search if things didn't work out. So you may be filtering out people who are not in such a fortunate position.

As this is a normal contractual regulation there is almost no risk of any legal trouble (usually).

On the other hand side as soon as this trail period ends all the German workplace protection regulations start to apply in case of permanent employment contracts. So after the trail period ended it gets quite difficult for an employer to get rid of an employee.

But all in all that's pretty fair, imho. After a half year you quite surely know whether you like the workplace, or form the other perspective, the employee.

Because there is a difference between writing FizzBuzz and solving one of those dynamic programming problems that are so common in competitive programming. For the former, I am surprised you can even work without being able to to this, for the latter, you pretty much need special training that is not very useful in most professional settings.

I never took a leetcode style interview so I don't know what is generally expected. If you are expected to do hard problems, it doesn't test much besides your leetcode skills. But easy problems look like a pretty good filter, assuming the stress of the interview isn't blocking you, which is another problem.

IMHO I believe the right approach is to either ask from a standard bucket of questions that require preparation and advertise which ones to candidates, or not ask them at all. Asking "only a few really easy ones" is becoming a red flag to me.

And what are you testing than? Whether someone can memorize things?

Even though I'm not good at memorizing things every second monkey out there is.

Actually, people relying mostly on memorization for "problem solving" aren't very intelligent in my experience.

Especially in software development you don't want people who can mostly only reproduce things once learned by heart!

No two problem instances are exactly the same. It's all about the context! What is the recommended text-book solution in one case could be the most stupid thing you could probably do in another superficially "similar" case. You want people being able to recognize the difference and act accordingly.

(Of course you need some amount of drones in every company. Especially when your company is big. Not everything needs highly skilled and highly intelligent employees. Also there is only a given amount of adequate people available at all. If you're big you can't be too picky if you want to hire enough staff in a reasonable time frame. But those are problems of really large organizations).

But what if too many people pass those filters?

Then we move onto mediums.

But what if too many people solve those?

And that is how we reached the current state of interviews.

* I confirm that day to day business problems rarely are the sort of problems you find on Leetcode.

* I might ask similar questions in interview. I don't expect the candidate to solve them. As a matter of facts, I don't care if the candidate actually solves them or not. I am observing how the candidate behaves in front of a difficult problem. Will they freeze? Will they jump head in the code? Can they articulate their thoughts and think analytically about it? Can they think on the spot if I challenge their approach? Are they comfortable saying "I don't know"? This sort of things.

In my book, being a "good engineer" is much more about communication, collaboration, familiarity with git/sourcecontrol, clarity of commit messages, pertinent emails, being reliable, being resourceful, etc.

Good grasp of algo is a big plus, of course, but it's not something that all the best engineers excel at.

So what if they freeze during those 45 minutes? How representative is that scenario for what most devs do?

Also, most problems are not solved in the 45 minutes and in day to day coding , we generally have a minimum of day to think on the problem and solve it without people looking over our shoulder, google or ask someone :)

And presumably fail said interviews because they froze. Usually "I think I need to think about this for a while, or maybe even sleep on it" isn't the answer that the interviewer requires.

As you note, it's normal to need more than 45 minutes to think about a problem that you haven't seen before. Many leetcode type problems puzzled eminent computer scientists and/or algorists/mathematicians for years before they were solved.

Then there's the psychological aspect of when interviewers try to "help" you by asking questions, providing clues or even the specific clever (or stupid) trick needed to solve the algorithm puzzle but really you're in no condition to understand the hints they might be providing.

If a candidate freezes for 45 minutes in a 45 minute interview, they won't get the job.

... Right?

Clearly thinking on your feet in front of people is what it means to be good at ones profession.

And yes, if I ask you a technical question and you freeze, I don't want you on my team. It doesn't mean you're a bad engineer. It means you're not a good fit.

Pretty much sums up how the hiring process is a gamble. So if you don't like somebody and they could be an asset to the company you would not hire them?

Don't undersell yourself, you ARE able to do them, maybe with some practice, like putting some basic algorithms implementation into your muscle memory.

Doubtfully it'll make you a better developer though.

Anyway, the most important skill for FAANG interviews is ability to write code on a whiteboard with a dried out marker.

The reality is that if this person's life really did depend on it, for example they lost their job and they have bills they need to pay or a family they are responsible for taking care of, then they almost certainly could put in the effort to brush up on their skills and get to a point where they could do leetcode easy or leetcode mediums in a matter of weeks or a month at most.

It's along the lines of an MIT grad saying that where you go to school doesn't matter or a rich person saying that money doesn't make you happy, or even the myth that Einstein failed at math. These statements that espouse a false sense of modesty have great appeal and they likely come from good intentions, but ultimately they give people bad ideas about what it takes to be a fairly competent developer.

This would be a good April Fools ecommerce site. "Dried out markers! Guaranteed to land you a job!"

For OP, I read your post and the post you linked from 9 months ago. It sounds like you two have fairly different backgrounds and experiences. The other poster said they had only worked for 1.5 years before getting fired at a first job, and then spent time leetcoding. 1.5 years is a short time for a person to be able to learn how to effectively work in a grown-up world after school/college. In fact, I had a similar experience at my first job (I didn't get fired, but I was getting below-average performance reviews and I left on my own), also for about 1.5 years. It wasn't until later I learned what matters, what to do and what not to do at a job, and then excelled.

For you, it sounds like you've already learned it, evident from the fact that you had 4 years at a real job with a senior title, proving that you can do it well. It sounds like your issue is more around finding meaningful work, having a disdain for the current trends of agile, react, CRUD apps, etc. which isn't uncommon. I think there are other solutions to what you're facing, and leetcode isn't it.

For me, the key has always been working in an industry I'm truly interested in, then I can dive deep into the business domain knowledge. I'm a very senior level engineer and I'm good at it but at the end of the day the code is still just a tool to me. I don't really care if architectures are tried and boring, I just want to make business impact and build products. Maybe it's the same for you, maybe not. The key is finding what matters for you, and not care about parts that don't matter.

Off the top of my head, React uses lots of graphs and trees to render stuff.

Also there is almost never a reason to implement such things yourself—even when you need the algos—as there are libs for that! (Imho one of the biggest signs of incompetence is when someone starts to reinvent the wheel! That's an absolute no-go. And the truth is: If you're not in academia doing research all the wheels you ever need are already invented).

A valid test for a candidate would be whether he/she is able to google for an algo and pick the correct code form the results.

Such a test would be good enough as a lot of bad candidates would fail as they wouldn't google but start to "solve" things on their own; the other bad ones wouldn't be able to pick the right solution at all—because they don't know what they should look for in the end.

I believe you and others when they claim they are good developers. I just want to point out that for many people, it can be impossible to understand how your minds work.

Maybe it is a bit like dyscalculia, where some people can not comprehend "amounts". They can not calculate well, but they can actually be good in other fields of mathematics.

Edit: I never did a lot of leetcode, but for reference, here is a problem they categorize as "hard": https://leetcode.com/problems/median-of-two-sorted-arrays/

It requires calculating the median of an array. Is that really a kind of thing people who are otherwise good developers can not do? I must admit it really boggles my mind and makes me a bit hopeless and desperate. It seems all attempts to explain stuff to people are futile anyway, at least for some things.

There's a huge meta-game around these questions that you pick up after practicing them enough.

Even without the hint, I intuitively know looking at that question that linear time is too easy for a 1 hour face to face interview at Google.

I also know that as the data is sorted the optimal solution must be logarithmic, as in these contrived problems there's no such thing as an unnecessary detail. Monotonic means binary search.

I haven't built this intuition from my experience as a software developer, but by spending my free time playing the game and grinding these arbitrary puzzles.

The fact you missed this meta, tells me absolutely nothing about your skills as a developer, only that you haven't been grinding leetcode.

That shouldn't be a signal not to hire you, but that's how the game works at FAANG.

If you can make this observation about the arrays, and code a fully functional binary search taking into account whether the total length of both arrays is odd/even, handling the out of bounds case, whilst under pressure on your third interview of the day with just the intuition you've built in your day job, then as far as i'm concerned you are the exception not the rule.

I really appreciate your greater point. I've been given all sorts of CS problems in interviews that I don't have any background in understanding the context enough to know what to do. I changed careers from experimental physics, so my software work is essentially self taught. That doesn't mean I'm totally useless in my job or not an asset to my team or can't deliver products that generate massive revenue. But, those things are how interviewers make me feel.

Merging and comparing arrays as in that task also seems like something that might actually come up in a job.

However, I take the point of the other comment that the real issue here is doing it with certain speed requirements. That does make it harder, indeed, but still doable.

Self learning 'big O' is a waste of time and effort. Never have I needed to know it to accomplish a task beyond interviews. Don't nest six for loops, reading lines from a file into memory each loop. Got it, learnt it, can do. Next problem.

This gatekeeping attitude is bullshit.

Understanding Big O notation is not that difficult and everybody knows it is a common question in interviews. Analyzing specific algorithms can of course be difficult.

Having a CS degree gives you a large advantage when solving problems like this, but that advantage is markedly lower when you are trying solve typical real-world problems in the private sector.

Self-taught or not, no one is able to derive an optimal solution to algorithm problems on the fly. You must have previously learnt the technique, and probably practiced applying it a lot.

Also I must admit I used to enjoy such tasks more in former years, now it seems more like a needless chore. On the other hand, somehow I feel compelled to solve games like "Human Resource Machine" or "Infinifactory", which can be equally tedious.

I'll try to solve that leetcode task.

I was once asked to produce the proof of the theorem of Pythagoras, which I hadn't thought about for many years. I failed to do it in the interview situation and later did it at home. However, I enjoyed the interview and I was also offered the job.

A good exercise, I think, would be to ask people to implement binary search (assuming they never have before). We can all intuitively explain the algorithm, but actually getting all the code just right is a little tricky. See if it trips people up. Then ask them to do it in 20 minutes or they are fired (e.g. comparable to interview scenario).

I've found a great number of "easy" problems too challenging to complete in 45 minutes. And yet once I learned the underlying techinques / DS / Algo's, many "medium" ones I can complete in 10 minutes or less, even when I have not seen that particular problem. Conversely, I was able to complete some of the harder problems in 5-10 minutes without EVER having seen the underlying algorithms before, because I actually had in real life problmes but had never drawn the connection. The more leet code I do, the more I realize when encountering a new problem, it is a complete roll of the dice if it will take me five minutes or five hours, despite being of the same level of difficulty and even same class of problem. But this is not so surprising -- this is how the history of those algorithms unfolded. Many were one line of code away from a far better runtime, and sat for years before someone cracked it.

My main take away is, algorithmic style questions can be useful to test whether candidates adequately prepared and practiced from a given set of information, and is perhaps most predictive of their level of comittment / professionalism / base-aptitude. IMHO unless you are building a novel product or charting unknown territory (rare), its far better to be experienced, prepared, and well read, than it is to be smart. Perhaps. I don't take issue with Google requiring a wide variety of expertise in such problems to get in. I do have a problem with a random set of "easy" problems and then making judgements of people afterwards. But that's just IME.

>I still deliver high quality software on time, and on budget, and have a solid grasp on my career.

There's simply no way of proving that to recruiters without Leetcode.

If a recruiter can't assess engineers without something like Leetcode, they need to find a another job. Assessing talent is the job of a recruiter, and if the only way they can do that is with Leetcode, that's just pathetic.

OP claims to have done 400+ LC problems over a couple of months. Let me say it out loud here: this is simply crazy. It strikes me as an attempt to not learn how to tackle these challenges, but to actually brute-force through them. To anyone preparing for an interview: don't do this! Grab a book like Elements of Programming Interviews (EPI), maybe follow some online courses on programming puzzle patterns, and then start grinding LC. Maybe interleave grinding with learning? Your end goal should be to develop deep understanding of what you are doing, not memorise the solutions.

Also, while going through LeetCode, it is very important to realise that the problem classification there is a bit wild at times. Don't stress that you cannot solve a medium sometimes as they are mislabeled. I did mediums that could be hards, hards that could be mediums, and hards that were just impossibly hard. Typically a very hard problem is not something you should expect in an interview setting as most interviers* don't expect you to implement KMP on the spot. Doesn't hurt to know it and impress the interviewer with knowledge, but if you think memorising KMP is the way, you're mistaken.

* - there is still luck involved and you can have a crazy interviewer. It can happen, so just accept it and move on. Don't treat it as a personal defeat.

Source: I grinded and I had offers from most of FAANG letters.

I didn't feel a need to do much more as they had very similar patterns. I did attempt the ones I had solved more than once though, but it was to really drill in the principles behind the problem rather than to try and "memorize" them.

Prior to my prep, I had almost 0 algorithm experience. I got an offer from every FAANG I applied for.

Easy problems literally mean jack and I don't even think 50 medium problems could span all of the possible topics.

Sounds like you got in when it was easier.

Out of the 12 companies I applied for I was given 2 hards (both were private startups), the rest were all mediums.

>nearly 100 lines of code involving multiple steps

I was never given anything even close to involving a 100 line solution. Are you sure this was even the correct/optimal solution? Either that or you're very unlucky. Which companies were asking such questions?

>50 medium problems could span all of the possible topics.

I was given problems that I hadn't encountered before, but I was able to solve them by deduction/critical thinking and applying the appropriate algorithms/patterns. Often the easy solution and the optimal solution weren't even that different, and just involved using a hashtable.

Grinding through hundreds of LC to try and memorize/familiarize yourself with the solutions really isn't the right method. Have you read Cracking the Coding Interview? Gayle McDowell has some videos on youtube in which she explains her process.

   I was given problems that I hadn't encountered before, but I was able to solve them by deduction/critical thinking and applying the appropriate algorithms/patterns. Often the easy solution and the optimal solution weren't even that different, and just involved using a hashtable.

You should check out https://github.com/poteto/hiring-without-whiteboards, which is a list of companies that don’t use LeetCode in their interview process.

An issue I often ran into when using the repo myself was I’d find a company that sounded awesome, and then find that they didn’t have any open positions. I created nowhiteboard.org to act as a way to pull all the jobs from the companies listed on that repo (and other companies that I’ve manually found that don’t use LeetCode).

I think there’s a matter of education and shining a light on the companies that don’t use LeetCode as I feel that the prevailing notion in online communities is that companies only use LeetCode to interview. I’m obviously biased since I’m obsessively researching this, but I’ve read a good few comments online of engineers who’ve stated that they haven’t had to use LeetCode for any of their interviews over their career, and that all of those companies aren’t listed on the repo above.

If companies had a good way to source candidates that are hesitant to jump jobs specifically because of LeetCode, I could see our industry starting to make some semblance of progress towards making LeetCode less prevalent in interviews.

Anyways, rant over, hope your job searching goes well!

Any mention of these gets a hard NO early on during the interview process.

It's really insulting to put so much effort into something and then get treated this way.

Recently: * burned 2 days PTO putting together a comprehensive solution I was proud of. Feedback was they wanted me more proficient in their specific tech stack. I'd already said I was looking to learn their preferred language on the job and would do the test in a language I was more comfortable with, and they had been happy with that line of discussion.

* was given an open ended dataset and told to spend 2 hours on it. Did all the initial analysis I do on any new dataset in my regular day to day job, spending a little more than the allotted time, and found some interesting things. Feedback was that I should have gone deeper in my analysis.

Ugh, gross. You dodged a bullet. Pathetic.

I really despise it when compulsively agreeable people agree to something without actually meaning it, just because they're uncomfortable with saying no, and then backtrack later.

If any of you out there do this, please stop now. It's a huge waste of time for the people who interact with you, and it's hurting your reputation.

> was given an open ended dataset and told to spend 2 hours on it. Did all the initial analysis I do on any new dataset in my regular day to day job, spending a little more than the allotted time, and found some interesting things. Feedback was that I should have gone deeper in my analysis.

Yeah, it's obvious that this "don't spend more than X hours" is just HR babble to make the process look fair. They want you to spend a week and pretend it took 2 hours.

I think if I had the power, I would allow candidates to have multiple ways to interview at a company. Some companies do this already where the tech assessment portion can be administered as a take-home, LeetCode challenge, or re-factoring some sort of code.

There are downsides to LeetCode, and there are downsides to take-home projects. My intention with the website is to offer extra choices to developers when choosing to interview at companies.

And I think as a candidate (and companies as well,) LeetCode is the more scalable of the interviews since there’s defined criteria to study and to test on, so I do see the merits of your POV!

I’m not necessarily about this full-on hatred for LeetCode, BUT I also did buy fuckLeetCode.com just in case

I also find that Leetcode translates really well into the code I write in my freetime (a roguelike. Real work is boring fullstack crud). I personally hate reaching for libraries in my side projects, so being able to have these data structures and algos at my fingertips and being able to implement say A* or a weighted rng function or something else on the fly has been super handy. I honestly don't think I would be able to implement a vertex fragment shader w/ lighting without the skills I've picked up from Leetcode grind.

"Solve this problem in 45 minutes. Top to bottom, single pass, no typos, right now, while I'm watching and interrupting your thought process. You are not permitted to feel anxious. You now have 43 minutes - Go!".

This is not a representative field test.

The "right" way to use Leetcode, is to treat it similarly to how IBM does their weird IQ test screening, except Leetcode is strictly better than an IQ test. It is NOT a simulation of work. It is also NOT an "intelligence" test (thank god for that).

If anything, it is closer to how professional sports teams evaluate young athletes via a training combine or a set of individual drills/tests. Doing vertical jumps or sprinting really fast are not "representative field tests" of how well you actually play a sport (the whole sport, not just a single part of the sport), but they are good-enough filters for an athletic "interview".

However, in the same way that IQ tests are bad for a multitude of reasons including implicit demographic biases, so too are Leetcode tests flawed (including a heavy element of age-ism, as there is a strong anti-correlation between "years since college" and affinity for Leetcode-style tests).

I’m not sure how common this way of thinking is, but I wanted to point it out since many of the comments here make it sound like only the best answer will do.

I've been doing this crap way too long to do brain teasers at an interview. I suck at them, I always have. Advent of Code makes my brain hurt.

That doesn't mean I can't design, implement and lead a team to create a service that can handle insane amounts of load with minimal cost.

Can't even think of a similarly stupid thing to ask for a different field. Are doctors quizzed on House[0] -style patient cases to see if they can tell the actual cause from the top of their head?

[0] https://www.imdb.com/title/tt0412142/

You just answered a different question. OP was referring to job interviews, not certifications (most certifications in S/W development work the same way).

The analogy would only hold if medical doctors would have to do these multi-hour exams each time apply for a position.

So do they?

Or is it a certification exam comparable to an AWS/Cisco/MS cert?

Now that I'm looking again I do see that many companies have switched to practical take-home type stuff, which is far preferrable.

But what really surprised me are the portfolios — trainee doctors keep track of things like procedures done, so they can present a portfolio at job interviews.

OSCE example: https://www.gmc-uk.org/registration-and-licensing/join-the-r...

The BMJ on “Creating a good portfolio”: https://www.bmj.com/content/338/bmj.b811

I don't know about doctors but police inspectors are definitely trained on Cluedo. /s

I get the sentiment. I really do. I have been both a programmer and a lawyer. I was a programmer for about 5 years in the late 90s/early 00s. Then I was a lawyer for more than 10 years.

Being a lawyer is not better than being a programmer. For the overwhelming vast majority of lawyers, you either make a lot of money killing yourself with lack of sleep and high stress and wasting your life doing the same shit over and over again, or you make a loooooooooot of money doing that same thing but making a bunch of assholes even more money in the process, or you make very little money but not proportionally less hassle/stress/life-wastage. Yes, your skills do retain relevancy for quite a long time though. There is that. But so what? Still gotta do shit-tons of CLEs every year. Still gotta keep up with the laws and chase clients (unless you're the super rare rainmaker or are okay stagnating).

After I got tired of being a lawyer, I went to be an experimental scientist. This has been nice, but it's not for everyone, of course.

I was going to continue on to a PhD, though my circumstances have changed enough that I am no longer sure if I can do that, as much as I want to do that. I have been thinking long and hard about what to do lately. Having had experience as both a lawyer and a programmer, I tend to lean towards going back to being a programmer.

My only real point though, is, the grass is always greener. :)

In the end, I really do sympathize. I'm not trying to be critical at all.

It sounds like hell compared to a software job.

Software development isn't perfect, but the compensation, hours, freedom, time off, potential upside, even stupid stuff like being able to wear normal clothes or get flights paid for if you want to go to a conference. It's a pretty sweet gig.

LC was obviously to prep for interviews which are time boxed. This means for each problem I had to:

- plan, come up with a pesudo-code and verify the correctness *before* implementing it

- write concise and readable code

- make practical tradeoffs

LC isn't fun. Maybe it is for some folks but it was discouraging for me to some extent since it made me compare with folks who can solve these problems when I'm clueless

But this was the eye-opener at the same time. It was shocking to see someone can solve the same problem with less than 10 lines of code when my code is 100+. It taught me what parts of my code was unnecessary and also some neat tricks certain languages provide

This isn't to say I'm LC God. I still suck at LC but what I appreciate is I get better little by little. I tried a medium level question last night after more than a year of break and couldn't solve it haha

I see your point about creativity. I think algorithms are mostly memorization. I'll never be able to come up with KMP algorithm or gift wrapping algorithm from scratch. However, how to apply these algos on a problem or transforming a problem into another problem that can be solved easily is creativity IMO

I do have ADHD as well and my advice is this is something you have to solve with pychaistrists with different meds and therapies.

LC is not fun but necessary to be a good engineer IMO

It did alter my coding too.

You are not an 3l337 h4x0r who p0wns puzzles for a living. You're a professional software developer who builds useful systems for people and organizations.

It sounds like you know the kind of culture you've enjoyed, and you know what the red flags are. Which makes sense. I think everyone gets pickier as they gain experience.

A classic.

Even if you don't do well at the single LC style question in our interview loop, you can still pass and be hired, there are other things we ask that are specifically NOT LC type questions.

Find a startup to interview at, skip the 4 LeetCode questions in 4 hours interview.

The amazing thing about SW is you can get a job - and even some of the best ones - without any formal education. So even if you don't agree that the ability to solve Leetcode problems is predictive how good an engineer is - just power through it.

And keep in mind that, for example, Electrical Engineers have to know tons of difficult math, physics, circuit theory, analog and digital design - and yes - even programming, where the acquisition of these skills is just as hard as getting decent at Leetcode - just to make a fraction on what you make.

In the US of A. In continental Europe this is just an office job. Maybe you can consider it an upper-middle class job if you're senior enough.

Pay is not related to effort, pay is related to value provided.

Its not an insult, comparative effort is a way many people think at the bottom out of necessity to focus and escape, people at the top gaslight people into thinking this way to retain all the value.

Tiger Woods started training at age two, and spent his entire childhood training hard, consistently, repetitively, nauseatingly.

It takes monumental 'raw effort' to get into a good law firm and to work your way up.

But the partners, even though they don't have to do a lot of the grunt work, are not slouching. They are busy to the point where it can even take over their lives: social aspect of their lives blend with business. Imagine your ski vacation becomes 'work' because it's with the clients. Etc..

This process lacks inspiration. Even following a company’s “false positives are worse than false negatives so we don’t care that experienced people can’t pass” logic, leetcoding doesn’t help with that. So a third unknown process needs to be done instead.

The simple reality is that there is alot to build, in this sector. People can slave away preparing themselves for a lower paying job with higher requirements, and that has nothing to do with whether this sector pays alot now or 10x more in the future. The market is saying what to do. Hiring practices are hampering the market efficiency. Full stop.

I think it's a weak correlation at best. A single data point (Tiger Woods) doesn't constitute a correlation. People working manual labour jobs put in a lot of effort, but they create comparatively little value.

I suspect that leverage and value are highly correlated. If you have more leverage, you're probably going to create more value.

That doesn't imply that 'hard work' alone creates success, value or leverage.

I resent the implication that we should beg to be paid what we're worth and be grateful to be made to do a jig in a tutu for scraps that fall off the table.

Managers of those engineers can make more plus they don't have to do technical interviews

Software engineering is an engineering discipline, not an art. Engineering is about applying the best known methodology to solve problems.

That does not mean there is no room for artistry and creativity.

But most jobs are looking for software engineers, not artists. To them it's more important to have a reliable ETA and get a robust product than for you to find new and creative ways to solve their problem.

Live out your need for creativity in your open source side projects.

Generally speaking: Be creating in WHAT your are doing, not HOW you are doing it. The more creative your methods are, the higher the likelihood of failure. Which is good if your goal was to learn something, but not so good if someone is paying you to solve their problem.

Also note that most software engineering is grunt work. That does not mean it can't be fulfilling, but it does mean you don't have to be a 10x engineer to do it. View software engineering as a great way to make money. Then tend to your needs in your side projects.

For most software projects including web development or CRUD applications, there is no known best methodology to solve problems. Despite how passionate some people are about extreme programming vs. pair programming vs. TDD vs. this vs. that, there is surprisingly little empirical evidence that one methodology is actually better than another. We do what we do out of imitation rather than out of solid and well researched engineering principles.

Other software engineering roles do involve a fair bit of creativity though, e.g. architects (designing the structures), computer scientists (study how to make better bricks), and perhaps also project managers (coordinate brick laying and manage bricklayers).

At any point of time, have two buckets of projects to work on.

#1 projects that lets you apply what you already know and ship fast while being useful in real world (typically dayjob takes this slot)

#2 projects that lets you learn new stuff and think creatively, while affordable to fail or ship slowly (usually side projects)

Following this gives you a balance and avoids burnouts.

and example might be a permissions feature that could be designed as adding a column to each row, or could be more generalized into a foreign table giving the ability to N:N, or create arbitrary new permissions etc.

It's a bubble of a specific type of engineer. Have you tried your hand at project Euler or Advent of code? I feel like those problems are like leet code( or hacker rank) problems but with a different bent, one thats more enjoyable and allows for greater level of creativity when solving for them.

I also want to affirm that yes, part of the reason for these tests is definitely to check that you are able and willing to jump through the hoops that a large organization sets up as it scales; it's no fun at all.

As someone who's done the grind myself, I would push back slightly and say that the skills I use to solve leetcode problems are ones I've used at my BigTech job, and that that can be fun and useful. Gaining that type of insight though, generally doesn't come from just grinding leetcodes over and over again, but also returning to study algorithms textbooks like CLRS. The insights you gain from understanding these techniques deeply can lead to some truly interesting solutions to real problems.

Best of luck.

a formal 400-level course in algorithms will go a long way, preferably at a good university with a good professor, but if you can't get that right now: https://ocw.mit.edu/courses/electrical-engineering-and-compu...

computer science is a discipline where people seem to think the education doesn't matter that much, but the truth is once you start to get even a little mathy it matters big time

I think when people say that education doesn't matter that much in our field; they are talking about formal education as offered in academia.

This is not to say that university education isn't valuable. But SE is unique among engineering disciplines because a) it is possible to learn everything relevant in self study and b) a lot of formal education in the area still teaches CS, when most people who attend the courses want to be engineers, not scientists.

On a personal note, I do believe LC has made me a better programmer. In my 3rd year of BTech, I was given a task to figure out splitwise (a bill splitting app) algorithm. I was quite proud to have written a modified version of Kruskal's which solved the problem. Last year, I saw the same problem on LC and it had a much cleaner and nicer solution to it. The solution opened up ways for me to think in different terms all together.

Similarly when I was in my 1st year, we used to play `Chain Reaction` a lot and I wanted to write a brute force A.I. for it. I had not been introduced to graphs, DFS or BFS algorithms. Hence, I had basically produced a recursion hell but working solution. Later when I had discovered DFS/BFS, I was ecstatic to say the least.

Thus, I believe LC helps/prepares/arms you with various techniques which you could leverage to solve certain problems in a more efficient (and also as a result, cleaner code) fashion.

Also, SWE is a highly movable profession, where being more than 5 years on the same place is unusual. So every ~5 years you have to polish your CV, grind LC and basically restart learning all computer science concepts you haven't used in those ~5 years, without feeling burnout or dismay.

How do you feel about puzzles in general?

I have a really strong antipathy towards 'solving' anything that I know is (a) already solved and (b) where the solution process is not interesting in and of itself. So I hate, hate, hate puzzles.

Your post made me wonder if there's a link between ADHD and finding explicitly pointless challenges unbearable. It feels kind of intuitively true that ADHD predisposes one to cut a lot of mental chaff in order to focus on stuff that's engaging and interesting; a puzzle is kind of explicitly chaff, it's something you have to manipulate in some way to get some predefined result.

The normal trick if you're up against this kind of intense, adhd-driven disinterest in something is to see if you can twist it in some way until it's interesting for you again. So instead of seeing the puzzle itself as the challenge, turn it into a training process for something for something you consider worthwhile.

I love puzzles though. They're short, they have a right and wrong answer. Optimization problems are especially satisfying because you can get a score, and improve on it over time when you come up with clever ideas.

I've never done any problems on leetcode, but thats absolutely my wheelhouse and I love that stuff. A few weeks ago I invented a new String (Rope[1]) class by combining skip lists and gap buffers. I don't know if anyone else has ever done that before. Its 3x faster than the next fastest library I could find. There's probably an academic paper in that, but that sounds really boring.

Maybe its useful for other people, but I think if you said "leetcode is a training process" to me, that'd make it more boring. For me the fun part is finding those puzzles in regular code. ("Sure this algorithm is simple but its n^2. I wonder if there's an O(n log n) approach out there somewhere..?")

[1] A rope is a "fat string" for text editors and things, where you want to insert / delete characters at arbitrary positions. My library is here - https://crates.io/crates/jumprope

But plenty of algorithmic ideas are broadly applicable and useful. Eg, b-trees, bloom filters and priority queues have some wild uses across a host of problems. Those tools strike my fancy.

I also find it unbearable to "solve" something I see the solution to, or can describe how to solve it. In fact, if I see the solution, I find myself unable to go through the steps to actually do it, especially if there is a time constraint involved.

The trick you have described was my way to do the problems in my spare time back when I hadn't seen them before, but the whole problem is that leetcode problems are designed for an incredibly narrow range of solutions.

Analytical solutions that have poor worst case run times, but incredibly good average case run times are not allowed and a lot of mathematical approaches involving matrices and exploiting vectorization aren't allowed either.

Leetcode-style problems force you to put your mind in a very narrow box and I simply can't do that. I've always had a very great need of orthogonalization in how I think and operate; i.e. if something doesn't stimulate me enough, I need another concurrent activity that is completely different to keep me motivated.

> This is also what Software Engineering has become: you memorize, regurgitate and participate in agile the masquerade. Creativity is shunned. Tried architectures/patterns are what is expected.

Compare https://sockpuppet.org/blog/2015/03/06/the-hiring-post/

See https://hn.algolia.com/?q=https%3A%2F%2Fsockpuppet.org%2Fblo...

I have in fact recently been doing a lot of Lichess puzzles, and what happens is I start to notice patterns. For example there have been several puzzles where the other side has just attacked one of my pieces, while I have one of their pieces attacked. So I can take theirs and they take mine, or I can move mine away and they can move theirs away, or I can do something else and let them decide whether to trade or disengage or leave that situation pending.

But wait! For that middle option--mutual disengagement--I see that I can move mine away to a square that gives check. They have to immediately deal with that check so they don't have time to mutually disengage. I'm winning a piece!

And now I've learned a pattern--if someone is depending on some sort of symmetry in a tactical situation that gives them matching moves they must play in response to mine, a forcing move such as check can break that symmetry.

For each puzzle where the answer is not an immediate application of some pattern I've already learned after solving it I step back a few moves before the puzzle position to see how it arose (Lichess puzzles are all drawn from actual games played on the site and include the score up to that point), identify why the move that set up the puzzle was bad, and see if there is some new pattern to learn from it.

Can someone with better understanding explain the negative sentiment around leet coding. Are most SWE just mediocre at coding or is there just some fundamental difference between leet coding and the skills needed to be a SWE?

At the risk of catching a lot of shit for this, I’m going to say yes to both of those.

A large amount of software development jobs involves taking various components big or small, and gluing them together with business logic of varying complexity and then trying to figure out what’s going wrong when one of the components or glues fails. Pretty much every job I’ve had personally has ended up being call some API / Query some DB and perform business logic on the results. There are a LOT of jobs like this out there, and a lot of them pay pretty good, by anyones standards who’s not into the whole tech culture. You perform at these just fine without hardly any knowledge of implementing many data structures or optimal algorithms.

I have also sunk weeks on algorithmic problems much more complicated and less clear-cut than anything in leetcode!

But yes, that kind of puzzles can be fun sometimes! (Back when I had no family and free time for such things).

But worst part is that the interview experience is entirely different from doing puzzles for fun at home. In an interview you need to present a carefully choreographed act where you:

- pretend to be quickly discovering the solution out of the blue (even though the original algorithm took some PhD multiple years to figure out)

- never solving any part too quickly, or they'll fail you for having seen it before (of course you've seen it before if you've done the requisite months of practice)

- never solving any part too slowly, or you'll be labeled "yet another who can't even write an if statement" (comment seen often on HN)

- maintain a running commentary to "show how you think", make it credible

- while doing all this, be writing syntax perfect code on a whiteboard

- while the interviewer makes derogatory comments about how much help you appear to need, alternates between browsing social media on their phone

You need the pocket Dijkstra, Kruskals, Union-find, Bellman-Ford, KMP, Kadanes (sliding window), LCS, DP (1-n dimensional), Topological Sorting, NP-hard heuristics (usually DP), BFS, DFS, Backtracking, Memoization (basically DP, but usually used in DFS), Prefix sums (DP as well), that weird palindrome-specific algorithm I can't remember, binary search, bisection (numerical anaylsis ftw!)

You also need tries, heaps, red-black trees, B-trees, DAGs, priority queues (heaps)

But wait.. there's more!

Euclidean algorithm, Josephus Problem, Sieve of Erastosthenes and all the number theory bullshit I can't remember and refuse to, because it has fuck all to do with daily engineering.

I have a masters degree from CMU, certainly a very top school in CS. I probably could've passed this style of interview fresh out of school. I did enjoy algorithm classes, it was fun.

It was also well over 20+ years ago and having had a successful career in silicon valley as an individual contributor, I have used that knowledge... never. Not once. It has no relevance to software engineering. I've forgotten nearly all of it. Want to hire someone to design and implement solid, performant, maintainable, secure production code? That's me. Want to test me by regurgitating memorized algorithms? Nope, I'm not participating in your game. The loss is yours.

I've never ever even heard of an interview problem where a b-tree or RB tree was required to solve it.

But my point stands that there are a ton of great little questions that involve very very basic data structures and tree traversal algorithms that you can use to glean quite a lot about a candidate.

You're absolutely right that asking a candidate if they can solve a 2D DP problem isn't telling you anything other than if they'd either seen this problem or they are good at this algorithm. I'm stating that you can learn a lot and eliminate some bad folks by asking some basic coding LC questions.

I think most candidates could give a solution, just not while they are being treated like sardines and prodded with a stick.

It has made me ask myself: do I really want a job at FAANG, or any high level company? I mean if it's pumping out leetcode while simultaneously dealing with office politics and sadistic managers, I think I'll just go back to selling cocaine.

I've done 700+ LC and I still regularly get stuck on Meds/Hards, but I imagine if you know all these concepts and can explain tradeoffs during an interview, you have a better chance of passing than someone who immediately spits out a memorized solution but can't explain why they chose that specific approach over another.

As an interviewer I learned that they don't tell me anything useful: people who show they can solve them just show that they spent months churning.

Most of the problems in Leetcode are related to CompSci theory (DP, DFS, efficient graph or tree reversal, etc). Reality in most software Engineering jobs couldn't be further away from the that. Even if you are working with C, you'll likely use Boost or a similar library to solve a problem that requires any of that (implementing your own low level libraries is a sign that you are a jr dev... I've seen lots of them trying to implement their email validation fn or similar).

Consider the interview question: "Write a function that can detect a cycle in a linked list."

> Between 1955 and 1967, the problem of “how do we determine if there is a cycle in a linked list without modifying the list or using an extra memory” was a essentially an open problem. Meaning, any number of PhD candidates in Mathematics or Computer Science could have written about it as part of their dissertation. With all of those hundreds and hundreds of minds, this problem remained open for 12 years.

> Do you honestly think you could, in a twenty minute interview, from scratch, come up with the solution to a problem that remained open in the field for 12 years, all under a pressure far more intense than any academic? Seems pretty damn unlikely, the only reason you think you could do so is that you’ve heard the answer before, and it seems obvious and simple in retrospect. In other words, “a-ha!”

https://www.nomachetejuggling.com/2014/06/24/the-worst-progr...

But that interest in the technical/algorithmic side of programming has turned into a paid job competition board ... I'm baffled.

If they can use what they learned to solve variations on the problems they previously solved it's probably a good signal of above average intelligence. That's also useful.

It immediately made him uncomfortable and I didn't get the job, because he didn't like the tortoise and hare solution not being as "tractable" as the set solution.

Damned if you do, damned if you don't.

For me, leetcode just helped with intuition for tools and approaches. When i see a problem, i think “ok what are the constraints? With this in mind, would it be better solved using graph structures or some recursion? Which would be cleaner? Which would be better for memory? What about speed? Etc.”, and from that point, it is just pure problem solving on the spot. Occasionally, i get those “oh, I remember solving a problem that wasnt quite like that at all, but it reminds me of it on fundamental level, and back then i remember using a recursive approach (though i dont even remember the problem at all anymore). What would happen if i approached this current problem the same way?”.

It just straight up helps me keep going and coming up with possible approaches to consider, as well as analyze and evaluate them, rather than being frozen on a problem for a while. And those “approaches” aren’t specific to a single unique problem, they apply on a fundamental level to a lot of other completely unrelated problems.

Yes, I’ve seen double nested for-loops in production code, which later became a performance bottleneck that had to be addressed. The issue is that “the problem” in that case was something that can be solved in linear time, and it would be a leetcode easy problem level of difficulty. It instantly jumped out to me wildly the second i saw that piece of code, but no original code reviewers were concerned. This is the kind of stuff leetcode is supposed to help with. Not with solving specific problems, but giving you a solid toolset and intuition on fundamental screwups and how to avoid them and spot them quickly in bajillion different situations that dont look the same at all.

Memorization won’t be your friend here, unless you possess one of those photographic memory brains that remembers the faces of every single person they’ve ever encountered. If you are going into leetcode with the mindset of “i am trying to memorize as many problem solutions as i can”, you are gonna have an awful time.

The more experience I have the harder they are for me to solve, as engineering problems tend to have very different mental models to reach the solution.

First thing you do is you ask people is that the problem they are actually need solving - most of the time refining the problem leads to there being something totally different that is requires. A process of asking people “why you want this hard to implement thing” and discovering that what they actually need is something smaller and more aligned with whats currently working. Leet code is the opposite usually - you see a simple problem but “there is a twist” that would be considered scope creep generally.

Then the implementation of the solution itself requires knowledge in your head, whereas years of experience has led me to put a lot of that knowledge out of my head and into “places I trust to find the answer” - google stack overflow, HN etc. And keep in my brain only the general abstractions of how to apply them. This allows for vastly more powerful solution making as you can stand on the shoulders of giants.

Example - see you have a leetcode puzzle. My first instinct is to use my google fu to find out what the best current solution is out there, understand it and either apply it or modify it a bit if it needs tweaking.

But that would be considered “cheating”. Leetcode: 1, Life skills: 0.

And there is the damn time pressure. Every time I’m pressed for time on my day job, its a signal something in tech or management has gone wrong, and I seek to optimize and fix that. Rushed engineers make poor, shortsighted decisions.

Each time I do an interview I feel out of sorts as all my instincts scream “something is really bad, you should _not_ be doing this solution this way it will bring pain in the future” But you have to power through. And I probably look way less impressive than someone who has the solution memorized.

  The more experience I have the harder they are for me to solve, as engineering problems tend to have very different mental models to reach the solution.

The first camp is pretty “meh” about leet code interviews because for them you just study a bit and get a high paying job.

The second camp is pretty vocal about how bad leet code is because it’s somewhat of a personal attack on their abilities.

Personally I agree with the criticism that leet code can be learned with enough practice and so it’s not totally indicative of a positive hire. But then I also sorta feel like there’s enough examples out there that people should be able to ace these tests with practice.

Some SWE just write code, they wanna make features and build a product. They don’t care about this stuff because things are fast enough without the extra thought — and if they turn out not fast enough they can still fix the issue.

Other SWE are more careful with their code, performance, etc. this is more of a systems engineer personality. Writing C, managing memory, writing optimized code the first go round. Yah, being thoughtful and careful pays off here.

No one’s right or wrong imo, or one better than the other.

Should FAANG do leet code interviews? I dunno, there’s surely better ways to interview, but at the same time they’ve hired plenty of highly talented engineers so something’s working for them?

Should SWE’s just spend a few weeks on leet code and learn the tricks? Ya, it’s pretty easy. But if you don’t want the job then don’t do it?

All the endless criticism of leet code generally comes from people who fail it. Shrug.

LeetCode is just what you get when you ask Software Engineers to solve the interview problem - they like showing off their chops so that's what you get. It doesn't need to be that complicated though. I know with about 80% certainty whether someone will work out based on how they solve that "SimpleProblem". The other 20% - just fire them if they don't work out. It doesn't need to be that hard. You don't need 100% certainty for a hire, you'll never get there. Just fire the ones that don't work out. You don't even need to feel bad for them - in this market they'll find another job by the end of the month.

I would struggle with this problem, because it's difficult to read whether you want me to push back against the requirement itself and try to solve the real problem instead of shuffling chars, or perhaps you want me to talk about the edge cases you're likely to encounter while I write the naïve solution, or maybe you want to pretend it's the 80s and nothing outside your chosen charset could ever exist in real data.

It IS important that you understand the algorithms, but I think they are far less important than data modeling and systems design. In any application, you must be able to understand and design how you model business things, and where you put them, and how and when you access them. Also how you fit a small unit of business logic into the larger picture.

This is much harder to test for, since for a given problem there might be multiple, equally valid models and solutions. So obviously the kind of auto-verification leetcode sites do does not work. There must be a human evaluating the solution, which is much more expensive.

Here is the truth about leetcode, advent of code, codeforces, whatever similar problem site:

  There is no memorization involved, just like you don't memorize every math problem on earth to map directly to a correct answer you instead derive the answer using the skills you have in math from experience solving problems before. Polya has a book for this, called 'How to Solve It' he just happens to have used math to teach problem solving but it's the exact same concept.

  You have at your disposal problem solving strategies such as: complete search, dynamic programming, greedy and divide and conquer. You don't need to memorize any code to write a greedy search, you could ad-hoc hack that together just know what a greedy strategy is. You don't memorize all search algorithms throughout history ever invented.

  There is no grind. People who haven't done it assume you sit there for hours daily writing brute force algorithms, no. Instead it's exactly like doing a crossword puzzle over a coffee and something you can do at your leisure where in a month or so you're now at leetcode medium/hard no problem.

And yes, LC problems do not deal with the day-to-day work of a software engineer. They are fun puzzles to do sometimes, if that's your thing. As a "hiring tool" I think they are abysmal. Fortunately, many companies don't use them. There is a bubble where it is prevalent, but again, people with experience can chose where they interview.

If you want Programming puzzles that are actually fun and correlate to problems an engineer actually encounters, I can strongly recommend https://www.codeabbey.com/

Hah! Not so.

I've been a dev for a long time, and my spouse a lawyer. Back when we were both fresh out of school I remember running her through quiz questions to help her prepare for her bar exam. We devs HAVE NO IDEA how much arcane archaic stuff lawyers have to pretend to know to get certified to do their jobs.

For example: "mortmain" (French for "dead hand"). What happens when property is bequeathed to a defunct institution? It's on the test. It's easy to come up with a logical answer. But to pass the bar exam would-be lawyers have to know the right answer, cold without looking it up, and why it's the right answer. Hint: it's not at all logical. And, will a working lawyer deal with that question? Maybe three times in her career if she's an estates-and-trusts specialist.

There are thousands of these things for lawyers.

Bar exams are hard because of protectionism -- low supply means high pay. The same is true of doctors and developers. Developer pay is high BECAUSE the exams are hard. The exams are hard BECAUSE developers want high pay.

It’ll land you a nice salary, to boot.

Note that I would never require leetcode during a job interview. However, a single LC question is a small-sized puzzle I can solve in a day (or a weekend). If I want to write a ray tracer, well... Good bye life for a week or two.

In other words, I have difficulties finding 50+ hours of large chunks of time to be unavailable to my family in my supposed off time. Leetcode I can do on a couch while my SO watches Games of Thrones.

Not necessarily! Maybe you just like puzzles? I don't.

>In other words, I have difficulties finding 50+ hours of large chunks of time to be unavailable to my family in my supposed off time.

If that's all that's stopping you from working on a ray-tracer, I think it's "just" a time-management problem. I work in increments ranging from 30 minutes to 2h. The trick is to schedule them, or at the very least, to have some kind of issue tracking system for yourself so that you can find an appropriately-sized chunk of work for those serendipitous 20 mins.

Lookup this book: Ray tracing in one weekend by Peter Shirley. You're in for a treat :-)

Meanwhile writing your own libraries, parsers, compilers, oh boi.

Additionally it gave me waaay more than LC stuff, especially when it comes to learning system modeling / proper OOP

None of that will help you pass an interview though!

I submit that you may be interviewing in the wrong places.

Obviously, it doesn't suffice to just point the decision-makers to your repos. You need to pick companies who would benefit from the expertise you acquired, and effectively pitch yourself to them.

Consider this problem: https://codingcompetitions.withgoogle.com/codejam/round/0000...

Several articles have been written about it, and the winning submissions all implement generic numerical integration in like 10 lines of code (a few even implement Simpson's rule), which is sort of neat it its own right. From reading solutions to other CodeJam/TC/SPOJ problems I've also come across similarly compact implementations of matrix inversion, linear optimization, etc. It sounds like your math chops are more than good enough, and these companies just want to test if you understand 80's computer science anyway. If you study interesting solutions to hard problems, you might stay interested and you might even improve more at boring LeetCode problems than you did after grinding. Chess puzzles help up to a point, but eventually to get better you have to start reading books, and that point comes before all chess puzzles are easy. Pushups help up to a point, but eventually to get stronger you have to switch to a barbell, and that point comes before you can do a million pushups.

Finally, I've given this advice in other comments, but if you're just posting this because you want to get hired, my experience is that it's better to focus on interviewing more than on LeetCode. Specifically: think of getting hired as a numbers game, and think of applying for a job as a sales process. That means having a funnel for companies, e.g. "discovered -> openings available -> resume drop -> recruiter screen -> interview round 1,2,3 -> offer". Make a spreadsheet and start filling it; don't just list companies you know about, start googling tech you're interested in to find more companies you can add. If certain types of interviews seem to go better, look for similar companies you can add, and wait to optimize your performance (e.g. with LeetCode) until you do notice a big drop-off in your funnel (e.g. recruiter screen, first round interview).

The nice thing is that there are lots of jobs out there that don't require leetcode skills. Sure, there are many jobs that do, too, but you can avoid them by looking at the job req.

Source: I too am bad at leetcode but have had many jobs in my career, including three different employers since 2019.

https://airtable.com/shr5TdnpVYVTpeRrN/tbluCbToxQ2knSLhh

Similar to the first link, as a github repo: https://github.com/poteto/hiring-without-whiteboards

Information related to companies, their culture/values, and hiring process: https://www.keyvalues.com/

Also, I've found that smaller companies and consulting companies tend to avoid leetcode style interviews. #anecdata

Alternatively check out my other post in this thread if you’re looking to target those non-LeetCode jobs specifically!

ask the first recruiter? put it in your emails? ask your friends about their employers?

I have failed candidates in the past, who have solved the LC problem, but could not reason tradeoffs and runtime complexities of the code. It was very apparent that, the solutions have been memorized from LC.

There seem to still be interviewers out there who focus on puzzle-like problems.

> This is also what Software Engineering has become: you memorize, regurgitate and participate in agile the masquerade. Creativity is shunned. Tried architectures/patterns are what is expected.

No, not really. Maybe some jobs are like that. Many are not. But even the jobs that are not like that will generally be gated by interviews that include Leetcode-style questions.

This happened in the software industry because credentials and experience often mean nothing, resume fraud is rampant, and the cost of hiring a bad engineer is very high.

How about a take-home assignment? Suggest that and many will respond, "I don't work for free" or "I don't have time to work after work, I have a family to take care of." How about just looking at prior experience, or credentials? Resume fraud prevents that, and a lot of companies prefer to hire generalists and find a team for them to work in, rather than hire specialists for a particular team. Outside of research-heavy fields like AI/ML, a university degree is no predictor of success.

So, we need to find a way to evaluate a candidate, in a short period of time, that gives a reasonable estimation of how they will do in the job. If there was a better way, and it was proved to be better, the industry would adopt it very quickly, and it would be a competitive advantage for the companies that realized it first. But that has not happened.

If you put aside the cheap cynicism that permeates threads about programming interviews, you'll realize it hasn't happened because none of the people who are hiring have figured out a more reliable way to hire, even though there are very smart people doing it and they have an enormous financial incentive to figure out how to do it better. A company that could find all the good programmers who can't Leetcode, and weed out the bad programmers who can't Leetcode, would get an enormous amount of talent that others overlooked.

This is just a hoop to jump through, and it's not nearly as difficult as getting a college degree or learning how to code in the first place. I'm not saying it's easy, I'm saying it's doable with time and practice. Most of your colleagues have done it at your current job and also at your future job. I can't do it at the drop of a hat either; I would need to practice like almost everyone else. You can do it too, if you approach it with the right mindset: you aren't supposed to enjoy it or find it intellectually interesting; it's just an obstacle to overcome and it's smaller than many other obstacles you've dealt with before.

The criticisms you mention about take-home tests apply equally to practicing Leetcode-style questions. It will filter out a ton of people who don’t have time or aren’t willing to spend it. In that sense it’s not better (and it’s probably why I see a lot more take-home coding tests lately).

But really neither of these is ok. They’re both ageist and sexist and lots of other things (older people and women disproportionately carry the burden of caring for others and many won’t have the time or energy to prep for Leetcode problems). Even if I’m willing to jump through those hoops, I don’t want to work at a place with a strongly ageist and sexist filter.

Lots of other careers don’t ask people to prove their skills before they get hired. They accept that some resume fraud will happen and deal with it. Bad hires are really bad and destructive, it’s true. But let’s not adopt solutions that are worse than the problem. Discrimination is not an ok price to pay. I’ve been working in this industry for almost 25 years now, and we did ok before Leetcode-style interviews. We can do it again.

There are many reasons why this could be the case, and it being the current best alternative is only one of them. Another that immediately comes to mind is survivorship bias.

If there was a better way to do this at the scale of the software industry, the incredible incentives to find out how to do it better would have resulted in something by now.

or better yet open your own high growth IT startup, raise few mills from VC and start hiring and see if you like leetcode interview or not.

Problem is, it's even easier to game the system by just memorizing LC questions. A metric that is known to be relevant beforehand and can be tackled by "learning for the test" is an almost surefire way of ensuring that a lot of people will do exactly that. There is an entire industry to prepare people for these tests, same as there is for standardized MC tests in eductional systems that rely on them.

It's not easy to detect resume fraud. But it's even harder to determine whether someone actually knows his stuff, or just spend time (and sometimes money) on just memorizing a lot of questions.

> If there was a better way

There is: Talking to people. Actually doing interviews.

https://www.linkedin.com/pulse/why-interview-coding-tests-mo...

However, to get to that point you need to get past the phone screen and that's usually a coding exercise. I'm not mad about that because I have seen firsthand that companies need to filter out all the ridiculously unqualified people who come their way, to ensure that time spent on interviewing (including conversation) is not wasted.

If you list a decent software job right now you will get hundreds, maybe even thousands, of applicants. Many will be outright liars, many will be junior people pretending to be senior, and many will be very good. You can't spend time on all of them. You need to have a way to decide who is worth your time, or you'll never have time to do anything else.

The "first filter" is what we have HR departments for. As you say, decent jobs get thousands of applicants. Whos going to do the phone interview on a thousand people?

The first filter is skimming the applications and checking basic credentials. Filter out resumes that don't check out, and looking for red flags. This already brings down the candidate pool to a manageable size.

I used "credentials" in the above post in a very broad sense of the word, because "something that shows on paper that you know how to program" is a bit of a handful to type.

Work Experience, Involvement in projects, a degree, a github link, code-camp certificate, reference to prior training, all of these can be credentials. The better the position, the better whatever someone puts in needs to be in Order to consider the candidate. If it's a beginners position even a short paragraph about when, how and why someone started self-teaching would be acceptable, if I am looking for a senior database engineer I want to see more.

Writing something tangible in a resume about ones skills is a prerequisite. If a candidate doesn't do that, his application is eliminated before it even gets past the desk of the first HR person. This is not "credentialism", it's normal procedure for basically every single job-that-requires-some-form-of-expertise on the planet.

"credentialism" would be to only consider candidates with, say, a CS degree. That would be bad in our industry, for the exact reason you outlined.

In larger companies, and for well paid positions, where there can be hundreds of applicants for each job, that just isn't feasible, so HR has no choice but to apply some sort of filtering.

If you can implement one of the memorised solutions on the spot, with tweaks, then you're probably good.

If I memorized how certain classes of problems are solved, and can derive an implementation from that, then yes, I am probably a good coder. I am then also someone who used LC et al. to learn about data structures and algorithms, aka. what these puzzles were originally intended to help people with.

If I memorized the question and its solution however, without understanding why and how this solution works then I am merely good at memorizing text and replaying it. This doesn't demonstrate my ability to solve problems or to code.

It's the same with translating a concept into natural language. I have not memorized the word-by-word explanation of how the JW-Telescope deploys. I have an image of the process in my mind, so if someone wants an explanation, I translate that principle into english dynamically.

If you can improve upon either the space/time complexity or even the comprehensibility/maintainability of algorithms, the industry is your oyster.

The algorithms are supposed to be fun and deriving them a group exercise.

leetcode merely tests whether you have foundational education for a professional software engineer.

like when you hire accountant you would expect them to know debit, credit and other basic stuff, right?

Would you hire someone for a highly paid job with literally no experience/practice?

But then again this is the same logic that gave us google doc coding interviews so I'm not sure why I'm expecting anything at all ...

yet there are Architect/civil engineering degrees and large engineering firms that design and build skyscrapers/bridges/industrial facilities that require quite a bit of formal training.

both of these engineering subtypes can coexist, same in software

So that's the one end. But on the other, this software I've built is already the biggest I've ever made. It combines SQL, the Go programming language, hexagonal architecture, REST, JSON, XML, some custom format like INI files, business logic, hundreds of different validation formats, models, fields, all in a very specialized three-letter-acronym-rich domain, and application that is / will be used by a small community that will end up serving millions if not billions of people (mobile networking technology)

So yeah, on the one side I'm a fucking idiot that can't get past day 3 of Advent of Code due to losing interest, on the other I am and have written applications for the masses.

I mean there was a time I worked on some iOS app, not on my own but a very small team. It had over two million installations some years down the line. And yet I didn't feel like this was my achievement, because others were involved and they all seemed to have more dedication, more 'talent', more intuition, more passion, and of course, more money.

Find joy in building something. Ignore the external pressure, slack at work if necessary, and use your free time to solve a problem you really care about.

Pros - I believe memorizing does help - If you do understand how things work - memorizing does make you fast - Leetcode did help me understand and appreciate pithy code - when I browse other's solutions - Leetcode did help me get inspired to learn new coding techniques - Leetcode did make me a better engineer who is quick to implement solutions which are already implemented - Leetcode did help me to learn libraries, functions, apis which i previously did not learn - Leetcode does bring needed positive peer pressure - sometimes helpful to get up and running and keep running

Cons - I believe it makes you run the rat race, you end up in another mill - running for someone else. - It doesn't foster creativity for the joy of programming - but rather it is motivated to clear interviews ( I wouldn't judge my skills based on leetcode alone | the gym is useful but it doesn't define me ) - I always adore super programmers like Fabrice Bellard - In programming, If I would want my skills to parallel someone, if not go beyond - it would be him. I am sure Leetcode wouldn't produce people like him. ( where would you have the time to dream and create if you use all the free time you have to leetcode ? )

1 - just try to think of a solution. Sometimes you'll just see it. 2 - what if you sort something? Sort the data and see if it helps to see a solution 3 - what if you stick all the data into a dictionary? Does that help? 4 - what if you stick all the data into a tree? Does that help?

Etc etc. You can make a nice long list of things to try. For 90% of the problems, doing one of the things on your list will lead you to a solution.

Software engineering also requires fairly strong communication skills - something Leetcode doesn't help with at all.

To me the really interesting part of engineering is educating Product people and customers about what computers are best suited to do and to rethink problems in systems of cheap tasks less than trying to fit arbitrary human centric processes (ie, a process that works for humans, but maybe isn't the best fit for a computer). Once we have a really clear agreement of the goal, it then fun to find a way to optimize a computer doing it.

A really simple analogy might be long division[1] -- if you implemented the long division algorithm on a computer you'd waste a ton of LoC, when you (usually, w/ certain caveats) can usually just use a division instruction. Sounds trite, but you'd be surprised how often I see product people, and even "Senior" engineers, just blindly copying a 10 to 100 step algorithm because that's how the humans do it, missing that the problem can be decomposed to a few general patterns and then iterated, recursed, map/reduced, faster when batched etc.

Often times these simpler computer centric algorithms also lead to much simpler code (for each do something simple), vs human centric algorithms often lead to big if/ifelse/else trees or code that does all of the tasks iteratively instead all of _one_ task for all items.

[1]: https://en.wikipedia.org/wiki/Long_division

Stop applying to those companies.

Creativity is not scalable, even dangerous, and big companies strive to scale => they need obidient soldiers, playing by the rules and just smart enough to not f*ck up a critical project.

Hence the Leetcode. It's a perfect way to ensure obidience, just enough brains, patience and motivation to risk wasting few month of preparation to the interview for the chance to get in FAANG.

If you want to be creative — "go fund yourself"! :)

I mean it in a positive way, because I feel exactly like you, ready to dump my current well payed job for the risky chance to do whatever I myself feel interesting and meaningful.

Wish you best of luck finding your challenges, and don't be so hard on yourself, leetcode is not a big deal anymore. Besides, there are plenty of startups these days full of creative people without leetcode mindset.

Trust me that I know it feels horrible when you're bad at them. It does not mean you're a bad engineer by any means. It just means you're bad at Leetcode problems! Clearly, you still have strengths that have allowed you to accomplish what you have in your career. Those are strengths that should not be discounted by potential employers and certainly not by you.

But that doesn't discount the value of those problems either. You're right that you have to memorize the basic data structures and there is a certain pattern to these problems once you're good at them. But if there wasn't any art to these problems, then after 400+ problems wouldn't you have figured out the robotic algorithm to solve them? I argue that there is more to those problems than bullshit.

People who are good at these problems exist. I would not dismiss the strengths of these engineers either. These engineers may not even possess the same strengths you do! But just like you, there is a certain skill or talent that allows them to solve those problems. Those skills are valued by companies who want to run smart engineering teams.

It is not the only skill out there, it's just the easiest skill to empirically measure. You cannot run a large organization without a data-driven method. If you trust the human intuition of your hiring team, you will have a lot (more) variance in your hiring quality. Not to mention that your hiring will be biased against women and anyone of a different race than of your hiring team. This is true even if everybody is aware of their own internal biases. This is why large orgs give these problems.

Even if you do not share those skills, you might still be valuable as a good engineer. You just have to look for teams that are looking for asymmetric advantages: that is, those who can't afford to compete directly against the richer teams.

https://www.youtube.com/watch?v=FHwnrYm0mNc

Copilot cannot "solve" these problems, it just knows the answer.

And for that exact reason, using LC as a hiring tool runs into the same problem as using standardized tests in colleges: Once people figure out that the tested metric isn't actually "understanding of the subject matter" but "test knowledge", and learning for the test is easier than understanding the subject, people start learning for the test.

The reason for the struggle is that, framed properly it tests a real world situation. Given this problem I've told you about in advance, how well did you prepare yourself to answer it?

I don't think it's fair to tell the candidate they could be asked about sorting, trees, lists, graphs, dp, lp so try and cram a 4/6 year CS degree(s) into the next two weeks. That said, telling the candidate, that they will potentially be asked to whiteboard a solution involving binary trees, sorting, or a linked list seems fair to me.

This.

That is, if you want to be a part of such company.

Because, yes, compensation is awesome, and you get the shares and what not, but there is more to life than that.

Scratch the surface a bit deeper, there are many different companies out there with different core values that will attract totally different group of people - while having all of the benefits of a "well known company"

So at least in India, from what I have encountered so far and I am yet to encounter a company that hasn't asked me those questions yet.

If you can, try to apply to companies in cities like Berlin, Vienna or Paris, but of course not everyone has that opportunity.

I recently interviewed somewhere where I did a leetcode interview, then a take-home and then it felt like they didn't care about the 6+ hour takehome and made me do another leetcode. Pretty frustrating!

Thanks for the thread, it's nice to vent! It's also good to learn how to be a better interviewer, and write better interview problems. My favorite is a debugging interview, where there are like 4 bugs in the program and we work with the interviewee to solve the 4 issues. I'm sure there are problems with this style too, but it's far more practical...

1. Team player. Modern development is a team sport. Bonus points if you've actually played a team sport so that you have an understanding of team dynamics and how to work with a team to achieve goals. A lot of people still think software development is a career for loners.

2. Good communicator. Developers interact with multiple business groups, multiple technical groups within the organization and multiple technical groups outside of the organization. You have to know how to communicate effectively with each of those groups - who all have varying technical backgrounds and understanding of what you're trying to accomplish. I'm not saying you have to be extroverted to be a modern software developer, but you can't be so introverted that interacting and engaging with others is difficult for you.

3. Big picture understanding (abstract thinking). A successful developer needs to be able to traverse several layers of abstraction. The people who can't do that well can't see the forest through the trees. They get lost in code and can't think about the abstract things the code is implementing and how those things interact with one another. They get lost.

You know what I don't care about? How well you do LeetCode exercises. I have some great people I've hired onto my team and I have no idea how well they can do LeetCode exercises because those aren't the problems we have to solve.

Same as for other professions, you would suffer in law for the first 5 years doing proof-reading (the grass is always greener).

But if you want creativity - why not just build your own stuff? You have a super power that majority of the planet does not have. Alternatively changing jobs to a different kind of company that structures this position differently?

It isn't. There is a bubble where it is prevalent, and there are lots of companies where people actually talk with candidates, eg. about software they have written, why and what they were excited about it, discuss the company product and what they are looking for in terms of contribution, etc.

leetcode is hands on demo of what you can do and how you think.

since big tech pays big $$ they can afford to set the bar higher than just talking