Ask HN: Is the Age of Leetcoding Dying? | Hacker News Reader

Ask HN: Is the Age of Leetcoding Dying?

I noticed from my peers network that more and more people land jobs in FANGs without knowing how to leetcode.

This is mostly happening thanks to the "Frontend Hiring Route" where engineers typically just need to show they know how to use React (eg. FB, Apple) - but I've heard (mind you, a few years ago) of people squeezing in Google Deepmind just by knowing the topic they're supposed to work on (shocking!) instead of having to spend months practicing puzzles.

I suspect we'll see this trend getting stronger with AI and companies requiring a lower number of developers with more specialised knowledge

Am I seeing things / too hopeful?

View on HN

No, Leetcode interviews are very much alive. I have interviewed at all three companies you mentioned for frontend roles & they all ask Leetcode questions, but to varying degrees.

FB: I currently work here. LC style questions but with a frontend twist. Best believe if you don’t have a strong handle on algorithms, data structures and Javascript, you won’t stand a chance.

Google: Phone screen is leetcode, during onsite they ask two leetcode questions & 1 frontend focused one.

Apple: Phone screen is Leetcode, onsite is a combination of leetcode & frontend.

I actually find frontend interviewers to be harder because you have to have a strong handle on frontend technology + data structures and algorithms, as opposed to non-frontend roles where just doing leetcode is all you need.

Also, there is the very wrong notion among people ignorant about the frontend engineering world like yourself that assume all it entails is simply knowing how to use React & CSS. It is more complex than that, you’d have to know about the DOM tree, know how to manipulate it, think about accessibility & performance. It can become complex very fast. Most of these interviews create Leetcode style questions from DOM tree manipulation & they are harder to reason about.

That's very interesting to hear your perspective!

I applied for a frontend position 1-2 years ago at FB. I thought I was going the Leetcode route so I prepared for that but somehow my application went through as a frontend position (because my CV and OSS is mostly frontend React and then some node.js), I was just asked some JavaScript basic algorithm (nothing you need to prepare for, implement a stack and something else similarly simple) && CSS (which I bombed completely, I certainly haven't used CSS without some sort of abstraction for the past 10 years, I certainly won't get it right at the first shot). I didn't pass eventually.

I have a friend who joined FB for a year (left purely for the stock decline, he was doing fine performance wise) and had a similar experience with zero LC asked.

My wife went through the normal engineer route a few months prior that and got asked only Leetcode.

My friend got hired at Apple as a frontend engineer and got asked zero LC.

I disagree on the perceived hardness, I feel like LC interviews are way harder than frontend engineer ones but I might be biased as I've been doing frontend for almost 20 years. My point is, the reasoning ability you need to have to solve LC (unless you memorise most of them) is way higher than getting the logic right for a frontend exercise. I would not call them "LC style with a frontend twist".

I did a couple FAANG interviews last year, and I was pleasantly surprised.

The coding questions were novel (so no needing to memorize tons of existing questions) and non trivial, but did NOT require obscure algorithmic knowledge or esoteric math. They wanted lots of working code, and for you to explain your thought process. So I was definitely happy I practiced on hackerrank and leet code, and think anyone would still need to practice coding under some time pressure, but it was a nice experience.

Contrast that to Microsoft interviews where they would just straight up ask me "code a way to find the shortest path in a graph". "Merge two streams in optimal time". just asking for me to implement code straight from Algorithm textbooks and hackerrank questions.

The MSFT questions you described leave out 1/2 of the problem - which is understanding what algorithm to use/what problem you are even solving.

I have no qualms making the interviewers extremely uncomfortable with questions like:

> Does this role require implementing two-dimensional dynamic programming problems? Seems like this is very poor benchmark for finding the right people to accomplish your business goals.

Anecdotally it works well filtering out mindless bullshit companies. The kind of companies that operate with a school of fish strategy rather than stand out and think different.

> but I've heard (mind you, a few years ago) of people squeezing in Google Deepmind just by knowing the topic they're supposed to work on

What position? No coding test for a research scientist is more plausible than no coding test for a software engineer.

Is the test administered remotely? I wonder how many employment tests have been taken by ChatGPT at this point.

Today a front end designer needs to read 50 documents to understand CSS, not least be able to make a small change to a web site without it all falling down like a pile of Jenga blocks. That makes coding a fast suffix tree building algorithm out of your head look easy.

In the case of React you could ask questions like "why does this simple web page call the render() method 714 times?" and then the interviewee says "that's wrong, it calls render() 715 times" and they will have to bring in one of the React core developers to adjudicate.

It was for a ML engineer position!

I remember being mad jelly at the time, he had 1-2 years of experience coding in Java, he had studied some ML at uni and he didn't even have to do LC to land a job at Google

Reply on news.ycombinator.com