What situation are people in that they have to result to this? Is this an issue with getting laid off and trying to find a FAANG job?
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.
>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.
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.
Unpopular opinion: If you’re competing for a cattle job, you have to do leetcode. If you want to be a pet, you have to stand out to people who are looking for you (what you have to offer), not just any fungible developer with a pulse.
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.
>What situation are people in that they have to result to this?
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.
I get interviews with "coding challenges all. the. time. IDK why, I'm a Linux systems engineer, not a programmer.
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.
In very large part what your interviews look like depends heavily on when and where you're searching, what type of job you want and what your background is. It's hard to overstate this. 2018 might as well be an entirely different universe.
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.
20+ years in. Don't be afraid those positions can lead to a greenfield development project or come from departments that don't have someone to vet your coding preferences. Usually these positions offer more technical freedom. A company who spends more time vetting code will generally be a place with less freedom and more micromanagement.
> 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?
> Why are you opposed to leetcode?
> It serves as a great arbiter
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).
> Perhaps creating a single view of a website/app for a frontend role. Or creating a few API endpoints for a backend role
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.
I'm sometimes involved in the interviewing process for my employer and we don't do any kind of coding tests. We do ask for them to submit a sample of their work and use it in the interview. I ask questions about the problem and about how they solved it. The code itself isn't usually that interesting, but the tangents we wander down usually are. If the person can't communicate well about a technical topic that they essentially chose, then they probably won't get an offer.
That said, I work for a small company and our turnover is pretty low. I haven't been involved in all that many hires.
This is pretty close to what my experience has been on the interviewee side. The conversations have been technical in regards to talking through problem solving, and esoteric coding philosophy conversations over lunch.
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.
So far it hasn’t been a problem. Junior candidates have shown code from a school project and others have submitted code from a personal project or from something they contributed to an open source project. I think the personal projects are the most interesting to talk about.
Expecting people to have personal projects outside work is very much selecting for a certain type of person. You're ruling out people who devote their time outside work to their families, or sport, or hobbies that don't involve programming.
I’m not ruling out anything. So far I have yet to find somebody who can’t come up with a code sample to bring to the interview. When that happens, I would probably give them a (paid) assignment. Maybe something like “fix issue #12345 on open source project X”. I’d have to think about it a little and discuss it with the candidate.
> What situation are people in that they have to result to this? Is this an issue with getting laid off and trying to find a FAANG job?
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.
For what it’s worth in my 15+ year career I have also never had to do leetcode interviews… until now.
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.
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.
If you've been working 10 years you're in the peak desirability age. A few more years you'll be nearly 40, after that people are much less likely to hire you.
Last time my job was threatened, I spent a few weeks brushing up on my algorithms, going through coding challenges, reimplementing the basics (in my case, a concurrent consumer-producer queue, an IPC mechanism, etc.)
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.
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.