Ask HN: What to do about ‘Good at programming Bad at Leetcode’

My advice? Same as ever. Suck it up. Do it - it's hardly the worst part of the job and not doing it will mean you make less money. You're very unlikely reaching $500k+/yr by avoiding LC compared to how trivial it is to reach once you accept it.

If you think leetcode is the worst part of being in this workforce - you live one incredibly privileged life. Wait until you have to deal with toxic management that exists in virtually every company and in virtually every leadership position. Wait until you have to deal with people who have a personal vendetta against you because of prejudice and will block any achievements you can make at a company. Are you excited for stack ranking? It exists at nearly every company and if it doesn't explicitly - it happens mentally. Are you excited to see incredibly huge churn in your industry? Are you excited to see the best and brightest constantly shutdown due to favoritism (and you will likely not be in that in-group)? Are you excited to watch people over the years lose all their hope and become soulless corporate ghouls who become the shill LinkedIn promoters that they themselves condemned a few years previously? Are you excited to work 60+ hour weeks to get PIP'd because that's just the way it is? (It will happen) Are you excited to put nights and weekends in at startups to see a round where the execs lose no value but your stock sees 3x+ dilution and no increase in value?

These are common problems at companies within SV. Leetcode is hardly a problem when you see how fucking terrible the rest is.

Sorry, but no. I refuse. The industry can continue to pump out subpar solutions with their toxic culture until the VC money dries up. Out of principle I will not memorize your LC problems.

I won't deny it's a great filter for getting the exact type of people that will tolerate, enable, and expand this culture.

> These are common problems at companies within SV. Leetcode is hardly a problem when you see how fucking terrible the rest is.

Am I understanding this logic? Are you saying let’s keep terrible, arguably pointless interview processes and needless gate keeping because there are other bad things in this world?

No, I’m saying there are bigger fish to fry. LC is easy compared to this other shit.

LC makes your job search terrible. The work culture makes your life terrible.

Money. Compared to other industries - it’s much easier to make $500k/yr or more.

I’ve had jobs where I was at $1m+. This would never happen in other industries unless I had X prestigious university on my resume or was married to the boss’ daughter.

I could’ve been a surgeon, a lawyer, etc. but most of those have even worse hours, more time in college (debt+non-earning-years), and tend to not favor my background. (Poor rural upbringing) I’m already an outcast in tech in SV - I’ve come from the smallest town, least educated, and poorest family of anyone I’ve met here under 35.

I don't think they said they currently are. I hope for their sake they moved on because it doesn't sound like they had a particularly great time.

On topic: there are plenty of great employers in our industry but you will have to make an effort to find them. And of course it's never going to be perfect.

Maybe this is an odd proposition, but if you can't find no-whiteboard employers in SV, why don't you go looking elsewhere?

It's still paying the bills and 80% of these problems aren't industry-exclusive?

I disagree with this take to an extent. Take it to the other extreme and you get folks who can’t even solve fizzbuzz. So some coding bar is good.

Leetcode is a very learnable skill, and I would argue any decent programmer can learn it well enough to pass an interview. I for years thought I wasn’t good at it, then I actually practiced and I got job offers at google and Facebook. I have also optimized code quite a few times using algorithm skills I picked up practicing for interviews so it’s not totally a waste.

There is a limit though, and some companies are pushing it with absurd questions that you couldn’t reasonably solve unless you had seen it before.

In summary, algorithms are useful and learnable, but some companies take it too far.

Here's the thing, large tech companies aren't looking to hire engineers, especially juniors, who are great at being an engineer because that's incredibly hard to test for in an interview and almost impossible to scale fairly. They're looking for people who will devote their life to the company and can quickly learn new skills. That's exactly what leetcode tests for, so it really isn't surprising at all that every tech company does leetcode interviews. Really the answer is either commit to the grind or go for a job at a non-tech company.

I appreciate the cynicism but isn't it more likely that they use it just because everybody uses it?

> an quickly learn new skills. That's exactly what leetcode tests for

I don’t know where people get this idea. Leetcode used to test programming proficiency

I feel the only reason companies continue to take leetcode to absurd levels is because (a) they think harder questions would get them better engineers and (b) other companies are doing it

> Leetcode used to test programming proficiency

The discussion is exactly this, that leetcode is used to test programming proficiency, but it's an inadequate bar.

The parent is postulating that it's a lie; that actually leetcode tests for malleability, and we're getting bent out of shape because we think it's a poor test of coding ability.

However it might be a good test of malleability, and that might actually be it's intended purpose, but that's not communicated.

I don't know about malleability, but I know Big Tech uses it to filter down the number of applicants. They get 200 applications in an hour so HR needs a way to pick a few that won't get them sued.

Understandable when big tech does this.

200 person tech companies are doing the same.

Not quite but almost: Leetcode doesn't evaluate programming proficiency but ability to solve complex and abstract problems using programming. Doing so doesn't require being good at programming but being good at solving problems, and doing so using a programming language. It doesn't require knowing a language well, but only well enough to solve the problem.

I've had zero or near zero gotcha string problems in my professional career, which are many of the leetcode problems.

Find the (gotcha) in this string and emit len(gotcha) ... Now do it computationally efficiently (or be able to explain tradeoffs to other resources).

> It doesn't require knowing a language well, but only well enough to solve the problem.

I guess that really depends on the language. IMHO, if you can solve a reasonably complex problem using a language, you know that language.

This doesn't seem right at all. I can kludge together a solution to an arbitrarily complex problem in any language, but that doesn't mean I'm writing it in a way that can be extended and developed upon by other people. The latter is also what takes up the majority of development time.

> Really the answer is either commit to the grind or go for a job at a non-tech company.

There is quite a world outside these mammoths Google/Facebook/Amazon/(MS, depending on how their IBMization is going these days) and their minions/wannabes. Personally I would not work for any of these even if they paid me in gold bars.

> devote their life

Sounds like they are trying to breed a cult...

More like, sounds like the parent comment you replied to has no idea what they are talking about.

I worked across a couple big tech companies mentioned in the thread, and I've met maybe a couple coworkers at most who "devoted their life to the company". And that's across almost a 3-digit number of people i worked with in some capacity over the years. People take vacations often, they work 40 hours a week or less on average (over the year).

One big thing about most teams at big tech companies (probably sans Amazon, from what i hear, haven't worked there myself) is the work/life balance being an important priority. We had a manager giving stern talks to the few teammates who would reply to work emails on their days off ("you left for a week of vacation in Hawaii, why are you replying to work emails or even brought your work laptop with you? Please stop doing that and enjoy your vacation, everything will be totally fine when you come back.").

I don't even care to defend any company, that's their problem. But seeing the whole "cultism" and "expected to dedicate your life to the employer" accusations just make me feel like I am reading some alternate timeline fiction story.

I didn't mean it in a "cultism" way at all. I was more saying that the point of leetcode isn't to discover if someone is a great engineer but to discover if they are capable of becoming one. Big tech figures if you're capable of becoming a great engineer you either already are due to experience or soon will be because they'll make you into one.

They've decided things like ability to devote time to a meaningless skill that is required to get the job, attention to detail, and problem solving skills are what is required to become a great engineer and see that letcode is a good way to test for those things at massive scale.

They are exaggerating but not all wrong. As hiring manager my job is not to train you for your next job. I'm hiring for productivity and that takes time. If you are going to jump ship before you "pay" back the company then I'd rather skip on you. There is no test but I want 2-3 years if you take 9 months or more to get going and I'd be foolish if I didn't want more.

Lots of programmers think they are 10x but few are. Even my best senior engineers took 2-3 months to settle in and contribute more than they take and juniors are bigger gamble.

The best proxy now is will you spend 1 hour on a simple set of tests, if not you are not serious or are shopping for counteroffers.

To second this point, part of being a good programmer means picking up new skills quickly, and then applying them.

Leet code is very contrived. However, learning leet code, then applying it in an interview shows you have the aptitude to learn quickly.

> Leet code is very contrived. However, learning leet code, then applying it in an interview shows you have the aptitude to learn quickly.

I feel very strongly that this premise is flawed. It shows that you have aptitude for a very specific type of learning.

I lead an engineering org at a small startup. We teach our engineers to dive deeply into the customer value prop to find ways to deliver the simplest technical solution to their problem. You don't need leetcode skills when you can identify simpler, more accessible solutions to a customer's need.

The reality is outside of very specialized technical businesses (or business components), most engineers jobs are not to build technically advanced solutions.

Yes, exactly this. Leetcode isn't just an irrelevant skill in these situations, it's the wrong skill. Algorithmic optimisations are pointless if you can't assess how much value they generate.

MAANG seems to use Leetcode as a legal proxy for conscientiousness and IQ without testing for other relevant qualities such as strategic insight, creativity, and other skills that are essential for a successful business.

There's no problem with testing for basic coding ability, but if you're not selecting for broader skills - preferably with some diversity - you get the same old leet monoculture causing the same familiar delivery and stability issues.

It also shows you have the time to prepare. Not everyone has that luxury - think working parents with some other challenging happenings thrown in and you have an advantaged and disadvantaged class of people for these interviews

I had a 3 and 2 year old when I prepared for interviews and I did alright enough to get a job at a FAANG (and it's not Amazon). I took about 2 months and blocked some time every single day. I still managed to cook meals for 4 and put two kids to bed, and wake up at 1am and 3am for night time milk feedings... yes that's not delegated to a housewife it's done by me.

The cynic in me says that's intentional. They want young, enthusiastic people willing to work for less that they can throw away when they're done.

It's more than cynical: https://www.britannica.com/event/Griggs-v-Duke-Power-Co outlines that IQ tests are unconstitutional due to racial biases.

It was out of that judgement, that companies started to require degrees for office jobs of all sorts, as you could discriminate based on education but couldn't on an arbitrary IQ test. And naturally, tests on the topic of a job can also be administered.

And I do think you're right - Leetcode does select for recent graduates who likely were taught in a throwaway language for academic purposes. And selecting for young college graduates are highly likely what they're searching for, as they also do not know their worth.

This argument can be used to justify forcing candidates to learn how to do double-entry bookkeeping (or insert other skill that you won't use on the job) just to see if they can learn. Yes, it checks if they can learn, yes, it is somewhat related to the area, but maybe there's a better way?

I've been 10 years in the industry. If recruiter tells me I need to prepare for an interview in ways other than looking back at the projects I've done, then the interview is not testing for what is important on the job.

> However, learning leet code, then applying it in an interview shows you have the aptitude to learn quickly.

That’s not why they were introduced. Leetcode using tools like hackerrank were introduced because college GPAs were very bad indicators of programming proficiency and a lot of people also did not have a CS degree.

The questions weren’t this bad before.

And these competitive programmers aren’t necessarily fast at learning things either.

> algorithms are useful and learnable, but some companies take it too far.

This is my take too. So I don’t see where the disagreement lies.

Except it’s not just some companies doing it. All companies paying over a certain threshold seem to be taking this to ridiculous levels.

And please do share your ideas for what people should do or what finally convinced you that you weren’t bad at this

> All companies paying over a certain threshold seem to be taking this to ridiculous levels.

They can afford it. And assuming they are a tech company, they need that in key roles. You cannot write things that scale without solid knowledge and intuition in designing and analyzing algorithms, something that can be learned and furthered through experience.

Now of course it's true that not every job in a larger tech company is like that, so there would be some room to adjust the interview based on the exact role. And there actually is. But overall, if you have a massive amount of people applying every week, why take chances, why not take someone from the pool who can demonstrate the skill and allow for some horizontal movement within the company, into a tech-heavier team?

> And please do share your ideas for what people should do or what finally convinced you that you weren’t bad at this

For me, back then, it was something that was fun for me. Part of why I got into computer science in the first place. I would be totally lying if I said I didn't study for the most relevant of my interviews, beyond what I would have done without them.

But I distinctly remember for example freshing up some graph algorithm skills not by doing leetcode examples (I don't think "leetcode" was already a thing back then), but by arbitrarily taking the Debian package database and do fun self-made exercises like: Let's find the largest strongly connected component in the debian package library, i.e. the largest set of packages where installing one will always install all of the others.

I work at a mid-large tech company ~5k engineers.

> You cannot write things that scale without solid knowledge and intuition in designing and analyzing algorithms, something that can be learned and furthered through experience.

The point is not whether people need to learn algorithms, they of course need to, but that Leetcode questions seem to test people’s ability to solve riddles more than their ability to design algorithms

Bingo – I've seen some of the interview requirements – like 20 mins to solve an LC medium, and you can only hit "Run" once so you have one shot...!?!?

Basically if you weren't already familiar with the question and knew the trick you're screwed.

Plus they're really blatant about it too – the recruiters will _actually tell_ you to practice LC, and to try again in 6mos/a year if you didn't make it this time!

> the recruiters will _actually tell_ you to practice LC,

Here they do this before you even take the interview for the first time

The recruiters actually email me all the leetcode prep material and tips

At some point the metric becomes the goal itself.

Ie. Leetcode style programing is/was used to filter out engineers that couldn't program. And the problems themselves were relatively easy, reverse a tree, build and LRU (which is not trivial at all).

But then there is an army of prep information, and people are just optimizing for Leetcode style programing. Then companies have to raise the bar again, and keep asking even harder questions. ie. build LRU from scratch was considered hard, now it is just a 'medium' level.

It has taken to stupid levels, where it is not anymore a metric of 'is this person a good engineer', but more of a 'how much this person did prep'. i.e. it becomes a measure of effort and desperation, and not just sheer ability.

That's why you see so many stories, of engineers preping for leetcode only, getting in, and not being able to do their job and getting piped....

Also, personally, the best thing that I did to make me a better engineer was creating an app, a backend, and full service, with paying customers. That taught me much much more than spending months on leetcode ever did. Brushing up some CS concepts and Data Structures, and some coding, does help you to become a better engineer. But doing just that, it doesn't make you a truly useful engineer at all.

Exactly! 10 years ago, I was a strong proponent of leetcode style questions instead of using college GPAs to hire engineers.

It’s the ‘Cracking’ idea that has thrown this whole process off. People have started over optimising for the metric

Woodworking is also a learnable skill that's completely unrelated to on-the-job activity.

Why not ask candidates to build a desk? As a take-home project! If you're truly kind, you'll let them keep the desk even if they don't get the job.

The algorithm test is standardized. If you make up your own weird test, candidates won’t play ball. Personally I’ve turned down companies that had a strange interview process that required extra preparation. It’s not worth it when I’m trying to churn through a dozen interviews (without my current employer noticing). The leetcode prep process is unpleasant, but since I have to do it anyway, adding one more company doesn’t take any extra studying.

You make the assumption that Google cares about their false negative rate when ranking candidates, ie not hiring somebody they should have hired. The process is optimized for minimizing the false positive rate, ie hiring somebody they shouldn't have hired.

I don’t care that Google is doing this.

It’s a problem that everybody else is using the same process. (I blame it on CtCi)

I've started ignoring companies that hire using leetcode or whiteboard algorithm questions.

Even if you make it through the interview process, you're going to be working for people who cargo cult their business practices and surrounded by coworkers who are willing to spend vast amounts of energy on stupid things to accomplish their goals.

It's a massively negative indicator for company culture imo.

I can't remember the last time I actually enjoyed using Google's software or their libraries, I don't know why I'd work for a mini-Google.

Copying the whole 5-7 interviews thing with leetcode stuff because FAANMG does it

No that's not true, the vast majority of companies/positions do not do this.

Most companies that pay very well and are competitive do it, and the reason is because we get so many crappy applicants that it remains to this day the least risky, cost effective way to filter out bad developers.

Blaming it on CTCI is like blaming it on needle manufacturers for people shooting up with heroin. The issue is more fundamental. CTCI is just giving a methodology for people to get through the interview process.

The issue is that SV cargo cults extremely hard. A lot of startups copy the big companies (and often the founders of small companies are from big companies - so they take what they know with them). Then everyone is like, "SV is so cool and full of money! Let's copy everything they do to emulate their success."

That's all it is. I'm not a fan of the author (for personal reasons) of CTCI but I don't think she or the existence of the book is the issue.

I’m not seeing everyone else doing it. I wish they were because I prefer those interviews over something that pretends to emulate real work. I want every company I interview with to do leetcode and most of them don’t.

if that's the case, it doesn't explain why Google's software and product quality has been declining steadily.

[Disclaimer: Two-time Googler here, obviously speaking only for myself.]

Sure it does. Collaborative software development is a low-pass filter, not a high-pass one. If you put 100 people on a team and tell them to develop a product, the product quality will track the least controversial ideas, not the best. With more people, the set of uncontroversial ideas gets progressively smaller, and trends toward the features that nobody really cares about because those are the only ones that don't provoke strong emotional reactions. The simple fact that you added more people is what made the product shitty, not that the people were incompetent or poorly-skilled.

I've been in design discussions where we've had a room full of incredibly accomplished people, folks who've written major open-source projects or launched consumer products with billions of users, and the eventual decision was more brain-dead than anything that any one individual in that room could've come up with. And everybody knew it too, but you don't want to piss off highly intelligent and accomplished people, so you make the decision that everyone can kinda live with rather than the one that will wow users.

The lesson here should be "Don't hire unless you absolutely need to", not "Google hires stupid people."

> if that's the case, it doesn't explain why Google's software and product quality has been declining steadily.

Why do you assume that poor products are poor products chiefly because of code?

The discussion here isn't about code. It's about quality of engineers hired. If their software and product quality is steadily declining then that says something about their team. Perhaps they are incredible coders but don't have good business skills or "customer obsession".

> If their software and product quality is steadily declining then that says something about their team.

My understanding is that Google internal politics are completely dominated by their promotion process [1]. I view the outcome of google products not as the result of poor hires, but the inevitable consequence of the organization's incentive structure. If pay (doubling or tripling) is dependent on launching new stuff, your best people will ship new stuff! If pay does not go up for maintaining old stuff, it will not be maintained. If pay does not go up for improving old products, old products will not be fixed. It doesn't matter which people you plug into that system, you will always get the same results.

1. https://news.ycombinator.com/item?id=31262428

User opinion is one of many success metrics that Google tracks but it isn't the most important one. Up until the recent recession their stock performance indicated that their product quality has been doing just fine.

That's not a valid metric. Every effective monopoly has a climbing stock price while it's product quality is declining, this is why they have such a terrible time when there's finally a market upset, they can have decades of bad practices to overcome just to stop their descent.

Come on! Showing 4 more ads per video on YouTube would boost their stock price while making me hate YouTube PMs even more

My advice is to get good at leetcode "the right way". Don't memorize problems. Instead, learn the underlying algorithms.

Learn heapsort, quicksort, how to find medians, how to derandomize and calculate the running time of the quicksort/median algorithms.

Learn how hash tables, red-black trees, and b trees work. Learn why vectors allow O(1) append but only if you amortize the analysis.

Learn depth-first and breadth-first search, learn A*, learn all-pairs-shortest-paths. Learn enough dynamic programming that you could implement a memoize decorator.

All of this is valuable knowledge. It'll pay off to learn this in the long run. Yeah, interviews overrate its importance. It's good to learn it anyway. If you learn that stuff and you are good at the basics of practical programming like string and array manipulation, you'll be able to do well at interviews.

I won't argue that being able to apply different patterns to problems is incredibly useful, but a lot of these are also fairly domain-specific. It really depends on what your typical work is like.

I've worked on teams that dealt with messaging queues and associated backend systems. In those cases it was rare, if ever needed at all, to see or use any kind of graph searching algorithms.

Sometimes some forms of memoization were helpful when it came to system issues that required a meaningful but efficient backfilling strategy. But they were almost never in the same form that typical DP interview problems are.

I would argue many of these patterns can be helpful to test candidates with but only depending on what roles they're interviewing for.

I've seen more "trivial" problems that test for the same kinds of answers that interviewers usually want anyway.

Usually the messaging is something like "we want to test that you can write code. We want to test that you can iterate over and consume/aggregate some data. We want to test that you can evaluate this codes performance." You can do all those things with simpler classes of problems than some of the brain teasers I've seen. And I don't mean the usual stuff like how many tennis balls fit in a school bus, but leetcode style, overly complex problems.

As much as I agree with your advice in general my interviewing experience is completely the opposite. To begin with reading algo books/being aware of the topics you mentioned doesn't necessarily translate to solving leetcode _puzzles_. The last time they simply asked me to implement quicksort was almost ten years ago. What is even worse, usually you have about 30 minutes to solve a puzzle. You won't have time to think even if you are capable of thinking under such circumstances.

Where I completely disagree with the original statement is that leetcoding hurts mostly experienced developers. What else are fresh graduates supposed to know well if not algorithms and data structures? Experienced developers are from generations when few people majored in CS and spent formative years interviewing long before anyone heard about leetcode. And they have too much experience with building real software to tolerate artificial puzzles.

SV companies are heavily loaded up with engineers that passed leetcode style tests. Not everyone though, due to acquisitions - engineers get grandfathered in. Leetcode coders implicitly will bias to hire other leetcode coders. There will be non-SWE departments, Program Managers etc. who might be hired via the MBA-tribe. So in the end, you end up with a mix of skills (or a mix of stereotypes) in a typical SV company. I think if it were strictly just leetcoder types the company would be a disaster (but I have no data or examples - I am interested to hear about if other folks know examples).

This model of operation feels kooky but it does work on various levels (but fails in some also e.g. as panglossian fantasies ). The overall hodgepodge results in SV dominance we see today in many sectors.

Leetcode is self-fulfilling now. It's like a ticket on to the prestige and mega-bucks ride a lot of engineers desire. People pay for the ticket with 3-4 months study. Those that cannot make the time, say due to family circumstances, are actually part of the implicit unfair bias in the system.

I think what works best is when Leetcode is part of the gauntlet but not the whole game. A genuinely good person, in terms of character, together with good programming skills is what I've seen as a company's best asset. An open ended technical focussed discussion on specifically what the engineer has done lifts the lid on that part of things.

At my old company, we never did take home assignments or whiteboard interviews. We just sat candidates down and pair programmed with them for a couple hours on whatever we were working on at the time. We paid them the same hourly rate we were making, (but didn't charge the clients for it).

If the candidate obviously didn't know what they were doing, we ended it early. Usually you knew within 15 minutes.

One candidate hated the interview process, and walked out. One candidate, likely a future business leader, argued vociferously for a higher hourly rate during the interview, and later with the founder.

But I would describe our success rate for finding good programmers who were easy to work with as "extremely high", and our rate for false positives as "I can't remember ever having one in about 4 years of working there".

The overhead for the engineering team to run these was not zero, and not everybody enjoyed doing it. But some people did, so we had them do it more often. I have no idea why this isn't a more common practice, I would recommend it to anybody.

Can you go a bit more in depth about the pairing session? Most companies I've worked at, even if the person coming in was familiar all technologies we were using, I can't imagine them grokking nor just "skipping over" the datamodel and system architecture/design. All non-trivial projects I've worked on had a "bad" codebase as a result of deadlines, pivots and misunderstandings. The code is always steadily improving, but never good enough that someone can just waltz in and get to hacking on it.

Being good at leetcode just requires grinding out those silly problems until you become good at them. That's the sad reality. Unfortunately, there's limited carry-over from years of experience of Actually Building Things(tm) so it can be frustrating. The upside is you're not having to learn language constructs or syntax like all the newbies are.

Let’s not forget the emotional element of these interviews where you’re being asked questions that mean very little about whether you can perform in the role. but many pretend that they are. For me the day long “technical” interview loop is a flashback to gradeshool hell. It tests my anxiety levels at least 5x more than my skillset.

It’s a common thought among my circles that interviewing is the hardest part of being a software engineer - once you’re in somewhere it’s a lot easier.

There needs to be something better.

It's often the hardest part because many people think they can hit the ground running after following a Udemy programming course.

Engineers are expensive to start with and inexperienced/over-confident engineers even more so due to the potential damage on the product.

Tough interview stages like leetcode are a simple method HR can employ to establish a baseline competence.

Personally I have zero interest in grinding for months solving riddles and when interviewing I always check what the stages involved are. On numerous occasions leetcode has been dropped upon request - no harm in asking!

> It’s a common thought among my circles that interviewing is the hardest part of being a software engineer - once you’re in somewhere it’s a lot easier

I’ve heard a similar sentiment from my circles too. But lately

I’ve also met people for whom it’s the exact opposite: they can clear the first round of the interview and they fail in the subsequent design rounds (which in my opinion are a lot less challenging)

I’ve also met people who manage to get hired but are soon overwhelmed with the real work that they have to do and some even get pip’d

I know leetcode hate is a popular theme on this website but frankly I think it’s overblown. You can basically solve any leetcode easy or medium if you understand like ten basic concepts (that you should know anyway) and then spend maybe a week reading solutions for the more trick questions. Leetcode hards require more memorization, but honestly, if we’re going to talk about pointless studying take a look sometime at what med school and law school students have to do.

In perspective, is 3-4 months of studying to get a job really that big of a problem? I spent longer than that studying for the SATs.

I think the hate isn't for the 3-4 months of studying to get your first job, it's the sense that you'll need at least 1-2 months of studying to get every subsequent job (since you won't be touching leetcode-like problems in the course of your actual job). That's not a big deal when you're young, single, and childless, but it's overwhelming if you don't have a lot of free time.

> it's the sense that you'll need at least 1-2 months of studying to get every subsequent job

I think it doesn't have to be this way if you focus on the fundamentals when you prepare, as it's easier to refresh a reasoning that clicked the first time than a complex algorithm you understood only superficially. And these fundamentals are enough for leetcode problems of medium difficulty.

2 months of studying every 2 years for job switch is 8.3% overhead. Do leetcode jobs pay 8.3% more after-tax than non-leetcode jobs?

> (since you won't be touching leetcode-like problems in the course of your actual job)

That is not universally true.

I'd love leetcode-type tests if you only had to do it once. Or even with a smaller every-five-years refresher to retain certification or whatever. And then not worry about it at all during interviews.

You are not expected to get them all. We want to see how you think and that you can think at all. There are a lot of people out there who claim they can write code, but can't even write "hello world" in the language of their choice. I'm not interested in your ability to answer trick questions, and we have a standard library that has optimized implementations of the basic algorithms everyone uses. I need to know you can write at least some code though - in some cases we have let some go with no affect on the teams productivity, you need to be better than those people.

We have so far had one person get all the answers in the allotted time, without any help, and he is working on his second PHD.

That might be true, for you. But I've interviewed many times across the industry -- including most of the big names -- and I'm here to tell you that if you can't perfectly solve a half-dozen leetcode medium questions on a whiteboard while talking and tap-dancing backwards, you aren't going to get an offer. I've been writing code since I was in elementary school. I've shipped multiple products, including some I mostly/entirely wrote myself. If it were as simple as "proving I can code", I'd have no problem getting offers at every single place I interview.

I think you're right that reasonable interviewers behave as you describe. But we're so far down the rabbit hole now that reasonable interviewers are few and far between, and most people are cargo-culting the interview process they themselves have experienced.

>We want to see how you think

Should publish a paper and instantly get yourself a bunch of awards then.

People love to spout that. It's nonsense. Psychologists with way more resources and time in their hand have consistently failed at even the most basic levels of achieving that.

And then some dudes hiring for a company say they can do it in an hour with some silly tasks and a little talk.

The interview process is supposed to measure (or attempt) a whole bunch of aspects. Coding / technical skills, but also communication skills, reasoning, logical assessment, context / intuition, social interaction, decision making under uncertainty, systems thinking, testing, etc. No serious interview process is going to rely exclusively on leetcode questions to fully vet anyone. It requires a balance of many things. Furthermore, good interviewers are aware of these multiple dimensions, and are evaluating candidates on any many levels as possible.

Yes, leetcode questions are a part of the process, and are often an early gate. However, one can perform “badly” but still score sufficiently well on the non-obvious metrics and make it through. Most interviewers don’t actually care if you have the standard libs memorized, and get that. You typically have a lot of leeway to demonstrate your knowledge, and staying open about what you’re thinking and doing goes a long way.

If you have sway in how your company interviews, consider being clear with candidates on all the dimensions they are being eval’d on, maybe let candidates choose take home assignments, ask candidates about projects they have worked on, etc. as part of the process.

People who say they are bad at leetcode sound like the people who say they are bad at math. Sure, right now you might be worse at learning math than someone else, but there are strategies to learning math better

If you are memorizing leetcode you are doing it wrong.

If you are doing more than 60-80 problems, and not applying to the most competitive companies, you are doing it wrong.

There is a strategy to learning how to study leetcode, and yes, studying leetcode is hard. But you need to make sure you are not blindly memorizing solutions or else you're doing it wrong and wasting time.

Let's say you are doing an array problem and there is some trick that is necessary for the problem that you didn't know. When you get the problem wrong, learn what the trick is, but don't "memorize" it. Learn it and learn how it works. Then think deeply on what other problems might use this trick. Does it involve a loop that goes until `i <= someVar.length` ? What happens if you change the code to < instead of <= ? What happens if some other edge case happens?

I've seen this happen with binary search. Someone learns the algorithm by finding the algorithm online in their language of choice, but doesn't spent time fiddling with the code or thinking about edge cases.

My feeling is that people who understand maintainability or other architectural concerns are worth more than people who master algorithmic underpinnings.

I thought the point of this discussion was how to change the industry emphasis rather than how to get good at it.

How do you understand maintainability and architectural concerns without understanding algorithmic underpinnings?

At the base level, leetcode problems and maintaining a complex system in practice requires key understandings: what your problem is, which tool to use, and how your tool works/tradeoffs. It follows what (I hope is) a universal truth: if you want to be a good coder, you need to know code.

If you want to change the emphasis, just don't work at companies that provide leetcode questions. If your hypothesis is true, then all the companies that don't do leetcode questions should have an advantage since their engineers are better at the practical aspects.

How can you test someone who can write a well maintained code?

Architectural Concerns are tested during System Design round.

Candidates who care about readable solutions, provide comments, add unit tests, think about integration testing, data validation, bootstrapping/deployment etc are the ones who are at least thinking about maintenance.

Incomprehensible one-liner whizz-bang solutions in perl are great and all, but no one wants to work with someone writing code like that.

Leetcode-style interviews disenfranchise different groups (parents, non collegiate education) from succeeding in the interview process. Like you mentioned, these assemssments are not an accurate proxy for development. I've detailed the various flaws of the Leetcode approach, compared Leetcode with common alternatives, and propose an alternate style of interview that is more accurate and fair here:

https://www.naveed.dev/posts/senior-engineer-interviews-brok...

https://www.naveed.dev/posts/leetcode-alternatives-compared

https://www.naveed.dev/posts/alternative-senior-engineer-int...

The flip side is that a DS&A toy problem grind is an actionable item that approximately anyone who can already bear the cost of their own training can work on, with legible indicators of their progress.

I know it's popular to throw shade on interviewing for "wasting" candidates' time on this instead of "learning to build actual things", but even if DS&A toy problems aren't the best-correlated with actual work performance, the fact is that (a) they're well-enough correlated, by the standards of scalable interview assessments (b) contrary to popular belief around these parts, presenting "actual things" is much easier to bullshit your way through than a few hours of talking through toy problems (c) every job opening gets a deluge of bullshitters.

Work at older, non-tech companies that have tech departments. Almost every single one of my jobs has matched this pattern, and none of them included a coding exercise as part of the interview process.

Silicon Valley and its satellites seem to disproportionately favor code interviews compared to the rest of the US market, for some ungodly reason.

> Silicon Valley and its satellites seem to disproportionately favor code interviews compared to the rest of the US market, for some ungodly reason.

I work at a well known SV tech company with about 3k ppl and we got over 50,000 job applications last year. Code interviews suck, but they're a scalable way to assess skill with minimal bias.

There could be an argument made that most code interviews have a bias twords younger less experienced developers. They are the ones that take the time and study these questions. Years of experience probably won't help since the questions don't represent day to day problems most developers are solving.

I interview at FAANG and we do take this into account by holding pretty much anyone over ~2 years of experience to the same standard with respect to leetcode questions.

A fresh grad is expect to be able to solve ~medium problems.

Someone with ~2 years of experience is expected to be able to solve ~hard problems.

Someone with 10 or 20 years of experience is still only expected to be able to solve ~hard problems.

The standards for a more experienced candidate are of course higher for other attributes: Leadership skills, communication skills, etc.

> Silicon Valley and its satellites seem to disproportionately favor code interviews compared to the rest of the US market, for some ungodly reason.

It's all the money that they're making compared to everyone else. Even in a crash like we're seeing now, they have extremely high revenue per employee.

The other US markets don't "get it" yet imho.

Tech companies favor deeper tech skills greater than non-tech companies do, is what I'm reading, and it does not sound too surprising.

You are also less likely to deal with the "leetcode" subject matter (e.g. design and analysis of algorithms) at a non-tech company, so if you don't want to deal with that, applying at a non-tech company is a good idea. Does not mean that a job at a tech company won't be like that, though. They have CRUD SaaS apps, too...

You can't have your cake and eat it, too. If you want to get paid as a developer who has to design algorithms as part of their job, you should know how to design algorithms.

Doesn't mean that pay grade is fully correlated with skill, of course. There are other industries that pay more and don't require anything like that.

> You can't have your cake and eat it, too.

But the thing is... you can

Most of us are not designing algorithms, most of the time, or any of the time

Many engineers are just filling seats in places that are just in the business of sucking up talent from the market instead of having a bunch of entreprenuers running around

Rest and vest

Sometimes. Particularly in the financial industry.

However, something to note is that while money is important, it's not the most important thing in life. Or it shouldn't be, anyway.

How do you feel about assessments in other professions? For example, the bar exam for lawyers? X Engineering Certification for the specific fields? Even networking and security folks take certification and exams as a means of attesting proficiency. Are these things accurate? Is there a better system? No idea. Software engineering's processes are more adhoc, but can be categorized similarly. We're looking to answer the same question: Is this person competent? Resumes / CVs often aren't sufficient for the examples above.

We do the dance when we swap jobs, other professions do the dance as their licenses / certifications expire periodically. I'm sure there's an engineer somewhere that struggles with anxiety when attempting their Engineer in Training [1] certification too.

In short, buck up.

1 - https://en.wikipedia.org/wiki/Engineer_in_Training

Upvoted because I think you bring up an important question. In many ways, leetcode style whiteboard exams are the BarrierToEntry(TM) for our field.

My problem with this analogy is that our field has no examinee "bill of rights" that slowly evolved over time (often hundreds of years or more) in some of these other fields. We (software developers) have no idea who will be conducting our exam, how they will be grading it, or whether it will be done consistently. We don't know if the graders are competent. There is no clear and defined study path, nor do we get any feedback. The exams appear very suddenly, when we get an offer for an interview, we have very little control over how and when the exam will take place. And lastly, we take them again and again and again, every time we interview.

I've read that people suggest several hundred hours of prep on leetcode to get ready. When I interviewed at Google, my lunch interviewer (no coding, just a conversation) told me that when he got an offer for an interview, he asked for and received well over 6 months to prep, and he studied intensely the entire time. Now, for the bar, I'd understand this, because passing the bar doesn't require getting hired by a particular firm. But if he'd missed google? Well... I suppose there are other companies, and the prep would have you ready. But also - these interviews can take all day, and there may be multiple rounds. Hundreds of hours of study and several all day exams? That actually sounds like something approaching the bar - but for just one company that can capriciously throw you out, with secretive processes and no accountability at all.

Law firms don't run the bar exam. They respect the results, and I suppose some might volunteer or work as professionals, but Dewey Cheatum and Howe does't run the bar. Also, large law firms don't claim that there is a critical shortage of lawyers to hire, all while running a makeshift, privately administered bar exam that they acknowledge results in an extraordinary high false negative rate.

I'm not sure if there is a great alternative to leetcode interviews, and I actually do respect the right of high tech companies to hire as they please. But I sure have no sympathy for companies that rely on these interviews and then wail about a shortage of people to hire.

> We do the dance when we swap jobs, other professions do the dance as their licenses / certifications expire periodically.

The huge advantage to the latter is that it decouples the license exam from changing jobs. This helps for two reasons:

First, it means that the friction of the recertification doesn't coincide with the friction of switching jobs. It's a lot harder to leave a bad job when you know you'll need to review for the "recertification" for a month before you can start interviewing.

Second, in these other fields your employer has a vested interest in keeping you certified, because you can't keep working if you aren't. This should mean that they're incentivized to help with the process, rather than it being something you have to take full responsibility for and do on your free time. In software, not only do your employer and coworkers not help you study for "recertification", you have to actively keep it a secret that you're grinding leetcode lest you tip them off that you're looking to switch jobs.

I'm not disputing that what we do as an industry can't be improved. I'm primarily against the idea that our profession is unique, and people should take us at face value when we claim expertise. Validation by employers is looked at as an undue burden. We have perks in this industry: For the most part no one cares about your education background and often not even your experience as long as you pass the interview. It's hard to have both those perks, and expect some of these hoops to disappear.

Should the hoops be a take home assignment? White boarding? Pair programming? A new governing body that offers a license? Not sure, but something will exist, and your anxiety and need to prepare likely won't disappear.

In theory, I'd be cool with taking some sort of standardized engineering test every N years. In practice, software engineering is pop culture and I'm not sure what those tests should contain or who I'd trust with creating those tests

When you say leetcode, are you talking about leetcode questions, or just algorithm/CS questions?

I've been asked a wide range of interview questions from "what's a cache" (I answered "would you like to me to cut to the chase and implement lru cache in python?"), how many steps does it take ants on a stick to fall off (https://physics.montana.edu/avorontsov/teaching/problemofthe... the interviewer said "it's easy if you just think of them as virtual ants that can pass through each other"), "what's the average waiting time for a bus that comes every ten minutes" (interviewer could not answer some of my starting questions like, "what is the arrival distribution- every ten minutes, or is that just sort of an average, is it poissonian, are the buses interacting with each other, etc", "implement quicksort" (got this wrong the first time I interviewed at Google).

When I interviewed at a company recently a junior employee administered a question straight out of leetcode, with the data inputs and outputs completely unchanged. I exited the interview and contacted the CEO directly to say that if that's how they interview senior staff, it's not the company for me (I wouldn't have complained if they'd changed the inputs/outputs or slightly modified the problem, or came up with their own interesting variant).

Because we need some signal that a candidate can program and do something a little more complicated than fizzbuzz.

The homebrew creator shouldn't have been hired at Google if that was his attitude. Also, homebrew sucks and many googlers try to avoid it if possible.

My suggestion is to start with the easiest leetcode questions and memorize the answers and type out the code and run it with various inputs.

I am talking about the kind of questions you would get if you went to hackerrank right now and took an SDE interview with any random company.

> homebrew sucks and many googlers try to avoid it if possible

Huh? What do they use then? I wonder what makes a Google engineer with a MacBook different from any other engineer with a MacBook that only Googlers in particular are avoiding brew

I am not sure why people bring up the homebrew author's case to justify the argument that "leetcode question = bad intervew question". I mean, I hate many of those leetcode puzzles, but "inverting a binary tree" is not one of them. IMO, this particular question is a good one. It is a simple manipulation on a simple data structure. I think at least a good programmer can probably discuss with the interviewer, take some hints, and write _something_? Instead, that tweet gives me a feeling that he didn't like the question and refused to think at all. Everyone knows that Google asks tricky algorithm questions, did he expect to get some special treatment because he created homebrew?

Homebrew is popular, and is indeed a very successful project, it is just not very well designed. Let me quote the author's own words:

> https://www.quora.com/Whats-the-logic-behind-Google-rejectin...

> I wrote a simple package manager. Anyone could write one. And in fact mine is pretty bad. It doesn't do dependency management properly. It doesn’t handle edge case behavior well. It isn’t well tested. It’s shit frankly.

> Is it any surprise I couldn’t answer their heavily computer-science questions well?

> On the other hand, my software was insanely successful. Why is that? Well the answer is not in the realm of computer science. I have always had a user-experience focus to my software. Homebrew cares about the user.

I've done SDE interviews with random companies (and administered them), although normally they are called SWE in the bay area.

Many of the questions in leetcode have a skill rating. The easy ones- I expect most programmers to be able to figure out in 30 minutes and type out an answer. The hard ones- those are for people (as you say) doing programming competitions, or who are doing CS research and have a lot of prior knowledge and skill, or for extreme coders operating at the 10X level.

I think many people have moved to macports. In my experience, the Googlers mostly do dev in the cloud and don't depend on having custom software installed on their machines. Also I think the other big problem was that half of homebrew is broken any time you try to install something complicated.

Assuming that you have found a real phenomenon where people who are ranked poorly on this proxy (but presumably high in some other metric) are undervalued, then you should start a company that identifies these people and

first-order: employs them to build something at a lower cost than the market would expect

second-order: convince non-FAANGy companies that you can identify employees who are lower-cost and higher-value, thus starting an evaluation and matching business

third-order: write a business book about evaluating people better than leetcode-like methods

I couldn't care less about leetcode, I literally have done less than 10 leetcode exercises in my life. I have been getting hefty pay bumps every 1-2 years since I graduated, and there are no signs that curve is flattening. FOSS / side projects and soft skills seem to be pretty underrated by most developers.

I'm at a FAANG right now. Havent interviewed in years, lead projects on one of the most critical services at my company. Just interviewed at a startup, they asked a design question, and immediately nixed me for not having the correct "design process". Meaning requirements gathering, scoping, etc. 20 minutes in the interviewing engineer basically checked out.

My resume is very good. Its a little scary, because this experience is actually common. No one trusts anything, and nothing you have done is worth anything, unless you are well known. You need to study whatever textbook answer they are looking for.

Sounds like they care more about process. Process-centric companies tend to not do well in the long run.

even if you're well-known you can be rejected

the author of brew (popular macOS package manager) got rejected by Google

I think learning to excel at algorithm interviews will make you a better engineer. It's not memorizing questions, it's learning to solve a variety of interesting problems you seldom get in your day today. You may think, if "I don't get those problems day to day, why learn to solve them?". This is similar to an airline pilot saying "Engines work well on my flights; why should I learn how to handle engine failures?"

2-3 months of devoted effort on algorithm interviews has given me some of the best ROI / time for engineering growth I've had in my career.

It's more akin to expecting the pilot to know how to replace a wiring harness in the avionics bay; someone else handles it and they'll never need it in practice.

Just practice it. It is a skill in itself just like anything else. It is true that it doesn't actually measure your real skills, but just like an IQ test can be corollary with lots of other mental faculties, leetcode skill can be corollary to programming skills.

I highly doubt that we are talking 3-4 months of memorising riddles. There are a few recurring concepts that you should memorize, sure. But after that, if you have the programming and logical thinking skills you claim to have, you should be able to think on the spot for the rest of the leetcode question.

Firstly, don't get discouraged just because the questions are hard. A lot of these concepts were cracked by dudes like Von Neumann who spent years trying to figure out stuff like graph theory and backtracking. Calculus seems hard at first but after a while derivatives seem trivial-- even though it took thousands of years of the greatest minds in math to arrive at the understanding of the Fundamental Theorem of Calculus. We all stand on the shoulders of giants.

Second, it sucks but the only way to get better is to practice. I recommend Python since it's the most efficient least verbose option for Leetcode. There are also a lot of shortcuts for learning as efficiently as possible:

Learn and internalize the 14 patterns: https://hackernoon.com/14-patterns-to-ace-any-coding-intervi...

Then practice with either the Blind 75, Neetcode 150, or the Sean Prashad leetcode list: https://seanprashad.com/leetcode-patterns/ There is a lot of overlap between these lists, and most of the problems are slightly more complex versions of a previous problem.

You also need to be able to talk about your solution and explain why something is O(n). Talk out loud to yourself while you are coding, you'll feel like an idiot but it really is helpful.

I know that it sucks but unfortunately this is the price to pay for the insanely high salaries for fresh grads in tech atm. On the plus side I think that Leetcode made me a better programmer in the sense that I became more intimate with the language I chose (Python) and am able to write code more quickly since I unconsciously internalized the syntax.

Lastly when facing rejections, don't take things personally. Luck is a huge factor and if a tech company doesn't want to hire you it has nothing to do with your value as a human. I applied to hundreds of companies and went through about 10 on-sites just to receive one FAANG offer. Keep in mind that on forums like Blind or Reddit, or personal blogs, you are mostly going to be reading stories with high survivorship bias and embellishment. Everyone wants to brag about their six-figure offer from Google, fewer people are going to write about the excruciating toll that hiring practices took on their mental health.

Not every company does this. If you want to earn the extreme levels of pay among the darlings of tech you might have to. But I have plenty of friends who relatively recently got jobs at more traditional companies (such as GM) making respectable total compensation (around 150k) that didn't have to go through this crap as a regular, not junior but not senior software engineer.

As an engineer who learned programming prior to the proliferation of coding tests, my struggle has been with my own ego. "How dare they use some simple test to judge me and ignore my body of work." This has gotten me a few times. Especially when I wasn't expecting a coding test. Adjusting my attitude and getting more okay with the idea that some companies will want to screen with this sort of thing, has helped. I also felt more empowered by recognizing that I can always decline an unreasonabpe test and that doesn't always mean I will be excluded from consideration. Like most things in life, it's easier if you practice. Focus on good communication skills, and sell yourself the best way you can.

Don't know if I am a good enough programmer, but I am clearly bad at leetcode too. After so many years programming, that is, solving puzzles at work, I really hate doing it in my spare time, so leetcode makes me instantly mad.

I even avoid board games for the same reason. OTOH, I enjoy cooking, construction work... manual labor, that is.

Everyone is bad at everything they haven't tried to do. You can be good at anything. I can't ride a bicycle but if I wanted, I could be good. Just gotta go and do it. Unfortunately doing things is work. Solving abstract problems is the main thing engineers do, if you're not doing that then you're not really engineering you're just copy pasting text.

I think that as an industry, we are about to move past this. Companies slowly realize that these leetcode tests do not assess the skills they need. We currently lean towards simple coding tasks paired with extensive collaboration slash pair programming on close-to-real world scenarios to assess the skills we‘d like to see in a candidate.

I like the idea of this list but in practice there seems to be a lot of 'hiring without witheboards *if you happen to interview with the same team that I did and if the hiring manager for that team hasn't moved on since I interviewed there 4 years ago.'

The problem isn't leetcode so much as how it's interpreted.

Goodhart's Law: “When a measure becomes a target, it ceases to be a good measure.”

Leetcode questions are a useful measurement in the interview process

What they are not is a useful goal to hire someone by.

I do a lot of interviewing and have never liked the Leetcode-style interviews favored by some of the big companies. I feel like they favor a certain type of person who can memorize a bunch of solutions where they should be looking at general problem solving and flexibility.

That said, some coding in an interview is pretty much a requirement for any sort of programmer job. If you ever start interviewing candidates yourself you will see why - a non-zero percentage of applicants are very poor programmers, even those that claim years of experience.

what if you have code that is available publicly?

doesn't that prove you have experience?

Practically speaking? Get better at leetcode. It's a skill, you can train, you can improve.

Lots of options for improving, but I suggest if you're feeling stuck to pay for a coach.

Also, stop focusing on FAANG type companies. There are tens, if not hundreds, of thousands of jobs, and if you're a new grad you're as mobile as you'll ever be. There are too many jobs to care about specific hiring trends; there'll be a job for you out there somewhere.

Many—maybe the majority of—software development jobs aren't gated behind these kinds of problems. Or, if there are any, it's one or two from way on the easy end of the scale.

But most of them merely pay very well, instead of ZOMGWTF well, and you'll be writing software in probably Java or C# to help out boring but profitable companies, rather than doing flashy startup change-the-world (LOL) stuff while burning VC dollars, or being in the advertising business.

Google dropped the college degree requirement but retained the leetcode interviews, so it must be working somewhat well for them. They have access to more data on this than any of us.

It's important to emphasize the last part of your sentence: it must be working somewhat well for them. That doesn't mean everyone else should be asking these questions, because your ideal hires might be quite different from Google's.

no, google's interview style didn't work for them. now they have the problem of having tons of junior leetcoders and need to hire a ton of technically savvy managers to ensure their efforts aren't wasted.

I do find that dynamic programming can sometimes be tricky, especially when I am being watched by a stranger and I don't feel relaxed. One thing I've learned is to insist in an interview that I may need a couple of minutes after shown a question to quietly think and jot down private notes without explaining out loud what I am thinking about. Once I have figured out how to design the solution I can explain my line of thinking and then narrate what I am doing as I am writing out the code.

If they think this isn't OK even with me understanding this need and communicating about it upfront, then it's probably not a good fit anyways.

> The no-whiteboard companies are very few

I would disagree. My guess is you are only going after top tier companies. It is okay to have a job with a company that is not a household name.

I’ve seen the no-whiteboard list. Almost none of them hire “outside their time zone”

The no-whiteboard list represents at best, a small sample of the total list of companies that don't require whiteboard interviews. Hanselman talked about dark matter developers, the unseen 99%. The same principle applies to companies. In other words, there are tons of jobs out there flying under the radar.

How do I find them? Or how do these companies find me?

I kid you not, I’ve received messages from 200+ companies over the past 3 months and all of them have the leetcode round as their first round.

Just keep in mind that the interview is two-way.

They're judging you on your 1337-coding skillz.

It's ok to judge them on their poor judgement. And seek employment elsewhere.

You can even be more helpful than most employers are to job candidates. Tell them that's why you're not interested. Maybe they'll learn from it. Maybe.

there are a lot of things in the world that seem unfair or unreasonable. often it's because they are. complaining about it can be satisfying in the moment, and if enough people complain, it might eventually change. but reflecting on how unfair or unreasonable something is does not help an individual achieve their goals.

as a fresh college grad, you have to decide whether you want to work at a company that does leetcode interviews. if yes, you have to practice them until you can pass the interview. if no, there are plenty of companies that don't do this style of interview. they just don't get discussed on hacker news as often. unless you are an incredibly well known engineer, there is no third way.

Get good at leetcode because it's not that hard and the best way to make tons of money as a young person.

The question answers itself, doesn't it?

If you care primarily about your salary, become good at leetcode.

If you don't, join a startup.

My salary is very good. I've never joined a company that does leetcode interviews. Only two of the companies I've worked for have been startups.

Very good compared to Google and Facebook, or is that a subjective statement?

But to be honest, your answer is not likely to change my opinion. For the vast majority of new grads leetcode is the obvious recommendation to maximize income. People grind for 3-4 months because it actually works, that's the reality.

Very good in that it puts me in the top 10% in terms of earning potential on the planet.

You have a different target employer than I do, and that's fine. I optimize for a different set of requirements.

Sounds a lot like you actually are one of the many individuals who do not optimize for salary.

Maybe OP is, too. If he isn't, I think my suggestion is appropriate.

I wonder if that itself is certain type of filter. For people who are ready to spend lot of unpaid hours for job. Might this also expand to their work?

I've worked for exactly one startup on a devops team of three. The coders next door to us were mostly fresh out of university and most of them thought they were the cat's pajamas. They worked for a fairly crusty former military cyber dude who had likely forgotten more about programming then they would ever know. Military dude told us that code checks were an eye-opener for these guys. There's boot camps, university, and then the real world. The real world is often not what these kids think it is. Same kids were shocked when I told them the company ran the back end on Bash and Python. They were incredulous we weren't using Golang, Haskell, or some other flavor-of-the-month language. I told them to go ask what runs their bank. None of them had the faintest idea it was COBOL. The one COBOL programmer I know is in his 60s, already retired and comes out as needed for the princely sum of $200/hour every couple of months for contract work. Beer money as he calls it. Guy retired a millionaire from COBOL but you'd never know it looking at his modest house and hatchback car.

Yeah, I think that's actually part of the intent of the whiteboarding in the first place. How type-A and career-obsessed are you? Enough to spend months learning tangentially relevant material to pass an interview?

Many startups cargo-cult these poor hiring practices.

The good news is that that's a predictor for a shitty startup (or at least a predictor for a startup that isn't focused on building things)

I wrote my own dynamic garbage collected programming language from scratch just to solve leetcode to prep myself for interviews.

I still don’t feel ready.

If you’re curious: https://www.github.com/glouw/rr

Why did you think writing a programming language was necessary to Leetcode?

I applaud the effort, I'm just curious why you say you wrote it "just to solve leetcode", when I'd imagine the skills for creating a programming language have limited overlap with Leetcoding.

Likely because one would “applaud the effort”. If I can’t prove to the interviewer that I’m capable of going beyond leetcode, by building my own language to solve the same problem, then I might as well memorize a thousand solutions to cheat my way into FAANG. The latter will guarantee entrance, but I can’t stand the memorization process. I’m a professional, and like an undergrad or grad, I shouldn’t have to memorize homework problems to pass exams

i have about 1000 stars collectively on my public GitHub repos and recruiters still ask me to do "coding interviews"

i take this as an insult and reject instantly

no matter how much money and stock you offer, i'm not gonna bend my back over to prove anything to you (that's what resume and GitHub are for, fool)

luckily, i have saved enough money to not care about this shit

Not a programmer, but a sysadmin/devops. Once had an interview at about my 15-year mark as a Linux/Unix admin working for some household names. Punk kid interviewer asks me if I know how to add a user to a Linux server via command line and, if so, please take the marker and write the command on the whiteboard. Same kid asked me why I would choose Bash over the far superior zsh and other nonsense. Kid didn't, likely still doesn't, understand that methods don't often matter, results do. Needless to say, I didn't want the job working with people like him. I found a better job working for a government contractor doing more interesting stuff working for people who just wanted results, methods not even a consideration.

Join a startup and move into engineering management asap.

If you can hit director level, they stop asking leetcode questions. But if the goal is to eventually get into a Big Tech company, they may down level a startup director to be a line manager (which may still require leetcode).

Depends entirely on the startup I guess? And, I mean, I could found a company right now and call myself "CEO" and my friend from school who's a brilliant actor with no computer skills "director of IT", that does not say much.

Experience depends on how many humans are under you. If you're a CEO with 0 full time directs, you would have a difficult time moving into an EM role.

That’s my point, except stronger, because number of people under you is not sufficient. If you’ve never written a line of assembly, you will have problems managing a compiler backend team for example.

Please let me know what startup that is so I avoid it at all costs.

All these people I have in mind are fresh out of college, self taught probably and aren’t old enough to be EM

This would be a 5-8 year plan. Communicating with your manager early that this is a career goal will help set them up for success in that path.

I’d say just keep on keeping on. I personally have and will never work at a place that does leetcode challenges during the hiring process. I wouldn’t worry about it. It’s a self-filtering process for places you don’t want to work anyway.

You just have to practice. I used to be quite bad at it, but I've improved greatly.

Here's what I recommend: start with a specific topic -- maybe HashMaps, Graph Problems, Dynamic Programming, Greedy Algorithms, whatever. Start with the easiest problem on Leetcode for that category and work your way up to a "Hard" problem in the same category. It helps build a mental "muscle" for that type of problem, and it will be easier to activate that "muscle memory" whenever you have to brush up on Leetcode again for your next round of interviews in the future.

I'm a senior sysadmin/devops guy. I'm not a programmer per se, but I can and do write a fair amount of code, usually Bash, Python, some PowerShell. I had an interview not terribly long ago whereby the interviewer was asking me as a sysadmin if I could write and compile programs in C++, Python, and a few other languages. I told him that my role historically didn't include these things. I told him I write code to primarily automate things. He asked if I could write programs from scratch--systems stuff and turn out MSIs. I told him no. End of interview. I've never stated I'm a programmer, it doesn't appear on my resume as anything other than scripting for automation or writing small tools to do something weird or odd that the built-in tools cannot do. Anymore, it seems that companies want people to be able to do everything. Same guy asked me about how good I was at setting up a router and switches from scratch. Networking is voodoo. It always has been. Sysadmins typically are not networking guys. Networks need to be run by dedicated network admins. It's a full time job in and of itself. I miss the late 90s and early 2000s when things were more clear cut in terms of roles. Editing to say that so many people in "leadership" positions don't understand the nature of scripting. They conflate it with systems programming. The two are vastly different. I was taught in college to keep scripts as small as possible. This has been echoed by mentors over the years. One mentor who was a veritable scripting rock star who now works at Google told me that if it's over a couple of hundred lines, it needs to be in a systems language, even things like Python. Compiled programs, of course, always run faster. But that's not my world. I live and breathe making servers run, tuning, etc.

> What would be your advice be to fresh college graduates, or anybody for that matter, who are good at programming but not at leetcode?

Were all of your college classes relevant to your career ?

Get better at leetcode - it’s a learned skill, if you can pass college CS you can pass leetcode

Isn’t it ironic that you’re ok with getting a job after graduating from a multiple-year college program but not after a “3-4 month grind on leetcode questions”? If the industry prefers experience and the ability to solve algorithmic riddles, would it not make more sense if college gave you this?

> Ever since 'Cracking the coding interview' was released, every company's interview process has become like Google's and Google didn't have a particularly great interview process to start with.

> The no-whiteboard companies are very few, hardly ever seem to have openings and not hiring junior engineers.

Both those statements are false.

There are plenty of places, both small and large, that don't do leetcode interviews. There are places that don't do whiteboard interviews at all; there are far more that do have you go to a whiteboard but don't have you do leetcode there (my own company is such a place).

Personally, I don't grind leetcode at all. I know what I know. If a company wants that, fine; if they don't, I'll work somewhere else. But I am far from junior. For a junior programmer, it may be harder to get the first job, and leetcode may open some doors. But the absence of leetcode doesn't close all doors - far from it.

What we care about is, can you code at all. We give a problem that is a step above FizzBuzz, but not all that far above it. Can you write code that does something like that? Can you think through the problem? It's not a "you have to find the trick" problem at all. We don't care about whether people can find tricks. But can you code at all?

We aren't alone.

This is probably going to be an extremely unpopular opinion, but it's based off my experiences.

SV-tech culture was attractive in the mid-late 90s when new things were actually being built and innovated, but today it seems many are just rent seeking near-monopolists that exist to sell ads. Working for a near-monopolistic advertiser with stupid hiring practices just isn't something I would want to do, or dedicate my life's work to.

If you want to use your talents in a way to make humanity better in some small way, advertising isn't it. I would recommend going into another industry and company that values tech skills, but doesn't cargo cult like SV type companies do. Almost all the code you write will probably matter and be used by people. In my 20+ years of development, I've had a total of one project shelved, and that was due to an M&A.

You have a pretty good chance of creating new products as well rather than just doing maintenance tasks (although you will do plenty of that too). Most SV type companies seem overcrowded and mostly out of ideas, at least significant ones. There are of course exceptions, but like I said, I see a lot of rent-seeking from the big boys.

If you're just into it for the money, SV type companies are probably your best bet, at least for a couple of years until you're financially set. Also, it helps to have at least one big name on your resume. You can earn plenty of money in other industries too.

> What would be your advice be to fresh college graduates, or anybody for that matter, who are good at programming but not at leetcode? Surely there must be a way to demonstrate their understanding of algorithms without having to spend 3-4 months memorising riddles

If leetcode is necessary for interviews in your city, train leetcode. DO NOT MEMORIZE. But, do simple exercises and work your way up to harder ones. It is learnable, but memorizing is just about the worst way of learning it. You don't have to burn yourself out either, go by pace easy for you.

Not being good at leetcode is not some kind of helpless unfixable state.

If you can leetcode, there's decent chance you can program other things well. If you can't leetcode, there's decent chance you can't program other things as well.

It's just a simple filter with the usual caveats of false positives and false negatives.