Widespread interview advice targets the "worst-case technical interview scenario" which is doing leetcode and running a gauntlet of interviews. This casts the widest net possible in terms of how many interviews you'll pass. There's also a little bit of reasoning like "if you can handle this, you'll be able to ace the easier interviews".
The other things for job hunting - like using your network and being contacted first - are additional layers that you go through.
>In my 10 years of being an employed dev, I have never had to do leetcode interviews.
I think the reason you hear prep advice so often is that no one has any real data on how many companies are doing leetcode interviews vs. non-leetcode interviews. Because of this ambiguity, that's why you hear so much advice about preparing for the worst case.
Part of it is that I’m pivoting from systems software (Linux kernel) to webstuff. I have zero network here, if I wanted to do systems again I’d have an easier time of it.
That said I would be a little suspicious as a mid/senior-level developer if I got hired at a place that didn't ask me to do any coding for them at all beforehand.
I'd be suspicious if they didn't ask me to do any coding, but I'd be just as suspicious if the coding they asked me to do was leetcode.
While it annoys me as well to have to brush up a little, someone who has both the discipline to review their fundamentals, and that can demonstrate they have the smarts to be good at it, that's a great sign of being a good candidate.
It serves as a great arbiter, if two people seem to have the same experience, how do you pick between the two?
And when hiring a junior, out of school, there will be no experience to go by, so what else would you assess on?
I'm opposed because I don't think it serves as a great arbiter. At best, it selects for logical/academic ability, whereas IMO the most important skill as engineer is pragmatic decision making and building an appropriate solution. In practice it just selects for people who have studied leetcode (and to a lesser extent, those who have a CS degree)
> if two people seem to have the same experience, how do you pick between the two? > And when hiring a junior, out of school, there will be no experience to go by, so what else would you assess on?
You use a technical challenge that resembles the work that the person would need to fulfil in the job. Perhaps creating a single view of a website/app for a frontend role. Or creating a few API endpoints for a backend role. Or whiteboarding through a technical architecture (with plenty of opportunity to ask clarifying questions).
Those things are relatively trivial, and easy to coach as well. If someone never did it before, you can easily show them how on the job. You also wouldn't have time to have them work that in an interview, so you'd need to do a take home, and then you can no longer validate they truly did it themselves, how much time they spent to do it, how much googling they had to do, how they approach the problem or delt with issues, etc.
I also find they tend to be framework/language specific, some companies even have internal frameworks and all that so they'd have to relearn part of it anyways.
> Or whiteboarding through a technical architecture
This is normally included as part of a "leetcode" like interview.
It tends to be a half day, where you're asked one or two system design questions, which are of the format you describe, and are asked one or two data structure and algorithms questions, and one or two small programming questions that checks your ability to write readable and maintainable code that is well structured, well organized and well factored. Sometimes the latter two are combined into one bigger question that tests both code design quality and requires an algorithm or special use of data structures to solve.
That said, I work for a small company and our turnover is pretty low. I haven't been involved in all that many hires.
The only coding exams I've ever had to submit were while working at consulting agencies for clients that require an interview process to pick what the client regards as the best candidates for the contract.
I also worked at "very small" (15 dev consultants) to "medium-small" (300 or so technical consultants) companies, hence why I was curious if this was a bigconsulting thing or not.
I'm an experienced systems developer with a pretty good resume, I didn't want to look stoopid if I was asked any such question in an interview.
Worked pretty well. I wasn't laid off but I ended up changing job for something more fun than my then position.
They're derived from cognitive sciences research and they have a high false negative rate, but it's more valuable to these companies to capture the true positives.
The challenge is that cattle jobs in tech have historically paid very well thanks to the free money environment. It looks initially like the right strategy: Cushy job, cushy work, much money. But the glass ceiling is hard and you won’t see it coming until suddenly you’ve had the same day-to-day for 10 years and no amount of grinding leetcode gets you to the next level.
Fortunately standing out is easy: My girlfriend got a (not-coding) FAANG-level job out of 2000 applicants in part by being one of the three people who actually read the job description and could hold an insightful conversation about what she can bring to the table.
But I constantly keep getting jerks wanting btree sorts that are like a college exam or take home challenges that assume I have industry type applications on my home network. No, folks, I don't run containers and terraform infra in my personal network. When I have to spend three hours to install a dodgy application just to start your janky "8 hour project" I lose all the enthusiasm I had for your job.
There's your answer: consulting companies and contract works.
You have a different bubble compare to the LeetCode crowds. The Leetcode crowds tend to work for Product companies as a Full-Time employee in major Hi-Tech cities. Product, Full-Time, major Hi-tech cities, hit those 3 characteristics => higher chance of getting the Leetcode interview jackpot.
It's reflective of the type of company you're interviewing for.
I lived in Seattle for a while, and almost every startup in the area did some form of algorithm lottery interviewing, because the startups were created by ex AMZN/MS/etc employees and they just took the process they were comfortable with to the next company.
I lived in Atlanta and a few other smaller cities for a while before and after that, and no company did anything like this, because the successful tech companies were all born of people with no FAANG experience, with different backgrounds and with different experiences.
I was laid off from one consulting company back in 2018 or so and had a new gig with more pay a week or so later. No leetcode or dev tests, just talking with people in phone interviews. It was a company I had previously done contract work for, and they called me, but nothing at the FAANG level.
Is it an experience issue (are the people getting laid off junior devs?), because I had maybe 6 years of dev experience across various stacks by that time. In my 10 years of being an employed dev, I have never had to do leetcode interviews.