“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 would be great is if companies offered multiple formats including leetcode, take home, pair programming, Github review, project review, just talking, etc.
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.
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 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.
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 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).