A guide to learning algorithms through LeetCode | Hacker News Reader

A guide to learning algorithms through LeetCode

github.com

455 pointsVitalyAnkh204 comments

It's becoming obvious to me that my time is better spent learning to solve these riddles rather than actually becoming a better developer. I have a job search coming up at the end of the year and whilst I've managed to largely avoid companies that ask this type of question, I believe it's seriously constraining my career.

I can't speak for everyone but the whiteboard interview has prevented me from leaving jobs earlier, moving jobs more frequently and left me avoiding certain companies altogether.

I wonder if that isn’t the point, to increase developer retention and reduce competition for devs.

It would be a "tragedy of the commons"-like effect for companies that don't adhere. I would guess that is just an unintended effect and that there is no master plan behind making recruiting expensive, slow and inaccurate.

Or it's part of an organised cartel between the major SV employers to reduce salary competition and employee turnover.

https://en.wikipedia.org/wiki/High-Tech_Employee_Antitrust_L...

I am not ruling out the possibility that there is a "recruiting should be hell" cartel but I believe there is no general bad bureaucracy HR bloat cartel and that it is an unintended effect, hazing, esprit de corps, HR self interest etc. The conspiracies are probably more simple like "no poaching" or wage cartels?

Surely the generous pay is the biggest factor for retention?

Competition is ill defined in the labor market because people aren’t fungible. So it’s hard to really point to hard evidence, so and so practice leads to so and so change in salaries or increase in retention.

Aside, nobody said this guy was looking for a low paying job. High paying ones want leetcode.

Google will pay a higher salary to a 21 year old than a Miami firm will pay to someone with 10 years of experience. Nobody will ask you these puzzles outside of ~5 markets in the US. They also pay way less.

Anecdotally I would say job satisfaction is at least as important a factor in retention, at least until employees are old enough to have started a family.

Many young people (age 20-30) I know are in a situation where they are paid large sums of money ($100k-$200k) for extremely dull work. I've seen most of my friends from college quit their FAANG job in search of something more fulfilling, often at a 50% or more pay cut.

That could be part of it, but I don't think it's the primary reason. Rather I believe it's just one example of a more general, emergent phenomenon in capitalism, in which the top decile of jobs in high paying careers converge to interview methods which are a legal proxy for IQ testing.

It is a game of cat and mouse between candidates and companies. The candidates want high pay and interesting work, and the companies want only the top n% of candidates for their work, for some metric of their choosing. However many candidates a company has to choose from, they will devise some way of choosing the best among them. The methods for determining the best become (in my opinion) increasingly pathological as the surplus of candidates increases. In tech, the result is that the past decade has seen a supermajority of the most lucrative, mainstream jobs moving to a local maximum: whiteboard interviews based on data structures and algorithms. In response, candidates have gamified the process of studying for these metrics using Leetcode, and so a cottage industry of adult test prep was born.

Other industries use extreme credentialism or other methods to cut down on the vast majority of resumes they see, and there likewise emerges a cottage industry of professional preparation to break into these careers at the highest level. The companies use these methods because they see an absolute glut of candidates and become risk averse to bad hires - because after all, if they can attract so much talent with high pay and prestige, why should they suffer possible duds? This is how we end up with the, "Google is okay with passing on false negatives but can't tolerate a false positive in their hiring process" reasoning.

It's funny/depressing to think all of my depression stems from not being able to do these problems fluently.

According to the believers it is an unbiased way of predicting whether people are capable for the job. Google has done a lot of tests and these style of interviews predict job performance best [1].

Assuming this is true then to me it means that universities and work experience are too heterogeneous as a measure of job performance.

In my experience that is true. Not sure how well the argument holds up if everyone is simply going to study algorithms though.

[1] clement mihailescu says it on his YT channel somewhere in a vid.

If you work at google you can go find those studies yourself, they are public internally. At least you could when I worked there.

> [1] clement mihailescu says it on his YT channel somewhere in a vid.

The "co-founder and CEO of AlgoExpert, a website that helps Software Engineers prepare for technical interviews." argues that algorithmic / technical interviews are the best predictors for future job performance?

Well color me shocked.

I was working on a “startup”/kinda just unemployed for two years. I studied leetcode hard, and got hired into a 300k a year job at FAANG. I know nothing about testing, git, software process, roll outs, dev ops, etc. I barely know how to do software engineering. What an idiotic hiring process.

Do you think it's unlikely for you to learn those skills quickly? People who have all those skills earn over $300K at those companies.

To be fair, a lot of people who have none of those skills also earn well over $300K at those companies. Just like grinding leetcode can get you in the door, the skills you need for advancement are not necessarily the same ones you need for making good software.

I hope the parent makes the best of it and becomes good at the craft, it will make the job a lot more enjoyable even if it may not be the fastest way up the ladder.

> the skills you need for advancement are not necessarily the same ones

Exactly this. I suggest learning how to fabricate (or at least exaggerate) "impact" to get promoted. It's the fastest way to make money once you're in the door. Show how much of a team player you are to deliver cross-team, impactful results specifically by stepping on bodies to get there--it'll make you rich!

Could you elaborate more on that or perhaps give specific illustrative examples of how one may do so? This will benefit a lot of us at FAANG. Thanks!

It’s been really stressful. I know python, but not really any other languages. I’m able to get work done. But I’m really nearly the same as a fresh grad. But really, I was just bumming around, then studied for four months and destroyed their algorithms questions, so much so that expectations for me are really high. But all I know is leetcode, literally nothing else...

Take the same energy and apply it to learning to build testable and understandable code. If you can go from nothing to smoking an algo interview in months you’re a fast learner. You’ll be fine.

I think that's what these leetcode type questions are good at. You're either naturally adept enough to do well, or internally motivated enough to memorize/learn them. Either way, it's a decent signal for a company that needs someone to learn their internal, proprietary techstack

I partially agree but this point of view has become very polarizing and controversial and I get the other side of it too. People who have spent ages getting better at their craft feel undervalued. However the two need not be mutually exclusive. One needs to learn to do their job while also navigating the system. That is part of the job just like selling your work is also work.

But having worked at both FANG and non FANG you can see the rigor of the interview process reflected in the quality of your colleagues. That’s something that is hard to deny having experienced it.

> You're either naturally adept enough to do well, or ...

I'm personally very wary of using algorithms questions as a proxy for how "adept" someone is at software engineering. If I were running a business, I'd personally want to make sure people could manage technical debt and build decoupled systems.

I have had multiple positions at FAANG companies, and despite being "adept" according to these algorithms questions the systems built by these highly-paid (and, around me, generally experienced) people are pretty awful in terms of quality and maintenance.

Learning a proprietary stack also hampers effectiveness in future positions if wanting to opt-out of FAANG later on.

Why do you suppose these hires aren’t good at learning engineering best practices? I see comments like yours here all the time. Is it some kind of arrogance, perhaps amplified by a false signal sent by getting hired off leet code questions in the first place?

It’s false based on what I’ve seen. Plenty of people passionate about good engineering where I am. But they are sometimes trapped in a system which doesn’t always incentivize it.

> Why do you suppose these hires aren’t good at learning engineering best practices?

I guess what I was trying to convey is different: being good at algorithms doesn't give much of a signal (positive or negative) about other things I think really matter more on the whole.

(Of course, having enough people being aware of algorithms subtleties is important ... everyone, not so much)

I have observed this problem and usually it’s not because the people are incapable but that the incentives are to ship things that move the needle to quickly get promoted. The financial rewards at these companies from promotions are huge.

Where the managers have incentivized quality and stability my team mates have moved mountains and I’ve seen some really good stuff but otherwise not.

What was your prep strategy?

You know algorithms (not leetcode). Most people struggle a lot with algorithms. It's the reason a lot of people flunk out of CS programs. That's why they hired you. If you can solve these problems on a white board, you can write the code in a programming language.

Being on other side of the interviews like this , trust me most interviewers know that .

The logic being if you can pick up leetcode in few months you can pick up most things on the job fast.

Understand that interviewers are first and foremost are looking for ability to learn and understand complex topics , it is not all that important which specific topic it is.

nobody really knows what you will be working on by the time you join or 6months later , even if the interviewer wanted to it he is not able to ask the right questions beyond the basgics.

Also university education in IT is woefully behind the industry. Functional programming, or dev tooling is barely covered in most places . Maybe they teach MVC a bit , I don’t expect most kids to understand CQRS or event programming .

Similarly I would be pleasantly surprised if you have setup a simple app, I wouldn’t expect you to know nuances between different cloud vendors , or have experience with zipkin,istio, helm , grafana or similar tools or be able to grok a explain analyse and fine tune a 500GB dB.

it is unlikely a fresh grad has production experience at best they may already know some frameworks and maybe developed a few small apps of their own, however working in large project with 1m+ lines and complex tooling is a skill that takes time to learn , there is a lot of gotchas in every area you will learn only when you see it .

So all I am left with is, does this candidate know the basics , can he understand and learn fast .

That is why these questions make sense for junior developers and never for senior devs.

N = 1 but here we go. Let's look at the CS bachelor/master offered at the Vrije Universiteit Amsterdam [0]. The truth is probably somewhere in the middle and I understand that university programs are heterogeneous.

So let's look at my university experience and use your post as a checklist, for funzies! :D

Functional programming: covered

Dev tooling: covered to some extent through electives where you'd teach it yourself (I also call it the Magical Course) [1]

MVC: Magical Course

event programming: never heard of it :) Reading the wikipedia page, the following courses will probably help in aiding understanding:

+ Hardware interrupts: kernel programming, binary and malware analysis and hardware security

+ User events (e.g. via JavaScript): The Magical Course and Computer Graphics

CQRS: never heard of it :D And while I get the need when reading the article from Martin Fowler, I do not have a backlog of knowledge where I've encountered this before.

Simple app: computer graphics, the Magical Course, Distributed Multimedia Systems (the practical assignments were in HTML5/JS).

Cloud vendors: nope, I learned about that when I started teaching for a coding school

zipkin, istio, helm, grafana: never heard of it :D

be able to grok a explain analyse and fine tune a 500GB dB: No. We did learn SQL though and how to model relationships with UML and entity diagrams.

it is unlikely a fresh grad has production experience: I do, because my thesis was harder than whatever production experience I was acquiring. Going to work as a web dev and web dev instructor was my form of fleeing for my much more difficult thesis. Also, computer graphics taught me volume as my OpenGL engine was 10K lines of code. The Magical Course allowed me to produce an app that I sold for 2000 euro's.

Diving into a 1 million line codebase: We did that way too briefly (the Linux OS) for just 15 minutes, unfortunately. The startups I've been at had about 100K lines of code for their complete product. In other words, a lot of companies don't have a 1M+ codebase.

Anyways, when you have someone from the Vrije Universiteit Amsterdam, you can have some idea of what they do learn ;-)

[0] My knowledge of the curriculum is a bit stale, so it could've changed.

[1] Whenever I use this sentence, I happen to refer to one course where the teacher decided not to really teach but coach and the goal was to teach yourself whatever you wanted. I happen to have learned a lot of practical stuff that otherwise wouldn't be covered. So did many others. What did I specifically do? I created an iOS app by following Hegarthy's Stanford-based iOS course online ( https://www.youtube.com/watch?v=gI3pz7eFgfo ).

Firstly, thank you for sharing :)

Yours is above the par learning experience than most fresh graduates I have encountered. When we hire in Eupope I would very interested to try and convince some of your juniors to join!

> The startups I've been at had about 100K lines of code for their complete product. In other words, a lot of companies don't have a 1M+ codebase.

Most large companies who are also large employers sadly do have such complexity. In a startup it may not a single repo at 100k+, however overall 100+k lines for the product is very low for Saas product over two-three years it easily goes beyond.

My N=1 in a startup: we went from one monolithic 300-400k+ L repo to a ton of repos with each one perhaps < 100k . Traditional large codebases are not designed for releasing 4 times a day, even builds can take a lot of time [1], Smaller repos does not mean complexity goes away, developers need to still document, read and understand how it works. It applies also when you use libraries or third party services, while number of lines have become less, you need a lot more domain understanding.

> be able to grok a explain analyse and fine tune a 500GB dB: No. We did learn SQL though and how to model relationships with UML and entity diagrams.

The reality is that most jobs are not developing new apps from scratch, it is lot more likely to work on older codebase that has its fair share of kinks.

That means I am going to throw you deep end into large sized DB. Schema perhaps has evolved over time as product vision keeps changing, a dozen 'architects' have messed about it. In a typical job, you will be fixing bugs more than developing new features, handling tech debt - it doesn't matter stupid mistakes were made before, you still to work with/around those mistakes as someone will have to work with yours.

Even on theoretical level NoSQL is not well taught in universities. Purpose built dbs for graphing, Time Series, KV , document DBs, search indices are all important to really understand. Each has solutions to specific problem set and come with their limitations. In a typical basic storage stack there is going to probably be something like Redis|PostgreSQL|ElasticSearch: all of them solve more than one type of storage problem in more than one way.

This isn't to say the that is it all bad. Education is evolving , universities are more open to longer internships, while most don't think software engineering (not CS) should be treated as vocational course, there are positive trends. Alternative learning avenues have opened up like Coding Schools and Bootcamps who do lot better job at focusing on job skills.

[1] https://news.ycombinator.com/item?id=18442941 This is infamous post, and of course the extreme example, but you get the idea.

Ha! I remember the source you mention [1]. 25 million lines, haha. Man-made software mountains :)

Thanks for reading my comment by the way. I wish I had more time so I could write succinctly. If you're ever in the position to hire people from my uni send me an email if you'd like some introductions to professors and what not.

> Alternative learning avenues have opened up like Coding Schools and Bootcamps who do lot better job at focusing on job skills.

Ah, got you there! ;-) *

* Probably not, but it's fun to imagine that I did for a second.

My first job out of CS was being a web development instructor. You might think I wasn't qualified, since I never touched NodeJS in my life and wasn't super familiar with JavaScript. I told them this but my teaching skills were really good so they gave me a unique challenge.

My challenge: make one NodeJS app in one month. I pried a bit what they wanted me to showcase, and they'd be happy with a custom blog that had user login, CRUD on blog posts and user registration.

In that month I made:

- A voting app for the game Werewolf of Miller's Hollow / Maffia

- An online sentiment analysis app based on my bachelor thesis

- A simple CMS designed to list all the hackathons in The Netherlands (though you could also retrofit it into a job board or party calendar)

- A blog app with the extra feature of adding markdown to it (what they actually wanted)

When I showed all this to them they asked me: you learned this in a month?! The thing is, I think most of us CS grads would have. And I think a lot people with a master in CS wouldn't be surprised that I created 4 apps within a month instead of the blog app only.

It's all function calls, for loops, if-statements and variables in the end. Sure, JS has closures, but we had compilers in class, so understanding on a high level the JS engine internals work, it isn't that hard. The same goes for callbacks, promises and all the other fun JS stuff that makes JS quite unique. *

* I use the debugger a lot when I learn a new language. I do think this is a super power since not many programmers seem to do it, but it gives a lot more context. It's the only way how I was capable of getting a foothold to understand X86-64 in binary and malware analysis. I'm pretty bad at simulating code in my mind, but now that I've seen it 1000's of times in debuggers, I'm a lot better at it.

Moreover, even in 2017, the resources available to self-teach how to do it were available and I self-taught everything via the official NodeJS documentation, code school and random YouTube tutorials.

So, in my case, I've seen both sides. Ironically, I became one of the best JS teachers by virtue of my CS education (and my upbringing, had to teach family members a lot of stuff). I know what coding schools teach, IMO the CS education I had was superior to that. Maybe not in time effectiveness though, but of those 6 years I spent on it, I'd say that 1.5 years was super useful, 1.5 was useful and the other 3 years is where I got C's anyway and did other things to enrich my life (such as a course on Buddhism) :)

You mention CS education is not efficient way to learn to be a developer, the other problem it is expensive, maybe Europe is different it is certainly a major factor US and many other countries.

As you point out your strong background in CS helps a lot, which is why tech interviews want to filter by that skill, it is however not essential to be a good developer.

To be a good mechanic you don't need to know engineering, knowing engineering certainly helps and give you an edge over someone starting the same time as you, but not much for senior skilled hiring. I would rather have my car serviced by experienced high school dropout mechanic than MIT graduate out of college.

Personally, I have a background in electrical engineering, I started hiring tech startup right out of uni, neither knowing tech or hiring. It is been 7-8 years and we are now 150+ strong. My brother has PhD in CS and multiple post-docs, studied in top universities and now teaches at one. Between the two of us, you would hire me any day to build a real application. If both of us started careers as developers at the same time perhaps he may have become a better developer, however today my experience would count lot more than foundation knowledge his education will bring.

tldr: The background in CS helps early on as fresh grad, but it should not be a factor for senior hires, that is problem in FAANG hiring.

In The Netherlands the only expensive thing about it is opportunity cost, which is as amazing as it gets. Now, it's a bit worse though. 8 years ago, I received about 3000 euro's. My education was 1900, my travel was free (also sponsored) so the rest was for books and living on my own. I decided to stay at home and take a longer commute. 1100 euro's for books is more than enough in most cases. I know that this is in stark contrast to the US. And from my point of view (which is biased), I find the US to be in an unfortunate situation.

I agree with everything you said. Perhaps it might be interesting to remark that I feel this picture changes in the startup landscape were things aren't always that complicated, but where the people that hire you do seem to hold you to the same standards. This is why I'm always wary about the title of "senior" at a startup.

My experience of FAANG interviews outside the US is that the salaries they offer are really disappointing compared to the US. Other industries like finance were a better deal compared those companies. If I can get paid £90-110k in the City why bother working for Facebook were they were offering less than £90k? Note, I don't consider bonuses or equity to part of salary.

Why would equity or bonuses not be part of the salary ? You are almost certain to receive it and the stocks perform quite well on average.

They still pay better than finance all things taken together or am I wrong ?

Bonus is not guaranteed so why take that into account?

Stock maybe but you can't pay the bills with that or get a mortgage even can make it more difficult.

You sell the stock when it vests and pay your bills ?

The bonus is pretty formulaic with fixed performance multipliers - if you're doing poorly enough to get substantially less than the target bonus, you're at risk of losing your job and comp is the least of your worries.

And you absolutely can pay the bills by selling the stock when it vests. Agreed on the mortgage part though.

What's the typical vesting schedule? The companies I spoke you would get the equity after four years. Not even a part each year. The offered 0.00[0]5 equity is not great.

I think the packages in US are just much better compared to UK/Europe or maybe they just gave me shitty deals. My offer at one of the FAANG in UK was £85k + 50 stock + discretionary bonus (they didn't give details).

For a FB offer in the US I saw but ended up not taking the RSUs started vesting in the first month. I treated that part of the offer as cash equivalent but with an uncertainty factor (could be more, could be less but wasn’t going to be nothing.)

Monthly or quarterly vesting is standard across the industry. FB and Google start vesting within a few months and large companies are switching to this norm although large startups till tend to have 1 year cliffs. You get liquidity though from signing bonus (which is paid immediately after joining but you have to pay back prorated if you leave in the 1st year).

The one exception is Amazon which is notorious for its backloaded vesting schedule.

At Google more than 97% of engineers gets the bonus, only people close to getting fired don't get it. If you think there is a risk you might be in that bottom few percent then yeah, but most people never fail to get a bonus.

> Bonus is not guaranteed so why take that into account?

Bonus is not guaranteed only if you're about to get fired. Even lowest ok performance grade at google (CME) will get you 15+% bonus. But it's not a whole lot of money anyway. Stock is where you make bank.

> Stock maybe but you can't pay the bills with that

Only at private companies. FAANGs are all public and their stock is as good as cash. You can trade it for raw cash any moment the stock market is open (except during trading blackout windows before earnings) and pay your bills with it

> Note, I don't consider bonuses or equity to part of salary.

Tell that to the tax man

“ Note, I don't consider bonuses or equity to part of salary.”

Depending on the company and how much the stock appreciates this can easily be +50% of your total take home so I’m not sure why you’d discount it.

How did you get past the resume screening? Or are you from the US, because then it's much easier to get past the screeming, or so it seems.

I have yet to be invited for so much as an HR call when it comes to FAANG (bachelor/master CS from a Dutch university). Maybe I'm not getting past the application tracking system?

The recruiter just reached out to my LinkedIn profile. My understanding is it’s really easy to get the interview

Your profile must have been pretty solid to get those interviews though. In my experience, just having some proof of knowing Python scripting is not enough. Would you mind discussing the other pieces of your background that you think may have helped in attracting recruits?

I almost wonder if throwing “leetcode” in your skills section would get you interviews at these companies...

Most likely you either don't have 5 years of professional experience or they are filtering you based on visa/citizenship status. The industry is very broken.

Having a current employee add your resume to an ATS as a referral is the most efficient route. Around SF at least it's not particularly hard to find someone willing to do that even if they hardly know you. This sort of networking is likely harder elsewhere, but perhaps not by much.

Simply uploading your resume to a large tech company's website will rarely get you anywhere, is what I've heard from recruiters.

Ah, so that's what I've been doing wrong for 18 months. Thanks! I'll be putting this to good use :)

Second this. Internal referral is the most reliable way to get in the door in my experience.

Interviews are only partially about testing your body of experience. They're also supposed to test your aptitude and ability to grow in the future.

If you were capable of studying Leetcode so hard that you mastered the interview process at one of the most selective software companies in the world in only a few months, it's not much of a stretch to imagine that you could apply that same aptitude, ambition, and ability to learn quickly toward picking up the basics of git, dev ops, and so on.

Arguably, this is one of the benefits of Leetcode-style interviews. They focus on core software engineering aptitude, while not arbitrarily excluding people because they didn't use the right VCS at their last job.

> it's not much of a stretch to imagine that you could apply that same aptitude, ambition, and ability to learn quickly toward picking up the basics of git, dev ops, and so on.

But you already have your reward, right? I’m not sure how much ambition is left after you actually get the job.

Promotions can double your salary or more from that level so people are plenty motivated.

That’s definitely not true at companies without incentive systems.

So can job hopping. In fact, IIRC staying at the same company earns you less money than finding a new job every two years or so.

Err, but why do you have to prove it for every next job?...

In reality, it's a legal way for:

1. Ageism - not many seniors are desperate enough or have a free time for Competitive Programming preps.

2. Making switching jobs harder - for every next job one has to prepare again, because nobody is using Competitive Programming stuff during real work, so you forget.

Keep in mind that CP != CS.

And CP is not everyone's cup of tea. It is a separate discipline/subject with its own trivia knowledge & tricks. CP uses Computer Science the same way as e.g. Physics or Biology use Math.

#2 doesn't make sense, though: If I'm company B, trying to poach from company A, it would be in my best interest to make the leap to applying/interviewing less difficult, not more for employee's of company A.

Unless you're implying a set of companies are all in league with each other to reduce churn/competition for talent

> Unless you're implying a set of companies are all in league with each other to reduce churn/competition for talent

They have been caught doing so in the past. [0]

[0]: https://en.wikipedia.org/wiki/High-Tech_Employee_Antitrust_L...

> Unless you're implying a set of companies are all in league with each other to reduce churn/competition for talent

This is a proven reality, and has been out in the open for a long time.

Then a few links to those proofs should be easy to produce?

On this same thread https://news.ycombinator.com/item?id=24182126

Yeah, I know about that one. Wondered if anything new had come to light.

This was 10 years ago and involved 8 companies.

Concluding from one crime that they all do it, and that's just what those people are like, you can't trust them etc, is an impulse we all do well to resist.

Of course, concluding that nothing like this will ever happen again is also naive. The incentive to cooperate is certainly still there.

My impression is that since the 2010 case, wages have gone up dramatically in that class of companies. There are also more big companies with owners who aren't pals from before. I think. Just guessing, relly.

FAANG don't really want to poach each other that much, as a sibling comment says, they had been already caught in the illegal non-poaching collusion. But even without any such collusion active they undestand that people would jump back and forth between these comapnies, ratcheting TC up every jump.

What they need is that somebody who passed the interview believed it was a lucky break and would not tempt fate trying a similar interview at another company. If they considered the interview just a filter, they probably would not be so lenient with letting people to apply many times and even encouraging this.

> why do you have to prove it for every next job

Obviously, each company can't blindly trust the interviewing practices of everyone's previous employer.

> Ageism - not many seniors are desperate enough or have a free time for Competitive Programming preps.

In my experience, senior developers don't need anywhere near as much prep as junior developers for these interviews. Leetcode problems are difficult when you're a new college grad with zero years of programming experience. They're significantly easier after you've been programming for 10 years.

> Making switching jobs harder - for every next job one has to prepare again

Companies aren't going out of their way to make it harder to hire good employees into their own companies.

Leetcode isn't an industry-wide conspiracy. Companies are using it because they believe it's a good filtering mechanism for candidates. When the Big N companies have higher rejection rates than Ivy League universities, they can afford to be selective.

> Keep in mind that CP != CS.

The problems are designed to test CS skills.

How else would you suggest reorganizing the interviews to test for CS skills?

I've been programming for 10 years and I'm pretty good at it, at every job I've had I get lots of praise and recognition and accelerated promotions. But I have a hard time with leetcode problems and have failed several interviews because of them. It's not that I can't learn the leetcode tricks, it's that I don't have the motivation or the time to drill for months on them so that I can retain all the tricks.

I don't have a CS degree so I think that might be the difference, I didn't get to spend four years thinking about algorithms and data structures. Leetcode interviews are a form of gatekeeping that CS degree people use to filter out non-CS people.

I also don't have a CS degree, and got hired at a FAANG company. If you want to quickly get up to speed on the data science basics, check out "Cracking the Coding Interview" by Gayle Laakmann McDowell. Her YouTube videos are also useful. Certainly, there are other methods, but this is one that I found useful.

> Obviously, each company can't blindly trust the interviewing practices of everyone's previous employer.

Yet, they copycat each other on this.

> after you've been programming for 10 years

...as I said, you're not desperate enough, so you become picky how you spend your time.

> Companies aren't going out of their way to make it harder to hire good employees into their own companies.

Lowering the churn rate has a higher priority.

> The problems are designed to test CS skills.

No, these problems are designed to test CP skills. Even Norvig admits it has nothing to do with being a good dev/hire: https://www.youtube.com/watch?v=DdmyUZCl75s

> How else would you suggest reorganizing the interviews to test for CS skills?

How Caltech, MIT, Harvard, ETH, etc... test for CS skills? Certainly not with CP riddles - unless you take a CP course, which indeed is a separate [optional] course at some of those universities for interview preps specifically.

Very few companies to need people that have very strong CS skills. CS skills are mostly useful for doing CS. For example designing and analyzing an algorithm that’s more efficient than any other algorithm at sorting integers with an average of 10^40 digits on a three tag Turing machine.

While CP skills also aren’t terrible useful for most companies, they are closer than CS skills. What’s really needed are software engineering skills but unfortunately our most prestigious institutions think it’s beneath them to teach that.

>Obviously, each company can't blindly trust the interviewing practices of everyone's previous employer.

But even two teams within the same company often don't trust each other's interviewing practices though.

Transferring from one team to another often requires doing the same algorithm interview that new hires go through, even though you were good enough to get hired in the first place and are ostensibly a better engineer than when you started with the company.

> If you were capable of studying Leetcode so hard that you mastered the interview process at one of the most selective software companies in the world in only a few months, it's not much of a stretch to imagine that you could apply that same aptitude, ambition, and ability to learn quickly toward picking up the basics of git, dev ops, and so on.

So by that logic, why not just create some game for candidates to master. If all you're testing for is "how much they want it" and how quickly they pick up on some arbitrary system that they'll never use in their actual job, then the subject shouldn't matter, right?

They already have. And at the time it was being developed and gathering momentum, some plausibility as a thin defense of it was helpful. Why go through that process again now when the existing system is already firmly in place?

> So by that logic, why not just create some game for candidates to master. If all you're testing for is "how much they want it" and how quickly they pick up on some arbitrary system that they'll never use in their actual job, then the subject shouldn't matter, right?

You have reinvented the Chinese civil service examinations, congratulations. More generally the higher stakes a test gets the less the subject matter matters. If you make admission to Harvard or Cambridge based solely on interpretation and knowledge of pre 2000 rap it won’t be long until the same people who would have done well on a test of English literature are intimately familiar with Tupac.

There's no reason to believe that being able to learn leetcode tricks is a better sign of aptitude then being able to learn good software engineering practices.

That’s because at FAANG those problems are already solved. And there’s a team of experts working on each of them. Maybe multiple teams.

Your job is to be a clever code monkey. The Process will take care of turning your coding into engineering.

Leetcode interviews are great at testing for just that. A high IQ willing to solve arbitrary puzzles just because someone said “solve this”

Even at my mid tier company we have processes around the crucial but (to me) boring parts of the software industry, which involve building, deployment, version control, access control, connection drivers, requirements gathering, provisioning of resources, maintenance...

The list goes on and on and if someone doesn't do any of these things, the whole operation will grind to a halt. And absolutely none of these procedures involve reversing a linked list or traversing a binary tree inorder (maybe git does but that's an implementation detail hidden from me ^.^)

Correct. And as far as I can tell, devops folks don’t do leetcode interviews. Most SREs don’t either.

At my last interview process (in June) I was being hired into a more seasoned role where experience matters more than code chops. There was an algorithms question but the biggest weight was put on the “Can you design a distributed microservice infrastructure with good tradeoffs and solid relational modeling”

Series A company so it’s conceivable that I’ll be involved in all parts of the stack.

If I just did well on algorithms (I didn’t) and nothing else, it would be a hard no hire. But they were very impressed when I said “Eh for this load, you don’t need horizontal scaling except for redundancy”

But people are taught the basic boring skills required to deliver value in a big org in the first few months and very few fail to learn them in that time, they are by far the easiest skills to teach in software development so it doesn't make much sense to test it when hiring.

Were you not asked to do system design, or leetcode did enough for you on that?

Edit: assuming it's not your strong area based on the list of things you claimed not fluent with.

Let me ask you this: Do you think you are doing OK, or even great, comparing to your peers at your company? If yes, then I would say the hiring process is more smart than idiotic.

Can you share some tips on how you achieved this? What did you do if you got stuck on a question you just couldn't solve? Did you look at the answer and memorized it? How many questions did you solve? Were they mostly mediums or hards? What about system design, any specific resources you used?.

I keep coming back to leetcode every few months but I always get stuck on mediums so I'd appreciate any tips you can share!.

Working at the companies that often ask these questions (FB, Goog, Amazon, MS, Apple) work at scales that many other companies don't. They also develop novel frameworks or work on problems that might interest you.

Example: if you want to work for a cloud service provider you need to jump through these hoops, even though regurgitating Rabin Karp or Tarjan's has little to do with day to day engineering.

Another example: Canonical (Ubuntu) Microsoft (windows) and Apple (OSX) all ask these questions. If you want to have a part in building an OS you will get asked these questions.

Basically if you want to work at "big tech" start grinding and don't stop until you move into management.

I really wish I could leave the field altogether, but the alternatives are things I hate even more or incredibly steep paycuts.

Have you looked into being a software person in a non-software (or only "software-enabled") company?

You'd probably get a pay-cut vs. FAANG or whatever, but it wouldn't exactly send you tumbling into the working class.

I really enjoyed working on software in biotech, for example, where I started my career... and sometimes think about returning with all my software-company chops to see if it's still as fun!

I suppose it might depend on the domain / industry. Biotech sounds like it has the potential to be interesting, but I currently work for a large non-tech company and have worked in government and don't like the being considered the cost center or having to deal with the seemingly unending layers of bureaucracy.

In biotech, at least back in the day, bureaucracy depended on company size and nationality, and there never seemed to be enough hackers for all the random tech stuff that needed doing. I'm sure it's changed a whole lot since then but as a general point, it was a lot more diverse along any vector you like than the software world.

Maybe you should find a startup with no layers of bureaucracy and no cost centers yet? This being HN, there are plenty of them around.

I am trying to resist cynicism, but I too am thinking that after my upcoming sabbatical if I want to get top dollar I should just invest in power-grinding at the leetcode gym.

Still hoping to find a friendly startup though, since some of the MegaCorps are lifestyle-incompatible and I'm already used to making a lot less than Googlebucks.

> after my upcoming sabbatical if I want to get top dollar I should just invest in power-grinding at the leetcode gym

Given that top dollar can mean potentially a six-figure raise over median salaries, that doesn't exactly seem like a bad deal.

All things considered, Leetcode is remarkably accessible relative to the barriers of entry in other high-paying fields like law, medicine, certain finance careers, and so on. It's a mostly-free website that you can work through at your leisure from the comfort of your home, with plenty of Google results to walk you through the questions if you run into a problem.

Have you spend some time on Leetcode already? I could see how the questions could be daunting to new grads, but I didn't find it all that painful with several years of industry programming experience.

Don't get discouraged by the sheer number of Leetcode problems. You don't have to do them all to get value out of it. The key is to do a couple per day in your free time (lunch break, while you eat breakfast, whatever). Any consistent practice will add up over weeks or months.

Actually I love leetcode (the website) and do it for fun once in a while, and if I decide to go for a big grind later on then I don't think I'll particularly mind that part even if it doesn't get me my ticket to the Google Bus.

The risk of cynicism is that I've been doing this for 25 years or so and there are some things I'm quite good at that can add a lot of value to a company, but it appears that the highest-paying outfits will judge me on things that are at best very tangentially related to how I can make/save them money.

Sorry if my comment came off as anti-leetcode, I have a low opinion of the thing so many people use it for, not the site itself. Before hearing of my impending sabbatical I was even planning to subscribe to the "pro" level and build it into my work routine, just as way of differently exercising my brain once or twice a week.

> but it appears that the highest-paying outfits will judge me on things that are at best very tangentially related to how I can make/save them money.

IMO, this is a popular misconception but it's not really reflective of reality.

Leetcode is ultra-popular with new college grades and people with a few years of experience who want to break into Big-N. As such, the vast majority of Leetcode discussions online revolve around that demographic.

It's true that the Big-N companies will still be heavy on the algorithmic interview questions, but it's not true that they'll ignore everything else on your resume. The early 20-somethings talking about Leetcode online don't have a long resume to point to, so Leetcode is the focus. If you show up with a 25-year career of successes, you're going to have a very different interview experience.

25 year seems so extreme though, no? At that point, won't it be more around the Staff+ role, even VP/Director of Engineering roles?

> but it appears that the highest-paying outfits will judge me on things that are at best very tangentially related to how I can make/save them money.

This is very wrong, leetcode is just the baseline and don't determine your seniority. Even the best leetcoder in the world had to start at the lowest junior level after college. Instead they look at your experience and what value you can bring to determine if you become junior, mid, senior, staff etc, so they very much value experience not related to leetcode. However you still have to pass the leetcode bar.

Yes, I will have to pass the leetcode bar, which has very little to do with my actual value add. I understand that’s how it works, I have friends who hire for some of these companies, but thanks for explaining.

I strongly dislike having that bar, because I think it is irrational to use it as the baseline hoop everyone has to jump through. And honestly because it’s not my strongest suit, I’m sure I’d be less bothered if it was something I’m good at and your average fresh CS grad is not. Which is kinda how we ended up here I think.

How do I maintain flow? I end up extremely depressed and disillusioned if I get stuck on a problem - that’s really what’s stopped me from doing consistent prep.

What do you recommend for revision of the different problems again? Won't that take much longer time?

Sometimes due to disconnect for say a week of preparation it takes much longer time to get back into the groove again.

I'm glad that I am not alone. I've done mostly non-UI C++/C#/Java/Python stuff, mostly business level rules and devops and evangelizing good practices such as CI and clean code and git (you would be surprised how many people don't even know how what it is or how to squash and rebase). Having studied computer engineering we did not really focus on algorithm but more on lower level stuff and signal processing.

I do not really fit any of the "standard" interviews. I've done the TripleByte interview and other top 100 corporation interviews and they all seem to assume a computer science formation or if not than assume you are a web dev. So yeah, I know how to implement most algorithms efficiently, I just can't remember how to describe exactly Dijkstra's from memory or how to balance a tree on a whiteboard under stress. I've seen them, I learned them, but 7 years after not using them I forgot (and frankly don't care).

FWIW, I've found that companies outside the valley, particularly those that don't see software as their primary product, are more interested in work samples than puzzle solutions.

Try broadening your search to things like aerospace and medical technology companies.

> Try broadening your search to things like aerospace and medical technology companies.

Not sure what the correct name is, but most job listings I've seen for these industries strongly prefer people with prior experience in them because they have to follow strict frameworks / processes for safety reasons.

Kind of a meta point, but why do you call it the whiteboard interview? I think that was more popular 5 to 10 years ago, actually writing code or pseudocode on a whiteboard. In my experience the leetcode style questions most companies use today have you actually write and execute code in a sandbox environment.

It may be that the algorithms you’re required to come up with are still overkill in that they’re things you would not normally need to write from scratch on the spot without being able to references any resources in your day to day work. But as far as the format goes, this style of actually writing and executing code is clearly an improvement on the write-code-on-whiteboard style of interview.

I feel your pain though, the weeks of study that almost any good engineer needs to put into preparing for interviews can be pretty grueling.

I have 2 friends who work at the Amazon office in Denver. Both work on boring projects utilizing internal tools Amazon built over the years and completely hate their lives. But the salary and stock options make them stick around. You can look at this as "Omg, this is total shit. I'd never want to work here." or "I don't mind suffering 4 years to get fully vested, get the fuck out of dodge and enjoy retirement a little earlier than others." Both of my friends picked the latter.

I’m gonna take a wild guess and say that if it was Google they wouldn’t have that opinion, eh?

What do you mean?

I spent a lot of time practicing leetcode, interviewed a bunch of times (4 times, about 25 technical interviews) at FAANG without getting an offer. They always tell me it was very close (or even that I passed, but they didn't find a team in the following month and asked me to reapply).

What leaves me with a bitter taste is that they don't seem to value the experience on my resume (e.g. OSS and tons of github projects, blog or scientific articles, things written by me they could actually check). It feels like they will favor a candidate who can solve leetcode problems a little bit faster to someone who is a more experienced SWE. Also the whole thing seems pretty random.

Also practicing leetcode feels like wasted time. It's not uninteresting but after you solve 500 problems, it starts to get uninspiring. There are cooler things to do for personal development, especially when you already have a demanding job.

But well, that's part of the game... at least the rules are clear, and the interviewers/recruiter are usually pretty nice.

“ Also practicing leetcode feels like wasted time.”

I think take home assignments are worst in terms of wasted time. At least your leetcode skills are transferable whereas take homes rarely transfer.

One of the big unspoken reasons these questions stick around: they cause little imposter syndrome anxiety for the senior engineers who need to conduct the interview. You ask a candidate to code a toy problem, and the candidate either knows the "trick" to solving it quickly or they don't -- very little risk for you as the interviewer, you're just watching things play out.

But if your interview requires you to pair program on real code like you'll do in your actual job, it opens up a lot of room to look dumb in front of an interviewee. You have to handle bugs on the fly. You have to look up (for the 5000th time in your career) whether you should be using Array.slice or Array.splice in this case. You go back and look at a similar implementation in your code base for a template instead of coding from memory.

And that's a shame because the live coding exercise is both a better predictor of hands-on job success and it's a better recruiting tactic: you've just had a vulnerable, collaborative experience with someone who will actually be working with you on a regular basis and you get a sense of whether you'd actually like to work there. But we keep doing these algorithms exercises because they require such little effort or interaction from engineers who are doing this interview in between two meetings with no prep time.

>And that's a shame because the live coding exercise is both a better predictor of hands-on job success and it's a better recruiting tactic

I'm very interested in this claim. Every interviewing-is-broken thread, someone mentions that pairing, or take-home exercises, or work samples, or their favorite method, are better predictors than algorithm problems. On the one hand I doubt any but the biggest companies could conduct studies on this; on the other hand individuals at smaller companies might honestly remember only those times their hires filtered through this method were successful, due to confirmation bias. So it seems like an inherently difficult thing to study.

Whereas, algorithm questions lend themselves easily to a "rubric" and seeing, 1 or 2 years later, if higher "grades" corresponded to better job performance.

Even for the biggest companies the analysis is only going to be as good as the internal performance measuring system and how can a company gain confidence that is working?

There was a long discussion in the GCP thread yesterday about what google has been hiring and promoting for over the last ten years and what culture that produced. Any look-back at hiring methodology vs success at google is going to embed that implicit strategy. Among other things that means another company should very much not extrapolate from Google’s experience—-even if it is based on solid data analysis—-unless they are trying to replicate that culture.

can you link to that thread? Does it dig into how a focus on rote memorization of leetcode, has made a subtle influence in how the interface/systems are designed?

https://news.ycombinator.com/item?id=24167260

It’s more about building new things vs maintaining / improving existing things.

There are studies out there [1] from assessment providers

The problem is any one spending time on this question also has a vested interest in the answer.

FWIW my experience in hiring for my org and in the talent acquisition tech also reflects this . (Not related to the company in the link)

The reason usually this method is not as popular while the efficacy is understood is because it very hard to scale and do inconsistent evaluations and also takes a lot more time per candidate

[1] https://www.qualified.io/blog/posts/truly-predictive-softwar...

I think these interviews test whether or not you're willing to work hard-- you can't just use critical thinking to get the answer, you actually need to study to learn all the tricks. That's an important characteristic to screen for imo.

I would just keep my confidence. After all your job is to develop, not to solve whiteboard-puzzles.

If you have to solve something, and can't because it's dumb, or partially dumb, then just explain your opinion to the interviewer.

If they weigh that against you, then it's not a good company for you anyway.

Example: An interviewer once asked me details about POSIX-portability of shell-commands in devops-pipelines. I didn't know the answer, but I had done devops successfully for many years so I replied: "I'm not sure, but I don't really need to know that, because I put all my scripts in http://shellcheck.net/"

Which was a completely satisfying answer for him and one he didn't hear before. So points for me.

Your link doesn't work. I think HN makes you leave a space between the URL and the quote if you want it not to mangle the URL.

I think these questions are bad for interviews because they cause so much anxiety for candidates.

Minimising that will give you a better interview, as if the candidate is more relaxed that’s going to be a more accurate picture of a day to day working patterns.

I like pairing for interviews on a simple problem in a real app in the tech stack your hiring for. But really spend effort easing the candidate in rather than barking orders as soon as the come through the door (or join the video call these days I guess).

I absolutely love doing Leetcode/HR myself - and think they’ve made me a better programmer. I’ve frequently found times when coding where a “trick” has improved code in my side projects (I’m really interested in making bits of productivity software so trees, graphs and ways of speeding up searching over large portions of text are a real help).

Just grinding them out probably isn’t helpful to everyone but go in with an open mind and you’ll be surprised what you learn.

Yes it is. I had to make this decision as to whether I want to work on my personal projects, explore interesting topics or grind leetcode. To actually work on good projects the first step is leetcode.

I have a lot of interesting projects and I can talk a lot about OS kernels and bluetooth. To get to companies working on such interesting projects the gate will be leetcode type judges website. The questions they later ask are rudimentary and none of your effort on going deep into the such interesting topics matter.

For a good developer, those whiteboard problems should not be hard. In my experience, the people who are better at those “riddles” are learning and adapting more quickly.

One could, I suppose, split the cost by doing the exercises in a language you are still learning.

Unfortunately, Leetcode only has one of the two languages I'd like to learn, and the one I'm probably less likely to find a job doing.

Gosh, I don’t enjoy that there is so much competition in this space. I can’t compete against people who essentially seem to have no life or other interests than getting job at Big N (or enjoy competitive programming).

It feels like this culture has ramped up in the last 5-10 years. When I started interviewing, the questions were easier. It feels like they’ve gotten more difficult - or at least the answer the interviewer wants is less attainable.

And I feel like I know why - go look at the leetcode discussion forums. There’s almost always some post at the top saying, “I did 1000 problems and won’t stop. I got accepted/rejected and learned so much. Believe.” From the outside and inside, it looks like a cult. I feel like these folks are just making it worse for everyone.

Maybe I am just bitter because I’ve passed every mock interview I’ve done but I can’t get an offer from Big N still. Startups are the worst as a non-founder/non-executive.

> I can’t compete against people who essentially seem to have no life or other interests than getting job at Big N (or enjoy competitive programming).

Interview prep doesn't need to be a grind. One of the nice things about Leetcode is that the problems are bite-sized. You can do one or two per day on your lunch break and make a lot of progress in a matter of months, or even weeks.

Don't approach it like a cram session before your interviews. That doesn't work unless maybe you're a new college grad with no other obligations.

> go look at the leetcode discussion forums. There’s almost always some post at the top saying, “I did 1000 problems and won’t stop.

Obviously the Leetcode forums are going to be a hotbed of discussion about Leetcode. You have to keep in mind that many of those people are entry-level developers treating this as an extension of their education. For them, it's basically a miracle that a mostly-free website lets them practice for interviews for $200K-300K+ career paths from the comfort of their web browser. Compare that to just about any other high-paying industry, where getting the right education, credentials, certifications, and test results will take years of your life and potentially hundreds of thousands of dollars of post-secondary education. We really have the easy end of this deal.

Don't let the total number of Leetcode questions overwhelm or discourage you. It shouldn't be approached as a cram session before the interview. It should be approached as a consistent habit or practice over a longer period of time.

If you just don't want to do any Leetcode or whiteboard interviews, that's fine too! There are plenty of jobs out there that won't require any of that.

However, you can't have it both ways: Big N salaries come with a high barrier to entry. All things considered, spending 50-100 hours of your free time solving problems on a free website at your leisure is really a small price to pay.

> All things considered, spending 50-100 hours of your free time solving problems on a free website at your leisure is really a small price to pay.

The problem is - it's not 50-100 hours for most candidates to pass. I've done well past 400 hours of interview prep and never received an offer from Big N. I tried the consistent 1-hour or so a day for months thing - it isn't guaranteed either. Want to emphasize this point to - it isn't like I can't do the problems. I've solved most any problem I'm given - it's that it just doesn't fucking matter. Whatever bias the person has is what they will evaluate on - the problem solving is merely a formality.

I don't think it's just about solving the problem.

It's also about: - how you convinced yourself and the interviewer that your solution was correct (essentially an informal proof of your code)

  - how you test your code after you finish coding

  - what clarifying questions you asked to tease out a concrete question

  - what edge cases you thought of and how you handled them

  - how you handle bugs if they appear in the code

  - what solutions you presented and what their tradeoffs were, and why you decided to use a particular solution

  - whether your code was idiomatic

  - whether you used clean abstractions

  - maybe also comments and variable naming

... and probably others I'm missing.

I don't deny that interviewers have their biases, but I would hope that your interview performance is the major factor in whether you received an offer. There are plenty of people at Google and Facebook who haven't majored in CS at a top school.

From talking to some people who give out these interviews, most of those points really don't matter at all. What matters is A) getting a correct solution and B) being able to explain how you arrived at the solution. Tests, idiomatic code, clean design, etc are not expected and will inevitably waste precious time. Besides, the very nature of the interview (using a walled-off in-browser pseudo-IDE) restricts you from actually writing best-practice code.

As a counter point, I was in an interview loop recently with a candidate that ended up solving the question eventually, but didn't hit a lot of the bullet points in the parent comment (asking clarifying questions, edge cases, abstraction).

After discussing feedback from other interviewers, it was apparent that the same considerations were lacking in multiple interviews, and so the candidate got a no hire decision. For any single interview it probably would have been okay to omit these things, but when there's a negative pattern across multiple interviews, that's when it really hurts your chances.

How do you expect to convince the interviewer that your solution was correct without tests? How can you debug your code properly if you end up with a spaghetti mess instead of using a clean design?

Testing and debugging vary from site to site. Most of the ones I've used run your code against a hidden suite of tests to check all possible edge cases. This would otherwise take up a very non-trivial amount of time in the session. Actual debugging is also not possible on all of the sites -- usually the most you can do is litter your code with logs, which is far from a clean design.

No one is guaranteed a job at Big-N companies.

It's important to understand that Big-N job offers or rejections aren't a perfect indicator of a person's programming ability.

The interview process isn't perfect. It's not designed to be perfect, because that's an impossible goal. In reality, Big-N companies have so many applicants that some of them have higher rejection rates than Ivy League universities.

At this scale, the goal isn't to admit any and every qualified candidate. The goal is to select for the best of the best and minimize false positives, even if it results in a large number of false negatives.

Statistically it’s bound to happen that some interviews don’t work out. Sometimes the problem just doesn’t click, or you have a bad day, or you get unlucky and 1 interviewer is being extra strict and unfair. I have both passed and failed interviews at most of the FAANG companies.

Some of my coworkers will usually apply at all the big companies at once and say pass 2-3 out of 5 interviews.

However if you consistently can’t get through an interview loop without an offer despite having studied the basics and repeated attempts there may be something wrong that you are not catching in your interview prep.

Shoot me an email if you’d like some feedback, would be happy to do a dry run and see if I can spot anything obvious. I’m at @cosmin on Github, you can find my email address there.

Why are you complaining about the problem solving / leetcode culture if that's not what has kept you out of the Big N?

I find this little sub-industry building up around, “the coding interview,” to be highly strange.

Where are the papers that correlate this niche, specialized skill to general job performance and productivity?

I get that at certain problem domains the asymptotic complexity becomes a baseline for performance so I’m not against testing people’s knowledge where it’s appropriate. But is it really the dominating skill?

Reading some of the comments of people who went through the pipeline of this cottage industry, it sounds like it’s not even useful after you get hired. In fact optimizing for it to get through the interview sounds like a bad idea! Imagine landing the job and having no other skills.

I’m curious how these algo expert/monster/crushing the interview businesses survive and perpetuate this highly competitive environment.

> Where are the papers that correlate this niche, specialized skill to general job performance and productivity?

I would love to read this research if it existed in the public domain. However, much of this comes down to trade secrets and business practices. It's also not very amenable to controlled studies.

Practically speaking, these companies have a lot at stake in their hiring process. It's strange that so many people are convinced that the Big N companies are shooting themselves in the foot or otherwise making poor decisions with these interview processes.

Leetcode-style interviews might not have supporting research in the public domain, but absence of evidence is not evidence of absence. That is, just because the research doesn't exist doesn't mean that the Leetcode interviews are bad or worse than the alternatives.

Even if companies did eliminate Leetcode-style interviews, they have to replace it with some other alternative. Most of these criticisms fail to suggest actual replacement interview processes.

Anonymous google employees have claimed in HN comments that google has data showing that these interviews do “work” whatever that means.

Can any of you post more info here ?

On your last point, the best alternative I've seen is take-home projects where it would take less than a week to complete. The interviewer is free to frame a problem in a way that allows the engineer to apply their real-world experience and show their fit for the job. It removes all the variables around interview stress/anxiety and as a result is a better (but not perfect) indication of their performance.

> On your last point, the best alternative I've seen is take-home projects where it would take less than a week to complete.

Ironically, take-home interviews are another contentious topic on HN and other internet message boards. The common complaint is that people don't want to invest much of their personal time into interviewing for companies.

I wonder which takes more time, take home tests or LeetCode grind...

If I were interviewing I'd take a LeetCode over take homes any day of the week. Preparing for LeetCode prepares you for nearly 70% of the jobs you will likely interview at.

Whereas with take homes the amount of time doing say 12-take homes can easily be too much. You end up in this weird positions where you can only devote so much time for certain take homes but with the LC & System Design you can at least prepare once and hit up a bunch of companies.

I refuse to do take-home interviews. My time is valuable, and it's important that the company I'm applying to shows its seriousness by allocating interviewer time to interviewing me.

>I find this little sub-industry building up around, “the coding interview,” to be highly strange.

You should see the sub-industries around passing a board exam. Most of us really don't understand the privilege we have relative to other high paying professions.

Can you imagine having to learn all this just to make a connection to a database, process some data, and then persist it somewhere?

But it might come handy when implementing - route optimization problems - Building database query optimization engine

You can argue that not everyone is implementing these from scratch every day. But it could be argued that given an opportunity, an engineer should have the skills and ability to build these systems.

Bullshit.

It has been my personal experience, and the experience of many people I’ve spoken with, that this kind of trivia is learned in order to get a job and then forgotten immediately afterwards because it’s useless.

Anecdotal example: a former colleague is an incredibly talented systems programmer and has had to study leetcode garbage for the last few months in order to feel qualified to interview for a position with a team that he had previously been on at an older employer.

As another commenter said elsewhere, these types of questions are used because they’re legal proxies for “IQ tests”, and because they filter for people who are willing to sacrifice much of their personal time for the sake of the company.

I don't think the knowledge is useless as much as it's properly abstracted away into core libraries for 99.999% of the real-world use-cases.

Maybe the questions started as "IQ tests" (or a proxy for "fresh out of a Stanford-like CS Program?") but my impression is that now it's a mild (or not) proxy for hazing.

"I suffered through this crap and by God you are going to suffer through it to, or you can't join my little club, and by the way I just make a hundred dollars telling you that."

Edit: clarity & speling

I think knowledge of the concepts is very useful, but precise recall of the algorithmic implementations is absolutely useless.

It’s very different for someone to have a solid grasp of, say, cache-aware programming techniques, algorithms and data structures that are necessary for low-latency architectural work, etc.

...but I’m aware of very few positions (if any???) that require the ability to arbitrarily synthesize that information on the spot.

EDIT: Originally meant to lead with the fact that I broadly agree with what you’re saying, I just wanted to clarify my original objection.

In this regard. I like the google approach for not asking questions that are publicly available on internet.

These are basic computer science fundamentals and critical thinking capabilities that essential for performing the job atleast for software development roles.

> But it could be argued that given an opportunity, an engineer should have the skills and ability to build these systems.

Having the skills and ability to build these systems doesn't mean you can regurgitate all the algorithms required to build them on a whiteboard in 30-60 minutes. It means you have to ability to search for algorithms and apply them to your problem at hand over the course of several days, weeks, or even months.

Do you really think anyone building these systems spent only 60 minutes both deciding upon, and coding ANY of their algorithms and called it a day because they obviously chose the best one?

Isn't it what computer science is all about. You won't necessarily see the exact problem. But having the ability to reduce the problem at hand to an efficient algorithm that you might have "regurgitated".

The popular sentiment on computer science knowledge has done a complete 180 in the past several years.

Not that long ago, it was popular to complain that junior SWEs didn't really understand the algorithms, the data structures, and what was going on behind the scenes. The complaint was that they were just copy and pasting from internet searches until things sort of worked on their machine, but they couldn't recognize when an O(n^2) solution was going to work on their local n=10 test set but bring down the main website.

Now that knowledge of CS fundamentals has become valued in interviews, the pendulum has swung the opposite way. We have more free resources than ever before to practice and study CS fundamentals, algorithmic challenges, and even practice your interview skills. It's never been easier for a junior SWE to sit down, put in the effort, and work their way into a $200-300K job with sufficient dedication. Yet people never tire of complaining about Leetcode or having to understand CS fundamentals online.

Personally, I've never met anyone who was good at Leetcode yet produced bad code in production. I'm sure there's someone out there who knows a guy who knows a guy who can somehow ace Leetcode but can't write an efficient website backend, but it's not the norm.

> Personally, I've never met anyone who was good at Leetcode yet produced bad code in production.

It's all anecdotal evidence. I've worked with some brilliant people at most places I've been and I can't think of 1 person who even had LeetCode account. Producing great production code is more about experience and knowledge of the domain than knowing how to bang out algorithms.

> I've worked with some brilliant people at most places I've been and I can't think of 1 person who even had LeetCode account.

That's not the point, though. No one said that Leetcode is mandatory for being a good programmer.

The point is that Leetcode, however imperfect, is still a usable signal for programming ability.

Those excellent programmers you know would likely not have much difficulty with Leetcode style problems if they were to try them. That's the point.

> I'm sure there's someone out there who knows a guy who knows a guy who can somehow ace Leetcode but can't write an efficient website backend

I don't see what makes you think a person who can ace Leetcode should be able to write an "efficient website backend". These are different sets of skills. You can ace Leetcode and not even know what a backend is.

> knowledge of CS fundamentals

Leetcode is not CS fundamentals. It's a small part of CS fundamentals. Besides, candidates aren't asked to show they know the CS fundamentals. They are asked to show that they spent more time practicing leetcode than the other guys.

Leetcode is not a good indicator of quality code by any means. It's basically a filter. If one can't solve these programming questions, there is a higher chance that they are not good at programming compared to one who can.

> Personally, I've never met anyone who was good at Leetcode yet produced bad code in production.

I competed with this guy in competitive programming competitions and while he was fantastic at it, he wrote the worst code I've ever seen.

I've also worked with many people who've never even heard of Leetcode or similar and they were fantastic developers.

In my opinion there's no correlation here and it's purely a distraction.

> Personally, I've never met anyone who was good at Leetcode yet produced bad code in production. I'm sure there's someone out there who knows a guy who knows a guy who can somehow ace Leetcode but can't write an efficient website backend, but it's not the norm.

Weird. Ability to leetcode doesn't mean you know what is happening in e.g. an RDBMS. We've had people good at leetcode write a single query to delete hundreds of millions of records in a table with billions of records that was being constantly updated by the live website. Needless to say it didn't go over well. Ability to leetcode doesn't give you any knowledge that doing so might be a bad idea.

You can learn how to use some function to call into a database and study its behaviour, if you can grind leetcode and solve problems.

It's a good enough filter, the alternative is either way more costly or way worse(if you have seen "interviewing" which are just thinly veiled nepotism).

> We've had people good at leetcode write a single query to delete hundreds of millions of records in a table with billions of records that was being constantly updated by the live website.

You didn't have anyone reviewing their code and mentoring them? No one reviewed their design before it went into production? If no, why not? If yes, why wasn't the problem caught then?

> We've had people good at leetcode write a single query to delete hundreds of millions of records in a table with billions of records that was being constantly updated by the live website.

This says more about the ability of the other employees at the company than it does about the new junior employee.

Doesn't leetcode also have sql questions?

A good free algorithms book is http://algorithms.wtf (by Jeff Erickson)

I took his class way back in 2010.

Challenging but fun.

All the items are taken from Leetcode problems, but for the vast majority of them the author (labuladong) does not give attribution.

There should at least be a link to the related Leetcode problem for each section.

16+ years of experience and won several awards and designed multiple highly scalable systems in retail. Still cannot get into faang. These coding interviews gate keeping me..

9 years of experience, used LeetCode for preparation for two months (solved around 200 mostly medium problems) and got an offer from FAANG. Coding challenges at FB and G are not that hard nowadays.

Found in my bookmarks: https://leetfree.com/

Not sure if all quizzes are original, but some of them looks interesting.

Can anyone explain/interpret what leetfree.com is saying here?

> ... don't try to solve it with online judge ...

> ... Try to learn from the solutions we provided as quickly as possible ...

> ... Interviewers only care about your WhiteBoard communication skills ...

Are they implying that rote memorization (memorize all problems and their solutions) is the best/easiest way to do the interviews?

If yes, wouldn't that trip you up the moment you're asked something new/original?

If no, what are they saying? Is the best leetcode stuff paywalled and they're providing a free version?

what's the latest on step-by-step most effective way to get ready for standard coding interviews?

Context: I'm trying to get back into this after many years. I've used leetcode in the past but don't remember anything about online judge.

Online judge is competitive programming like https://open.kattis.com/ or CodeWars or CodeForces meaning a server that takes your source, compiles and runs it, tests if you satisfied all the req of the challenge. There's books for this https://cpbook.net/#CP4content and despite leetfree claims of being 'useless because no online judge in interview' there is actually 2-3 judges sitting there in the interview performing the same function, telling you if your code does not satisfy the problem requirements

Firefox says, "Warning: Potential Security Risk Ahead" for that website.

Nice how browsers have trained people to be scared if there's not a lock. It's just an expired cert, not revoked, and you're not entering payment information.

There's a reason certs have a limited lifetime. People should be trained to avoid such websites.

Thanks for the write up and git book.

Related question: I’m curious if any has game-ified algorithm learning, sort of like those old educational math games targeting certain grade levels.

Might be cool to make a point and click adventure centered around dynamic programming or greedy algorithms.

There are plenty of competitive programming sites where you can grind rating just like you would for MMR rating in video games.

For example CodeForces, AtCoder, TopCoder, and even LeetCode have rated contests

Thanks ghj.

I was aware of top coder/leet code, though hadn't heard of code forces/at coder.

For me the adventure game give a bit more concept linkage. Take Monkey Island, I can remember how to reply to many of the sword fighting insults, or what was needed to get pieces of eight via the cannon at the circus. There's something to be said for linking problems via a memorable story, giving examples and meaning from multiple angles helps retain the content over the dryness of problem prompt/quick solve.

Usually when you try to combine education with gaming, the result is something that's not very educational and not very fun.

It can be done, see Dragonbox Elements or Dragonbox Algebra.

For me, codeforces is fun the same way chess is fun. Yeah, the mechanics look dry on the surface, but lots of variation under the surface, and lots of chances to link concepts by having an aha moment during the contest or afterwards in analysis.

https://codecombat.com/

I am a self taught programmer (python). I learned things because they required to solve some problem. You face problem and then you find solution. I used to solve puzzles in childhood for competative exams. But now as adult, it is very difficult to connect with imaginary problems which you never deal in day to day life. It makes me feel empty - learning something to just get a job. Recently I picked up interest in OS because I started to notice my limit with application programming. I learn to write comments and importance of git, after working in startup where you keep wearning thousdands of hats daily and forgot what code last week. And I feel this is very organic approach to learn.

Being on both sides of table, whenever I conduct interview I just ask simple programs to do (mostly fizbuz) and try to gauge candidate passion by understanding projects s/he worked and problems faced. If candidate passes fizbuz, I believe s/he has basic understanding of logic. Other things can be thought easily if candidate has passion.

I have friends in university who only talks about algos but can't write single line of code (I am not blaming them, it is just their field doesn't require intense coding. What i am trying to say here is, writing good code is like craft. You need to write actual code to excel in craft. Solving leetcode problem successfully doesn't imply you can write good code automatically). Last time when I switched jobs, I studied couple of algos and now I forgot them. I am again switching and thinking to start with leetcode. The biggest problem in industry is hype. These days even small stupid IT shops are asking for hackerrank test with full stack developer. Lot of focus is still on memorization and hype.

Thank you for your guide. I do apologize in advance, but this tutorial, like others, simply goes into the _what_ to do and doesn't explain the _why_.

Forever math will be about memorizing these "tricks" and not understanding it intuitively - can someone please help offer some suggestions to me?

Is there a list of companies that purposely not use Leetcode in their hiring? Someone should make one.

https://github.com/poteto/hiring-without-whiteboards

What language should you grind leetcode in for FAANG? Or does it honestly not matter. Like C# or Javascript, for example?

"fucking algorithms" such a good repo name tbh.

This is really sweet. Thank you kind sir.

This is really cool. What order are the chapters in? Seems intense to lead with dynamic programming.

I got really good at dynamic programming problems but then none of the companies I interviewed with asked me a dynamic programming problem. These were large tech companies and well funded startups. Perhaps it was just luck.

Partially luck and maybe you never solved it with a DP solution. There are problems for which DP will give an answer but it isn’t a hard requirement for you to come up with it.

I’ve received quite a few DP problems in my time interviewing.

Then again, I feel like saying I’m unusual. I’ve received a lot of very difficult problems. Almost like the people are trying to set me up for failing. ;)

DP solutions were really in vogue for awhile, and seem to be asked less now. I heard a completely unsubstantiated rumor that FB found them to cause high false negatives because they're such a tricky and specific problem type. Also, once you know the "one trick" to solving them they don't help illuminate candidate thinking.

Questions with DP solutions are usually not particularly great for interviews. They usually don't have any solutions in-between brute force and DP. If somebody doesn't come up with a DP solution you, as an interviewer, just learned that they don't know DP, but it doesn't give you too much useful signal on the candidate's skills. DP is just kind of a trick that you can learn to solve this specific type of problems, but knowing the trick is not something that FAANG companies want to test for.

I tell interviewees to practice some dynamic programming problems because dynamic programming questions are the least intuitive, and it's good to be prepared in case that's what you get asked.

For the same reason though, I think they make for terrible interview questions - very much dependent on knowing a specific "trick" that doesn't actually come up often in day to day coding.

DP as a paradigm is very interesting. From a high level view, one can appreciate the essential concepts that make it work, with things like memoization, optimal substructure, etc. It's also interesting how it relates to shortest paths problems, and greedy algorithms.

However, as you said, actually trying to solve DP problems relies on knowing the trick, and the tricks varies almost wildly from problem to problem. They're unintuitive, and difficult to derive normally. The intuition you gain from one of them could be entirely useless, or, worse, counterintuitive for another. I personally think, they shouldn't be used for interviews because being able to solve them seems to be more a matter of luck than actual competence.

I haven't seen gitbook before, is this a common tool for documentation?

Occasionally you see a gitbook on HN. It is mostly for well... books and educational content.

Edited to remove

Sorry for stating the obvious, but money is a pretty big reason to continue doing leetcode style interviews. Most high paying employers ask them. Out of curiosity, how much does your no-leetcode job pay? Is it at least $200k?

> If it comes down to it, maybe I’ll move into hardware design.

Hardware jobs generally pay less than SWE, you'll lose even further on the monetary aspect.

repo name is on point

Why is the title censored?

As a European citizen, I absolutely don’t get it. Why can’t we say fuck on the internet?

Just personal preference. I made this title by myself other than censorship. Anyway, “fuck” sounds a little rude.

Is this evidence of the 996 culture?

996 is a universal culture.

People who wish to master a skill on their own time are simply pursuing an intrinsic (/identity-based) goal: here, excellence in computer science.

Evidence of Leetcode culture more than anything

FYI https://en.wikipedia.org/wiki/996_working_hour_system

"The 996 working hour system is a work schedule commonly practiced by some companies in the People's Republic of China. It derives its name from its requirement that employees work from 9:00 am to 9:00 pm, 6 days per week"

Looks more like tech interview culture.

Temporary comment for following and future retrieval of this post.

Imagine what would happen if everyone did that!

Some practical advice: HN has two ways for you to do this without cluttering the discussion. You can simply upvote the post, or you can favorite it.

Both of these lists are available at the bottom of your profile page:

https://news.ycombinator.com/user?id=Gummaluri

Be aware that favorites are public, while your list of upvoted posts or comments is private. (View your profile page in an incognito window to see what the public sees.)

Reply on news.ycombinator.com