Happily employed and had no trouble with coding interviews myself. So my opinion isn’t from some personal angst about passing this bar: I found it easy.
That said: I’m tired of the attitude that there is no effective alternative to this style of interview. You do know we hired people to do engineering jobs for many decades before the industry started cargo culting what they observed a handful of Silicon Valley mega-companies doing. Plenty of very competent people were interviewed and hired before this “relive your algorithms class final on a whiteboard” style interview process became the thing to do.
These interview processes are not the only way. As I said: it’s cargo culting where insignificant companies try to act like Google or some other giant in hopes that perhaps the billions in revenue will start rolling in if they mimic them. To me this behavior is no different than “founders” who adopted dress styles and presentation mannerisms imitating Steve Jobs a decade or so ago. …And bloggers who can’t resist the “considered harmful” trope.
Is there a difference in the interview process between the US and the EU? Wherever I applied to in the EU I was almost always given a small, practical programming exercise relevant to the field I was applying for and for which I had a few days to hand in my solution (usually they were quick to solve, depending on the level of polish you would put in). In the interview itself we would then discuss the implementation and that way I got to know the team I'd be working with and they could see if we were able to discuss and explain code.
"There are only two kinds of languages: the ones people complain about and the ones nobody uses." -Bjarne Stroustrup
And so it is with interviewing techniques. You say "[leetcode] interview processes are not the only way," which is of course true. But it is also true that all other interviewing techniques are also unpopular on HN and with programmers in general. Of course each programmer has one or more techniques that they prefer, but there is no single technique that has even simple majority support amongst engineers as a whole.
Let's review some common techniques and what HN would say. NB: not expressing my opinion on any of these, just compiling common complaints you can find in any HN thread about interviewing.
Leetcode problems: rewards rote memorization over real ingenuity, not relevant to job, high stress.
Take home problem: company not incentivized to respect candidate's time; bias towards candidates that are unemployed, not engaged at current job, or otherwise able to devote large amounts of time to the task; easier to outsource; basically asking candidates to "work for free"
Review of github profile, OS projects, blogs, etc...: bias against candidates that "have a life" and don't program 24/7.
Discussion of previous work: highly subjective, susceptible to frauds and/or exaggerators, prone to false positives (complaint usually phrased in a form like: "we did this at my last company and we hired a bunch of people who couldn't code.")
“I don't know what the l̶a̶n̶g̶u̶a̶g̶e̶ interview technique of the year 2̶0̶0̶0̶ 2030 will look like, but I know it will be c̶a̶l̶l̶e̶d̶ ̶F̶o̶r̶t̶r̶a̶n̶ unpopular on HN.
> You do know we hired people to do engineering jobs for many decades before the industry started cargo culting what they observed a handful of Silicon Valley mega-companies doing.
Very much this. I worry that those relatively new to this industry may now only have seen the leetcode-style interview disfunction madness and get the impression it's the only way.
Absolutely not! It's not how it used to be, it's not how it needs to be. I was closing in on 20 years into my career before ever hearing about this type of whiteboard algorithm memorization-style interview. It's common now, but it's not really normal and shouldn't be.
I for one take no part in that charade. I interview a lot of people and have never done a whiteboard algorithm dump question and never will.
I don't hire people to memorize algorithms from a book and write them on whiteboards all day, so I'm not going to interview for that irrelevant skill.
I'll read your resume and let's have a chat about projects you've worked on and what you'd like to work on.
Well argued, but you didn't address the need for tests and/or certifications to prevent companies from being overwhelmed by a flood of unqualified candidates.
A doctor, lawyer, public accountant, and, well, many types of engineers obtain public or private certifications. As a result, it is much, much, much easier for hiring companies to find and interview qualified candidates.
I suppose, in the "old days" universities kind of, sort of, filled this role. A hiring manager looking at a resume might have said, "Oh, he's got an EE/CS from Berkeley, there's a good chance he's qualified.
Leetcode is simple: performance on it is a proxy for a combination of two metrics, raw IQ and willingness to consistently jump through a series of arbitrary hoops to achieve some end, which is a predictor of success at large companies.
If you're hiring at scale, there's nothing else that matches it in terms of difficulty to game and cheapness of cost to implement. And for every engineer who says that they refuse out of principle to do Leetcode, there are ten who refuse to do time consuming take home projects and the nth implementation of a bespoke open source static site generator just to build a portfolio on Github.
Most smaller companies can and must figure out other hiring niches for overlooked/available candidates since they can't effectively compete with large companies for good conventional candidates using the same hiring process (e.g. by offering candidates more flexibility, taking more hiring risks), but pretending it's not a tradeoff isn't taking the problem seriously.
The problem is that we have no theory of intelligence that tells us what, if anything, IQ is actually measuring.
If you renamed IQ to "linear-correlated ability to take non-domain specific tests", or "GTTQ" (general test-taking quotient). Then you'd explain every observed correlation between IQ and non-IQ performance.
So, do businesses want intelligent software engineers, or those with a high GTTQ score? As research at google, iirc, has shown: high performers on coding challenges tend to do worse in practice.
Any plausible theory of "competent software engineering" would, I think, place an extremely minor emphasis on a GTTQ. Intelligence is a much richer phenomenon (need for cognition, curiosity, resilliance to failure, domain-specific depth-wise thinking, cross-domain lateral, etc.)....
Honestly I think leetcode should be reserved for the jobs where you build the Lego bricks (the MANGAs).
Anywhere else where you use the Lego bricks to build some applications shouldn’t really use leetcode.
If you’re a good product engineer and you enjoy building good products, maybe you should start a company to build good products that solve problems for other people. Let the engineers who enjoy building the bricks do leetcode in peace so that we have solid pieces to build good software.
I’m doing the latter and trying to build a company. I realized I much prefer to build products that customers love, and I want to build useful software for people. I’m not that interested in low level tinkering and re-inventing the wheel all the time.
While I'm not in favor of LeetCode-style interviews, I recently had a fairly pleasant interview process with a company that used these coding challenges. The twist was that they were all camouflaged as scenarios that resemble their own business, instead of some random unrelated concept. I found that their effort to make the questions look relevant made it much more pleasant for me to actually feel engaged and solve them.
I did get an offer from them though, not sure how I would have felt if rejected.
That's exactly how I frame my technical interviews as well. I only pick questions which I could tie to an actual, real-world problem that we've had.
A couple for example:
1. Given a set of number ranges (e.g. [1..3, 4..5, 9..20, 2..5]) consolidate them. Tying this to a real world scenario: we had a system that dealt with "time periods" and we needed to write a validator to ensure all future dates were covered by at least one configured "time period." One of the first steps to do this was basically the number-range consolidation.
2. Given a list of numbers output metrics like average, min, max, and mode. Now what if the list doesn't fit in memory and instead comes in as a stream (or from an iterator)? This one was inspired by an intern that got stuck when he needed to run calculations on data that didn't fit into memory. He was seriously about to request a host with 10+TB of memory before we stopped him.
I'm unpersuaded. To begin with, _is_ it such a waste of time to study programming problems, as, you know, a programmer?
Also, more specifically on this piece: can anyone explain how Theranos fits in here? I don't get the connection. One the one hand we have a massive fraud, and on the other... people studying techniques that are rarely used by normal software engineers? But that nevertheless are, still, programming techniques.
And please no more "considered harmful" titles! It's painful to read at this point.
>I'm unpersuaded. To begin with, _is_ it such a waste of time to study programming problems, as, you know, a programmer?
Me too, I've worked in teams without coding interviews, and they hired a lot more subpar engineers that made everybody's life harder.
If I interview I don't put so much emphasis on syntax or the algorithm itself, but whether people can tell me how the algorithms basically work and when to use them.
I find Leetcode discussions strange. I recently changed jobs so I was preparing by doing some Leetcode problems. The actual problems I was asked during the interview process were very simple compared to what I expected. Interviewers even explicitly stated that they wanted to see how I think, and the solution didn't even have to compile. So in my experience the whole idea that «Leetcode is harmful» is overblown a little bit.
To me the value of coding interviews are knowing enough algorithms/data structures to apply and adapt them to problems, being able to quickly sketch out your idea, and explain trade-ffs.
If I used Leetcode to interview someone I wouldn't even ask them to code a solution.
I'd show them a few problems that I thoroughly understand, ask them to pick two or three of them, and ask them for their thoughts on how to approach them. It would just be a discussion with no need to touch a computer. A whiteboard and scratch paper would be available if they wanted to use them.
I'd provide enough input to make sure the discussion moves along to figuring out a solution, but would try to let them take the lead only providing enough myself to make sure we make progress.
If I ended up providing most of the solution that would be fine. The most important part of the interview comes later.
Then what we'd do is look at the official answer and talk about it, seeing where it matches what we expected and where it does things differently, and maybe talk about whether those differences make it better than what we came up with.
Finally, and this is the most important part, we'd go to the Leetcode discussion for the problem.
In the discussion people post all kinds of solutions and those have all kinds of errors. Some are just flat out wrong. Some are mostly right but miss common edge cases (edge cases I would have made sure the interviewee and I talked about earlier). Some miss somewhat ridiculous edge cases such as failing if an input array is so large that all positive integers in the language they are using are valid array indexes. Some always give the right answer but don't meet the specified time or space constraints.
We'd do code reviews on some of those, again with me trying to just provide enough input to keep things moving along.
But I find the whole discussion not strange but rather dishonest. I realize I'm biased towards thinking that the blog posts condemning some special sort of interviewing come from the "losers", the people that didn't get the job. That isn't true in general, but there is still this aura of entitlement: "I am a good programmer! I have other skills than leetcode! I demand an interview process that is tailored to my specific skills!"
I don't believe the claims that the current style of interviews is not working. This claim usually is made in the blog posts and in the interview horror stories, but I haven't seen it any of the FAANGs I worked in. Sure, some questions give more signal than others, but that's the company's problem, not the candidate's. If anything, large companies realize that lack of diversity is a larger problem and are trying to combat that directly (not with changing the hiring process for the general case though).
What it feels like is the blog posts try to solve a different problem ("how can I get a FAANG job") under the disguise of making the world a better place. Meanwhile, companies try to solve a completely different problem altogether ("how do we weed out candidates that might not be a good fit for what we value at scale with low latency?").
As a hiring manager, I'm interested in applicants that are (among others) good at leetcode-style questions without having had to train a lot on leetcode: Technical problems that are not easy to understand (cognitive and communication abilities), have a simple and easy trivial solution (higher level view on problems and customer orientation) and have high technical depth at scale (specific technical knowledge). So that's where the post is right: don't spend so much time on leetcode. But also don't try to change how companies interview. It's unbecoming.
Depends on the company. FAANG and unicorns will absolutely ask for it to compile (except Google which asks questions on Google Docs of all things), and they want the optimal solution almost right away and will penalize you for not getting such a solution.
> Interviewers even explicitly stated that they wanted to see how I think
That's a common phrase, but it's hardly ever true. You'll actually need to almost perfectly regurgitate the memorized solution, stumbling only enough to give a convincing theatrical impression that you're developing this algorithm on the spot instead of having memorized it (even though the original development of the algorithm probably took years of research).
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.
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.
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.
I took the pill (what color were you supposed to take again?). I'm prepping for the leetcode interviews. If my opinion counts for anything, don't change the interview format now. How will i get my time back that I've spent learning how to use hashmaps with java-specific syntax? My notebooks full of pseudocode are waiting to be converted into a leetcode-time-limit friendly programming language. Dont tell me it's actually Python, not Java. A man can only stoop so low.
A lot of people say that they never encounter leetcode-like problems in real life and therefore they are silly.
Am I an outlier? I feel like I actually encounter these kinds of things fairly often, or at least the insights that they represent. (Eg: this week I'm implementing a simple path-finder to deal with a sliiightly overgrown state machine from a vendor. )
So - at least because of that - I tend to think of leetcode problems as more or less a slightly harder and more practical fizzbuzz. Complaints about leetcode do tend to mirror complaints you read about fizzbuzz.
Am I being strange here? Perhaps not. I figure there's at least two or three ways to pass a leet-code-like test: Either you just happen to have just done a bunch of marginally interesting programming somewhere in your past (which is probably what the test was designed for?), OR you did a study in college that ideally allows you to avoid the worst parts of the school of hard knocks (also ~fine), OR you explicitly practice for the test.
I suspect Goodharts law might be at work here: In some cases the measure has become the target.
The history has it that the git prototype was written in about a week. If everyone is so familiar with algos and data structures nowadays why don't I see good and novel solutions popping up here and there?
Is that I'm blind? Or is it that the set of approachable impactful problems has been exhausted? Or all the innovation happens in closed source/saas space?
I used to have a physically demanding job. I didn’t often do movements at work that were identical to what I’d do in the gym. But it was helpful to fit.
I think of leetcode as the gym and I try to do one exercise everyday outside of work.
The advantage of leetcode style interviews is that they appear to be objective. Anyone can learn to be good at them if they have the time and base intelligence to prepare for them.
Of course they are not really that fair for people that don't have the time to learn the circus tricks because they have family and stuff but at least there is some appearance of fairness.
Also, compared to other performance based testing, the time requirements on both sides are kind of reasonable. I get more annoyed when the interview process requires me to basically provide free work.
This is no different than doctors who have to go through FRCS or EDAIC etc exams, these are very hard exams with very low pass percentage adding to the fact that you need to be a qualified MD when you give these exams.
my wife is an MD and has been giving exams for the past 3 years and will be giving exams for atleast another 3 to 4 years and she studies with whatever little time she has after work. The exams she gives have little to nothing to do with the work she does. The real life medical work does not require you to be smart, most average people could do surgeries if they are trained. But getting in is the hard part. The exams there are not qualifying rounds but elimination rounds.
Medicine is an old field, and I think these leetcode style interviews are only the beginning for the computer science based industry, the bar is only going to get higher as years pass which I feel may not be a bad thing overall for the software field.
Basically there are two approaches: LeetCode vs project/test based.
The LC approach is fair if you only consider the fact that everybody will get these exercises. They are somewhat standard, and you know what to expect. However, you need to spend quite a lot of time to be able to solve difficult problems under a given time. And yet, emotions might get the best of you and you lose it, despite having solved the problem a bunch of times.
LC problems are not really useful as they don't resemble anything you'd do at work. However, if you do solve them, this shows to the company hiring you that you have been persistently training on LC problems, which shows you are consistent. A good quality, despite the uselessness of the problems.
The alternative, take home tests, are a better indicator of experience and engineering capability, although some might say one could "cheat". That's no different than outsourcing your job to somebody, which means this is fundamentally a trust issue -- so the problem lies elsewhere.
I've also seen variants of having candidates do some kind of trial where you get to experience what a typical day of work looks like at a company. This makes sense at a surface level, until you realise that the "typical day of work" is usually pretty atypical. They day of work trial generally can go two ways: the candidate works on an actual thing that needs to be done, or the candidate works on a fake thing users are supposedly asking for.
The latter is problematic, because you can do everything right, but since it's a) a fake problem, and b) you have no actual user feedback or requests to work on, this gets pretty subjective. Unless you read your interviewer's mind, you're left to wonder why you were rejected.
I'd take a LeetCode problem over a fake work day any time, as much as I dislike LC interviews. I guess all of this is to say, it's complicated :)
Whether Leetcode is necessary can be discussed but this person doesn't add anything to the discussion. Almost disconnected 7 paragraphs of text and the conclusion is FAANG and S & P 500 needs to find a way to assess without Leetcode.
It clearly works for them so they continue doing it and able to grow their eng organisations to thousands of engineers. Any other solution to this problem wouldn't be without its trade offs. If he really wants to contribute to tech industry he is more than welcome to found his own company and hire the way he wants, instead of saying "I don't like this FAANG find a new way!".
> If he really wants to contribute to tech industry he is more than welcome to found his own company and hire the way he wants, instead of saying "I don't like this FAANG find a new way!".
I don't think this is a very practical suggestion. FAANG are the winners and hold all the cash, which is why this is actually an issue. Asking someone to essentially try for a lottery ticket chance (in the best case) of repeating this success as a qualification for criticism is like telling people: "If you don't like America, you can get out"
It is fascinating to me that people write books and articles on why "leetcode is harmful", just to have a justification for avoiding the hard work. It really makes me giggle. Considering that, if you are new to coding challenges, solving a hard leetcode problem can take up to or take more time, as it needs to write an article, I have to giggle even more. And it just shows me that the system works as intended in filtering out the lazy kind of people. Sorry for all the giggling but it is just so funny to me.
You sound like you haven’t been interviewing/interviewed recently.
Knowing your DSA is one thing: the task isn’t: “let’s write some code to balance this tree”
It’s the extremely cringy “John has 40 watermelons that he needs to take to Mars” style problems
If you only need to demo your understanding of the undergrad level DSA, that’s fine. But if people have to exclusively spend 3 months preparing for LC in particular that’s just madness
And in India, people are just taking this to new heights with people beginning to no-life with LC for 3 *YEARS* and skipping everything else
It seems like this interview glosses over the differences in hiring senior junior and student intern engineers. Or maybe I missed it, please enlighten.
[+] [-] porcoda|3 years ago|reply
That said: I’m tired of the attitude that there is no effective alternative to this style of interview. You do know we hired people to do engineering jobs for many decades before the industry started cargo culting what they observed a handful of Silicon Valley mega-companies doing. Plenty of very competent people were interviewed and hired before this “relive your algorithms class final on a whiteboard” style interview process became the thing to do.
These interview processes are not the only way. As I said: it’s cargo culting where insignificant companies try to act like Google or some other giant in hopes that perhaps the billions in revenue will start rolling in if they mimic them. To me this behavior is no different than “founders” who adopted dress styles and presentation mannerisms imitating Steve Jobs a decade or so ago. …And bloggers who can’t resist the “considered harmful” trope.
[+] [-] spacetraveler11|3 years ago|reply
[+] [-] jaredklewis|3 years ago|reply
And so it is with interviewing techniques. You say "[leetcode] interview processes are not the only way," which is of course true. But it is also true that all other interviewing techniques are also unpopular on HN and with programmers in general. Of course each programmer has one or more techniques that they prefer, but there is no single technique that has even simple majority support amongst engineers as a whole.
Let's review some common techniques and what HN would say. NB: not expressing my opinion on any of these, just compiling common complaints you can find in any HN thread about interviewing.
Leetcode problems: rewards rote memorization over real ingenuity, not relevant to job, high stress.
Take home problem: company not incentivized to respect candidate's time; bias towards candidates that are unemployed, not engaged at current job, or otherwise able to devote large amounts of time to the task; easier to outsource; basically asking candidates to "work for free"
Review of github profile, OS projects, blogs, etc...: bias against candidates that "have a life" and don't program 24/7.
Discussion of previous work: highly subjective, susceptible to frauds and/or exaggerators, prone to false positives (complaint usually phrased in a form like: "we did this at my last company and we hired a bunch of people who couldn't code.")
“I don't know what the l̶a̶n̶g̶u̶a̶g̶e̶ interview technique of the year 2̶0̶0̶0̶ 2030 will look like, but I know it will be c̶a̶l̶l̶e̶d̶ ̶F̶o̶r̶t̶r̶a̶n̶ unpopular on HN.
[+] [-] jjav|3 years ago|reply
Very much this. I worry that those relatively new to this industry may now only have seen the leetcode-style interview disfunction madness and get the impression it's the only way.
Absolutely not! It's not how it used to be, it's not how it needs to be. I was closing in on 20 years into my career before ever hearing about this type of whiteboard algorithm memorization-style interview. It's common now, but it's not really normal and shouldn't be.
I for one take no part in that charade. I interview a lot of people and have never done a whiteboard algorithm dump question and never will.
I don't hire people to memorize algorithms from a book and write them on whiteboards all day, so I'm not going to interview for that irrelevant skill.
I'll read your resume and let's have a chat about projects you've worked on and what you'd like to work on.
[+] [-] Jistern|3 years ago|reply
A doctor, lawyer, public accountant, and, well, many types of engineers obtain public or private certifications. As a result, it is much, much, much easier for hiring companies to find and interview qualified candidates.
I suppose, in the "old days" universities kind of, sort of, filled this role. A hiring manager looking at a resume might have said, "Oh, he's got an EE/CS from Berkeley, there's a good chance he's qualified.
[+] [-] scarmig|3 years ago|reply
If you're hiring at scale, there's nothing else that matches it in terms of difficulty to game and cheapness of cost to implement. And for every engineer who says that they refuse out of principle to do Leetcode, there are ten who refuse to do time consuming take home projects and the nth implementation of a bespoke open source static site generator just to build a portfolio on Github.
Most smaller companies can and must figure out other hiring niches for overlooked/available candidates since they can't effectively compete with large companies for good conventional candidates using the same hiring process (e.g. by offering candidates more flexibility, taking more hiring risks), but pretending it's not a tradeoff isn't taking the problem seriously.
[+] [-] mjburgess|3 years ago|reply
If you renamed IQ to "linear-correlated ability to take non-domain specific tests", or "GTTQ" (general test-taking quotient). Then you'd explain every observed correlation between IQ and non-IQ performance.
So, do businesses want intelligent software engineers, or those with a high GTTQ score? As research at google, iirc, has shown: high performers on coding challenges tend to do worse in practice.
Any plausible theory of "competent software engineering" would, I think, place an extremely minor emphasis on a GTTQ. Intelligence is a much richer phenomenon (need for cognition, curiosity, resilliance to failure, domain-specific depth-wise thinking, cross-domain lateral, etc.)....
[+] [-] moomoo11|3 years ago|reply
Anywhere else where you use the Lego bricks to build some applications shouldn’t really use leetcode.
If you’re a good product engineer and you enjoy building good products, maybe you should start a company to build good products that solve problems for other people. Let the engineers who enjoy building the bricks do leetcode in peace so that we have solid pieces to build good software.
I’m doing the latter and trying to build a company. I realized I much prefer to build products that customers love, and I want to build useful software for people. I’m not that interested in low level tinkering and re-inventing the wheel all the time.
Coexistence is possible!
[+] [-] whateveracct|3 years ago|reply
[+] [-] tokyolights|3 years ago|reply
I did get an offer from them though, not sure how I would have felt if rejected.
[+] [-] valbaca|3 years ago|reply
A couple for example:
1. Given a set of number ranges (e.g. [1..3, 4..5, 9..20, 2..5]) consolidate them. Tying this to a real world scenario: we had a system that dealt with "time periods" and we needed to write a validator to ensure all future dates were covered by at least one configured "time period." One of the first steps to do this was basically the number-range consolidation.
2. Given a list of numbers output metrics like average, min, max, and mode. Now what if the list doesn't fit in memory and instead comes in as a stream (or from an iterator)? This one was inspired by an intern that got stuck when he needed to run calculations on data that didn't fit into memory. He was seriously about to request a host with 10+TB of memory before we stopped him.
[+] [-] unknown|3 years ago|reply
[deleted]
[+] [-] throwyawayyyy|3 years ago|reply
Also, more specifically on this piece: can anyone explain how Theranos fits in here? I don't get the connection. One the one hand we have a massive fraud, and on the other... people studying techniques that are rarely used by normal software engineers? But that nevertheless are, still, programming techniques.
And please no more "considered harmful" titles! It's painful to read at this point.
[+] [-] carlmr|3 years ago|reply
Me too, I've worked in teams without coding interviews, and they hired a lot more subpar engineers that made everybody's life harder.
If I interview I don't put so much emphasis on syntax or the algorithm itself, but whether people can tell me how the algorithms basically work and when to use them.
[+] [-] hughesjj|3 years ago|reply
https://news.ycombinator.com/item?id=9744916
[+] [-] crsl|3 years ago|reply
To me the value of coding interviews are knowing enough algorithms/data structures to apply and adapt them to problems, being able to quickly sketch out your idea, and explain trade-ffs.
[+] [-] tzs|3 years ago|reply
I'd show them a few problems that I thoroughly understand, ask them to pick two or three of them, and ask them for their thoughts on how to approach them. It would just be a discussion with no need to touch a computer. A whiteboard and scratch paper would be available if they wanted to use them.
I'd provide enough input to make sure the discussion moves along to figuring out a solution, but would try to let them take the lead only providing enough myself to make sure we make progress.
If I ended up providing most of the solution that would be fine. The most important part of the interview comes later.
Then what we'd do is look at the official answer and talk about it, seeing where it matches what we expected and where it does things differently, and maybe talk about whether those differences make it better than what we came up with.
Finally, and this is the most important part, we'd go to the Leetcode discussion for the problem.
In the discussion people post all kinds of solutions and those have all kinds of errors. Some are just flat out wrong. Some are mostly right but miss common edge cases (edge cases I would have made sure the interviewee and I talked about earlier). Some miss somewhat ridiculous edge cases such as failing if an input array is so large that all positive integers in the language they are using are valid array indexes. Some always give the right answer but don't meet the specified time or space constraints.
We'd do code reviews on some of those, again with me trying to just provide enough input to keep things moving along.
[+] [-] throwaway-dos|3 years ago|reply
But I find the whole discussion not strange but rather dishonest. I realize I'm biased towards thinking that the blog posts condemning some special sort of interviewing come from the "losers", the people that didn't get the job. That isn't true in general, but there is still this aura of entitlement: "I am a good programmer! I have other skills than leetcode! I demand an interview process that is tailored to my specific skills!"
I don't believe the claims that the current style of interviews is not working. This claim usually is made in the blog posts and in the interview horror stories, but I haven't seen it any of the FAANGs I worked in. Sure, some questions give more signal than others, but that's the company's problem, not the candidate's. If anything, large companies realize that lack of diversity is a larger problem and are trying to combat that directly (not with changing the hiring process for the general case though).
What it feels like is the blog posts try to solve a different problem ("how can I get a FAANG job") under the disguise of making the world a better place. Meanwhile, companies try to solve a completely different problem altogether ("how do we weed out candidates that might not be a good fit for what we value at scale with low latency?").
As a hiring manager, I'm interested in applicants that are (among others) good at leetcode-style questions without having had to train a lot on leetcode: Technical problems that are not easy to understand (cognitive and communication abilities), have a simple and easy trivial solution (higher level view on problems and customer orientation) and have high technical depth at scale (specific technical knowledge). So that's where the post is right: don't spend so much time on leetcode. But also don't try to change how companies interview. It's unbecoming.
[+] [-] cercatrova|3 years ago|reply
[+] [-] jjav|3 years ago|reply
That's a common phrase, but it's hardly ever true. You'll actually need to almost perfectly regurgitate the memorized solution, stumbling only enough to give a convincing theatrical impression that you're developing this algorithm on the spot instead of having memorized it (even though the original development of the algorithm probably took years of research).
[+] [-] urthor|3 years ago|reply
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.
[+] [-] hughesjj|3 years ago|reply
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.
[+] [-] teg4n_|3 years ago|reply
I dislike leetcode style puzzles so much that I will simply drop out of the interview loop rather than subject myself to them.
[+] [-] lbrito|3 years ago|reply
Take home project: typically capped at 4 hours.
Hmmm, this is a tough one...
[+] [-] matthewmacleod|3 years ago|reply
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.
[+] [-] eikenberry|3 years ago|reply
[+] [-] booboofixer|3 years ago|reply
[+] [-] postsantum|3 years ago|reply
[+] [-] ivolimmen|3 years ago|reply
[+] [-] Kim_Bruning|3 years ago|reply
Am I an outlier? I feel like I actually encounter these kinds of things fairly often, or at least the insights that they represent. (Eg: this week I'm implementing a simple path-finder to deal with a sliiightly overgrown state machine from a vendor. )
So - at least because of that - I tend to think of leetcode problems as more or less a slightly harder and more practical fizzbuzz. Complaints about leetcode do tend to mirror complaints you read about fizzbuzz.
Am I being strange here? Perhaps not. I figure there's at least two or three ways to pass a leet-code-like test: Either you just happen to have just done a bunch of marginally interesting programming somewhere in your past (which is probably what the test was designed for?), OR you did a study in college that ideally allows you to avoid the worst parts of the school of hard knocks (also ~fine), OR you explicitly practice for the test.
I suspect Goodharts law might be at work here: In some cases the measure has become the target.
[+] [-] 331c8c71|3 years ago|reply
Is that I'm blind? Or is it that the set of approachable impactful problems has been exhausted? Or all the innovation happens in closed source/saas space?
[+] [-] urthor|3 years ago|reply
What do you tell a React developer?
You're going to need Knuth-Morris-Pratt to center a div?
95% of software jobs involve using a library for algorithm problems.
[+] [-] mouzogu|3 years ago|reply
now there are leetcode grinding courses and books, it no longer serve any purpose than to dissuade those who don't have time, or motivation.
good way to identify the desperate willing for a small % chance in an 8 stage interview when someone may still reject you for some unknown reason.
[+] [-] pneumatic1|3 years ago|reply
I think of leetcode as the gym and I try to do one exercise everyday outside of work.
[+] [-] cardanome|3 years ago|reply
Of course they are not really that fair for people that don't have the time to learn the circus tricks because they have family and stuff but at least there is some appearance of fairness.
Also, compared to other performance based testing, the time requirements on both sides are kind of reasonable. I get more annoyed when the interview process requires me to basically provide free work.
[+] [-] unknown|3 years ago|reply
[deleted]
[+] [-] evnix|3 years ago|reply
Medicine is an old field, and I think these leetcode style interviews are only the beginning for the computer science based industry, the bar is only going to get higher as years pass which I feel may not be a bad thing overall for the software field.
[+] [-] kif|3 years ago|reply
The LC approach is fair if you only consider the fact that everybody will get these exercises. They are somewhat standard, and you know what to expect. However, you need to spend quite a lot of time to be able to solve difficult problems under a given time. And yet, emotions might get the best of you and you lose it, despite having solved the problem a bunch of times.
LC problems are not really useful as they don't resemble anything you'd do at work. However, if you do solve them, this shows to the company hiring you that you have been persistently training on LC problems, which shows you are consistent. A good quality, despite the uselessness of the problems.
The alternative, take home tests, are a better indicator of experience and engineering capability, although some might say one could "cheat". That's no different than outsourcing your job to somebody, which means this is fundamentally a trust issue -- so the problem lies elsewhere.
I've also seen variants of having candidates do some kind of trial where you get to experience what a typical day of work looks like at a company. This makes sense at a surface level, until you realise that the "typical day of work" is usually pretty atypical. They day of work trial generally can go two ways: the candidate works on an actual thing that needs to be done, or the candidate works on a fake thing users are supposedly asking for.
The latter is problematic, because you can do everything right, but since it's a) a fake problem, and b) you have no actual user feedback or requests to work on, this gets pretty subjective. Unless you read your interviewer's mind, you're left to wonder why you were rejected.
I'd take a LeetCode problem over a fake work day any time, as much as I dislike LC interviews. I guess all of this is to say, it's complicated :)
[+] [-] unknown|3 years ago|reply
[deleted]
[+] [-] golondon|3 years ago|reply
It clearly works for them so they continue doing it and able to grow their eng organisations to thousands of engineers. Any other solution to this problem wouldn't be without its trade offs. If he really wants to contribute to tech industry he is more than welcome to found his own company and hire the way he wants, instead of saying "I don't like this FAANG find a new way!".
[+] [-] P_I_Staker|3 years ago|reply
I don't think this is a very practical suggestion. FAANG are the winners and hold all the cash, which is why this is actually an issue. Asking someone to essentially try for a lottery ticket chance (in the best case) of repeating this success as a qualification for criticism is like telling people: "If you don't like America, you can get out"
[+] [-] weq|3 years ago|reply
If you wernt such an evil company you wouldnt need to pay people so much money to work on your ad data scam.
[+] [-] setuid9001|3 years ago|reply
[+] [-] mikymoothrowa|3 years ago|reply
You sound like you haven’t been interviewing/interviewed recently.
Knowing your DSA is one thing: the task isn’t: “let’s write some code to balance this tree”
It’s the extremely cringy “John has 40 watermelons that he needs to take to Mars” style problems
If you only need to demo your understanding of the undergrad level DSA, that’s fine. But if people have to exclusively spend 3 months preparing for LC in particular that’s just madness
And in India, people are just taking this to new heights with people beginning to no-life with LC for 3 *YEARS* and skipping everything else
[+] [-] texaslonghorn5|3 years ago|reply