Instead it’s been “Grokking Algorithms”, “The Competitive Programmers Handbook”, Alex Xu’s “System Design”, and enough leetcode that I’m actually doing more than I did at work.
What sucks is that there are still lots of medium problems I cannot do. Hards are right out. Dunno what I’ll do.
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 see this all the time, "coding interviews suck", "leetcode doesn't test if you're a good coder", but in the end it's better than nothing, and having worked at places without coding interviews there's almost no bottom to people's abilities. So a low, but existing, floor is a good thing.
The biggest issue IMO is lack of flexibility. Leetcode is a specific format with specific questions, but is not necessarily the work you'll do day-to-day.
What would be great is if companies offered multiple formats including leetcode, take home, pair programming, Github review, project review, just talking, etc.
There are several issues that leetcode solves that the other ones don't work as well with or have flaws that prevent their use in some hiring processes.
Leetcode has a single rubric. The same questions and the same answers. Conducting it has minimal additional effort on the employer's side. It does have false negatives, but it has fewer false positives.
Take homes are often similar to leetcode, but some less scrupulous companies have used them for unpaid work (note that this becomes more and more of an issue as the take home becomes more and more relevant to hiring company) the and unless the interviewer has done the take home themselves to benchmark it (this should take between 1-2 hours), it is possible that the request be "do this thing that will take 20 hours."
GitHub review requires that the person have a GitHub project of sufficient size, that it isn't just copied from someone else and that they have time to work on it. There's a joke in /r/adventofcode that shows a GH repo that only has activity in December.
With pair programming, project review, and just talking the lack of a rubic becomes an issue and it becomes more likely that biases get into the interviewing process and leads to possible issues of discrimination.
When mixing any of these so that some people do leetcode, others do pair programming then it becomes an issue that not everyone is considered using the same scale and those biases and discrimination issues become even more something that legal starts wondering about if they'll have to deal with a lawsuit.
If one person can do the interview with "just talking", then that should be the same criteria that everyone uses (no leetcode) and "just talking" has an abysmal false positive rate.
You're definitely correct, I've learned a lot while practicing leetcode. Especially about my chosen language (Python). I do feel I'm a better engineer because of it.
I don't think much of what I've learned will be useful in the day-to-day SWE grind. It's really quite interesting, but I cannot recall ever having to remember the skeleton of an iterative DFS before now.
I've taken away more useful lessons from system design studying. If I had my way, I'd spend more timing finishing "Designing Data Intensive Applications" (AWESOME book), instead of figuring out why my oranges aren't rotting correctly or trying to remember how to solve the coin problem using dynamic programming instead of a greedy algo.
On the plus side, once I've got a good memory base and can solve random Mediums and some Hards, I should be OK to pass basically any technical interview - barring random chance. Right now I took a break for xmas and need to go back to it, and that is the hardest part :)
I was in the exact same situation. What I did was take a web manager job at a non-profit. I run their Wordpress website. It isn't what I was hoping for when I left marketing in the SAAS space, but it's a start and I finally enjoy going to work.
I have complete autonomy in this role and am setting things up so I'm not just managing a WP site, but actually working on the code base and learning as I go.
My thinking is it's better to get paid to learn than grind Leetcode at home (which I did for six long months).
“Now I’ll have time for my projects!!”
Instead it’s been “Grokking Algorithms”, “The Competitive Programmers Handbook”, Alex Xu’s “System Design”, and enough leetcode that I’m actually doing more than I did at work.
What sucks is that there are still lots of medium problems I cannot do. Hards are right out. Dunno what I’ll do.