The advantage of leetcode is that you study once and then it applies for every job you interview for. Like democracy it's a horrible system except for all the others.
Take home project? There goes 4-12 hours per company that gives you one and sometimes more. Companies have no incentive to cut it down or not give it to even marginal candidates so you'll get a lot more of them than full in-person interviews.
Pair programming? That's basically white boarding with a better white board or, in the remote interview world, just regular white boarding. Sure the problem is more real world, in theory, but then you get issues of knowing the same frameworks, etc. So to do well you need to spend a lot of time beforehand studying their specific frameworks and code bases if they ask you to do an issue on their open source project.
I would argue the problem is it's not a one-time cost. You pay the cost almost every time you want to change jobs, because leetcode/algorithmic interview questions are so fundamentally different to what we actually do day-to-day as developers.
It is very easy to completely forget all about graph algorithms in, say, 3 - 5 years during which time you've been a productive, valuable member of a software development team that...you know...actually builds things customers care about.
Small price to pay to get more and more absurdly high paying jobs every 3-5 years.
Being a productive, valuable member of a software development team is teaching you things that will set you up for success in higher level roles. You won’t be taken for those roles on Leetcode interview performance alone.
>You won’t be taken for those roles on Leetcode interview performance alone.
I think the problem is that for some teams the entire process is some combination of leetcode-style "technical" interviews and then some "culture fit" interviews, without any chance to talk about actual dev work.
Large tech companies will have system design and project oriented behavioral interview which will somewhat cover actual dev work. Other than that it pays to build up your network during your career. You can basically bypass interviews at smaller companies with the right referral.
>because leetcode/algorithmic interview questions are so fundamentally different to what we actually do day-to-day as developers.
I mean, maybe hard or esoteric easy questions but I don't think that's true for basic things like 'find the first duplicate' or '-traverse- this graph'. When people rail on whiteboard coding, I think they mean obscure algorithmic questions and not fundamental data structure questions.
I don't expect someone to be able to do Dijkstra's algorithm (or even spell Dijkstra, did I do it right?) but everyone should be comfortable enough with a bit of help doing BFS or working with linked lists, hashmaps, no? Am I crazy here?
I don't think you're crazy, but if their work and your work are detached enough from BFS and linked lists, why use them as the assessment criteria?
It's not really that difficult to make quotidian software engineering tasks into interview questions. I've at least seen it done successfully before.
More anecdotes: a nontrivial number of the "algorithmic trick" interviews I've done were questions I knew the answer to beforehand – and often the interviewer didn't care when I told them ("I just want to see how you think" or "Just show me how you'd code it" or sometimes even "OK, just tell me the solution and we'll move on to the next part"). What happens to the people who don't have the same background? Are they really less competent software engineers because their algs class didn't cover making a queue from two stacks?
I've worked both as an electrical engineer, and as a SW engineer/developer.
"Find the first duplicate": In my actual SW roles, this was trivial: Use a hash/map/dictionary/set. However, this isn't a typical Leetcode question - often it will be with additional constraints (cannot use a set, need O(1) space, etc). I don't doubt there are domains where this is important, but I've never had to do this in my professional work.
"Traverse this graph": Probably had to do it a few times. Less than once a year.
BFS: Never for my job.
Linked lists: Never for my job.
Yes, it is good to know what a linked list is and know if your library's data structure is using one, but again: That's not your typical Leetcode question. You'll be expected to write a linked list to solve some problem.
I do get what you're saying: Stuff like linked lists and BFS are fundamental, even if most SW jobs almost never require them. It would be a red flag if a candidate didn't know the basics about them. It's another thing to ask them to code it on the fly.
Going back to my electrical engineering experience: We have to take and use a ton of calculus to get the degree - much more than a CS grad will take algorithms. Yet it's a common trope that most electrical engineers will never use calculus on the job (literally not hard to find one who had a whole career in EE without using calculus). If you're doing research or are at the forefront of a discipline - sure, you'll need calculus. Or if you're doing electromagnetics, etc. The theory is built on calculus, but you don't need to know it to apply the results of the theory.
Would it be a red flag if a candidate clearly didn't understand the basics of differentiation (i.e. rate of change) and integrals (i.e. summing quantities)? Perhaps.
But should I ask someone to do a tricky integral for an EE role that will not require the person to do any calculus? I would be criticized by my peers, and if I kept doing that I would be excluded from interviewing. In fact, even if I ask them to do non-tricky integrals I would be criticized.
Asking people to figure out a trick to solve a linked list problem is equivalent to asking EE candidates to do tricky integrals or differential equations.
In the past we had some candidates complain about take-home problems. The primary complaint was that candidates weren't interested in dedicating 4-5 hours of their own time unless they felt that someone from the company was putting in an equal amount of their own time. Some candidates also had suspicions that we were trying to use them for free labor (Not true, we used the same toy problem for every candidate). One candidate even thought they should be able to bill us for their time spent applying (We passed).
Eventually I changed the strategy and offered candidates the choice of the take-home problem or an on-site whiteboard style interview where they solved a subset of the problem in pair-programming fashion with us. Zero people chose the on-site interview. Everyone chose the take-home problem.
No one complained any more after we reframed the take-home problem as the candidate's choice rather than the company's.
Aren't meaningless shenanigans generally associated with meaningless things?
Do you have any evidence that either strategy really matters? Does it boil down to, "We choose an interviewing strategy that selects for people who look like programmers."
It's always surprising to read people complaining about spending even 8 hours on a take-home problem in the comfort of their home, with no one looking over their shoulder, finished at their leisure. Meanwhile, anyone serious about applying to the same company wouldn't hesitate to take PTO and leave work to go on-site for a similar amount of time for an interview.
If you do the take-home problem, do you get to skip the interview? My understanding was that it might, at most, replace a 1-hour whiteboarding interview. The one time I did a take-home problem for an interview, I spent a whole weekend day on it (which felt hard, given that I was making my wife watch our child all day), and then I still had to spend a whole day on in-person interviews.
And then they didn't even ask me any questions about my take-home solution--it was just ignored. It felt like a pure waste. I'd much rather do whiteboarding.
The problem might be that you might need to interview for alot of positions and having a homework for each would add up.
The homework is no cost for the employer and you are not sure how serious about you they are when you do it (if it is in the start of the process) so I wouldn't bother if I had an alternatives to go for.
Except most companies give the take home as essentially a first line screen so the chance of passing is low (as they need to filter out 90+% of applicants with it). So instead of spending an hour per company I now need to spend 8. When you're talking to 10+ companies that adds up quickly. If you also have a family and a a day job it becomes untenable very quickly.
Gotta disagree on pairing, as that gives you an actual computer. If it's your own environment, you're at least comfortable with that. You don't have to worry about penmanship and can get IDE suggestions. It's frustrating not being able to get your ideas down quickly enough like when writing code on a board.
I agree that take home projects and pair programming are nowhere near ideal, but I think the advantage you mention for the "leetcode" white boarding is one of the main disadvantages. If all you need to do is study these and memorize their solutions then what is it showing us of your actual ability.
I personally when I interview candidates prefer to get to know them and how they think before I even try to understand their ability to problem solve. Knowing the language or algorithms are all easy to learn things. Knowing how to naturally be curious and solve problems is a far more difficult skill to learn and demonstrate, but it is easy to evaluate indirectly.
>Knowing how to naturally be curious and solve problems is a far more difficult skill to learn and demonstrate, but it is easy to evaluate indirectly.
That's what leetcode used to test and then people optimized for it and now it tests memorization. At scale things work differently than in isolated cases. I've also found that most problem solving interviews really test how well I've seen the problem before and how well I can lie about seeing it before. Interview enough candidates and the good problem solvers will look dumb compared to the ones who simply saw it before and can act like they didn't.
I give people the choice of take-home, whiteboard, or code sample. Code sample can be any code they've written for a side-project or even a take-home they've done for another company. Obviously, they can't share actual code they've written for another company, but take-homes are generally fair game... And so that solves the O(N) problem for people who are applying to multiple companies.
Depends how the pair programming is done. Last time I did pairing I was told I could use any language I wanted to solve the problem regardless of whether or not the interviewer knew it. You just need an interviewer who is curious and asks questions about the language you're using to make sure they understand your approach.
My worst experience so far were pair-programming interviews. This requires so much training on the interviewee side of things that most companies just completely tank this one. They have some fixed expectations in their head and they have not a single clue how to objectively evaluate candidates.
Yup, leetcode at least is fairly easy to make interviewers competent enough at giving especially if you restrict the problems they can give. Although worst one me and my friends have gotten were system design. Friend got interrupted with questions every 30 seconds, told to just answer them directly and then failed for not elaborating deeply enough on things.
Same exact thing happened to me at Microsoft during the system design interview round. Interviewer wouldn't just let me explain and kept on arguing about a relatively minor issue and wouldn't let me proceed and in the end failed me because I didn't come up with a good design. Really the whole 45 minutes were like him repeatedly stopping me and coming back to that one issue.
Take home project? There goes 4-12 hours per company that gives you one and sometimes more. Companies have no incentive to cut it down or not give it to even marginal candidates so you'll get a lot more of them than full in-person interviews.
Pair programming? That's basically white boarding with a better white board or, in the remote interview world, just regular white boarding. Sure the problem is more real world, in theory, but then you get issues of knowing the same frameworks, etc. So to do well you need to spend a lot of time beforehand studying their specific frameworks and code bases if they ask you to do an issue on their open source project.