Ask HN: What to do about ‘Good at programming Bad at Leetcode’ | Hacker News Reader

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

291 pointsmikymoothrowa478 comments

Over the past few years I've met people who are really good programmers when it comes to putting together a full back end system , creating a very nice front end or creating any kind of app for that matter.

Many of these people are fresh out of college and the ‘industry’ puts them through leetcode/hackerrank style rounds that are needlessly hard. I’ve seen the kind of questions these rounds have and quite frankly, if I graduated this year, there’s no way I’m going to get a job.

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.[0][1]

Now, there are several GitHub repositories that prescribe 3-4 month grinds on leetcode questions to "crack" the interview. And people do go through this grind.

The people who do manage to crack these rounds are not necessarily good at programming either because the time they spent doing competitive programming stuff should have been spent learning to build actual things.

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

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

[0] homebrew creator.. https://mobile.twitter.com/mxcl/status/608682016205344768?lang=en [1] Zed Shaw gets offered a sys admin job https://news.ycombinator.com/item?id=93984

View on HN

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.

I can't answer for the parent, but I've done similar style interviews. Because the candidate is not familiar with your codebase, you must be the expert. Your job is to let them drive as much as possible, while you "unstick" them when they trip over what they can't possibly know. It is a collaboration, which is part of what makes this a good interview style IMO. Sometimes a candidate will offer an otherwise good solution, but it won't work well within your codebase -- in this case you explain why, and then you iterate.

Yeah, usually we would give a little bit of context, and then look at the sprint tickets in Jira, and take one. The candidate was not expected to be familiar with the codebase or product at all beforehand, and they weren't expected to become an expert on it during the course of the interview. But coming up to speed quickly is one of the skills we liked to see, since that was part of the job.

They should be able to 'hang', in the sense of being familiar with how we approach problem solving as programmers. They should ask questions when needed, and answer questions as they arose. The goal was to just figure out what level they were at in general, and what it would be like to work with them. They weren't expected to come up with the best possible solution, because usually there wasn't a single right solution.

We would ask them questions like "well, you saw the ticket, how do you think we should approach this?" or even just natural things like "this function we just wrote isn't working, what's going on here?". The point is that they are working on real problems — literally real problems — and not abstract CS exercises.

Since we mostly did pair programming every day, the other thing you'd get a sense of is how easy someone is to work with. Not everybody had experience pairing, which is to be expected. You found out quickly who took to it, and who wanted to be a lone wolf. We didn't not hire someone because they weren't good at pairing, but we factored it in. Some people just did not communicate very well, which is a problem.

(This also gave them a good sense of what it would be like to work with us, and sometimes people decided not to take an offer because they didn't like the way we worked: good outcome for everybody)

They would usually do two rounds of this, both on the same day. Morning session, then an afternoon session. We offered to take them to lunch in between, which exposed them to more of the team, and let us talk to them in a more casual setting. Part of the interview would also be a private talk with one of the founders, and an HR person (in a different session).

The people the candidate paired with would provide input like: "I would recommend hiring this person" or not, but didn't make the decision themselves.

Here, I should admit that we did have a set of artificial problems we'd give candidates if we were hiring for a skillset that did not have a real project to test them on. We did both web and mobile contracts at this (consulting) company, so if we were hiring, e.g., an Android dev but didn't have an Android project for them to work on, we'd have them check out a repository and work on a fake ticket instead. Usually this was with a developer beside them, but I can remember times when the candidate had to do it solo.

This is great. If I had my own company I would do basically the same:

1. have a look at the candidate's github / stack overflow profile. If you like what you see, invite him/her for an interview; 2. have a couple of pair programming sessions as you described, with different team members (and don't let team members influence each other during the hiring decision); 3. invite the candidate for lunch and see how he/she treats others (basically an asshole test)

> 1. have a look at the candidate's github / stack overflow profile

Not everyone has a github or stackoverflow account!

This is great for small companies, but large companies are interested in standardizing the interview process. Leetcode is great for that since the outcome is pretty binary.

Agreed, but I see the impulse to standardize as the source of a lot of the problems people have — by people, I mean both good engineers, and the companies who can't hire them.

Honest question, how would you handle hiring at FAANG scale without standard processes?

For reference we had an opening in my team and 1600 people applied.

This process still relied on screening, including technical screens. The biggest difference is that it substituted a day of whiteboard interviews with a day of pairing, which we found to produce better results, and candidates really liked too.

Having 1600 applicants for a SE role is not a unique, but definitely a very niche, problem to have...

Apple used to have a per team interview process(don’t know if it has changed). While the interview experience can vary a lot, there are certain pockets/teams that are spectacularly brilliant and have the freedom to maintain the bar & conduct targeted hiring.

go on linkedin and message the people you think can do the job based on prior work and experience or degrees. trash the rest.

Sure, great for metrics, terrible for actually doing the job.

Leetcode can never compete with or allow a candidate to demonstrate real multi-dimensional or multi-systems thinking. You may be able to write some bass ackwards arcane algorithm and prove you’re “31337” but can you make that work at scale with a data store that you have no information about? How’s it going to get the data to operate on in the first place? Will your data retrieval query cripple a prod database? Read from replica? How far behind can that data be without making your fancy algorithm useless? How will you parallelize that work set? In-request or background job? Multi-threaded or single thread? What about changing state in multi threaded contexts? Database indexes? Schema design? How will you handle failures in your algorithm? How will you handle malformed data? And most importantly, does what you’re doing benefit the user, or just your epeen?

Leetcode is bullshit. It’ll never let somebody show you they’re good at anything other than solving bullshit problems. And you’ll lose everybody who CAN work within the larger context by chasing candidates who’s chief skill is solving bullshit problems.

Leetcode is a proxy IQ test. Anyone who can do leetcode can learn how database indexes work (hint: it uses Data Structures and Algorithms) but not the other way around.

I mean yes, it does filter for those that are willing to put up with some bullshit to get a job. But you haven't convinced me that the group that's unwilling to put up with this is unqualified.

There are many senior people or folks with families/etc that don't have the time or patience for this ridiculous cargo cult hazing ritual masquerading as a hiring technique.

I would say your assertion that "leetcode is a proxy for IQ" is a bold statement to make without some bold sources to back it up.

I've personally met a number of people that are great at these small scoped problems but suffer at broader systems engineering.

> the group that's unwilling to put up with this is unqualified

Companies that get a lot of applicants care more about false positives than false negatives. So they're fine not hiring a lot of qualified people, as long as there's a low chance of accidentally hiring an unqualified person. Apparently LeetCode-style problems work for that type of screening.

companies can win by hiring exceptional people with deep experience. the cost of not hiring these people has been unquantified. i would never want to be in their position. imagine a startup hires that one person who will make a billion dollar difference?

The startup isn't likely to be getting resumes on the scale that the big tech companies do and can afford to spend the time to look at each resume and maybe even do an interview with each candidate.

However, if you are getting resumes on the scale that the larger, well known tech companies do, then the individual attention cannot be paid on each resume. At that point, one looks more at a quick filter to try to remove the risky hires.

If you've got 1000 resumes and 80% of them are bad hires, and after an online assessment that takes it down to 200 resumes of which only 50% would prove to be bad hires, that is a significantly improved pool to consider.

Yes, it is possible that a great candidate was removed in that filter, but its also possible that one still remains in that pool.

Startups may be cargo cutting big tech interview processes, but the process has value for big tech companies and any others that have more resumes than they can reasonably deal with.

cost of living is driven by FAANG and startups use the same leetcode hiring process as FAANG, but pay less. the equity you get has a miniscule chance of becoming valuable.

No, that's not true, LC style problems are not bullshit. There's no rote-memorization required. Just basics of a language that you know and the very basic constructs.

95% of programming is data structures and algorithms because that's where all the performance gains are usually made. The other 5% is knowledge of the hardware and micro-optimisations like avoiding branch mispredicts and understanding the compiler.

Hashing in databases is very similar to how hash-tables work as is sharding.

It is true, most of the leetcode problems use the same underlying collection of approaches. If you don't know them (by memorizing them), you probably won't solve the problem. There is some value in knowledge of those approaches (algo and DS stuff), but these toy problems are not a good way to evaluate how someone would use then in a real life situation.

"95% of programming is data structures and algorithms" - it's just not. 95 percent of programming is gluing together libraries, refactoring code and reorganising what you have to solve new business requirements.

Your focus on performance (albeit important) above all else makes me question how much real world experience you have building large scale systems. (Unless you're a systems/embedded developer).

But this is the crux of the issue: using metrics that don't map well to what we're trying to optimize for. Perhaps your trying to optimize for finding great performance focused, low level software devs? If so that's different that my goal.

>can you make that work at scale with a data store that you have no information about? How’s it going to get the data to operate on in the first place? Will your data retrieval query cripple a prod database? Read from replica? How far behind can that data be without making your fancy algorithm useless? How will you parallelize that work set? In-request or background job? Multi-threaded or single thread? What about changing state in multi threaded contexts? Database indexes? Schema design? How will you handle failures in your algorithm? How will you handle malformed data? And most importantly, does what you’re doing benefit the user, or just your epeen?

Some of these questions are perfectly valid during LC coding rounds. Others would be more appropriate in a system design round.

sure, let's spend time solving Leetcode problems instead of understanding how HTTP works.

> I have no idea why this isn't a more common practice

It used to just be “the practice”. The folks who don’t do this are trying to automate hiring.

> The folks who don’t do this are trying to automate hiring.

Or they are trying to emulate Google and similar companies without understanding why they do it.

If this interview process is so golden (based on your metrics of success) why isn’t every one doing it?

Not OP but here are a couple reasons:

* It doesn’t scale well to huge organisations.

* It’s not standardised “repeatable” in the sense that you cant generate datasets from this that let you correlate interviews with subsequent outcomes and improve hiring metrics company wide

* It requires expertise in pair programming, which most companies don’t have

Basically, OP’s hiring process is an excellent example of “doing things that don’t scale” to gain an asymmetric advantage as a small organisation.

They don’t need to derive metrics, they can invest the time, they have a team who are skilled at pair programming - so they can have this hiring process and other people can’t.

Brilliant.

This is exactly the right way to do it. Not only do you find out if the candidate can program, but how well they can pick up unfamiliar code, tools, etc, can they communicate, can they work with others, etc, etc, etc.

Leetcode bears little resemblance to everyday programming. Of course it's sometimes necessary to understand big-O, and that various data structures and algorithms exist, and which ones you might apply to certain problems, but coding them from scratch, from memory, within a fixed time? Pretty much never.

> but coding them from scratch, from memory, within a fixed time? Pretty much never

This is definitely true, but having to do it quickly and on-the-spot is one way of measuring just how comfortable you are with it. You might never have to do it in an hour, but being able to is a proxy, however weak and indirect, for your competence, and guess what, I only have an hour to talk to you.

I love and hate leetcode interviews. I enjoy the challenge, and I hate being put on the spot and knowing that poor performance on one specific problem might result in an unwarranted thumbs down. I sincerely hope any interviewer whose chair I'm sitting in treats them the way I do, which is that it isn't important that you come up with the optimal solution; it's important that you can think through the problem and come up with any solution, however inefficient, and then honestly evaluate this solution (including big O) and point out how it could be improved. You probably don't have time to implement that improvement, but you've demonstrated competence in both thinking and coding along the way.

Edit to add: When I'm preparing to interview, I practice leetcode-style problems, but not so much to memorize all the questions and their answers as much to just practice my quickness for thinking and coding on that type of thing. It feels kinda silly because, as you point out, that's pretty much not a part of the job at all, but it's very very helpful to exercise your mental muscles for that sort of thing so you don't stumble over the simple mechanics of the problem. It feels absolutely great when you get a question you've never heard before but you've put yourself in the mental state to solve it and you kill it. And like it or not, I've personally found that people who enjoy this type of challenge are often the exact types of coders I want to work with.

I don't agree it's a good indication of competence; leetcode skills are almost orthogonal to the skills required in general programming.

It might be different if you're being hired to develop a new video codec, or distributed consensus algorithm or whatever, but for the typical large web property or enterprise database, leetcode is all but irrelevant.

Code cleanliness, code communication, defensive programming, properly considering edge cases etc, flexibility, API UI design, and how other people interface to your code, etc, etc, all these things matter far more than advanced algorithms, which will rarely be required.

> I don't agree it's a good indication of competence

my statement was that it's "a proxy, however weak and indirect, for your competence"

I'm 15+ years of experience, I funded a few high level projects for corps and a few startups including hiring my teams. I was always conducting my interviews by making some work with the candidate and I found it best approach.

And quite recently I sat on another end of hiring table. I'm good at algorithmic challenges like letcode or hackerrank, I always liked puzzles like this. And yet, last interview I failed. Purely because I got a bit nervous and did not manage to deliver fully working solution in 15 minutes in front of interviewer. And that after passing their hackerranks and answering their general system questions. I guess their approach was all or nothing. Is it good or bad, I don't know. But from hearing their problems I knew their problems is something I eat for breakfast :)

the goal of the leetcode interviews is to get into who is the smartest mode, so the cost of hiring can be driven down. those who conduct the interviews are unaware of this. the process you describe would result in paying people more which is not what FAANGs and those imitating them want.

This!

> I have no idea why this isn't a more common practice

My maths teacher once said in class during lecture, "Kids, when you venture into the outside world, you will realise 'common-sense is not a common thing!'".

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.

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.

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.

> 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.

Some people lie on their resumés.

If they're good at lying in person, it can be difficult to detect that.

If they're able to deliver working code of some kind under the pressure of a job interview, then they're almost certainly about to actually program at least a little, so you can trust me of what you see in their background and what they tell you about their achievements.

I'm personally skeptical that leetcode really tests what most companies need in a programmer, but it's probably better than nothing.

> Some people lie on their resumés.

My point isn't that I want to only chat about my resume - just that the problem you give me should be something I may encounter in the new job, ergo I do not need to prepare for that since my entire career prepared me for those (unless I want to reskill and the new job is different than the old one, then some preparation may be warranted).

> If they're able to deliver working code of some kind under the pressure of a job interview, then they're almost certainly about to actually program at least a little, so you can trust me of what you see in their background and what they tell you about their achievements.

Sure! But if the assignment is depending on stumbling upon a brilliant idea, instead of solving a problem that you may see in your day-to-day job, then I don't think it's useful. Think "trim a string" or "split a CSV" [1], not "find the longest increasing subsequence". And maybe also explicitly stick to ASCII encoding for string-based problems (but TBH, if a candidate asks about encoding, they probably know their stuff, or at least know where the gotchas are)...

> I'm personally skeptical that leetcode really tests what most companies need in a programmer, but it's probably better than nothing.

Agree that it's better than nothing. Disagree that we can't do better. :)

Edit: [1] ... maybe w/o relying too much on standard library if those are built into the language you chose.

Yep, that all makes sense.

FWIW, I agree we can do better than leetcode.

I'm personally a fan of an approach I saw someone else describe here, where you literally have the candidate do a few-hours freelance gig for you, paid at a decent rate. Triage some of the low-priority bugs so when you're interviewing you have a little stack of relatively self-contained, well-defined tasks for candidates to pick from. Probably good to have someone pair with them, if the candidate is willing.

You get to see them work in a real context, they get paid, you can learn about how they work, and it seems like a win-win to me.

I also think it's good to be open to other options - if a candidate has a different way to show they'll be good at the job, let them do that. If burntsushi wanted to work on a company's CLI tools, I'd hope a link to the rg repo would satisfy everyone that he knows how to write a good CLI.

> 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.

leetcode was introduced because the founder in india could not get a job because he didn’t have a degree. so he made a platform where people could prove how good they were.

the trouble is that this just trains code monkeys to memorize optimal solutions to a set of problems and to quickly reproduce them.

it does not optimize for real engineers who have the experience to build good software and to come up with creative solutions to hard problems.

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

Naturally, but how is that a flaw?

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.

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.

Glad that worked out for you. After a day of watching my now 1.5 year old the brain fog sets in. I tried grinding Leetcode for a while but the pace of progress was glacial and nowhere near the recommended pace for BigCo interviews. I'm glad I went back to doing my own thing even though nothing has come of it yet. Doing Leetcode felt like memorizing party tricks that wouldn't even guarantee a job at the end.

Honestly, do you want a BigCo job? Would it make you happy? The experience of being a tiny cog in an unthinkingly vast machine is more alienating than you might think, even if you like the money.

I think lots of those who stay on long-term in that environment, say >3-4 years, effectively become institutionalised, condemned to spend the rest of their life philosophising about whether they can ever be L8 material. These are people who are, by and large, smart but not wise. Yes, the money is good, for an employee, but it barely equals what even a small business owner could make - and these are people whose smarts would allow them to thrive in the software niche, at least with a minimal amount of commercial nous.

The truth is that FAANG (or FAAG, considering what's going on at Netflix?) keeps these people there by creating a value system. If you've ever read the internet-classic 'Five Geek Social Fallacies' post (https://plausiblydeniable.com/five-geek-social-fallacies/), you'll know that people like us - frankly - are suckers for taxonomy. If you tell them that they are the best because they work for you, and the only thing that can make them any better as an engineer is creating maximum returns for the Borg, and surround them with others who mirror and validate that behaviour, they will fall for it for the rest of their lives.

Don't fall for it. There are a fuck ton of smart people at FAANG companies – that's one of the few marketing points which is unvitiated in its merit, they do scoop up very many of the smartest (again, smart-not-wise) people in the world – but that doesn't mean the only way to be smart is to join. It doesn't mean you - as a unique human being - will be happy there. Carve your own path, be suspicious of people selling you axiologies and hierarchies, find a middle road between excessive cynicism and excessive credulity.

It's something I consider every couple of years. But unfortunately I see a lot of similarities in the hiring process for much smaller interesting companies hiring remotely that seem to be cargo culting BigCo hiring practices. BigCo from my example were just the only ones to be open enough about what will occur during interviews. Is it something fulfilling? Probably not, but I have 5 years of practically unpaid work to get caught up on.

What exactly did you do during that block of time? As someone in a similar situation to you I'd like to begin getting some practice, but I'm not sure where to start. Are there any resources or websites that stood out as being particularly helpful?

> 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.

I think this style of interviewing also serves as a proxy for age discrimination and/or to detect personal work/life balance values that don't favor the prospective employer.

If you aren't willing to dedicate a considerable part of your unpaid, personal time to an activity that they mandate, you aren't a good fit for them.

I agree. We lost two of our worst performers to FAANG companies. They were both junior and came from top schools. Communication was a huge problem and both wrote very sloppy code. We would assign trivial tasks to them that would take an average developer 30 minutes or less and they would struggle even with heavy mentoring. I was the mentor for one of them and I really tried my best, but there was little improvement over several months and luckily they moved on.

Now I'm mentoring two devs who didn't study CS in college and only completed a coding bootcamp and they're working out amazing.

Yup this is a pattern I’ve seen as well and why I think Leetcode is on the way out. People will figure this out

> 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

Exactly, even before the first interview, that’s what I’ve seen too

> The point is not whether people need to learn algorithms

No, I said design and analyze algorithms, which is a distinct skill from "learn algorithms" (although that certainly helps). And which is certainly very riddle-like.

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

And it may be worth observing that, as far as I know, this sort of thing is totally unique to programming. No other branch of engineering does it. I've certainly never had to do any unusual prep for an interview--though, admittedly, my handful of jobs since just out of grad school have all been through people I know.

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.

> devote their life

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

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.

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.

> 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.

> 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.

A one-day interview can't test you on things that take up the majority of your career time.

I am on the interview team for the company I work for and I wrote what some consider to be our canonical python solution (fastest and simplest) for one of the problems we use. I had to look up the syntax for a "for loop" because I hadn't written python since my first year at university. To me, being able to stitch together simple concepts present in almost all mainstream programming languages doesn't mean I know python, it means I know how dynamic programming works. I don't know the python ecosystem (history, present, or future), know the standard library, know what idiomatic code looks like, deeply understand what makes the language unique, have the mindset of a python programmer, etc. Maybe I just have a high threshold for feeling like I "know" a language.

i did a leetcode interview in c++ and didn’t remember some syntactic details of lambdas and that was the end of it. please stop with this nonsense that interviewers are understanding and that you can look things up or that you will be able to take your time to produce the optimal solution to a problem.

Well I can't speak for other interviewers especially at other organizations, but I try very hard to make it a positive experience. In fact I'll give as much help as necessary to get to a working solution, within reason. I would much rather fix the lambda syntax myself or help the candidate find an example on stackoverflow so we can go back to the interesting part. If the interview ends with a working solution but needed a ton of help, the candidate probably did not pass but maybe they learned something. And maybe they'll tell their peers that it seemed like a place where they could fail without embarrassment, collaborate, and learn.

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).

Don't forget: in 45 min, without bugs

oh and do it in Go* ... Good F'ing Luck .

Go makes normal string operations tricky due to rune being an alias for int32, ranging a string gives []byte indexes ...

https://go.dev/play/p/33jCwNG6Eu6

It's a bit sucky but you can use the standard library function "utf8.DecodeRuneInString(a)".

String problems are rare, though may come up more in search engine companies.

But manipulating sequences comes up a lot in many contexts. Usually it's sequences of more complex things: instructions, packets, files, polygons. It's hard to assign tests directly on those, because you have to explain the objects themselves first. So it's a reasonable shortcut to test ability to manipulate sequences of characters.

You mean simple abstract problems, right?

LeetCode problems are solved with under 50 lines of code, using textbook models.

This is fine, except when the candidate knows substantially more than the interviewer about how to solve the problem. I was once asked to implement a spsc circular buffer, and I used C++11 atomics rather than a mutex. I wrote up a working solution, but most of the interviewer's followup questions fundamentally didn't map to my wait-free solution. I spent most of the time explaining to the interviewer how atomics and non-blocking algorithms work. The FAANG rejection email came a few days later.

So I don't think these interviews evaluate the candidate's ability to solve complex and abstract problems. They seem to evaluate the candidate's ability to grind contrived sophomore-level computer science homework. Experience solving the real-life version of the problem rather than the academic one is unwanted.

this illustrates the problem very well. your lock free solution is superior yet the interviewer had no clue and you only know about this solution due to experience which is not what leetcode optimizes for.

As I understand it, programming is only part of it, a big part is just seeing if you will study hard to learn meaningless stuff

If they’re so interested I have a massive catalog of things that can fulfill such a requirement.

> 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.

Off topic: what’s this IBMization at Microsoft?

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

Yeah, it's clear these people have never hired for a company. I've sat in on a thousand hiring committees, helped design these processes, all that boring shit, and the idea that someone would say "let's do Leetcode challenges so that we select for people who are willing to subordinate their lives to our company" – presumably followed by a "mwahahaha!" – is fantasy, it's something out of a movie.

I mean, look, it sucks when you can't get a job. I've been there (when I briefly tried to escape programming for a different metier) and it's awful. But pretending that the entire outside world is a dark mass of malevolent forces arrayed against you.. well, it may be psychically necessary in some Freudian, Jungian sentence, to prevent ego death or whatever, but in the long run it's neither (a) true (obviously), and (b) nor is it going to do your mind and mindset any good.

> But pretending that the entire outside world is a dark mass of malevolent forces arrayed against you.. well, it may be psychically necessary in some Freudian, Jungian sentence, to prevent ego death or whatever, but in the long run it's neither (a) true (obviously), and (b) nor is it going to do your mind and mindset any good.

Maybe you can post this in the endless Russia threads posted here, which seem to have crowded out the endless China threads.

I guess what you're saying is that apprehension about the motives of of corporate executives is so irrational, it's akin to a psychological problem.

It is low of you to conflate the two. While both companies and russia pursue goals in somewhat pragmatic manner, the former aims to maximize profit while the latter aims to execute an entire nation and take their resources with calculated brutality (most war crimes committed were under direct orders).

> I guess what you're saying is that apprehension about the motives of of corporate executives is so irrational, it's akin to a psychological problem.

No, that wasn't what I was saying there, but coincidentally, yes, I would agree with that statement. For one, 'corporate' is a phenomenally lazy word used to invoke some mental image of besuited sociopathy, from a million children's movies and internet debates. In the real world, 'corporate executives' - human beings, mothers and fathers, working in management careers at (large) companies - are humans doing jobs, like any other humans doing jobs.

I've been involved (as an engineer) in C-level meetings with people like that, as well as worked alongside them in the same teams, and my experience - thoroughly unsurprisingly given what I said above - is that they are pretty ordinary human beings on the whole. I'm sure there are differences between companies in terms of their cultures or values, but that's company-specific and not discipline-specific or seniority-specific.

I get that your experience is that these are people who mete out decisions from on high, which affect you in sometimes-negative and always-unforeseen ways, and that makes you feel like a mediaeval peasant might have felt towards his feudal liege. And maybe it's helpful, from a cathartic standpoint, like I said above, to picture them as evil baddies from kids' movies. But no, the reality is more banal.

(Incidentally, I think those who worship company CEOs - and suchlike - are equally stupid, from the Elon bros to the HackerNews types who recite stories about startup founders as though they were superheroes. These people underestimate the role of chance and – in a way, very similarly to you – overattribute the differences between execs/founders vs regular workers to a proportionate difference in their inner essence [in their case, they think intelligence & industry; in your case, you think amorality]. Both are fantasies.)

Yup exactly, that’s the whole thing. They want people who will devote their lives to meaningless tasks

> They're looking for people who will devote their life to the company and can quickly learn new skills

This doesn't reflect my lived experience in SV. People I know who learned leetcode skills and got into big companies usually work less than people who passed more practical tests and get into smaller companies.

I'd say big companies are trying to hire employees who are a "good" mix of:

1. Smart

2. Conscientious / willing to work hard on the right things

3. Existing CS knowledge you know well enough to explain and apply.

For some vague handwavy definition of "good"

(2) is probably worth expanding a bit. Many people are willing to work very hard on the wrong thing, this extends to engineering. As an example, a common failure pattern you might see is someone constantly struggling with how React works and what they really need to do is sit down and read the ~15 pages of documentation. But they never do, and just keep putting in 10 hour days with subpar output.

I've met some legit geniuses (think Putnam winner) for whom basically no studying was required to pass these interviews. Companies paying top dollar are happy to have them. For people like who are less smart and need to dedicate ~100-200 hours of focused studying and practice, companies paying top dollar are happy to take our mix of smarts and willingness to do that work. But once in the company I haven't noticed any expectation to "devote my life" to it.

Right, I think you've explained it better than me. I was just going for the idea that the point of leetcode isn't to figure out if someone is currently a great engineer, but if they have what it takes to become one. Everyone complaining that leetcode isn't related to their day to day job is missing the point.

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.

> Take it to the other extreme and you get folks who can’t even solve fizzbuzz. So some coding bar is good.

Sounds like the epitome of a slippery slope, to be honest.

Some people are going to say FizzBuzz (or similar) are a good enough bar.

More people are going to say 2Sum is a good enough bar.

Even more people are going to say Longest Common Substring is a good enough bar.

{...}

And the cycle will continue, because people who will have been asked such things will (most of the time) feel like 1) they've been asked it before, so now they must ask it, 2) they can solve it and feel anyone can solve it (in theory this is fine but in practice, not everyone can solve a problem in 45 minutes that they've never seen or never fully solved before).

Which reminds me of when I was going to college and I frequently had professors or TA's say X problem from the problem set is an "easy" one. Well, yeah, you're the professor or TA (for a reason) and you're the one giving it, of course you'd know how to solve it and such.

I recently went through a round of interviews at big tech companies, and I found that the coding questions were less stressful than I was initially worried about. Leetcode problems are fair, and it just isn't true that you need to know the trick to pass. It allowed me to get in the door at a company I would have had no chance with otherwise (no CS degree, no top school, small no-name companies, etc)

System design on the other hand... that can be hard to prep for!

The reason companies provide so much info upfront, and even send candidates to leetcode.com, is so that everyone knows what to expect. Not everyone is on HN or is even aware of these types of interviewing trends.

Go work in an industry. Any industry that isn't IT, I suggest manufacturing and raw resource industries like farming and mining. After a year and you get your head around what's going on automate some of their business process or collaborate some some of their data into a form that's easier to interpret.

Sell back to your employer or their competitor. Congrats you've just started your career in coding and you didn't do a single whiteboard riddle I interview. Also your doing real work for real people and making actual differences in day to day lives. Not just some faang companies pleb work, bleeding metrics from the masses.

You’ve also built a mental model of how large systems interface that takes years to acquire from the other direction.

this is good advice.

Much better advice than “get used to ‘em” as alternatives to the status quo do in fact exist.

Yep, get in through the backdoor.

this is actually our company/startup for the ChemE type companies.

it is just hard to find software/data science people interested in manufacturing/engineering

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.

After all this knowledge you still won't be able to solve "Next Permutation" or "Integer to Words" or "LFU Cache" within a 45 min Interview if you haven't seen the problem before or never practiced enough leetcode for it to become subconscious and automatic.

If you learn all this and you can't solve LFU cache in 45 minutes, go back and study the parts about heapsort, red-black trees, and B trees.

If you learn all this and you can't solve "integer to words", go back and do some more practical programming. Build your own blog in Django or something.

If you learn all this and you can't solve "next permutation", well, yeah sometimes interviews ask you dumb theoretical stuff that you will never use in real life. Them's the breaks.

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

i've done around 800 leets and never had to learn any of these.

you can do a whole bunch of leets if you just learn the following and fill the gaps along the way

1. data structures: tries, maps, lists, heaps/priorityques, stack, dequeue.

2. graph: shortest paths, dfs, bfs, cycle detection, topological sorting, union find.

3. binary search

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 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

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 tests my anxiety levels at least 5x more than my skillset.

I'm not so convinced that these are two distinct things. I want coworkers who can maintain their level of skill under extremely hostile, stressful conditions. I'm not going impose those conditions on them, but I can't necessarily control the myriad third parties or circumstances that might.

I am not particularly good at competitive programming, but at some point I did invest quite some time into it. Contrary to my username I have a pretty decent memory and I can remember easily if I've solved something similar.

At some point I've interviewed for a company who gave me four exercises to solve in an hour. Normally, it would've been impossible to solve them without previous knowledge. Funny part is that I knew the idea for all 4 and the only difficulty was to write things quick enough so I can finish everything in time. 57 minutes later, I was finishing all of them, to the surprise of the interviewers who were watching me coding.

I had the all time best score for that company, and everyone thought of me I am some kind of genius, which was certainly not true, because I know my limits, and I am far from it.

Nevertheless, everyone was a little disappointed by me in the next 6 months. I was quite junior, and had junior problems.

I haven't done whiteboard coding interviews for a long time, but this was a problem back when we did. We started by using generic coding problems that someone got from somewhere (probably a popular book or website). Occasionally someone would show up and basically recite the solution from memory.

Having 4 different problems is usually an okay defense for this because you can spot when the candidate recites some answers from memory but then struggles through relatively easy questions they obviously haven't solved before.

The fact that you had all 4 memorized defeated that heuristic, of course. The smart companies are careful to rotate their problems and customize them in ways that will trip up most recited answers.

> I had the all time best score for that company, and everyone thought of me I am some kind of genius, which was certainly not true, because I know my limits, and I am far from it.

> Nevertheless, everyone was a little disappointed by me in the next 6 months. I was quite junior, and had junior problems.

I mentored college students and recent grads for a while. A lot of them had been convinced by the internet that they just needed to memorize enough LeetCode problems to squeak through a FAANG interview and then they could relax for a decade or too until early retirement. It was like all of the Reddit memes about CS careers collapsed into a single narrative.

I spent a lot of time reminding them that high paying companies have high expectations and it's not as simple as collecting $300K/year to do nothing. Of course, they didn't really want to hear it from me.

There was a Google talk some years ago that brought up this same idea with regards to people who did programming contests: https://m.youtube.com/watch?time_continue=51&v=DdmyUZCl75s&f...

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.

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

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

> 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

[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."

Yeah this is so true, I’m experiencing this at my current org. Does anyone have advice on how to avoid these pitfalls?

Don't put 100 people in a room. Put 4 or 5 in a room max.

You need a feedback loop to sanity check features some how, but you also need vision and the courage to release stuff that not everybody wants. Every good product I've worked on has had team members who thought the newest features were stupid. Too bad, you aren't the target audience, get over it.

Accept that you'll be releasing features that are either wildly liked or hated. You are going to be hitting both ends of the bell curve more often this way, embrace and accept it.

Put some potential users of the product in the room. Show them mockups. Iterate. Get user feedback. Repeat.

Surely this is a consequence of management and corporate ideology, rather than a natural outcome of having some arbitrary number of devs in a room. A good project manager doesn't allow great ideas to die on the vine unless there is pressure to do so, and that pressure is not coming from the team or customers -- it's coming from the top of the company.

For all of his and Apple's faults, Jobs aggressively fostered a culture of "good is the enemy of perfect," which placed the focus on polished features instead of the dull hum of incremental development. And that bucking of homogenization is what led to such a rabid base of loyalists, as consumers tuned in to that momentum of (albeit perceived) innovation.

Google, on the other hand, has never really had a fan base to speak of, and the few remaining loyalists are rapidly disappearing. I genuinely have never met a consumer or dev who believes Google is at the bleeding edge of any feature. That is wholly reflective of Page and Brin's ideologies, who fostered a culture of "over-engineer, refactor and ship incomplete," which is exactly what you're describing. Angular, for example, is the perfect representation of the Page/Brin ideology, and that's why nobody uses it.

It's the rule. Steve Jobs is the exception.

HP, IBM, Cisco, Sun, Netscape, Google - they were all visionary when they were small and bloated and inefficient once they got big. Apple too - do you remember the late 80s and early 90s, when Apple had a zillion PowerMac models, plans for Copland that never shipped, multiple new programming languages, the Newton, and basically a lot of ideas but shitty execution?

Steve Jobs basically managed to rein it in by being an asshole - he had both the product taste to be right, the charisma to convince everyone else of it, and the insensitivity to not care whose feelings he hurt. Elon Musk is similar. But note that the flip side of this is often a crisis of succession: IMHO Apple really hasn't been that visionary or helpful since Jobs died, and have basically pushed out a series of incremental improvements.

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.

what does "cargo cult their business" mean?

https://en.wikipedia.org/wiki/Cargo_cult_science

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

100% Leetcode is now a great metric for me on company culture.

Is your company able to back the trend when it’s obviously wrong?

I agree, but in general I've found if you want FAANG cash, it's better to just be good at leetcode and deal with it.

I prefer money over perfect culture though.

Right, all the most valuable tech companies in the world have hiring practices that are "obviously wrong." I'm not saying they got so valuable because they're using this style of interview, but if it were so incredibly ineffective, how would they have become so successful?

Because this hiring process came _after_ they were already successful?

Yeah they didn't start this way, with the exception of Google, its a recent invention... and now a cargo cult sped on by comments like this

one thing tons of people don't understand is that interviews are two way streets. companies are getting to know you, but you are also getting to know the company.

as you said, i would never work at a company with bad interviewing practices because it means that either the employees were hired by these bad practices OR the practices changed and no one cares.

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.

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.

Sorry but there’s a lot of ways to filter devs, you would need to back this up with data.

Here’s another avenue, show me your OSS work if you have it. That give me a far better picture of how you develop than LC ever could. Don’t have OSS, then a take home test also works perfectly fine or a programming exercise that’s realistic

There are not many that are as cost effective and scalable for the number of applicants that a tech company can get.

> Here’s another avenue, show me your OSS work if you have it.

For the complaining elsewhere in this thread about how leetcode filters for people who have free time to work on it and thus selects for upper middle class... this is even worse in that regard. Furthermore, the contributions of a new grad are... often "poor".

The take-home test is similarly derided in many circles that refuse to do leetcode and the "write this program" is even less transferable to doing interviews at other companies.

With OSS you're at least coming out with a product that is useful to the ecosystem and you can show off for the rest of your career. It'll take you about as long as the LC nonsense does.

You think you have more data than all these companies who are worth Trillions of $$$ because they actually hired smart engineers?

I've also worked for companies worth billions of dollars that had tons of really smart engineers and didn't do LC. Its a cargo cult at this point, plain and simple. Google made it cool, now other people have jumped on, not because they have data but because they want to be like Google

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.

Microsoft was one of the first big tech companies to popularize these styles of white board coding interviews. Back when I was in college, Google had just lowered their hiring bar from "must have PhD" to "well BS from an Ivy League may be good enough", CTCI was seen as a way into Amazon and Microsoft.

Come on, there's enough, far more than enough, out there which is not like this.. just change your expectations.

Just went through a round of interviews in the past 6 months (~20 phone screens, 6 in person loops, 3 offers). Not all of the companies do it. If you don't like the process, then politely decline the interview. (you probably don't want to work there anyways).

The worse to me are the interviews that ask you technology specific commands (for ops positions, especially k8s) and/or specific language constructs.

having worked there they had a decently high false positive since the hiring bar wasn’t consistent. workers choose what questions they want to ask. seen some onsite loops have two seperate dp questions while others have “design tic tac toe” and 2 sum.

plus a lot just blindly memorize thousands of leetcode answers but aren’t great coders.

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.

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

That is not universally true.

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?

Probably more like 100% more tbh.

Yup, 200k -> 400k, sounds about right

So I guess try to get your first LC job before your personal life gets demanding, then hold on to that job for dear life so you don’t have to grind LC again?

This is a decent strategy, I approve.

Is this the norm in the US/SV?

Very skeptical of someone who switches every 2 years... you also become only really efficient after 6 - 18 months.. not only the code / legacy / wider system your stuff integrates with, but also socially knowing all the right people, context of all the bigger processes, a good chunk of domain knowledge ingrained??

It’s quite common among the Silicon Valley scene during the tech boom. People bouncing between startups or even between FAANG level opportunities. Switching companies annually even (though not for many successive years).

Sometimes it’s not the worst strategy as the hidden truths of a startup reveal themselves over the course of a year or two.

It's surprisingly common, and a great way to filter out candidates if they have a history of job hoping.

People under 35 change on average every 20 months in the US. People who are focused on salary and career achievement. There are a lot of people who get a job and blank out on cruise control and wake up 10-15 years later and wonder why everyone else is making more than them. But the talented people are usually switching every 2-3 years. It's not uncommon for someone to spend an extra year at a company to have a child, plan a marriage.

Uh, generally yeah.

Your math is wrong. People aren't literally doing LC for 2 months straight without eating or sleeping. If we assume it means you study for 2 hours a day that's only an overhead of 0.7%. I still think that's an overestimation of the time you would actually need.

> 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.

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.

SATs are also a very bad way of evaluating anything meaningful

They're useful as a second piece of evidence if, like me, you did poorly at classwork because of undiagnosed ADHD.

YMMV. I studied zero hours for the SAT and did well. There are honestly no hard questions, just a lot of them in a short time.

I have studied at least a hundred hours for leetcode and I still have never passed an interview at a well paying company. Leetcode hards are legit hard.

Yeah people in India/China spend 2-3 years grinding complex maths/physics puzzles just to get into a college and Americans can't put in a few hundred hours of hardwork to get a high paying job. It's probably lack of rigour in American schooling system that's behind this entitled mindset.

If the grinding is not going to translate into a business advantage, then it is pointless.

A lot of those people in India and China commit suicide, have mental breakdowns, or end up living generally unsatisfying lives. Their system is entirely unenviable.

OP here.

I’m in India. People spend 2-3 years grinding leetcode questions too. So you can imagine how difficult the tests have become over the past few years and how pointless this whole test is.

There's a difference between 'entitlement' and recognizing that a system is flawed such that it doesn't necessarily select for the best candidates, only those who are willing to play the game hardest, which doesn't necessarily correlate with the best on the job performance.

The zero sum burnout games many Chinese and Indian students play are also a good example of such a system, and I think it's a positive feature of American culture that it's objected to.

You are right. The problem is not solving the question, but solving it in 15 minutes with the optimal algo/data structure. Practicing can easily get you there. Also. In the grand scheme of things it's nothing compared to the job/comp bump.

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.

You do realise that these leetcode rounds are virtual and there are “agencies” on the internet that would take this test up for you?

When I interview people, I have to make sure that the person actually wrote the code by asking some arbitrary questions about it in a subsequent rounds

We’ve had cases where people committing this fraud did manage to slip through the cracks but thankfully here it’s very easy to fire people once we found out.

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.

I guess you just swear off ever doing an algorithms problem? This doesn’t seem comparable at all - there are feasible circumstances where you need to know this stuff.

> I guess you just swear off ever doing an algorithms problem?

I swear off memorizing the answers to them. If I run into a problem that requires a leetcode-style solution, I'll find many available bits of information to help me solve it.

My advice? Start memorizing the riddles.

Consulting jobs require case interviews - they're pale imitations of actual projects that translate loosely at best. And every company uses them.

Trading jobs ask probability questions - they're idealized versions of what traders do all day, requiring tangential (at best) skills like mental math and memorizing niche formulae. And (almost) every trading firm will ask them.

Tech jobs ask leetcode questions - they're vaguely correlated with tech skills (you can't learn leetcode without learning to program, I guess?). And (nearly) every company asks them.

All of these industries put up somewhat-arbitrary filters just to get a manageable signal, however imprecise, on the endless morass of new grads trying to break in. They ask them because they work: the pool of candidates who pass them are of a higher average quality than the pool who fail.

They're biased, arbitrary, and often quite silly. And they've persisted for a half century. Get used to 'em.

> Get used to 'em.

No.

I’ve spent the last year or so reinventing the hiring process at my tech company to expressly avoid algorithmic puzzles and leetcode nonsense, and I was able to do this because I patently refused to accept the status quo.

You can do this too. Anyone can. I’m basically a moron and I managed to convince our talent team to radically change how we do things; if I can do it I feel like the bar is pretty damn low.

The only real requirement is that enough of us simply refuse to accept how things are today. Right now is a fantastic time for the tech industry to adopt change because your talent recruiters are probably struggling to find and retain new developers and are almost certainly willing to listen to suggestions on how to stand out.

Would you be able to share the kinds of questions you ask and have had success with? :)

We basically adopted the MINASWAN interview, which Jesse Spevack can explain much better than myself in his talk [here](https://youtube.com/watch?v=c4K-ORZmrGk&feature=share).

The overview is that for each candidate we spend 20 minutes reading through code we provide to them to demonstrate comprehension, and then we give them 45 minutes to pair with us on reimplementing that same code from scratch.

What that code is doesn’t really matter, it’s more about getting a chance to work with them and start a conversation, and starting with trying to explain a provided example really smooths the way into the pair programming.

How much time and resources does it cost to successfully hire one candidate?

Substantially less than our previous process.

We went from a process that took weeks to get through (multiple interviews, about an hour each, with a full code day at the end) to a two step process. Talent reaches out to the candidate and has a thirty or so minute chat to make sure the candidate meets basic hiring requirements, and then we have our MINASWAN process which is a single three hour interview, including two breaks for the candidate to get off camera and catch their breath.

The participants are: - the candidate - a hiring manager - between two and four developers for pairing - an open invitation to the hiring team’s devs for a closing panel interview.

The feedback we’ve received from candidates has been overwhelmingly positive, even for those who didn’t receive an offer.

> 45 minutes to pair with us

Do you require pairing on real work? How do you handle candidates who need quiet to think? Going by the continual complaints about open plan offices, there seem to be a lot of us.

We require that ICs are able to work with others effectively; we have a very large engineering team working on issues related to health care and collaboration is effectively mandatory.

We keep the pairing as short as we can and we provide breaks between the short sessions to be as friendly as we can without being unrealistic as to what the candidate should expect in the actual job.

Your hiring process sounds great. Is there a link where one could apply?

Sure, you can view all of our open positions here: https://experience.covermymeds.com/open-positions (and then narrow down the list with the “all teams” drop down and selecting “technology”)

If you’re looking for a general SWE role: https://mckesson.wd3.myworkdayjobs.com/CoverMyMeds_External_...

> I’m basically a moron

Google and other companies are actively trying to avoid hiring morons.

I’m not sure if you’re just being snarky or you’re trying to make an actual point here, but I can tell you that this kind of commentary reinforces the egocentric interview process we currently suffer through.

Solving puzzles doesn’t prove that you’re smart, and not memorizing them ahead doesn’t prove you can’t do the job. Unless you’re really on the edge of the industry—designing rockets for NASA or surgery tech or something—most dev jobs aren’t really all that hard, and we should stop pretending they are.

Solving complex riddles may not prove you're Einstein, but it's a pretty good filter for morons.

Disagree. I’m very good at puzzles.

then you shouldn't have said you're a moron. You seem somewhat contrary, which leads to its own problems, at least for me.

Disagree. I’m highly agreeable.

> most dev jobs aren’t really all that hard, and we should stop pretending they are.

I agree with you about GP's commentary, but I don't know that I agree with this statement.

Getting something working is often relatively easy. Shipping v1.0 is often relatively easy. But it starts to get gnarly as you build out capabilities, add services, split concerns up, have to maintain compatibility with previous versions, dependencies multiply, the amount of data you're dealing with massively expands, and so on. Most problems have one or more inflection points, whether that's around performance, or scale, or volume of data, or whatever, that when you pass them make that problem substantially harder to solve.

Still, these are all issues that come with a certain amount of success. Not necessarily crazy success: I'm just talking about the kind of traction that companies that grow to earn millions to tens of millions of dollars or pounds per annum experience.

The really hard part of being a dev, of course, is knowing what the right thing is to build. Often, because users tend to struggle to articulate their needs, the only way to find out what to build is to start by building something that you know is probably going to be at least a bit wrong, if not massively wide of the mark, just to get some feedback. And then you have to iterate, sometimes quite painfully, towards an actually good solution from there. Of course, this isn't something you can assess with a leetcode interview.

I don't hate interviews where the candidate is asked to write some code. I think writing code is a valid form of assessment because I've encountered enough jokers over the years who couldn't program if their life depended upon it - yet still manage to carry a job title like "software developer" - that I need some way of weeding them out of our hiring process. One reason for this is that I simply don't have gobs of spare cash to pay large salaries to people who are fundamentally incapable of doing the job they're asked to do.

Note though that asking them to write code does not equate to leetcode. We'll generally give people access to an IDE containing a template project and common tooling they would use on a day to day basis in the job. We also select problems that have some relation to our systems rather than asking hardcore questions about algorithms and data structures: we give them internet access so they can look that stuff up if they need it to help them (just like the rest of us do in our day jobs).

Cynically, a lot of interviewing I've seen over the years seems to be about the interviewer trying to appear to be the cleverest person in the room, and I think leetcode often falls into this category. I find this perverse and unhelpful but I guess these interviewers are just insecure, angry people.

I ask candidates to write code, but I tell my interviewers that the point is not completing the task but rather the conversation around it.

If they can’t write code at all, obviously it’s a hard pass because we’d just be setting them up for failure. But, if they’re maybe not the strongest dev ever but ask good questions and provide good observations I will be fairly likely to hire anyways. Honestly having people with room to grow just gives the rest of the team opportunities to teach… which in turn helps them to grow too.

I also tell my interviewers that we absolutely must start with the assumption that we will hire the candidate, and passing on them requires objective concerns. I really work hard to relate to my team that we are not so special that we should only hire the absolute best of all experts. What we do is not rocket science, and we don’t need rocket scientists. We need collaborative, intelligent team members to help /us/ grow.

All of this is to try to limit the impact of ego on the hiring process. It’s not about the candidate proving that they’re good enough to work with us, it’s about us being good enough to be worth working with. The candidate should meet the bar of helping us to make that statement true.

To be clear, dev roles can be difficult, demanding jobs. I’m not diminishing that, just reigning it back into the realm of reality. The industry treats hiring like people are going to die if we make mistakes, and unless that is actually true maybe it’s worth asking if what we’re doing is actually reflective of the job requirements.

> To be clear, dev roles can be difficult, demanding jobs. I’m not diminishing that, just reigning it back into the realm of reality. The industry treats hiring like people are going to die if we make mistakes, and unless that is actually true maybe it’s worth asking if what we’re doing is actually reflective of the job requirements.

This I agree with.

I'd also say that our worst mistakes have generally not been technical, though I don't want to go into the specifics here.

It matters more that you get the right person with the right skills for more senior hires, because they can have an outsized impact on business and delivery outcomes. I've seen the wrong person running a team lead to 6 months of rework when they left, as an example.

> Note though that asking them to write code does not equate to leetcode. We'll generally give people access to an IDE containing a template project and common tooling they would use on a day to day basis in the job. We also select problems that have some relation to our systems rather than asking hardcore questions about algorithms and data structures: we give them internet access so they can look that stuff up if they need it to help them (just like the rest of us do in our day jobs).

This is the best way I've found to assess if the interviewee can actually do the job. If you're trying out to be a violinist in an orchestra, they'll give you some sheet music and ask you to play your instrument. Leetcode would be like sitting the prospective violinist down at a piano, then asking them how to resolve exotic chord progressions and grilling them on obscure music theory. Yeah, any great violinist who studied at a decent music academy probably learned that stuff and still remembers it, but it's still a stupid test for the job you're asking them to do.

> Cynically, a lot of interviewing I've seen over the years seems to be about the interviewer trying to appear to be the cleverest person in the room

I'm even more cynical. People who were hazed to get where they are tend to want the new people to get hazed too. To them, it's only fair. And make no mistake, leetcode is hazing: it's not a test of ability, it's a test of how hard you're willing to grind for the possibility of giving a company your labor.

I think it can make sense in only one instance: for entry-level positions, if the person is trying to break into the software industry and they don't have a relevant degree. These people simply won't be able to do the same stuff that someone who's had a relevant position (or even just an internship) would. Navigating an unfamiliar IDE alone might kill them. But if they've done a bootcamp and they can crush some hard puzzles, they're probably competent enough to train up quickly, and it they're eager and they seem like they'd be great to work with, it can absolutely make sense to bring them onboard.

For everyone else, I just want them to show me what they've done in the past, and I want to test them on a problemset similar to what they'd actually be doing on the job just to make sure they're not full of shit. This is usually much less stressful for everyone involved, and provides a much more accurate signal.

The reason Google doesn't do this is likely for HR reasons: for a given position, they have to try to give the exact same interview questions to each candidate, as steering individual interviews in different directions on a whim can open them up to discrimination lawsuits. For example: women applicants might have less technical backgrounds on average, be given leetcode problems, and then the company could rightfully be accused of giving a typical woman a harder set of questions than men.

But there's opportunity there. While companies of Google's size are forced to formalize and lock down their interviews pretty hard out of an abundance of caution, smaller companies have a lot more freedom to tailor interviews to the individual candidate to figure out if they're right for the job. Great hiring managers figured out years ago that you can build a stellar team by snatching up the really talented folks who either refuse to play the leetcode game or happen to have a life outside of work. They're easy to identify if you're looking for them.

> I think it can make sense in only one instance: for entry-level positions, if the person is trying to break into the software industry and they don't have a relevant degree.

I'm not even sure I think it's necessary here.

We have a guy working for us who's a former nurse, and was still a nurse when he interviewed with us. He'd started programming on the side as a hobby, and our job ads were pretty explicit that we didn't really care about your background as long as you could program and were a reasonable human being, so he applied.

We still have a very short (20 - 30 minute) pre-screener interview before our main interview (90 - 120 minutes). That pre-screener has three objectives:

1. Figure out if the candidate is really interested in the job. We're not expecting people to turn tricks to show their enthusiasm or anything ridiculous like that, but we've had enough candidates that give off a "totally can't be arsed" vibe that we're basically just looking to screen those out.

2. Quick read on what the candidate is like as a human being.

3. Answer the question: can they write any code at all?

For (3) we have a whole raft of simple problems that require the candidate to write half a dozen or so lines of code. We'll generally explain the problem, given them an empty method or function and ask them to fill it in.

One example is write a function to reverse a string: this one's interesting because, in C# as an example, there's a functional solution, and an imperative solution (of course, there are several variations). The functional solution is enough to understand whether they at least grasp the basics of functional programming. The imperative solution will tell you whether they know how to use basic control flow and iteration, understand arrays (a string is really a wrapped array of characters), know about mutability and immutability, etc. Most of our code is OO/imperative, with some use of a more functional style where appropriate, so we generally encourage in the direction of imperative.

All our pre-screener problems are kind of like this: basic numeric or string manipulations, because our systems contain a lot of numeric and string manipulation. Definitely not leetcode: most of these problems don't require any knowledge of data structures more advanced than an array. It is literally: can this person code in any language similar to what we use here at all?

Our former nurse nailed the pre-screener first try - didn't even get caught out by any off by one errors. Whereas I've seen plenty of "senior developers" completely fail at these very basic tasks.

Our full interview involves a more in-depth pair programming exercise. Again, our former nurse nailed it, where plenty of more experienced candidates have made a right hash of it.

We took on our former nurse with both him and us realising that he'd have loads to learn, but four years later he's still with us and doing incredibly well.

This is obviously anecdata, but it does show that you don't necessarily need leetcode to assess someone entirely new to software development.

So what'd you come up with?

I answered this in another comment before I saw this, feel free to respond to it if you want to chat about it: https://news.ycombinator.com/item?id=31453571

> now is a fantastic time for the tech industry to adopt change because your talent recruiters are probably struggling to find and retain new developers

Unfortunately, this will likely change much sooner and more rapidly then most of us expect. The music is stopping and chairs are about to be removed. It was great while it lasted, but all good things come to an end.

I’m not sure I agree, but I’m positive this isn’t a barrier to adoption right now. Recruiters are really looking for an edge to provide differentiation, and “friendlier, faster process” is a big one.

What has changed in the past 20 years? Because this sounds like the same shit I’ve heard since entering the industry. And it isn’t like this topic is new at all.

Sure. Someday. Same thing has been said since the 90s

After working though the dotcom bust and the subprime fiasco it seems a bit dramatic

although I'm also not beyond my means and have some savings this time (didn't last time and it got hairy)

in general i worry more about other people in much worse situations that I'm unable to help

And it's happened a couple of times since the 90s.

Yeah, I've worked in tech 6 years now and never had to do Leetcode to get by in interviews. That being said, I never interviewed at FAANG. But many teams set a bar easier to pass than leetcode that still ensures good engineering skills

> I’ve spent the last year or so reinventing the hiring process at my tech company to expressly avoid algorithmic puzzles and leetcode nonsense, and I was able to do this because I patently refused to accept the status quo.

I think companies that break out of the leetcode habit are going to do well. There's a lot of great talent out there that's being passed over by these tests.

If the job is to solve leetcode problems, by all means, test the candidates for that. If the job is to solve real life problems, there's almost certainly a better measure.

I will never judge someone based on that kind of problem. I believe the data that results is just bad.

Edit: I should add that leetcode is useful for developing programming and problem-solving skill. I've done tons of problems, myself, and have fun solving them... and learn from them. So I do recommend it for a challenge. But not for interviews.

Strong agree with all of this.

Ideally, interview questions should be directly related to the domain of the position. Show the candidate what they will actually be doing if they accept an offer.

The whole process should be a two way conversation.

> I think companies that break out of the leetcode habit are going to do well. > There's a lot of great talent out there that's being passed over by these tests.

Agreed. And there's a lot of great talent that doesn't even want to try with some of these companies solely due to the hostile interview process.

I recently took a year off, and started interviewing in March. I spent a fair amount of time in fear of interviewing, doing LeetCode pushups and feeling miserable about my performance, and wondering if I could swing retirement rather than go through another fucking hazing ritual. Excuse my language.

I resolved up front not to submit to any kind of take-home test, proctoring software, or algorithmic nonsense unrelated to the actual job of shipping software. A polite "No thank you" was what I planned. But the plan was thwarted!

I was pleasantly surprised by the technical interviews I actually got. They were mostly nicely constrained problems that were real-world and not algorithmically nasty. One was a little unintended "collaboration" in the form of helping a senior dev debug their own "what is wrong with this code?" exercise (it probably went smoother for the next candidate they interviewed). In short, it was actually kind of fun.

I started a new dream job this week. At 61 this is no longer easy, but the company is enlightened enough to support me while I get up to speed, and it's fun to help mentor the folks just getting into the industry.

There are decent companies out there. Hopefully the terrible ones will start getting a clue.

Agreed. As a hiring manager, I’ve also explicitly, purposely come up with coding questions that reflect normal work: call APIs & issues, sync data issues, model data for usable systems.

The hires, then, focus on the right customer problems and don’t spin on creating random, useless code.

Everyone from mgmt to ICs, technical and non-technical, are happier.

Only on the internet, that someone working for a cost-center division, building an piece of internal software used by 20 users, gets to lecture how a $2 Trillion Dollar, building multiple Billion real-world user products, generating > $500,000 per engineer profit should run their hiring process

That’s making a lot of assumptions about who I am and what I do based on nothing.

FWIW, happy you're doing this! A better process would make so many peoples' lives better.

The ONLY people who should "get used to 'em" are new/recent grads looking for a junior-ish IC job. For them, it's just a fact of life: they had to learn history & biology to get their CS degree; they have to learn leetcode to get a job.

Interviewers should make a better process, as you're doing.

Honestly, I think I would encourage junior devs to shop around before just accepting the leet code life. Unless they’re in dire need of income—in which case, do what you need to do—the kind of company willing to treat you like a game show contestant may not provide the best culture for learning and growth.

If you can avoid the BS you should definitely do so.

The worst part is it's biased towards those who already have the time / security to devote to it, aka those from the upper class. Vicious cycle.

That bias is generally true for any education-based employment that requires a significant upfront investment.

> My advice? Start memorizing the riddles.

I don't have a strong opinion either way, I got with the Leetcode grind program for my current position, but I really wonder about this: is it really possible to memorize these questions? Last I checked Leetcode has over 2000 questions, anyone who can memorize the solutions to all those is some kind of genius savant and should be hired anyway. Or is memorizing meant in a different context here?

> anyone who can memorize the solutions to all those is some kind of genius savant and should be hired anyway

But that's the problem. Why should they be hired?

The actual job will not consist of regurgitating those memorized solutions.

I'm impressed by someone who can memorize 2000+ solutions, same as I'm impressed by the acrobats at Cirque du Soleil, but I don't want to hire from either group for a software engineering job because that's not what the job is about.

Memorizing is meant in a different context.

Ultimately the problems boil down into a few "types". So you are memorizing the types.

https://dev.to/fahimulhaq/14-patterns-to-ace-any-coding-inte... https://neetcode.io/

As a sidenote: this holds true for other types of arbitrary-interview-riddles. There's only 3-5 "frameworks" you need to memorize/apply for consulting case interviews. Finance probability problems typically test one of ~a dozen prob/stat formulae + ability to multiply 3-digit numbers in your head.

After all, it has to be manageable for the interviewers to make sure all the questions are roughly equivalent in difficulty.

I have used hackerrank/leetcode previously just sporadically to learn a new programming language. I used it for the first time to help me get another job earlier in the year.

However, I have continued to solve 1 problem a night because what I realised is after 15+ years in the industry, I don't have a good grasp of some concepts anymore.

I'm slowly getting better at identify types of problems and apply what could be the most efficient data structure/algorithm in solving the problem. Once I solve the problem I go have a look at the solutions to see a more efficient way of solving it and try to store it away in my memory banks for another day.

The thing I don't like is when interviewer asks follow ups such as "Can you do the same solution but using O(1) space complexity". Unless the job has a restriction on running on limited hardware resources. I feel like it's unjustified asking such follow up questions because most of the time that is a very specific solution for the problem - or maybe I'm just not good enough to come up with such a solution yet.

> They're biased, arbitrary, and often quite silly. And they've persisted for a half century.

Half a century? Absolutely not. It's a recent phenomenon (in software jobs).

All through the 90s and 00s it wasn't like this.

For what it’s worth, it was like this in my interviews at Microsoft in the late 80s.

The point is that leetcode is an instance of the class interview_riddles; the class has persisted for a half century.

One big issue with these problems is that they are timed. So if for whatever reason you get stuck, stressed, distracted and take an extra 10m to reverse a linked list you're filtered out.

If a trading job asks you a probability question they might be looking for you to be able to understand risk-neutrality. This is an important distinction because risk neutral pricing is a very important concept i.e. don't just try and memorize it.

> you can't learn leetcode without learning to program

A lot of people learn the jargon and sound like they know how to program, but don't. Failure to filter these out can be very expensive for a company. They have a strong incentive to ask for a programming demonstration to filter them out.

Realize that in a lot of companies most people are mediocre at best; nowhere near "leet." It's worth studying psychology to understand that many of the swords held over your head in interviews/scouting are plastic and held by insecure people.

Doing so takes the pressure off and helps you to realize that there's a ton of opportunity out there if you want to get to that level.

The truth, though, is to build stuff, practice, and don't stop. I've circumvented most of the gatekeeper stuff because I intentionally hustled freelance/contract work early on and got to a level where I had a portfolio of high-quality work (i.e., leave money on the table short-term to make big money easily long-term). Now if companies turn me down, they look like fools.

Always worth asking: "how do I circumvent the hoops?"

Also (via Derek Sivers):

> “The standard pace is for chumps.” - Kimo Williams

Feel free to email if you want an opportunity to practice/gain experience: ryan.glover@cheatcode.co.

I find interviewing skills are more important than job skills in terms of income.

Trying to get a 20% raise by doing a good job I've found to be a protracted difficult task, but a 50% raise by interviewing? Much easier.

You do need some job skills, but in my experience being fired for not being good enough is rare, and can take a lot of time - during which you're getting paid.

Another thing I've found is I pick up the most exposure to new ideas in that first 12 months in a job.

These two things together means being able to get a new job easily is very useful.

But getting a job is different from doing a job, don't expect the two activities to have much in common. It could be better, but hey 3-4 months of evenings spent programming to get a big step up in the job market is a pretty good deal if you enjoy programming :)

(Personally I've found leetcode useful at becoming a better programmer, though I didn't approach it as memorizing riddles.)

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.

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

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

I wouldn’t want to be on call for Homebrew. In the author’s words “It doesn’t do dependency management properly. It doesn’t handle edge case behavior well. It isn’t well tested.”

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

I'm curious if you would share the design question. I have seen these very contrived "study guides" with questions like "how to design drop box", "how to design FB newsfeed, etc" and they all seem to just be lists for rote memorization. Was that what your experience was? You didn't satisfy the check list that the interview was looking for?

They wanted an answer you would get from one of those guides, not a discussion on technical design

This is my biggest fear that I have to study for the foreseeable future. Nothing you did matter if you can't solve a puzzle or give cut out answer.

Remember it's probabilistic, not certain. There are still companies out there where you'll get hired with just a casual 30 minute conversation about your past work and how it should help you deliver value for this new work, maybe even over lunch. Different companies, even different teams or interviewers within companies, will have their own criteria with their own quirks and sometimes mental games. Even with perfect preparation on the technical side, you can easily fail a process because you failed some mind game, and those you can't really grind for. In other words, accept that no matter how much you prepare there's still a significant chance at failure, and use that to forgive yourself for not spending all your time trying to be in a constant state of readiness and trying to minimize a small portion of that chance, and maybe chill out some.

This is true, but generally speaking the former pays better, more mature and looks better on your resume. But oh wait, yeah whats on your resume doenst matter XD

Thanks for your kind words though, I have to fail more... And be okay w it

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.

Do they pay comparable money?

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.

> 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.

Would you suggest someone with 10-20 years of experience to practice and learn how to solve leetcode problems? Or just expect them to be able to solve them without any prior exposure?

And if you would suggest they learn them what would that person be gaining that they lacked before?

the fact that SV companies are getting 50,000 applicants while other more or less critical sectors struggle to field any talent at all points to a (the?) deeper problem at the root of the leetcode fiasco

Let's unpack that for a second.

"Skill" is probably one of the least valuable metrics of a given hire's performance over time for an employer.

Yes, being able to effectively select for the people most likely to develop a competitive non-extant algorithm is an important metric for certain employers that skill tests will assist with. However, it's as niche to general society as academic studies are.

This is not to say that it's unworthy of practice or attention. In some cases, it's absolutely justified.

What I'm advocating for, however, is skewed towards the broad middle of employment cases - people who are competent, able to solve most day-to-day problems, and not adverse to new practices.

In most cases, people aren't looking to advance the knowledge of a particular field of study. They're just looking to solve problems for their day job while earning appropriate compensation. The employer gets a satisfactory advancement of their capabilities, and the employee gets to enjoy a quality of life they're used to.

The "broad middle" is much messier, but also easier to filter for. As a hiring manager, I would look for people that are A) not obvious assholes, and B) likely to improve my team's performance in some measurable way.

In other words... Company X, which lives and dies by having the absolute latest technology available to humanity, may well need to use code interviews to even establish a baseline performance metric. Company Y, which is just interested in appreciably improving its market share versus a wide cohort, is probably better served by "softer" hiring metrics.

One possible a consideration would be that "softer" hiring metrics breed mediocrity and complacency in the long run. Should the company in question to pivot into a more, let's say, intellectually rigorous direction, how should they handle the predicament they've put themselves in without the end result being bankruptcy, mass layoffs, bad PR, or some combination of the three?

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...

> 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.

Older, non-tech company with a tech department employee here. And uh, yeah, we do code exercises with candidates. Nothing ridiculous, we just put a basic, relatively straightforward problem in front of the candidate (two notches above fizzbuzz) and ask them to solve it, or at least talk us through how they might solve it.

We've had a problem with candidates who seem impressive on paper and during the first phase of the interview, and then can't solve this exercise without being seen to glance at Google or SO results on camera -- or worse, being caught copying a worked example directly off the web!

There are plenty of people who can talk a good talk about their technology experience but can't write a line of code to save their lives! Entire majors at universities are devoted to this; when I was in college, all the people who couldn't cut it in CS because math, fell back to MIS -- Management Information Systems -- whose courses had big colorful textbooks I call "Richard Scarry books" because they're packed full of busy-looking illustrations. MIS helps you learn about technology in a business context, but prepares you very little for actually doing technology and building the systems with it. The coding exercise helps screen out the people who can't actually do what's needed of a developer.

I guess people reach for leetcode because it's easy, but it misses the point of the coding exercise. The point is to screen out people who can't program at all, not to select for the programming equivalent of NES speedrunners. So it needs to be set at a very low bar and administered by forgiving interviewers.

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 in similar situation… it’s been two years since I graduated from college and I have done literally less than 10 leetcode problems so far… but I do spend a lot of time on my hobby projects and it served me right for getting jobs as a mobile engineer in some good startups.

I was involved in the dance business for a while. The first thing they teach you is steps, then patterns, then frame, then arms, then posture, then fingers (yes, finger styling is important!) and on and on. Do you know what ballroom champions do? They regularly hire a coach to go over, again and again and again and again, how to take a step.

So yeah, you can be a competent dancer without this emphasis. But you ain't gonna be a champion without a very solid foundation on your feet, as it all grows out of that.

I've advised college graduates to learn the leetcode stuff. It's foundational for being a champion programmer, and besides, with the $$$$$ that Google pays, it's a very high return on investment of your effort.

It's also easier to just learn it than expend all the effort fighting it. It isn't that hard, either. Just make it your bathroom reader, one puzzle at a time.

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.

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.

> 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.

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

Go for jobs or companies that are not popular and are struggling to find talent. Try to get the highest paying one of those (my subjective experience is that your colleagues will be more professional). A job is what you make of it. If you take a role at a company that puts you through a tough leetcode test you may find yourself editing config files all day because you are surrounded by superstars and there is only so much interesting work to go around.

My first job was at a startup that couldn’t attract the talent that the bigger Corps could. They paid more than the big Corps and I’m pretty sure I learnt a lot more than if I hadn’t taken the risk.

Another approach is to use Meetup events in your chosen tech field to shortcut the hiring process. You chat with someone who works somewhere, they speak to their manager and get you an interview. People that know each other personally are unlikely to put the other person through a leetcode test. It helps to have one or two projects on GitHub that someone can browse through to make sure you are legit. They don’t have to be popular or useful. Just some code that is not terrible.

You found a startup that paid better than big tech? Mind sharing who they were?

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.

Thanks! I've never knew there's good curated lists, this is super helpful

I hate how the industry has become, but I chose to be compliant. I recently substituted all my free time playing video games to leetcode-ing, b/c it's the only way to become hire-able at any given time. I'll most likely do this for the next 10 years and then become a manager of some sort so I don't have to do this for lifetime.

Did I become unhappy b/c of this change? It's arguable. I'm sad that I can't play video games anymore but I'm happy to know that I'm interview ready at any given time, and can exercise my will to attempt to get higher salary jobs at any given time. So it's a give and take.

We don't have to, but we'll have less pool of jobs to choose from.

As for solving leetcode problems; it's just like a riddle. You become better at it the more you do, b/c you start to see a pattern. However, if you choke or don't get a question you solved before (or you solved before but can't remember) , better luck next time.

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...

What kind of pre-screening would you combine with the on site programming challenge? To me this seems like much more of a time commitment and much more biased against certain types of candidates than a similarly scoped take home test.

I've done a number of on site interviews in my career and they were typically not in my home city or even home country. They often involved flights and hotels plus time off work beyond the interview day for travel time. As a single guy at the time a small number of these was manageable but it seems like much more of an obstacle than a take home test for anyone with family or childcare commitments.

You mentioned in your first article having interviewed with 30 companies over 4 months. That would obviously be impossible for anyone currently employed if they all involved a full day on site. Most full day on site leet code style interviews involve some pre screening so that only promising candidates go through the full on site.

Would you pre screen with an online leet code style problem?

It looks like these articles were written pre covid? How would you adapt the process to a more remote friendly world? Is there a variation of this that could be done remotely that wouldn't look a lot like a take home test with a tighter deadline?

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.

This is the thing. I've been solving abstract problems for a living well over 20 years by now. Can I have some time off?

I know I can solve many leetcode problems (fizzbuzz? roman to arab numerals?) given some time, but I hate doing it.

As software developers, we constantly have to proof ourselves. At dailies, in leetcode.

This is fun when you are 25, much less so when you are 50.

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.

> 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.

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.

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

You don't need to completely avoid SV-style companies as some people recommend. Check out: https://github.com/poteto/hiring-without-whiteboards.

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.'

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.

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 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.

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 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.

I don't buy this at all. Orthogonal things are orthogonal. I work with developers who probably have no idea what a red–black tree is but I'd trust them to advise on how to structure a complex project based on user requirements. I'd rather they spent their time getting better at the latter and I don't see how getting good at puzzles is especially helpful in doing that.

Programming in the large is usually about managing complexity over time. It has more akin to designing a large factory than it is to understanding how a pocket watch works. There's a huge human factor as well - complexity arises where people meet code and understanding how to keep that complexity in check is the key to being a good programmer.

you learn math by doing lots of problems, the same is true for leetcode. sure there are patterns and tricks to it, but you have to do enough problems to apply them "intuitively". it's one thing to know you need two pointers to solve a problem, but a different thing to actually code up the solution...

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.

My advice is to just vote with your feet and not work for companies that leetcode interview.

You're premise assumes someone who has the safety net to spend time on non-compensated work (which is what leetcode is and is really unfair to poor people, but that's a different discussion). Assuming your premise holds:

- Work on an open source project and contribute to it.

- Work on your own project and publish it

- Get an IT job (which only requires Windows and Mac skills but not programming) and then volunteer for any programming project that comes up (automating the ticket system, automating deployments of equipment, automating basically anything that's manual).

- Find a non-profit that needs a new web app or phone app and volunteer your time building it for them.

Basically, take the time you would be doing leetcode and actually build something public, so that you can take that to an employer and say, "hey I built this".

I'm someone with a lot of YOE but couldn't reverse a linked list when asked in an interview (why would you want to do that? I remember thinking). After a few years on competitions and LC, I'm decent enough to usually pass LC style interviews. I think I actually learned a lot by doing this, and it has improved my coding skill.

Ahhh! Now I know what this style of interview is called! Thanks for explaining what the heck was going on in some of the interviews I went through in the last few years. Since 2005 spent a long time at 2 companies and then went self-employed 6 years ago. When getting back into full-time employment around 2019, I had a couple really weird interviews where they gave me some intense timed puzzle solving "games", and then brushed me off. I was so confused because it had no relevance to any of the web development work I had done, ever, in my years of career experience, and it was super stressful.

I thought these hiring managers were insane. I get it now. I think code tests are fine, but timed puzzles just don't tell anyone much about any dev's ability to assemble features out of higher-level tools.

I’ve been in tech 22 years. For the first 10 years it was leetcode gymnastics to prove I had the chops. All these did was to serve as a basic filter for weeding out people who didn’t know what they were talking about. The actual leetcode exercises didn’t do much to prepare you for the actual job, it was more that the existing team wanted to be sure you were nerdy enough.

The last 12 years in tech I’ve actively fought back against leetcode and homework coding interviews. Unless you’re going to pay me for my time, I’m not going to work for free.

Someone in a thread said “show them the actual day to day during the interview” is spot on. If you are interviewing and they aren’t doing this, move on. If you are interviewing for your team and aren’t doing this, start.

I encourage everyone to state up front that they refuse such interviews. I have the following disclaimer in my LinkedIn intro:

> I have a personal policy against any type of live coding or online coding tests during interviews and I don't enjoy or engage in any form of competitive programming. Otherwise, I am happy to work offline on coding assignments with reasonable goals and deadlines and to have in-depth technical discussions about software architecture and design as well as relevant technologies.

Yeah, I’m aware that I can easily get away with it given my current CV, but some companies do care about their candidates and adjust their process as needed. As long as we bend backwards and tolerate any abusive practice, nothing will change.

There are more companies noticing this now and have stopped asking these questions. For example, we at Neuralink[1] only give out practical programming challenges. If are you good at building practical systems, you should be able to ace our coding interviews without any preparation. No leetcode and no whiteboarding. In fact, I prefer to hire those who doesn't waste time practicing leetcode.

Over the past couple years, I have interviewed at a handful of other startups who also have similar coding interview philosophies.

[1]: https://neuralink.com/careers/

Hey! I run a job board at NoWhiteboard.org for companies not using whiteboard/LeetCode interviews in their interview process. I can add Neuralink’s roles to the website for free!

If you’re open to it, could you share the high level overview of the interview process?

How much do you all pay tho?

I don't get the hate, Leetcode is great. Best signal for your buck, fun, and the most equitable and fair process. Like SATs, LSATs, etc. Just git gud

Also, for system design interviews, they should use stuff like Factorio and Zachtronics games

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?

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?

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?

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.

I don't get the modern (?) obsession with having the latest tech in your resume.

Knowing how to solve problems for someone willing to pay you a lot for it seems to trump knowing how to solve problems in a specific way. I've improved my salary more by putting work towards fixing things for existing code bases than I have by building brand new things on brand new technology.

With that said... having been in the position of the hot-headed junior engineer full of ideas, I don't think that position's without merit either. The trick is to balance new ideas for the employer, personal knowledge growth, improved performance for the employer, and making the right kind of mistakes.

In that latter bit, I don't think _anyone_ has figured it out, yet. Not in a way that's easily repeatable, anyway.

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)

> every company's interview process has become like Google's

although the leetcode hiring model is too often cargo culted by orgs trying to emulate faang this is not representative of the industry at large. if it seems true you may be considering too narrow a slice of it

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

consider applying to roles that don't use the leetcode hiring model

personal anecdote:

first job out of undergrad, small shop whose software you probably haven't heard of but have almost definitely interacted with if you live in the US: phone screening, remote technical session with 2 hours (own time) to write 3 functions, on-site interview given a laptop, an hour, and instructions to write a toy API then asked a few questions about solution and general concepts

second job, cold emailed a professor asking about openings for a programmer/research software developer, asked to clone and build a project repo and sketch a simple (<1 hour) feature

third job, also research software, online application, 1 hour video interview, entirely qualitative, no coding component, having work from the previous role on Github likely obviated the need for a technical session

I'm not a great leetcoder, I reason fairly slowly, I struggle under time pressure and observation

if you're like me, play to your strengths, you're still competent and you can find work

Leetcode problems aren't that difficult and if you can't solve them, your coding skills are weak. Not surprising since you are fresh out of college and still have massive amounts of knowledge to learn.

> 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.

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.

> Over the past few years I've met people who are really good programmers when it comes to putting together a full back end system , creating a very nice front end or creating any kind of app for that matter. Many of these people are fresh out of college and the "industry" puts them through leetcode/hackerrank style rounds that are needlessly hard

I'll get downvoted for this but... There's no such thing as "leetcode/hackerrank" interviews. It's simply using questions that will be familiar to any candidate who took a serious algorithm and data structure class [0]. Any serious engineering/computer science degree should have at least one. If you can figure out algorithms, you should be ok figuring out how we built our back-end in whatever language, as the fundamentals (the underlying algorithms and data structures) will be evident.

If you're just hiring programmers, don't expect them to be familiar with those concepts. But any serious engineer will and should.

[0] https://ocw.mit.edu/courses/6-006-introduction-to-algorithms...

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.

The problem I see over and over is that the new "job relevant" interview formats are always way easier than the old interviews. It is not even close, maybe as high as by a factor of 10.

People argue that we should make interviews more relevant to the actual work you do on the job. But in practice it looks a lot like we're really just trying to pass more people. Half the new "practical" questions are literally like make an http call, iterate through the array of objects and do some basic data transformation using map and filter. Or something. The actual thinking part is usually about leetcode easy, maybe low medium.

Seriously, any time I see a "modern" non-leetcode interview I basically start rehearsing salary negotiations in my head. I suppose you could argue that's all that's needed to do 90% of modern software development, and so the new questions are measuring the right thing... but then doesn't that just indicate that modern software development is a joke and the job is not actually hiring developers to do anything difficult?

> but then doesn't that just indicate that modern software development is a joke and the job is not actually hiring developers to do anything difficult?

You just said the quiet part out loud. Most of what we're doing is just slinging CRUD code. Some of the worst developers to work with are the ones who think they're God's gift to programming, because they're the ones who twist the codebase into knots in pursuit of cleverness points. Guess which type leetcode filters for.

Yes, this is true and a real problem. The empire-building types.

My personal favorite non-leetcode interview format is having the candidate spend 2-4 hours building a toy version of your product from scratch. It's hard, relevant, and filters for straightforward code (or you won't finish in time).

Software has not improved since LC took off, and in fact has gotten worse in many ways. LC is just the newest hiring cargo cult (a spot previously occupied by transcripts, internships, and 'open-source contributions'). The biggest difference is that, unlike previous hiring voodoo, LC has already been gamed before it entered the consciousness of HR.

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

> 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.

If the bigcos had any interest in this, they'd have created such a cert/license. At the very least, they wouldn't make candidates who'd previously passed their interviews, and perhaps those of similar companies, multiple times, do it again.

Since they haven't created a cert, and they do make people re-test, they're clearly doing it for purposes that aren't served by those actions.

For one thing, I don't think they'd be happy about any change that makes it easier to leave. Imagine what'd happen to comp at these companies if you didn't have to do yet another goddamn leetcode gauntlet every time you switched.

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

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.

Software engineering as a profession is relatively young. I'd be very happy if we eventually end up with a license that can be revoked. Cause a large data breach? The board investigates and revokes your license, much like if you were a civil engineer who caused a bridge to collapse due to negligence.

There's tremendous potential in this space for a startup, but nothing seems to have stuck, which demonstrates the difficulty of getting companies to trust a third party. They'd almost always rather trust their hiring process flawed though it is.

I think your educational merits should carry some weight. Seems to almost ignore this is industry standard.

> The people who do manage to crack these rounds are not necessarily good at programming either because the time they spent doing competitive programming stuff should have been spent learning to build actual things.

I disagree with this, with a disclaimer that I enjoyed competitive programming since before I knew of leetcode's existence.

That said, salaries for SWEs are increasingly becoming bimodal. You can have a fulfilling career without having to do Leetcode-style interviews. Or you can have a go at grinding Leetcode for a few weeks and have a higher salary for the rest od your career - a much greater RoI than a 4-year degree, IMO. Framed differently: would you grind leetcode for $100,000?[1] How about for $100,000 every year going forward?

There are no wrong answers, for some, the answer is "no", and they have my respect.

1. Assuming you're in the US and aiming for FAANG/FAANG-adjucent employers; adjust this figure for your circumstances.

This is an extremely interesting subject. I understand the "hate" for leet code, or simply live coding exercises in general, though so far the majority of "hate" I've heard for this comes from the candidates who haven't had to do a ton of hiring. Or they've had the ability to hire slower and take their time evaluating fewer people over a longer period of time without a ton of inbound pressure. Or they've set some arbitrary bar for inbounds that many people also disagree with (such as only talking to people from top ranked CS schools, or only candidates from well known companies, basically some other metric they can use for themselves as some abstraction on competence).

I do believe having someone do paid work / pair with the team for a few days is likely the most valuable, and I do actually think the best people are ok with this because they use it as a way to evaluate a company. But this strategy simply isn't scalable and can take a lot of company man hours without extremely good up front vetting.

I've found coding exercises, of some sort, they don't have to be leet-code-esque, to be one of the very few "put your money where your mouth is" activities to perform. The amount of folks that can speak forever and in-depth about what they've worked on, and then will completely fail at writing for-loops in their favorite language has astonished me. I don't believe live coding exercises have to be adversarial, I believe candidates should be offered a more accessible often if it's too high pressure for them, but I don't believe coding exercises are inherently bad or evil. I do believe there are bad or evil exercises that can be chosen.

A practical coding exercise that requires no more than 8-10 lines of code done live has generally served well in my experience for assessing candidates. I've seen similar pure failure rates from practical exercises as I have from "perform a dfs" style exercises, in the above 60% range.

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'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.

> I think many people have moved to macports.

I did the opposite. Macports reliably broke itself every three or four months under ordinary use, and Homebrew's package selection was much more useful to me, so I switched. I also think the Homebrew CLI is above-average, ergonomics-wise.

Granted, that was about 10 years ago, but exchanges for/against brew and macports looked awfully similar then. But maybe it got better, I dunno.

They still both don't work as well as linux packaging.

I prefer it to all of those that I've used, which is a lot of them—for the specific use case of managing the tools I use on my workstation.

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.

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

Google is more than welcome to come up with something better...

My experience might be biased, but my solution was not working for American companies, specially big I.T. ones. I've worked in Brazil and Europe and have very rarely even been proposed the sort of grinding bullshit interview that seems common on the US industry.

Obviously, that's not exactly an easy route, but anyway.

Leetcode should be about practice, not memorizing. Know the basics. Breadth first and depth first. Know different data structures; binary tree, arrays, linked lists, dictionaries, hashes, sets. Know your sorts. Have an understanding of big o. Just knowing the basics will get you most of the way there.

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

Never dismiss the possibility that your interviewer is bad.

We don't challenge this enough in the industry.

If your interviewer was interviewing a candidate who was a prolific software author who published works that had mass adoption, 9 out of 10 of them would be nonplussed by it, and it's so stupid.

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

> when I'd imagine the skills for creating a programming language have limited overlap with Leetcoding.

FWIW golfing languages are a thing, where a language is designed specifically for code golfing type problems and usually optimizing for a tiny core language and small source files.

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.

6000 stars here. It doesn’t matter to be honest

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).

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.

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.

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.

>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.

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.

I wouldn't be surprised if you were right.

It's pretty shameful how macho people are being about leetcode.

Yeah, leetcode is "fun" when you're 23 and don't know better. It probably won't be at 33 when you're tired of all the bullshit.

Start building things. Volunteer for open source projects. Make some pet projects.

Go to meet-ups, join mailing lists/discords, network. Get hired for minimum wage on very small projects (but make sure somebody pays the taxes). Add them to your resume. Get contracting gigs (contractors rarely have to pass the scrutiny full-timers do). Join a startup.

FAANG may not hire you on these alone, but I would, and so would many others. We want to see that you can build something, and we want to see you have made lots of mistakes and learned lots of lessons. After you have proven yourself, you don't need to do leetcode. Then you just have to worry about the rest of the interview...

I've never known people who have contacts/good experience and can deliver to "have to grind leetcode". This may be the case for new entrants or areas with huge amounts of competition. I've known several people to get jobs at Microsoft and Google due to their educational background (PHD projects), industry knowledge and conference presence, and general competence. I'd be very surprised if any of these people was working through these lists of questions and I've never directly used these tests when I've been interviewing, although I have used some of the concepts of course.

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.

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.

I feel like any pleb can be trained to do my job. What's difficult to train and find is a problem solving mentality, a let me try first before asking approach.

most common day to day tasks have solutions or best practices. So you're looking for someone with the the foundation skillset and right mentality to do the job.

I think leetcode is comes from the ivy league elitism culture of faang. also a lot of nerds are deeply insecure and like to show what they know or tell others what they don't know smugly. just look at the "show hn" posts and the type of comments your get there eviscerating some noobs hobby project.

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.

Interview at startups like Ramp — we don't care about leetcoding at all. There's many others.

https://ramp.com/careers or hit me up nico@ramp.com

I know my personal experience may not apply here, as I've been in the industry for quite some time now, but this is my take: reject code assessments.

There is nothing to be gained from them. Candidates waste time trying to solve problems that may never face in a real work environment. Companies end up hiring people who has prepared for the interview, not for the job. Even worse, some companies seem to have standardised the same useless process across many levels, and end up asking senior candidates to e.g. reverse a binary tree.

Personally, never in ten years has a code assessment helped me choose the right candidate.

I feel your advice is more directed at employers than the OP.

As a job candidate, refusing to participate in interviews that involve code assessments is going to severely limit your career, since the vast majority of companies make use of code assessments.

I give lots of interviews. If someone refuses the assessment, I have to fail them. HR says we have a legal obligation to interview al candidates for a given permission with the same format and criteria for evaluation. I imagine most companies are the same.

I think there definitely an opportunity for employers who can evaluate candidates without code assessments to get talent at bargain prices, but IMHO refuse code assessments is bad career advice.

i watched a prep video from a FAANG a while ago where that Gayle woman who wrote that cracking the … book solves a typical challenge. she arrives at the optimal solution after one hour.

i then took an interview with another FAANG. i was asked to solve this exact problem and it was clear i was supposed to do so within 3 minutes or so. this just illustrates how horribly broken the process is.

it’s infuriating how this woman lobbied herself onto the hiring committee and essentially created a broken process that disregards any experience gained and optimizes for those willing to memorize optimal solutions.

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 don't believe at all that this is a possibility.

What those programmers have been doing is gluing code from StackOverflow to create UIs. Just look at development in React. There's no thinking involved whatsoever. Just navigate to Redux copy-paste code and remember what it does to create a glued up pile of shit. Npm install 100 packages and you are good to go.

I don't know of any decent engineer who's good at problem solving that would struggle with LC easies which are the most common types of problems asked. I mean, how could they it's just basic logic and looping.

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.

I'm good at leetcode and probably fairly good at programming, though I struggle when problems pass a certain threshold of complexity. The issue I have is that I get seriously demotivated working for boring ass CRUD applications that most companies end up implementing and it like makes me sick just trying to push through that over time.

Not really sure what to do in my situation either. I know it's different from ops but I thought of it as sort of a corrolary.

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.

The median salary of a heart surgeon compares favorably with a senior at FAANG [1][2]. The former involves 15 years of rigorous medical education, the latter requires on an average 7 years work-ex, maybe someone in your network for a referral and 3 months of LeetCoding. I’ll take the 3 months of LC any day. [1] https://www.salary.com/research/salary/benchmark/surgeon-car... [2] https://www.levels.fyi/?compare=Google,Facebook,Salesforce&t...

It says a lot about the society we've built that those who save lives are valued roughly equally to those that fleece unsuspecting consumers.

If you are a good programmer you should be at least able to make a brute force solution to a leetcode problem. Then it's just a matter of seeing enough problems to learn the tricks that are used to optimize the time complexity.

>homebrew creator / inverting a binary tree

This is just a traversal of a binary tree + swapping two variables. I would expect any good programmer tqso be able to do both of these things.

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.

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.

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

Yeah, somehow I feel the consequences are only going to end up on one side

leetcode is just a skill like any other skill. If you understand the data structures / algos behind it (which are mostly CS stuff you learn in college), given enough time, you should be able to solve the problems.

It's okay if instead of doing a medium problem in 15 minutes it takes you 4 hours at first. Start solving and make a habit of doing 1-2 problems per day. In no time you're going to learn that the problems are doable and the time it takes to do a problem will go down a lot. When you can do an easy in 10 minutes and a medium in 15-20 min you're ready. I have rarely seen hard questions in an interview.

Also the more senior you are, the more the emphasis is going to be on system design and behavioural.

Yes, it's stupid. It is what it is. You know what is going to happen, you prepare for it, you get the job.

I don't understand OP, so you have problem with leetcode, and you also have a problem with hire and fire culture (most of these companies don't ask leetcode) so what do you want free money? And how you decided just after meeting "people who are really good programmers"?

Start your own company

> 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

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

I think no-whiteboard companies correlate pretty heavily with ‘good place to work’, ergo, they’re not looking for people as often as revolving door companies.

It’s my impression that just doing enough grinding to hopefully remember how to solve a specific problem is different from having enough experience to be have gained the aptitude to solve them without it feeling like a grind or cram session.

Frick idk. I have a Chime interview scheduled with Amazon on Tuesday and I'm definitely going to fail it after many years in frontend. But I'll do some basic prep I guess and see how embarrassing it is.

Just practice the leetcode, it's a skill you can develop even if it's worthless for your actual job. Grit your teeth, dance the dance, and land 400k/yr gig for your two months of trouble.

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.

You should see the LeetStudying medstudents/residents do to make $200-350k. Compared to other ways of making it into upper tier of income groups, this has to be the easiest.

I tend to look elsewhere if companies want to do code tests, my answer to them is

“here is the many thousands of lines of code in my various GitHub accounts, don’t like the code, don’t hire me”

Could we all be spending the time we spend on leetcode, on better things, like projects?

Do I learn enough in leetcode? Do I get anything valuable (outside of skills/practice) out of it?

IDK

If a company has a terrible interview process it's probably a terrible company. Don't work for those companies.

>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

This is a gross over exaggeration.

I'd say about 50-60% of companies do a programming test.

Others are happy to look at your open source code and discuss it with you. They might pepper you with some programming language trivia questions.

That has been my experience.

TL;DR: As a web dev of 13+ years I not only failed miserably on these types of coding tests/interviews, but fail to see how they accurately display one's ability to do a job UNLESS it is specifically optimizing algorithms every day.

I just want to add that I 100% agree with OP: many companies put too much into LeetCode type testing and interviewing.

I have been a web developer - so not advanced in algorithms or LeetCode type stuff to begin with - for the past 13+ years. in 2021 I resigned from my employer due to burn out, took 10 months off, and started looking for an employer again.

Many interviews for "web developers" and "wordpress developers" required me to take a LeetCode type test, which I bombed repeatedly. One company I really wanted to work for asked me to retake the test in 30 days. I spent the next 30 days in the pockets of time I found available trying to go through LeetCode challenges and wrap my mind around these algorithms. Many times I could "solve" the problem my way with my own experience and knowledge, but not LeetCode's way, so my scores were poor.

Fast forward 30 days, I retook the potential employer's test, and got a 14%...they advised I should re-apply again for 2 years. LOL. It was so comical I had to email them that the process didn't allow me to display my 13 years of experience at all, and the testing challenges in no way reflected what I knew as a web developer.

In the end I took a different position for a vastly greater salary than they were offering.

There is a lot of programmers who are bad at both, programming and leetcode. And they have jobs.

You can search on a site like nowhiteboard.org for jobs that don't do interviews that way.

The real purpose of this process isn't filtering out brilliant programmers but who are more obedience.

Managers aren't some kind of stale guy but predators who sucks slaves' blood. They actually know what they're doing, they're sending a powerful messages that they have power to order subordinate dumb things, like memorising riddles.

“The only winning move is not to play”

My advice as someone who doesn’t accept these kinds of interviews on principal - and has repeatedly payed the price for my insolence - you have three choices: accept and do it, work around it, or something I don’t know about.

I work around it.

My life isn’t special, no one cares what I have to say, and no book will ever be written about me, but I get to build great software everyday and I am happy.

In not so many words, you have to optimize for what you really want.

- Do you just want to build software?

- Do you want to have a lot of money?

- Do you need access to a quantum computer?

- Do you want to live your life learning new things, or focus only on one thing?

- Maybe build your own business?

- Do you want to buy and sell people like cattle?

If you’ve got that right in your head, and you don’t want to play the game I’ve found the gigs outside of the valley/US to be more often about doing work than about status and position. It’s less about the “difficult hiring process as a badge of honour” BS, and more about building things. I mean, Ex-fannG people are out here too so you still run into it from time to time.

So, TL;DR, maybe look at the world as an option instead of narrowing in on the typical valley/FANNG path.

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?

The problem is that actual work experience doesn't give you this. The more experience you gain shipping working software, especially in a senior capacity, the less exposure you're likely to have to the skills tested for in the algorithm-based whiteboard interview. We don't write algorithms often, but based on this style of interview, you'd assume that's what we do primarily, or even mostly. Some of my time is spent putting together the solution to a business user's request. The rest is spent reading other peoples' code to figure out where I can safely add the new feature, writing the feature (which rarely involves algorithms), writing automated tests for the feature, and babysitting my PR to production. Asking a candidate to solve a gnarly merge conflict is more relevant than asking them to produce an algorithm on a whiteboard.

Smaller companies don't always go through these extended formalities and you can get a good job and build a few years experience that way.

Our company, which is service and tech based (GIS) has about eight full-time developers among 400 or so employees and we're doing cross platform mobile development and some web and some server applications and plugins.

When we interview, we usually do a phone interview with basic questions ("Explain inheritance" or "What's the difference between abstract and virtual"). It's weird, but a lot of people either panic or don't prepare. Missing things like this isn't a deal breaker, but we want to see the thought process.

If that goes well, we do an in-person interview and tell the candidate to schedule at least a half day (or sometimes a full day). We introduce them around, chat, do a more formal interview, and then do a coding test that we concocted. Basically, it's pieces of our app and a list of like 10 things to accomplish, like "Make it compile and run" (usually there's a syntax error or two and we want to see how people use the IDE and tools) or "Add a label to the page or app that shows the current time" or "Fix the alignment of the buttons on the left side" (for web). They get progressively harder and we've only had one person complete them all on time (we hired him, naturally). We've also had candidates completely choke and not even know where to start (you are free to ask questions and look up things online - totally open book, as if you were working and had a list of tasks to work on). There aren't any tricky problems. The harder ones require a little domain knowledge in GIS (which isn't a requirement), but can be figured out with Google (or by simply asking us how to do something - it's kind of a joke that NO ONE ever asks). You're not watched, but we check in every once in while to see how it's going.

We eliminate quite a few resumes, and eliminate others after the phone interview, but for those who make it to the in-person interview, we've eventually made offers to about 50% of them. And we've had great success in getting people who can do the job and excel, which you have to do with such a small team.

We do look for github projects, open source projects, and any sample code you can share. We also like people who have completed successful individual projects, written on subjects, and we love it when candidates actually have domain experience, but, as I said, that's not required.

My favorite interview question is "Tell me about a project, personal, school, or professional, that you are proudest of. Preferably something that presented a challenge you figured out." I like for interviewees to relax and geek out a bit. I honestly want to know if they enjoy coding, designing, and learning or if they're just looking for a paycheck or stepping stone (not that there's anything wrong with that, but I don't want to feel like we're paying someone to do something they're not the least bit interested in).

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.

Look, you are thinking in the wrong direction or plane.

What is the group of customers for your labor output that will never put you through a test?

Hint, other beginning developers.

I feel I must be living in an alternate world to everyone here. I studied leetcode for around 2 months then tried to get a FAANG job. I applied to every FAANG (plus about 10 others who had high comp on levels.fyi). Then netted me 2 tech phone screens, which I both failed. The way everyone talks I should have had 5 offers after 2 weeks of studying.

Become a Haskeller :)

Rails interview question - who said "I don't do riddles"?

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.

So why are you in this industry?

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?

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 would love to be an outcast at work for $1m/yr.

It sounds better on paper than in reality. I quit that job and took one for a massive paycut. I ended up getting divorced partially due to this job.

Is it worth losing your marriage over? YMMV.

We have some that make way more than that in my FAANG company

Jobs as a software engineer at 1m/year? Sorry, I simply don't believe you.

Stock appreciation is a hell of a drug. I have worked with multiple engineers making multiple millions a year. They were all ICs.

To break into the 1% in SV - you need to make $3.6mil/yr. Just let that sink in. It's a very rich place.

I didn't get that stock was part of that equation. I took it as base salary. SV is an outlier, really wish people would stop talking as though that's a universal amount, and that if you don't make that amount then you're not senior. I lived in SV and it's a disgustingly money-oriented culture.

You need to speak to more senior people who work at companies that make their money selling software or Internet services. ("Senior" is not 5 years of experience. Think engineers in their 30s & 40s.)

I wish people would stop talking to me as if I don't realize this. This conversation gets had every week on HN and people talk as though seniority is this rich person only club that applies everywhere.

Nevermind, carry on then. Top engineers usually max out at around $200k all-in. Sorry for the confusion.

There are software engineers that make much more

https://techcrunch.com/2010/11/11/google-offers-staff-engine...

I don't get why you are working at all :) what do you plan to do with all this money ... Only to do leetcode?

Lol exactly, get a mission for Christs sake

I'm also someone who entered the field for money. As someone who grew up in a family of poor immigrants who pushed me to work hard and opened the door to opportunities that I'd have never been exposed to in their home country, it's really great to know that my family will never have to endure that hardship and will enjoy one of the highest qualities of life and that I can give back to my parents who struggled to give me this quality of life.

If anything, one of the challenges I face raising my own family is to make sure my kids don't become complacent and squander the opportunities available to them.

I hope that means you can retire at 40? Because otherwise I'm not sure if you're aware you're going to die one day and you can't bring your money.

I know no one who is on my path who wants to be working past 50. Almost everyone like myself is trying to find a way to save money + pick the right place to work for fast returns.

My problem is that I've got a real knack for choosing partners that drain accounts dry instead of adding to it. (One part where I differ from my peers)

I'd love to tap out by 40 but that ship sailed and sunk.

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

I agree. A lot of these are not industry exclusive to tech/SV. However, we take it a bit further at times and more importantly we advertise that we're different. We like to think we're different. Other industries don't try to act like they're different. You go into law, biz, med, etc... You know what you're signing up for. You need to be a little brown nosing subservient ass hat - and everyone knows it. And everyone knows when you get to the top - you get to subject everyone everyone else to your whims, your hazing rituals, and so forth. They know that's the reward for getting to the top. Boss says you do X even if it's unethical to ask - in other industries you do it anyway. In SV, we act like it's okay for you to question it even if your boss will still fire you for insubordination.

The difference is subtle but it's that SV at least tries to act like it's different even if they're not. That's what rubs me wrong about this industry the most. The virtue signaling without any real actions behind it. It is truly ghoulish.

> 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.

Cultures that accept LC are more likely to make your life terrible.

I work for a company that pays well and doesn’t do LC because of all the obvious reasons, and that is a representation of the culture.

$400k+/yr well for senior eng or “I think it’s enough”?

Sometimes you have to do the stupid thing because the boss or the client tells you to.

Some of those times you get to say "I told you so", later.

But the reason you get paid is because someone wants to pay you to do it. You can try to convince them to do it right, but in the end it's their money. Do you want it?

When you have the control you can try to make the better hiring system, but since you're asking i assume you're not in a position to dump your balls on the table and say you won't play their game, but they should still hire you.

It's a gamble to as your first impression show that you're not a team player.

Exactly, yeah let’s all keep going along with this nonsense cause ya know?

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.

When the VC money dries up I expect things to get worse, not better for candidates.

Which is fine! Nobody has to do LC and nobody has to apply to companies that use LC interviews.

The reality is that when most people sit down and think about the math behind the finances, avoiding LC on principle comes with a massive opportunity cost that can exceed millions of dollars over the span of a career. Which again, totally fine if that's not your thing, but we should still let people know what's at stake.

The reality is that's only from one super limited perspective and fails to consider the ideals of the applicant and how they think companies should operate ethically. Becoming wealthy isn't the only thing in life, this includes considering which companies you're willing to work for based on how they operate and what they do.

If we constantly have people buying into a damaging system just for the money, it compounds issues and they get worse down the road

I agree, it is fine if people choose to do this! It doesn't change my perspective on it however. There is definitely an opportunity cost. However, not in all cases. A single developer who is talented can take a variety of paths outside of this system to make significant or more money.

I'm going to get ahead of the idea of the risk of stability and the implication I'm saying a software developer would be banking on risk/reward of a technology startup. I'd like to say that they can also use all the skills and knowledge of a software developer in a non-tech company with great success and similar or higher compensation with similar risk profiles.

> A single developer who is talented can take a variety of paths outside of this system to make significant or more money.

Please write a post about this then. I'd love to know roles that are regularly paying $500k+/yr.

Agree, I’ll do literally anything than buy into this nonsense. You can take your crappy devs that memorized Leetcode problems and I’ll stick with people who solve actual problems and can demonstrate it.

Leetcode isn’t a good measure and will be phased out in coming years as this is realized.

> Leetcode isn’t a good measure and will be phased out in coming years as this is realized.

Given how long it's been around and the lack of credible alternatives for hiring at scale, I'm having doubts.

It _hasn't_ been around long, this is a recent phenomenon in the last 3-5 years, and its a cargo cult like so many other things in tech. It doesn't work well because most of the really bad engineers I know just grind leetcode and end up at FAANG. This will be seen in time

CtCI has been first published in 2008, meaning that such interviews had already been widespread for a few years by then. Since then, websites like Leetcode have apparently become viable as businesses. As a career choice, I find it unwise to bet on this practice disappearing anytime soon.

> their toxic culture until the VC > 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.

Hm. I hope this comes of gently - I don't know you, your skills, your background, your experience or your goals for that matter - but this feels overdramatic and even a little condescending.

If you have your CS fundamentals together it really shouldn't be that much effort? I know some whiteboard interviewers will ask unreasonably obscure algorithms, but LC hasn't ever been that unreasonable. I really don't get the absolute vitro people have. Sure it's not an ideal measure - but hey: eat your vegetables. It's not some unfathomable distant unrelated set of hoops to jump through.

LC questions can be a little bit of a chore but I've never spent more than an hour or two brushing up before interview cycles if I reviewed them at all and have done pretty well in my interviews. I've tanked my share of interviews but it's never been so dramatically unreasonable. It's not like they're asking you to write paragraph upon paragraphs on why you'll be the perfect fit and this opportunity is unlike any other for you. Cover letters are at least 70% more bullshit.

For context: I joined the industry in 2012 where whiteboard interviews were the normal but before leetcode, hacker rank, etc. were common, but I've interviewed plenty since then.

> Cover letters are at least 70% more bullshit

Agreed. And yes, on LC problems they are a chore. I've been thinking about this a lot and here is my take on all of this from a different direction that re-inforces my opinion that it is a toxic culture.

The fact that developers are required to do a dance and memorize LC problems to regurgitate them in a timed setting is because there is a fundamental lack of trust on the hiring side. This is actually offensive.

Now, we might say, okay well LC problem regurgitations provide actionable signal. Definitely more than a cover letter! But is it a significant signal for software production ability? I don't think it is except in cases where the domain is well-trod.

I get why we need some kind of signal with the current way employment and hiring is structured. We need something actionable, something to build trust. But I think that's the problem. Trust should come first, otherwise we enter this current world where hiring is slow, fraught with problems, no one can fill their positions (and I don't think it's for lack of a talent pool).

I haven't through all of the implications of this part yet, but here is where I'm at. VC backed companies and VC backed company copycats will say they are doing all of this to avoid false positives. All so they don't waste their time on the Wrong hires. How long does it really take to know, when actually working with someone, that they are the wrong hire? Not long in my experience. Let's say 1 month. Just hire people on a temporary basis, pay them, it's a more ethical take home project in a way. And what is the current state? Well the current state is filtering so harsh on a low significance signal that it takes a company many months to fill a position. Are our assumptions about the false negative rate so wrong that it's actually very high? I think so.

I've had some pushback on the hire fast, fire fast methodology before as being bad for candidates. However, I don't think it's any worse than the current experience they receive.

> The fact that developers are required to do a dance and memorize LC problems to regurgitate them in a timed setting is because there is a fundamental lack of trust on the hiring side. This is actually offensive.

> Now, we might say, okay well LC problem regurgitations provide actionable signal.

Oof. You keep calling it "regurgitation" and "memorization" as if there's no way that one could possibly be capable of thinking through those problems with a bit of experience. Maybe it's just me but I don't think a brief test of your fundamentals is that out of line. You're not supposed to memorize your times tables to 100, you're supposed to know how to multiply.

I think there's plenty of reasonable criticisms to be made, but if you're equating LC problems to StarTrek trivia I'm not sure you're making them.

> But I think that's the problem. Trust should come first, ... How long does it really take to know, when actually working with someone, that they are the wrong hire? Not long in my experience. Let's say 1 month. Just hire people on a temporary basis, pay them, it's a more ethical take home project in a way. And what is the current state?

> I've had some pushback on the hire fast, fire fast methodology before as being bad for candidates. However, I don't think it's any worse than the current experience they receive.

That is in no way more ethical and it's so, so much worse. It shoves tremendously more cost and risk onto individuals vs companies. I don't know your situation or experience or what's driving these conclusions but your concerns just don't connect to your conclusions for me here.

The following is a chunk of my reply very similar comment recently: https://news.ycombinator.com/item?id=30889389

> I can't even fathom in what ways you think "time to hire more, and fire fast?" is more "effective and equitable"? You just shove even more risk onto individuals who might be getting their footing still.

> You're just turning a 8-9 hours commitment to an interview into a 6 month commitment. Sure, you get paid but you also have to deal with churn and burn.

> I mean, did you think stack ranking was a good idea?

Very well said.

To the OP: if you really are a good programmer, then mastering LC is just a matter of time and effort and really, the problems aren't that hard. You're also hired at most companies to solve problems; not just be a code monkey. It's a matter of interest and motivation not whether you're good at LC or not.

LC is the best proxy we have for aptitude and general problem solving ability at this time. So best to suck it up and grind.

Grinding LC is the definition of being a code monkey.

> You're very unlikely reaching $500k+/yr by avoiding LC compared to how trivial it is to reach once you accept it.

I wouldn't say it's "trivial". It may feel that way once you've made it and been promoted up the ranks, but outside of that bubble I see a lot of people who have failed out of multiple attempts at FAANG interviews (despite practicing LC), burned out of FAANG jobs after a couple years, moved away from cities with those salaries (not every place offers remote work), or simply been unable to get through the promotion process to reach the upper ranks.

Don't get me wrong: Practicing LC and grinding at FAANG is a remarkably easy way to reach $500K/yr salary compared to other options, but we need to stop pretending like it's automatic or easy. It's still hard and requires some degree of sacrifice/luck/location to get there.

In no way am I saying it's easy. I'm saying it's trivial compared to other options. Other options are basically fucking impossible. At least with FAANG and staff roles - there's a chance. Even if it might be this meme: https://www.youtube.com/watch?v=wGdhc9k07Ms

> requires some degree of sacrifice/luck/location to get there.

Bingo. You can answer everything perfectly and still not get it depending on interviewer or other applicants.

My problem is that I hate leetcode and I’m also burnt out from all the nonsense you mentioned

In the big scheme of things, there are worse things that grinding leetcode in order to land a 6 figure job.

I have no idea what to do except be OK enough at the skill to get jobs, meanwhile using social media to attack the practice. I hate these god damned things.

My advice is to start early to avoid stress. Start mid-tenure of your current job.

Reply on news.ycombinator.com