31–40 of 675 posts
A task you solve with someone (as part of your team if you get hired) > take home task > leetcode interview in my opinion
In a previous job of mine, we would show candidates a printout of some buggy code, and ask them to find the bugs. We would leave the room and let the candidate work through it on their own. The code in question was basic algorithms and data structure stuff in C++, such as inserting into a doubly-linked list. I always thought it was a good exercise. Suits slow-thinkers and nervous people, and it's a good test of codin…
Just talk to the person, ask them about projects they’ve worked on, problems they’ve solved etc. you’ll learn far more about them that way than getting them to put on a dog and pony show at a whiteboard!
Talk to the person and you will (1) hear a lot of bullshit and (2) filter out a ton of good but not really silver-tongued candidates. P. S. I hate coding interviews.
I don't really understand the point almost all of the thing they list as downsides of using Leet Code are actually benefits. If someone can't manage to code some simple questions during an interview I can't imagine they'd ever make real contributions.
if the "simple questions" are realistic problems they might face day to day, fair enough. But the classic example in these articles is an exercise like invert a binary tree, which most people never have nor will need to do, making it a poor test.
These articles always seem to have an underlying assumption that really great people are being denied access to jobs because they can't get through these interviews but it is implying that the people who do get through these are not also great but are less hassle, easier to measure their ability and so what if they have swatted up on LeetCode to help their application? That means they are driven, that they have learn…
> I am also not sure of any good alternatives because someone will always object to any alternative which they cannot achieve for some reason. When I was on the market, a couple of companies actually gave me a variety of options, which I appreciated. I don't want to spend hours on a take-home and I also don't want to do leetcode, but an open question/answer plus some code review and live debugging was an acceptable c…
The exception is my current position (only started last week): "oh yeah, we looked at your GitHub already and it's actually similar to the take-home anyway, so little point in that". Instead, they prepared an "alternative" interview where they posed some scenarios with "what would you do? How would you handle this?", which was intended to test both some technical skills, but also social/attitude things. I wrote down some answers, which took me about 30 minutes, and then we discussed them, taking a further 30-45 minutes.
The questions were a bit clunky because they were looking for someone ASAP and there was only 2 days between the first and second interview, but I felt that was a much better approach for the company as well, because they got a lot more information this way: they could already verify basic coding skills themselves, and this way they got a new chunk of information they wouldn't have had otherwise.
I think for large companies where they want to reduce the number of false positives, leetcode style questions work well.
I don't really understand the point almost all of the thing they list as downsides of using Leet Code are actually benefits. If someone can't manage to code some simple questions during an interview I can't imagine they'd ever make real contributions.
- interviews are inherently more stressful than even a very busy day at work, - they cover topics unrelated to what you'd do as part of your job so if you're good at the job you might still fail the interview - people with time (==money) to prepare for interviews will come out ahead of those who don't have that luxury, despite the fact they may be far better prepared for the actual job.
So you get a bunch of false positives, a bunch of false negatives, and on top of that you're discriminating against people who are in a worse financial situation or have interview anxiety. I can hardly think of a worse outcome for a seemingly sensible hiring method.
It's much better than the alternative and ideally only one part of the interview process. Ultimately the proof is in the pudding, I've had loads of candidates that could barely code and Leetcode-style problems are a great filter against that. Otherwise you risk just getting PM-style bullshitters as engineers, who talk persuasively about projects that other people actually implemented.
The more I learn about software development the more I try to _not_ have leet code style parts in my code - in the very rare circumstances would I see something like that and say - yes there is _no_ other library out there that has a battle tested algo to solve this particular problem, _and I have to code my own_.
Worse people who excel at Leet Code could start to bring that sort of thing into your codebases, optimising small parts of your code to perfection, and then leaving the whole thing a mess or just plain reject to work on solving business issues and concentrate on polishing their small bit of algorithm.
Of corse there are positions where that sort of mindset is welcome and sought after. Especially in very big companies, but for the most developers out there leet code is _just_ for the interview part and they would (should) never use that kind of problem solving in their day-to-day work.
When I have to interview somebody, and there's leet code involved:
a) they are _really_ comfortable with those types of challenges - that tells me they have spent a lot of time preparing - either for this interview or just generally, either way that wouldn't _really_ tell me much about their problem solving skills
b) they feel uncomfortable and fail to solve anything due to stress or anxiety - again no really knowledge gained, as real-world work environments tend to try to minimise those, at least in the places where I work in.
c) they feel uncomfortable but get the hang of it - now I _might_ have a glimpse of their problem solving skills, but I've put a human being in a very uncomfortable position just to _test_ them. There _has_ to be a better way.
The way I like to conduct interviews where possible is to ask people to walk you through some of the code they've written and ask various questions about decisions - much more relaxed and I still get the sense of how they organise their stuff and how they work.
If that's not possible - a take home task or something. Or even "hire fast fire fast" approach works too.
I don't really understand the point almost all of the thing they list as downsides of using Leet Code are actually benefits. If someone can't manage to code some simple questions during an interview I can't imagine they'd ever make real contributions.