Ask HN: Did preparing for LeetCode type of interviews improve your skills?

[wreath]

I'm not new to the field and I have nearly a decade years of experience under my belt. I'm currently job hunting and decided I'm not gonna shy away from LeetCode type of interviews as before (I used to refuse to proceed with any company that had this as part of their interview process) and actually give it a shot.

As I'm doing some Hackerrank/LeetCode exercises, I'm actually enjoying solving these puzzles. I'm wondering if anyone who went through this prepping for an interview ended up being technically better overall. I know that I rarely needed this kind of skill in my career, but also I'm wondering if there were cases where I did need them and I didn't know.

Cheers!

[msteffen]

My feeling on this is mixed—I competed in ICPC in college, which is a competitive circuit of programming contests (like leetcode, but predating it) and went to the world finals, which is easier than it sounds but not nothing. I think there are a few levels on which this sort of practice might help your career, and the question of whether they do help depends on which level you mean:

1) Learning the algorithms. I agree with the general criticism that these algorithms aren't that broadly applicable. I work on data storage software, so we use a few relatively fancy data structures, but even so most of my day to day work isn't on the code that manipulates them. That said, I think succeeding at these contests (especially when they're timed) requires you to practice avoiding bugs, particularly off-by-one errors, and I think that practice is pretty broadly applicable.

2) Thinking in terms of data structures. The data structures that a program uses are a lot more important than the actual code. Some critics complain that programming contests teach you to write messy code. I think that the people who are really good at programing contests who write messy code (ime, it's more compact than messy) do it because they've trained themselves to look at a program and see the data structures rather than the code, and in my opinion that's a better way to think about a program.

3) Learning to get good at something in general. This is the main reward I feel like I've gotten from these contests. I think many skills in life (including job performance and career advancement) can be developed the same way: study the rules, study the best competitors to understand what's achievable and what techniques are available, make an attempt, try to understand the results you got, try to improve your approach, repeat. I think programming contests are a great place to learn to do this (among many others, of course).

[jameshush]

"Learning to get good at something in general" is the real thing these kind of tests proxy for.

There's a lot of things in life that are a pain in the butt, hard, and stupid that you just gotta do.

I went through the leetcode grind a few times, the last time I went through it I ended up taking a job at a startup that I was using as a "practice" interview before the FAANG ones because I could relocate out of California. I never would have interviewed there though if I wasn't laser focused committed to leaving my previous job for a better opportunity.

If you're the kind of person who grinds leetcode, you're _probably_ also the kind of person who spends the extra time reading all the documentation for redux. Or spends the extra time writing a tricky unit test before shipping something. That being said, there's still _plenty_ of people who fail leetcode phone interviews (e.g. myself) but go the extra mile, and FAANG companies still manage to let some questionable hires through the cracks. But engineer hiring is currently a filtering game, not a sourcing game.

You can either learn the rules of Monopoly and play or sit in the corner during board game night and complain you're not playing checkers. shrug

[nsonha]

> they've trained themselves to look at a program and see the data structures rather than the code, and in my opinion that's a better way to think about a program.

I don't see how this is mutually exclusive to writing readable code. I'm not good at these but I picture good code in your definition to be utilizing data structures in an intuitive way instead of coming up with some novel but wacky performance trick.

[harryputtar]

I think as somebody wfo too as competed in ICPC albeit not at world finals, I just want to add an important caveat, getting to world finals has a lot to do where are you from, for example if you are from a historically tough university or place such as India, Belarus or China. It is exponentially harder since due to how ICPC works the rules make it a piece of cake if you are from an unnamed college in norther America but much harder if you are from an established IIT in India or from somewhere like university of Tokyo.

[tester34]

>look at a program and see the data structures rather than the code, and in my opinion that's a better way to think about a program.

that sounds pretty difficult for me to understand

when you read the code, analyze and understand it and due to your experience you see that something is bad (e.g poor api), then how can you "lose focus" from it / ignore it?

how it ain't just lack of experience or simply not caring?

[sdevonoes]

I have to thank LeetCode for one thing: it made me realise that,

1) preparing for an interview doing LeetCode puzzles two weeks before is like studying for an exam the day before. It's worthless. If you haven't been studying the subject for months (i.e., if you haven't been working as a software engineer for years), then nothing will make you pass the exam. And even if you pass the exam (because, you were lucky and the questions in the exam were the exact bits you just studied in the week before), you don't really know the subject: you'll forget what you studied the following week.

2) I can successfully avoid companies that require LeetCode interviews. I thought I would be out of the market if I rejected such companies, but it turns out that's false! In my limited experience, around 50% of companies out there do not require LeetCode-kind-of interviews.

Don't get me wrong, I do enjoy solving programming puzzles but only on my free time, not because a company is telling me to do so.

[bialpio]

I'm looking at it like this: if I have to _prepare_ for an interview after being in the industry for almost 6 years, then the interview is testing different skills than what I'm using in my day to day job.

Edit: clarifying a bit: in an ideal situation, my preparation for the interview would involve going over all the work projects and reviewing how to talk about them.

[gaws]

> I can successfully avoid companies that require LeetCode interviews. I thought I would be out of the market if I rejected such companies, but it turns out that's false! In my limited experience, around 50% of companies out there do not require LeetCode-kind-of interviews.

How do you know this detailed information ahead of time? It's not a surprise companies say they'll do technical questions, but those specific to LeetCode? They don't share that.

[jim-jim-jim]

I thought it was a waste of time because the most optimal solutions tended to require a stateful, even pointer-diddling, style of code that doesn't align with what I do in the real world. I'm sure they're fun and enlightening to some extent, but I'm not really interested in programming like it's still the 90s.

In Australia I have fortunately not encountered a company that uses these puzzles in interviews. I feel bad for my friends in America who have to practice them every time they switch jobs.

[hnzix]

Working closer to the front end, I've found that a solid foundation in SQL (to prevent ORM explosions), regex and basic app architecture is far more useful than deep algo knowledge. I've had to use tree traversal like a handful of times and bit shifting like twice.

Let's not talk about working with dates and times.

[xupybd]

Yeah I find in business software an optimal algorithm is not worth the cost of readability.

Most of the applications I work with have moderate data and few users. It has to work robustly and has to be easy to modify.

[nsonha]

> most optimal solutions tended to require a stateful, even pointer-diddling, style of code

not necessarily, a search problem can be solved in a functional way in 2 steps: 1) constructing a search space in lazy stream, this is where dfs or bfs happens 2) filtering the stream using standard filter function

Similarly if you do dynamic programming using memoization instead of tabularization you might not need any state

I think, like practical problem solving, algorithms have been predominantly taught in a stateful way of writing code that was popular because of the computing power constraints back in the day. That doesn't mean that's the only way to write them

[nsonha]

We use it less but they're there, mostly for filtering. It's hilarious because there was one time this company sent me an easy hackerrank. I nailed it, did interviews with them, one of which they followed up on the lame hackerrank instead of something useful like pairing or system design, nailed that too. Then they called me after the final round and asked me to do a dynamic programming problem, just so they "have one more data point". I actually tanked that one but at that point I already felt they didn't know what they were looking for anyway, one of waaax

[lloydatkinson]

Wanted to echo the same sentiment but from the UK too

[erklik]

> In Australia I have fortunately not encountered a company that uses these puzzles in interviews.

The big ones are definitely doing it. FAANG of course, but also Atlassian, Optiver, Xero, Akuna etc. I am not sure, but maybe it's more common in the less experience levels? I am not experienced enough to know hiring after 5YOE etc.

[seestraw]

For all the hate these interviews get, they do make you a better programmer. Before doing these problems I had no framework for thinking about how to program optimally. Doing these problems helps a lot.

Don't fall for the hate people give. Every selective interview process gets hate. It's extremely useful for your development as a programmer.

Edit: I do think it's not good when there are bad interviewers. For example, interviewers who don't give you a chance to think, or expect you to know the perfect solution rightaway. Or just arrogant interviewers :(

[ozim]

I don't hate selective interview process.

I hate it when interviewer is an asshole. Somehow in my experience companies that have 'Leetcode' or that kind of thing in process have interviewer that is an asshole.

If someone thinks he is better than me just because he is in a position to ask questions, well that leaves me frustrated for the rest of the day after interview.

It is specially frustrating when you already have the experience, I am now almost 10 years and a senior dev and I cannot really put up with it.

When I was a junior trying to find any job I was not offended at all, but I still remember all bad interviews.

[spoiler]

I agree to an extent, but at my company we have hired a few very intelligent people who ace these leet code algorithmic interviews, but they're at the same time the most incompetent engineers in the company.

On top of prematurely optimising code that executes once in a blue moon and creating an unnecessary maintenance burden, they also lacked any skill in designing codebases whatsoever, and generally pick the worst solution for a problem (which is sometimes detrimental to performance overall, even if the "local implemenation" is great) Most of my refactoring nightmare situations were caused by leetcoders.

Maybw it's just anecdotal, but in my experience there's been a strong correlation.

Also an aside: they tend to be quite a bit snobby/circlejerky and vastly overestimate their skills. IMO, leetcoding is a skill but not the most important one. And also, once you start approaching software as design/engineering, the leetcode will start coming gradually and naturally to you.

[hocuspocus]

> Before doing these problems I had no framework for thinking about how to program optimally.

You didn't study CS in school?

> It's extremely useful for your development as a programmer.

Can you give some concrete example?

[tmsh]

Let’s say you have some interesting challenges in a new space in deep learning and you like to hire people who can ramp up and learn the area relatively quickly.

Or let’s say you have a massive set of services you need to integrate with to solve your next set of business commitments for the coming year.

How do you hire folks who truly have the motivation and speed of learning to solve these areas on your team? Both are proprietary subject matters. Both haven’t really been done before and require a tenacious self-starter.

In that sense leetcode + team player/leadership qualities might make more sense.

Yeah it’s CRUD more or less 80% of the time re: code. But the ability to tackle ambiguity in an overwhelmingly large space and still be inventive: that’s what’s being tested. And as you get more experienced the technical assessment skews to system design which is also a good bar for just - how do you consistently simplify technical and organizational complexity?

It’s why FAANG + unicorns’ compensation is high. It’s a correctly-priced asset in the market. To the business these are important functions.

Does it have anything to do with pure programming for having fun’s sake? Why Linus created Linux? Only loosely.

[b20000]

leetcode style interviews do not test the skills you need for what you describe, those skills come with experience, not by practicing leetcode until you can produce solutions in under a minute.

[texaswhizzle]

LeetCode is an excellent collection of problems you’ll never encounter in real life. If you don’t have a computer science background you might learn some things. Otherwise, it’s just solving silly problems for the sake of solving silly problems.

It reminds me of when my college required linear algebra for my degree. Learning things that I knew without a shadow of a doubt I would never put to use again.

[arduinomancer]

Funny, linear algebra is essential if you want to do anything machine learning or graphics related.

More so than LeetCode

[Kim_Bruning]

You know how some people think that fizzbuzz is useless, and how no one ever uses fizzbuzz in real life? if you google it, you'll read things like "I have never needed to write fizzbuzz in production in my entire career!" or words to that effect.

Of course, fizzbuzz is just checking if you grok some super basic programming concepts like logic, branching, and iteration.

So what if you want to know if someone knows a little bit _more_ than just the basics? It's the exact same story.

The ability to be able to work with algorithms and puzzle your way out of a problem is kind of important when you're doing some sorts of programming, especially when you need code that scales well (up OR down).

If you're really bad at it, you might write pessimal code that even overheats your regular laptop; but fortunately most people aren't quite that bad. ;-)

[hocuspocus]

> So what if you want to know if someone knows a little bit _more_ than just the basics? It's the exact same story.

> The ability to be able to work with algorithms and puzzle your way out of a problem is kind of important when you're doing some sorts of programming, especially when you need code that scales well (up OR down).

The main issue is that many companies don't do that. They ask leetcode questions because Google does it. But they expect you to have seen the problem earlier and memorized the solution.

[ping_pong]

What LeetCode does really, really well is have a ton of test cases and chances are you will fail one of them and will have to try again. So they may explain a problem to you, but they never tell you the edge cases. For example, question #2 is adding two numbers where each digit of the number is a node of linked list. Simple things like carrying a 1 is easy to forget, but then you need to deal with other edge cases, like what if the lists aren't the same size, etc.

So in terms of testing and finding edge cases to handle, it's really eye opening how deep you may need to go. When I do LeetCode, I try to write my program once and if I fail a test case, I consider my attempt a failure and move onto the next question.

But otherwise, it doesn't make you a better overall programmer. There's no incentive to write maintainable code, and you're incentivized to get the code running as quickly as possible by trying to shave off milliseconds, which usually don't matter as much in real world situations.

[wheelinsupial]

Do you mind elaborating on why all of these test cases doesn’t make you a better overall programmer?

I think this would be a great thing to help in coming up with requirements and writing code that doesn’t crash because of edge cases or malformed inputs?

[austincheney]

Actually, usually the opposite.

I do more challenging work as a hobbyist than as an employee, by several orders of magnitude. The cause for that is that as a web developer the emphasis on work and capabilities is entirely around knowledge of tools. If fact it is pretty extreme to the point of people often telling you to deliberately avoiding writing original solutions to problems, even if quick and minor, if instead you can download an untested package from the internet.

See:

* https://en.m.wikipedia.org/wiki/Invented_here

* https://news.ycombinator.com/item?id=27310461

I usually excel at the leet code portion of the interview and then immediately bomb the next round of interview when I advocate for writing code, originality, and portability.

[kodah]

I came into software as a dropout. I'll spare you the back story, but it was for good reason. I dropped out junior year.

1. I think professionally testing algorithm knowledge is fine, but it needs to be one and done. I want a certification and I don't want to have to do it again.

2. This knowledge is largely useless in actual programming. It does teach me how to interrogate data structures and how algorithms work well with certain data structures. This kind of knowledge will only be relevant later in your career and at a certain type of company though.

So, am I better? Yes, I think I am, but I don't think I'd thank algorithms for that. I thank an innate desire to learn that happened to be briefly applied to algorithms and data structures. The hyperfocus on algorithms misses the forest for the trees.

[pydry]

I find it's usually a signal that:

* The company is cargo culting Google or it is Google, in which case it's cargo culting hunting down people like Larry and Sergey.

* The company makes decisions based upon safety in numbers. "Everybody" interviews this way, so if you're worried about justifying your process in future, it's a safe option.

* If this system selected me for a $200k / year job, it can't be all that bad.

* It does correlate somewhat with ability.

[MeinBlutIstBlau]

Also it's a standardized test to prevent bias. HR could've pushed for it too.

[b20000]

it doesn’t matter that you can solve them, you need to be able to solve them in under a minute while your interviewer is constantly distracting you. so basically, it has nothing to do with being able to build software.

I have been writing code for more than 25 years now and graduated top of my class in CS. I also have a degree from a US ivy league school on top of my CS degree from europe. I developed and launched 4 succesful products. I won awards for my work and I’m a semi celebrity in my niche.

I recently went through several FAANG loops and did not pass their retarded leetcode questions. each time i had the feeling it had to do with not being FAST enough or not producing the EXACT solution the interviewer wanted.

what is funny is that I got one interview where the guy asks me to solve a problem that gayle mcdowell (cracking the code interview) spent ONE HOUR solving in a video provided as “training material” to candidates, YET they wanted me to do it in a few minutes WHILE EXPLAINING what i was doing.

the above is why I no longer participate in coding interviews.

for all those who think people who pass these interviews are “better” engineers: this particular FAANG has shipped broken SaaS products for years, despite having the “smartest” engineers on the payroll.

[random42_]

it doesn’t matter that you can solve them, you need to be able to solve them in under a minute while your interviewer is constantly distracting you. so basically, it has nothing to do with being able to build software.

I realized that my issue with this style of interview are not the questions, but this exactly. I can solve lots of Leetcode problems, some just take me longer than others.

It’s even worse when the interviewers behave like you described. Most I’ve met, luckily, were cool and just followed what I was doing eventually asking some questions and sometimes giving me pointers; the worse I’ve found would not accept any solution I proposed and would keep asking “how about not using extra space or how about solving in O(1) or how about you solve this in 5 seconds”. So freaking annoying.

[Dave3of5]

I have 15 years working for a bunch of unknown small businesses under my belt so I'm in a similar situation. The answer for me is a resounding no it did not help in the slightest. I too actually enjoyed doing these problems personally.

I think the types of companies using these tests are the big FANG type companies and they are mostly recruiting more junior people so for them 10, 15, or 25 years experience doesn't matter. They don't care how long you've been working just if you can balance a binary tree or solve NP hard problems in under 15 minutes.

So if you are applying for a FANG type job then yes definitely but the likelihood of you being picked is actually really low. Why you ask ? Because ageism is rampant in the tech sector so the FANG companies almost exclusively hire younger candidates (with 10 years experience you're not young).

What about other smaller companies using similar tests though? That's true but I've found most small companies that do these types of tests don't hire for some reason. I think they reject a lot of employees as they think they will get better candidates. So the likelihood of anyone getting a job there is really low.

[yoyonamite]

My guess for the small companies that don't hire is that it's the incentives. If my outcomes as the hiring person are that a bad hire is a large negative, a no hire is a very slight negative, and a good hire is a slight positive (possibly even neutral), I'm going to prefer no hire most of the time. I believe this is a fairly common decision matrix.

For example:

bad hire lowers managements' opinion of my performance and can be costly to team morale, especially if company culture makes firing difficult

no hire can be blamed on lack of qualified developers rather than a competency issue

good hire is nice, but if current development team can push back on workload, that benefits the company much more than the development team

[dominotw]

> Why you ask ? Because ageism

They expect you to be M1 roles at facebook if you are in your 40s. Not compete with fresh grads.

[zaptheimpaler]

No I don't think it has helped my skills at all. In the rare one or two cases in my career where I've needed an advanced algorithm, I had plenty of time to look up the best way to do it online.

I think it is important to know WHEN you're facing an algorithmic problem, and to be able to generalize your problem enough to recognize what kinds of algorithms might apply. But leetcode style questions as currently posed go way beyond that imo.

[bialpio]

I found that preparing for LeetCode type of interviews improved my skills of solving LertCode type of problems and did not change how I performed in my day to day job. IMO the type of work is so dramatically different that I don't think they will bring any value, maybe except in the cases where you're dusting off some language you haven't been using in a while.

[captaincaveman]

Useful for refreshing concepts I'd learnt/coded at Uni, 20 years ago and not used since ... which isn't as snarky as it sounds.

Basically with a bit of drilling, a competent programmer should be able to get the hang of those questions, and maybe the fact you can get competent at doing tricky, niche things is a useful indicator.

I wouldn't say doing leetcode would in anyway make you better at writing clean, well structured code, which is what we typically interview for in non FAANG. Probably does help sharpen your cracking out gnarly inner loop type coding skills i.e. better at writing a difficult function, doesn't do anything for how you would write the rest of the program.

[henrik_w]

I interviewed with 3 companies recently, and all had some kind of coding test, although not all of them were Leetcode-style problems. But I did practise on Leetcode before, and it was useful for passing the interviews.

However, in my experience those kinds of problems don't make you a better developer. They are almost the opposite of what you do day to day as a developer.

I've written more about it here: https://henrikwarne.com/2021/04/19/recruiting-software-devel...

[ssaturn]

I am on the job hunt right now with about 5 years of experience. How do you find jobs that do not require technical interviews? Every single company I have applied to (about 10 so far) has required LeetCode style interviews

[wreath]

Maybe in Europe it is different? There is still a coding part, but is somewhat relevant to the job position (build an API that does xyz etc)

[redis_mlc]

As of 2020, most SV interviews for Devops/SRE were not Leetcode - just normal programming, though possibly kinda lengthy.

In 2021, it's a few percent higher. The one I saw recently was related to checking for N matches against M permutations.

All required passing a test suite.

[csdreamer7]

Yes, and no.

I thought I was a good Ruby programmer, but preparing for a FB interview in Ruby, and bombing an earlier one, really showed me how slow I was with the syntax.

Leetcoding really improved my grasp of the language.

[lordnacho]

I would say yes. A few years ago I signed up for one of the test sites as an employer and downloaded all their tests. I then solved them myself, well sorta half of them.

It's easy to say that such tests are useless, and they probably are as a tool for judging coder skill. However when I did a few of these it did open my eyes to a few common solutions that I could apply in various places in my code. If you read through an algo book you'll probably find a few things that are a bit surprising like Kadane's algorithm, or some things that you kinda know how to do but you need the last piece of the puzzle for, eg various graph algorithms (is there a loop etc).

I'd say the main benefit is that it illuminates what kinds of things you can solve and what kinds of things are tricky (eg knapsack), which is a useful intuition to have.