6 ms·

I've never heard of an effective alternative to Leetcode though. We're engineers. If you don't like something, make something better. Take home projects and

by urthor 4y ago

I've never heard of an effective alternative to Leetcode though. We're engineers. If you don't like something, make something better. Take home projects and how many marbles in a jar are extraordinarily worse than traversing a binary tree. I suspect that any interviewing practice will always being in detractors. It's a process of culling, those culled will dislike it.

teg4n_ 4y ago
I much prefer take home projects relevant to the job I would be performing than leetcode style puzzles. I dislike leetcode style puzzles so much that I will simply drop out of the interview loop rather than subject myself to them.
- ab_testing 4y ago
  So you don't like to solve 2-3 leetcode style problems but would rather work a weekend on a project.
- deleted 4y ago
  [deleted]
- elcomet 4y ago
  Please no. I don't want to work 10 hours on some project for free.
  - jasonboyd 4y ago
    That is one way to look at it I guess. But if it means a substantial pay raise then the amortized cost of those hours is negligible.
  - axlprose 4y ago
    When taking into account the total amount of time involved in a traditional multi-round interview process (which can potentially go on for months depending on the company), the travel time required for any in-person interview rounds, and the time spent practicing leetcode drills in preparation for these interviews, 10 hours is nothing.
  - hughesjj 4y ago
    10 hours on some project per interview Like interviews aren't lengthy enough as-is. I had an onsite the other week with two sys design, two leetcode-esque, a hiring manager, and a project manager. I'd take that any day over the take home project I had to do in a subset of common LISP fresh out of college. Twas NOT a fun weekend, especially since I had no familiarity with LISP. With few exceptions, I don't do takehomes anymore. I don't want to spend an hour or so fuddling with your/your vendor's poorly documented, buggy environment (or setting it up myself) on my own time, outside of office hours, talking to exactly zero human beings during the actual process. It teaches me nothing about the company or team I'd be working on, doesn't allow for any gauge of culture fit, and (unlike leetcode) doesn't make me a better programmer.
  - wizofaus 4y ago
    I see this complaint a lot, but 10 hours is crazy - I've been involved in setting, reviewing the results for, and doing such tests for many years and the longest I've ever expected anyone to take is 2 hours, which is more than enough to demonstrate whether you have at least basic capabilities as a programmer. As it is in the "real world" my biggest problem with other devs is for them to spend days on a story, then finally put up a PR that shows they really didn't understand the requirements well or make any attempt to clarify them. It's actually pretty rare I'd ever expect a dev to be able to take a story away and put anything like 10 hours time into without needing to discuss it first, so why would I expect that for a take home test?
matthewmacleod 4y ago
Literally any other process is better, in my experience. Short take-home exercises. A system design exercise around a whiteboard. Talking the interviewer through some previously-written or open-source code. Pairing up to fix a bug in the org’s code during the interview. Leetcode-style problems as an interview technique are probably the one that’s furthest away from testing the from day-to-day software development challenges most organisations face.
- urthor 4y ago
  > Short take-home exercises As others have said, open to extreme abuse in terms of timeliness. > A system design exercise around a whiteboard I've worked with a frankly extreme number of architects who can talk the talk but cannot (or will not) code the code. If you're hiring for someone to code the code system design isn't the signal you want. > Pairing up to fix a bug in the org’s code during the interview Open to cheating. Very difficult and time consuming to rotate the problem. With Leetcode you can take the problem out of a college textbook. > Talking the interviewer through some previously-written or open-source code. Works well for small companies where you're hiring someone who fits a team well. Probably the best approach for small companies. For big companies, it's open to extreme racial and personal bias. And I don't mean racism in an abstract sense. I mean that I've interviewed with a company that pairs with a particular coding exercise across all candidates. They asked me back whilst knocking back my INFINITELY more qualified good friend who was interviewing with the same company. We walked through the same code base, I'm a LOT less qualified than they are. We got far different feedback, to the extent I genuinely can only assume unspoken racism.
lbrito 4y ago
Leetcode: weeks or months spent grinding daily, adding easily up to 100s of hours Take home project: typically capped at 4 hours. Hmmm, this is a tough one...
- AstralStorm 4y ago
  Often enough someone gives a take home project that actually is not even close to be capped in the time range requested unless you already work on this project. Every such test is supposed to be calibrated. Leetcode... Is not.
  - lbrito 4y ago
    Be that as it may, it will never even come close to the 100s of hours of leetcode grinding. It's not even the same order of magnitude. Like I mentioned, it is common to spend months grinding leetcode. How can people rationalize this and prefer it to a closed scope assignment? I honestly don't get it.
    - urthor 4y ago
      > How can people rationalize this I've personally learnt a lot from Leetcode, and found the process really valuable. I learnt a ton from bashing my head against the wall until dynamic programming made sense. I anecdotally code much, much faster, in all languages, having done it. It's like doing college homework again. Something useful that makes you a better "coder," (not necessarily a better engineer). It was a damn hard slog, but having done the hard slog I really enjoy having done it. I'm not going to pretend it's not time consuming or I'd be happy doing it if I was a busy parent. But in hindsight I've really enjoyed having done it, and found it extremely valuable. I suppose it's for people who just have that kind of time/energy/enthusiasm for programming/their career.
hughesjj 4y ago
Even amongst the "top tier" companies, there are alternatives. Stripe essentially does pair programming on things you might actually do in your day job, using your own dev environment/etc. That said, I'm partial to good leetcode questions. Some of them are worded terribly, some of them are essentially trivia, some of them are overly esoteric and not applicable to most roles. Some of them are great but have "optimal" solutions which take an absurd amount of research and effort to produce, like quickselect. These questions are bad and should not be asked. Others I find fantastic questions. "Scheduling meetings", anything that requires you to walk a tree or do a binary search/BFS/DFS, and tasks that require you to combine two data structures like the "Hashmap with O(1) get random" question really helped me get better t my job. There's others I'm lukewarm on, like many topological traversal, shortest/longest path, and knapsack/space filling questions. I personally love them and have gotten good at them, but I also don't expect joe schmo to remember how to implement the relevant algorithms off the top of their head. I'd consider this question cohort good for "open book" interviewing at "less prestigious" companies. I'm totally fine with Google/Meta/Amazon asking these closed-book for normal roles.
eikenberry 4y ago
Simply having them work through a basic problem out loud as they code it with a decent engineer that understands the problem is much better than Leetcode.

by urthor 4y ago

teg4n_ 4y ago

I much prefer take home projects relevant to the job I would be performing than leetcode style puzzles. I dislike leetcode style puzzles so much that I will simply drop out of the interview loop rather than subject myself to them.

ab_testing 4y ago
So you don't like to solve 2-3 leetcode style problems but would rather work a weekend on a project.
deleted 4y ago
[deleted]
elcomet 4y ago
Please no. I don't want to work 10 hours on some project for free.
- jasonboyd 4y ago
  That is one way to look at it I guess. But if it means a substantial pay raise then the amortized cost of those hours is negligible.
- axlprose 4y ago
  When taking into account the total amount of time involved in a traditional multi-round interview process (which can potentially go on for months depending on the company), the travel time required for any in-person interview rounds, and the time spent practicing leetcode drills in preparation for these interviews, 10 hours is nothing.
- hughesjj 4y ago
  10 hours on some project per interview Like interviews aren't lengthy enough as-is. I had an onsite the other week with two sys design, two leetcode-esque, a hiring manager, and a project manager. I'd take that any day over the take home project I had to do in a subset of common LISP fresh out of college. Twas NOT a fun weekend, especially since I had no familiarity with LISP. With few exceptions, I don't do takehomes anymore. I don't want to spend an hour or so fuddling with your/your vendor's poorly documented, buggy environment (or setting it up myself) on my own time, outside of office hours, talking to exactly zero human beings during the actual process. It teaches me nothing about the company or team I'd be working on, doesn't allow for any gauge of culture fit, and (unlike leetcode) doesn't make me a better programmer.
- wizofaus 4y ago
  I see this complaint a lot, but 10 hours is crazy - I've been involved in setting, reviewing the results for, and doing such tests for many years and the longest I've ever expected anyone to take is 2 hours, which is more than enough to demonstrate whether you have at least basic capabilities as a programmer. As it is in the "real world" my biggest problem with other devs is for them to spend days on a story, then finally put up a PR that shows they really didn't understand the requirements well or make any attempt to clarify them. It's actually pretty rare I'd ever expect a dev to be able to take a story away and put anything like 10 hours time into without needing to discuss it first, so why would I expect that for a take home test?

matthewmacleod 4y ago

Literally any other process is better, in my experience. Short take-home exercises. A system design exercise around a whiteboard. Talking the interviewer through some previously-written or open-source code. Pairing up to fix a bug in the org’s code during the interview. Leetcode-style problems as an interview technique are probably the one that’s furthest away from testing the from day-to-day software development challenges most organisations face.

urthor 4y ago
> Short take-home exercises As others have said, open to extreme abuse in terms of timeliness. > A system design exercise around a whiteboard I've worked with a frankly extreme number of architects who can talk the talk but cannot (or will not) code the code. If you're hiring for someone to code the code system design isn't the signal you want. > Pairing up to fix a bug in the org’s code during the interview Open to cheating. Very difficult and time consuming to rotate the problem. With Leetcode you can take the problem out of a college textbook. > Talking the interviewer through some previously-written or open-source code. Works well for small companies where you're hiring someone who fits a team well. Probably the best approach for small companies. For big companies, it's open to extreme racial and personal bias. And I don't mean racism in an abstract sense. I mean that I've interviewed with a company that pairs with a particular coding exercise across all candidates. They asked me back whilst knocking back my INFINITELY more qualified good friend who was interviewing with the same company. We walked through the same code base, I'm a LOT less qualified than they are. We got far different feedback, to the extent I genuinely can only assume unspoken racism.

lbrito 4y ago

Leetcode: weeks or months spent grinding daily, adding easily up to 100s of hours Take home project: typically capped at 4 hours. Hmmm, this is a tough one...

AstralStorm 4y ago
Often enough someone gives a take home project that actually is not even close to be capped in the time range requested unless you already work on this project. Every such test is supposed to be calibrated. Leetcode... Is not.
- lbrito 4y ago
  Be that as it may, it will never even come close to the 100s of hours of leetcode grinding. It's not even the same order of magnitude. Like I mentioned, it is common to spend months grinding leetcode. How can people rationalize this and prefer it to a closed scope assignment? I honestly don't get it.
  - urthor 4y ago
    > How can people rationalize this I've personally learnt a lot from Leetcode, and found the process really valuable. I learnt a ton from bashing my head against the wall until dynamic programming made sense. I anecdotally code much, much faster, in all languages, having done it. It's like doing college homework again. Something useful that makes you a better "coder," (not necessarily a better engineer). It was a damn hard slog, but having done the hard slog I really enjoy having done it. I'm not going to pretend it's not time consuming or I'd be happy doing it if I was a busy parent. But in hindsight I've really enjoyed having done it, and found it extremely valuable. I suppose it's for people who just have that kind of time/energy/enthusiasm for programming/their career.

hughesjj 4y ago

Even amongst the "top tier" companies, there are alternatives. Stripe essentially does pair programming on things you might actually do in your day job, using your own dev environment/etc. That said, I'm partial to good leetcode questions. Some of them are worded terribly, some of them are essentially trivia, some of them are overly esoteric and not applicable to most roles. Some of them are great but have "optimal" solutions which take an absurd amount of research and effort to produce, like quickselect. These questions are bad and should not be asked. Others I find fantastic questions. "Scheduling meetings", anything that requires you to walk a tree or do a binary search/BFS/DFS, and tasks that require you to combine two data structures like the "Hashmap with O(1) get random" question really helped me get better t my job. There's others I'm lukewarm on, like many topological traversal, shortest/longest path, and knapsack/space filling questions. I personally love them and have gotten good at them, but I also don't expect joe schmo to remember how to implement the relevant algorithms off the top of their head. I'd consider this question cohort good for "open book" interviewing at "less prestigious" companies. I'm totally fine with Google/Meta/Amazon asking these closed-book for normal roles.

eikenberry 4y ago

Simply having them work through a basic problem out loud as they code it with a decent engineer that understands the problem is much better than Leetcode.