7 ms·

The problem is that "leetcode" is a definitely a thing that exists in "FAANG" interviews. The biggest stumbling block with leetcode is that you shouldn't be pr

The problem is that "leetcode" is a definitely a thing that exists in "FAANG" interviews. The biggest stumbling block with leetcode is that you shouldn't be programming like that in real life. "make a linked list" no, just use a library like everyone else. "Implement addition in python but with string inputs", "no you can't use the built in x" All of that "clever" shit should be filtered out at PR/MR/diff review time. All of this "clever shit" is exceptionally bad programming. We don't live in the 80s anymore. we don't need to make our own sort algorithms. just. use. a. Library.

dkdbejwi383 3y ago
It also doesn't resemble "real" work with regards to gathering requirements, clarifying ambiguity, weighing up trade-offs, making sure code is clear, etc. It tends to be a rote regurgitation exercise.
- yieldcrv 3y ago
  > It tends to be a rote regurgitation exercise. where there are much greater selective pressures in India and China to excel at this than there are in the US, raising this irrelevant bar to absurd territory if you value your time
- robryan 3y ago
  A lot of places will also do a desgin interview to cover this aspect of the job.
  - pavlov 3y ago
    Which raises the question of why do the other kind of interview at all. I mean the leetcode nonsense whose end state is often a theatrical performance: “I’m pretending to invent this clever algorithm on the fly although I’ve practiced it for weeks”. Is there any evidence that candidates who do well on design interviews but fumble on leetcode would be any worse at the actual job?
    - slt2021 3y ago
      Leetcode is simply testing whether you studied Computer Science, took Data Structures & Algorithms course, and read the CLR book on algos and practices it. Nothing else. This is really freshman level cs work. very simple. people who cannot leetcode - a simple data structures & algorithms inteview - cannot understand runtime nuances of what they write. This is how you end up with N+1 algorithms and exponential runtime. For example look at all modern front-end in javascript - usually leetcode is more relaxed for front end, and you end up with ungodly gobbles of unnecessary loops inside loops wrapped in loops that traverse DOM for no good reason and freeze the browser. it is the javascript people who import node libraries that contain 3 lines of code, instead of writing it properly
      - Clamchop 3y ago
        Maybe. My experience is that a lot of the unprimed recall gets weak very quickly without practice. There's irony in testing for skills that a fresh graduate may do better at than someone with substantially more experience. Primed recall can remain strong for many years, but leetcode often penalizes googling around to refresh your memory, even though that is what almost everyone should do before taking any further steps toward an implementation. Depending, it's often also the correct thing to do before choosing a library, the parameters to a function, code base organization, and lots of other details. Of course, domain experts may be very strong in their specialty, but that's a special case with narrower scope. I can hypothesize that testing for a "fast study" may have more predictive power. I have seen some interviews that are designed for this, leetcode adjacent but less antagonistic. But anyway, I am spitballing, to be real with you.
      - remich 3y ago
        You don't need to be good at leetcode to make a performant and well written frontend. You don't even need to know data structures, algorithms, or Big O notation.
      - iwsk 3y ago
        what do you mean by N+1 algorithms?
- photon_lines 3y ago
  LeetCode has no correlation with great software development. Great development is more about paying attention to the end users, having an eye for usability and design and great communication & the ability to execute. The current LeetCode churning explains why Google hasn't produced anything worth using since Brin & Page checked out and why so much of software today is absolute garbage - but it is what it is I suppose. I suppose its better to screen for IQ and desparation than you know...people who love developing great software. Let them keep doing what they're doing while treating their own people like disposable garbage during hard times (like Google & Meta just did) and we'll see what they'll churn out over the next decade or so (I'm not expecting anything from either of these companies).
  - josephg 3y ago
    > LeetCode has no correlation with great software development. Great development is more about paying attention to the end users You can’t make blanket statements about software like that. Our field is way too varied. For example, if you’re doing high frequency trading, then performance absolutely 100% matters. And knowing your data structures and algorithms backwards is part of that. On the other hand, if you’re building the website at a large company, the hard part of your job may be interfacing with the rest of the business. So networking and navigating corporate politics will be an incredibly important part of your job. And if you’re on a small team making a product for consumers, then your work will succeed or fail based on usability. We could brainstorm dozens of other skills which might be important. Which of these skills matter the most depends entirely on the company and the role.
    - photon_lines 3y ago
      I don't disagree with you and I agree with your take on understanding data structures and algorithms ... it is important, but making 80 to 90 percent of your recruitment process based on this and on playing games with quizzes and LeetCode is idiotic. There are lots of other factors that play a vitally important role in creating great software and most big companies do NOTHING to pay attention to these factors albeit I fully admit to this being hard to test for. That's why I offer every company I'm recruited into to do a paid (or free albeit open source) work sample test if they want to do so. Most don't take me up on this offer and I think its idiotic but it is what it is.
- slt2021 3y ago
  > gathering requirements, clarifying ambiguity, weighing up trade-offs, making sure code is clear if you dont do that in leetcode interview - you will not make it, or you will be graded as junior/entry level engineer. No senior engineer will be passed without doing what you described during the leetcode interview
fnands 3y ago
My understanding is that they use it to filter candidates a bit. FAANG positions get loads of applicants, so they have to find efficient ways of thinning the herd a bit. The correlation between people who are willing to grind leetcode and who turn out to be good engineers is high enough that it's worth it for them to keep as a tool to sort the massive pile of applicants they get. Of course, hiring someone purely on how good they are at leetcode would be... dumb.
- dkdbejwi383 3y ago
  > The correlation between people who are willing to grind leetcode and who turn out to be good engineers is high enough that it's worth it for them to keep as a tool to sort the massive pile of applicants they get. One "subtlety" this misses is that leetcode-style trivia tests only work for those who are willing _and able_ to grind leetcode etc. There are many who have the aptitude and experience but have e.g. children, or interests outside of programming which means they do not have the required free time to spend rehearsing for this kind of interview.
  - fnands 3y ago
    The cynical part of thinks that that might be a feature, not a bug.
    - comprev 3y ago
      It is a feature. FAANG want dedicated engineers who don't have the distraction of family and/or sick relatives. They don't want people who need to finish _promptly_ each day to put their kids to bed. They want their pound of flesh in exchange for a high salary and ability to add "Worked at FAANG" on their CV. If you have the time and dedication to grind leetcode for months the you've passed their requirement.
      - jen20 3y ago
        This certainly does not match my FAANG experience.
a_humean 3y ago
The only justification is that its a filtering mechanism. You likely won't use any of this, but its a proxy to certain characteristics you might find desirable in a candidate - some baseline intelligence and motivation. That you have the capacity to sit down and rote memorise a bunch of different techniques and practice completing a these kinds of tests indicates the likeliness of success in absence of other hard evidence of likely future performance. In a way it is the same function as university entrance exams. That these companies continue to do this for experienced candidates and not just recent graduates without a track record in employment is more perplexing.
- shagie 3y ago
  > That these companies continue to do this for experienced candidates and not just recent graduates without a track record in employment is more perplexing. This assumes that they don't get similar number of people applying to the experienced positions who are lacking skills. For example, I know some Java devs who could put down 5+ years of professional experience but are still very junior when it comes to problem solving skills. They are capable of following precise instructions and there's enough work of that nature to do - but an open ended "there's a bug that has a null pointer exception when running in test but not dev or production" is something that they're not capable of doing. If they were to apply to a position that said senior java developer based on their years of experience and there was no code test as part if it, they might be able to talk their way through parts of it and there is a risk that they could get hired. For a senior java developer position at Google, would it be surprising if they got 500 applicants with 5+ years of experience? How would you meaningfully filter that down to a set of candidates who are likely to be able to fill the role?
faizshah 3y ago
The reason they do this is because there is a lot of debate over having some objective way to collect information about a candidate. So they have multiple rounds of standardized technical interview questions from which they can compare interview feedback. The rounds will be from different interviewers so they can control for bias of one interviewer. Then they are able to compare this standardized data across multiple candidates. Imo this process is flawed though because just one or two rounds of technical interviewing gives you enough information about whether the candidate can code. After that you need to understand how the candidate thinks since most of the job is spent doing things that aren’t coding. These are better probed by design questions, asking the candidate to critique some code, asking the candidate to explain a project from their resume and then propose alternatives and trade offs. Too often you get people who pass this interview process that can code at a basic level but hinder your team by giving poor feedback, having a fixed mindset, being a bad communicator, not being able to unblock themselves etc. It’s fine if you are just looking to grow a new grad though, although former interns are better.
PaulRobinson 3y ago
The problem is though how do you evaluate for real work without a portfolio of experience? Real work projects take weeks - perhaps months - to design, build, review and release. How do you test for that, really? I agree leetcode style interviews are artificial, but I think they persist because few people have identified and popularised effective alternatives. At least with leetcode you've shown people in front of you have been prepared to go learn arcane stuff and apply it. It's not good, but it's better than nothing. I was once asked to do the Gilded Rose kata[1] for one ~200 headcount Series D "startup", and it not only resembled real work - it's a refactoring problem - but it also showed their engineering culture. When I joined, I found smart people who weren't leetcode robots, but thoughtful engineers trying to solve tricky engineering problems. I "stole" Gilded Rose to use in other companies when interviewing until I joined my current employer (a FAANG, heavily prescribed process), with great success. I would like to see more katas that are as good at testing real world skills. Also, something I've only ever been interviewed for twice in 25+ years, which I think is underplayed: pair programming and handling code review feedback. Do this more, please. If you hire people not knowing how they're going to respond to a principal engineer telling them "we need you to think about 4 other things that weren't in the original scope given to you by the PM, can you please go deal with them", why are you surprised when toys are subsequently thrown out of metaphorical prams? [1] https://github.com/emilybache/GildedRose-Refactoring-Kata https://github.com/emilybache/GildedRose-Refactoring-Kata
- dkdbejwi383 3y ago
  Thanks for sharing, I've not come across this kata before. Seems like it'll be a fun one.
- jebarker 3y ago
  This seems like a better way to evaluate real-world coding skills. Did you use it in a standard 45-60 min interview or as a take home problem? It seems like it'd take a decent amount of time to read the requirements and just introduce the task.
  - PaulRobinson 3y ago
    Take home and “please time box it to maybe an hour maximum, you’re probably doing a load of interviews and tech tests at the moment, so you don’t need to finish: I just want to see your approach”. In-person time I used to like to ask a question I got from here: “Tell me about your favourite coding work or side project”. We’d then dig into choices, trade offs, obstacles and how they got around them. My favourite answer to this was “an OpenGL implementation for the X Window protocol which I wrote in Common Lisp”. Just getting through the first layer of “Why [x]?”, took 15 minutes and we spent an hour talking about all the facets. Hired him, was a superb colleague.
sdfghswe 3y ago
Just use a library, but those who can implement the library are better than the ones who can't. And that's what leetcode aims to distinguish. You thought the point of leetcode was to simulate live work conditions? lol
- thereisnojesus 3y ago
  What is it for. I don't think anyone here understands its purpose anymore.
onion2k 3y ago
All of this "clever shit" is exceptionally bad programming. In a company like Google (or Google 15 years ago really) there are problems with many possible solutions, but some solutions are better than others. The aim of leetcode recruitment is that it filters for people who can not only solve hard computer science problems, but also recognize what problem they're solving and find good solutions rather than just solutions. "I can implement this with a library" is only a good solution if the library is solving the problem in the right way. If the library is solving the problem but solving it in an inefficient-but-working way that is not good programming. At the end of the spectrum where Google exists you need developers who know the difference. The problem with leetcode is that it doesn't actually filter for people who can understand problems in a general sense. It filters for people who know leetcode problems.
- josephg 3y ago
  > If the library is solving the problem but solving it in an inefficient-but-working way that is not good programming. Yep. And even then, you need to know what you’re looking for. Years ago I wanted a library which implemented occlusion on vector shapes for plotter art. I had no idea what terms to search for because I don’t have a strong enough background in graphics. Turns out there are algorithms which help - but it was years before I found a good enough library. And if you know what to search for, there are so many terrible implementations out there. Look for priority queues on npm. Half the libraries implement custom binary trees or something, despite the fact that using a heap (an array) is way faster and simpler. If you don’t know why a heap is better, how could you possibly evaluate whether any given library is any good?
varjag 3y ago
Not a fan of LeetCode but arguments like this almost sell me on it.
gumby 3y ago
I'm not going to defend "leetcode grinding" and its pathologies but TBF this is problematic: > "make a linked list" no, just use a library like everyone else. > "Implement addition in python but with string inputs", "no you can't use the built in x" All of that "clever" shit should be filtered out at PR/MR/diff review time. Sure, those statements (just use an existing library) are what you'll do in practice especially as a beginner. But there is value in asking these kinds of questions. One is "do you know what's going on under the hood?" On another post I just saw a comment in which someone advocated counting the number of occurrences of something in a list by filtering it and then getting the length of the result. This is almost certainly a terrible solution as it allocates memory (which has to be freed) in what can be done in a single quick pass. By asking you such a question the interviewer can learn if you have some idea of the tradeoffs and why something might be a good or bad idea. These are the kinds of decisions that can have order of magnitude impacts on runtime, which can have huge impact on the company's costs. Likewise doing arithmetic with strings as inputs would expose interesting but not super complicated questions about how arithmetic works, how you parse a numeric value out of its written representation (detest the word "conversion" for this), what are interesting bounds. If the job is really so high level that you don't have to think that there's an actual machine involved, then yes the questions aren't useful. But how many jobs are really so abstract? > We don't live in the 80s anymore. we don't need to make our own sort algorithms. No, but sometimes you have to make a choice based on the data to be operated on.
- KaiserPro 3y ago
  > Sure, those statements (just use an existing library) are what you'll do in practice especially as a beginner The more code you write, the more you have to maintain. Sure, of course there are times where you need to re-implement something from scratch. But those times are rare (or should be). Making something from scratch without strong justification is a strong signal, just not a positive one. Now, as you point out, "when would you write x from scratch" is a great question to ask someone. I am vary wary of people that are willing to overspend innovation tokens. But thats a design/systems/culture question, not a coding question. the signal I want from a coding test is the following: o Can they demonstrate and understanding of the programming language? o Do they create readable code? o Do they ask questions? o Do they follow the style of the programme they are modifying? o Do they say "I don't know"? o Do they push back on weird or silly requirements? all of those things make working with someone much easier. None of those questions require "implement algorithm that only exist in Computer Science courses". They can all be answered by something like: "here is a program that fetches a json document, but it breaks often, please make it more reliable" That is far more realistic, and more likely to what they'll be doing. The dirty little secret about most coding jobs is that actually, the important thing is getting something functional and stable for the business, so it can make money. Then after that its responding to feature/bug requests. As a programmer, your job is to convert business logic into computer logic. 99% of the time, this doesn't mean making artisan libraries that improve some tiny metric by 20x.
hardware2win 3y ago
You realize that somebody wrote that lib and maybe they want ppl with skills to build stuff instead of just reusing? People always make weird arguments about lc, but whats the point? Just put effort into it or not, no excuses needed
- PartiallyTyped 3y ago
  My team is doing things for which libraries do not exist, things that are very much leetcode-esque, deeply into theoretical CS, lots of applied science. Some other teams here are doing data plumbing others do UI stuff. Our team can get to be very picky about people because ... well, we need to be.
foldr 3y ago
I think a fair number of Leetcode 'medium' problems are reasonable as augmented versions of FizzBuzz. In most cases, someone who can code should at least be able to write a brute force solution to one of these problems and explain why their brute force solution is slow. Where I think Leetcode-style questions become problematic is when they're used as test of whether someone can invent and implement a clever algorithm under time pressure. Unless you're hiring someone to do specifically that, then I think this style of Leetcode interviewing is of limited value. Also, some Leetcode problems just have unnecessarily unfriendly descriptions. For example this one, which is quite simple to implement, but which has an unnecessarily obscure problem description: https://leetcode.com/problems/count-and-say/ https://leetcode.com/problems/count-and-say/
- slt2021 3y ago
  some companies/teams use leetcode hard level problems to specifically select for ACM ICPC level talent to solve their particular problems, writing very tight compute kernels in constrained environment and unbounded input
catiopatio 3y ago
> "make a linked list" no, just use a library like everyone else. If you cannot sketch out a simple linked list on a whiteboard, you’re not an engineer and have no business being hired as one at a place like Apple, full stop. I was asked to sketch out a hash table on the whiteboard. It was trivial, because a trivial hash table is trivial.
- KaiserPro 3y ago
  > you’re not an engineer and have no business being hired as one at a place like Apple well, unless you have a engineering degree, you're not actually an engineer, but we'll gloss over that. (big hint CS isn't an engineering discipline, otherwise testing, requirements gathering and cost analysis would be a big part of the course. ) I was once asked to implement a distributed fault tolerant hashtable on a whiteboard. I'd still never make one from scratch unless I really really needed to. (and I've worked on distributed datastores....) but that wasn't part of the coding test, that was part of the design test. Which is my point, re-implementing things for the hell of it, is an antipattern. rote learning of toy implementations of some everyday function doesn't give you a good signal on if the candidate understands why you should use x over y. and again, my point is this: If I catch someone re-implementing something in a code review, they need to have a really good fucking reason to do it, otherwise it'll be rejected.
  - whateverman23 3y ago
    > well, unless you have a engineering degree, you're not actually an engineer That's not a requirement in the US.
    - edgyquant 3y ago
      Nor is it a requirement for a majority of engineering types regardless of country. Civil engineers think they have a monopoly on the word; this should always be pushed back upon.
  - OkayPhysicist 3y ago
    They're not asking you to re-implement it on a whiteboard so they can open a PR and shove it in their new app. They're asking you to re-implement it to demonstrate that you understand it, and that given an understanding of something, that you have the skills to implement it. If you can't hammer out a technical interview using off-the-top of your knowledge, you're in the group they're trying to weed out.
zyang 3y ago
Hiring should be a team level decision. Product roadmap should be an exec level decision. Google has it completely backwards. That's how you end up with hoards people gaming the hiring process by spending months on leetcode. And 3 chat apps from Google competing against each other.
- slt2021 3y ago
  gogle's product failure is failure of executives and product managers, not engineers.
- compiler-guy 3y ago
  Teams at Google are very fluid, there are many of them, and they change regularly. So it makes a lot of sense to be sure a candidate could be successful in a wide variety of teams.
- deleted 3y ago
  [deleted]
hotnfresh 3y ago
What’s funny is that in most positions the hard work has nothing to do with any of that. It’s communication, empathy, navigating people-problems and organizational dysfunction, and working with/around awful systems that you can’t change, while limiting their blast-radius to protect the business (and your own sanity). You can always just google how to invert a binary tree or whatever and get a solid answer in no time. Which means it’s easy shit. Unless you’re one of a few devs doing PhD level work in the industry, that CS-heavy “mathy” stuff’s not the hardest thing you’re dealing with, and being good at that indicates almost nothing about your ability to deal with the hard problems you will encounter on the job. (or else you’re greenfielding at a startup and are doing everything on easy-mode anyway, aside from problems you create for yourself on purpose or by accident)
- nh23423fefe 3y ago
  Sure, you can pretend developers don't read and write code. Just like people who complain about leetcode pretend the questions are hard and that performance is uncorrelated somehow.
  - hotnfresh 3y ago
    > Sure, you can pretend developers don't read and write code. Weird. Why would someone pretend that?
- varjag 3y ago
  Communication, empathy and navigating people is easy: there's a deluge of people capable of doing that. Writing code is hard. Not many people can code at all; even fewer are any good at it. This is why you can easily be unemployed after BA in Communications but have little problem getting a job after high school if you can code.
  - remich 3y ago
    In my experience, it's relatively rare among software engineers. So, even if it's over-represented in the general population (which I'm skeptical of), having actual skill at that makes you leaps and bounds more effective than others, once you get up to senior+ level.
jeffbee 3y ago
Adding 1 to an ASCII decimal strings is a great icebreaker and I always use it. It is not leetcode. It is a filter for people who have actually encountered computers before. Even though our industry is maturing there are still a huge number of candidates who present themselves without ever once having written a program. I find the question has a massive signal. Either the candidate aces it in 15 seconds, or they immediately ask a bunch of on-point clarifying questions, or they are stumped.
- marliechiller 3y ago
  I have written countless programs but would not be able to answer that without first turning to google. You might have screened out plenty of valid applicants with this
  - pphysch 3y ago
    You don't know how to transform the string "12345" to "12346" in a mainstream PL? I don't think "valid applicant" and "doesn't really grok strings/types" are compatible, outside of intern/maybe junior positions. The filter works.
    - marliechiller 3y ago
      The filter works perhaps for whatever niche you might be working in. I cant imagine asking this to one of my candidates and then assessing their entire professional experience off of something like this though.
      - pphysch 3y ago
        What domain do you program in where handling strings/bytes is not a weekly if not daily task?
        marliechiller 3y ago
        The point is not whether an applicant can or cannot do it, the point is that the question is deliberately rephrasing to obscure a candidates understanding. If you ask your average candidate to do that in laymans terms or they were given 5 seconds to google this would be a trivial task and you would have a different outcome. All this selects for is the candidate to have a working definition of an ascii decimal string in their head, it represents no ability to problem solve whatsoever.
gaoshan 3y ago
Agreed. At our company the technical interview involves walking a dev through a working app that uses the same stack we develop with. There are bugs to solve, potential optimizations that exist and the dev explains and walks through the client/server/database portions (leaning into one or the other as needed). No tricky questions or puzzles... just actual code (a simplified subset but still real, working code).
circuit 3y ago
You do know we hire people who have to _write_ these libraries, and they can't just defer to something else with no consideration to time or space constraints. None of the questions are designed to be brainteasers or 'gotchas' but to get you to start discussing the problem and show your depth of knowledge/expertise. If I ask you a question along the lines of "write me a function to tell if two number ranges intersect" and your solution is to grab a library instead of writing a simple predicate...then perhaps the role is not a good fit. "Use a library for everything" is how we ended up with left-pad on npm.
- KaiserPro 3y ago
  > "Use a library for everything" is how we ended up with left-pad on npm. bollocks, that's because javascript doesn't have a standard lib. > You do know we hire people who have to _write_ these libraries I know, because I'm there. I'm working in VR/AR. We have a number of people who are world experts for doing what they are doing. Do I go off and re-make a SLAM library because I don't like the layout? no because I have to ship something useable in a normal time frame. I can't just drop 3 months replicating someone else's work because I think the layout is a bit shit, or I can't be bothered to read the docs (I mean obviously there are no docs, but thats a different problem) But, and I cannot stress this enough, having more than one person making similar or related libraries is a disaster. Nothing gets shipped and everything is devoted to "improving" the competing libraries.
TillE 3y ago
If you can't explain in detail how a linked list works, that's an enormous red flag that you've probably never studied data structures. It's a FizzBuzz level question. I'm sure some companies have lousy interview practices, but algorithms and data structures are super important if you want to hire someone who's actually competent, who can think for themselves.

dkdbejwi383 3y ago

It also doesn't resemble "real" work with regards to gathering requirements, clarifying ambiguity, weighing up trade-offs, making sure code is clear, etc. It tends to be a rote regurgitation exercise.

yieldcrv 3y ago
> It tends to be a rote regurgitation exercise. where there are much greater selective pressures in India and China to excel at this than there are in the US, raising this irrelevant bar to absurd territory if you value your time
robryan 3y ago
A lot of places will also do a desgin interview to cover this aspect of the job.
- pavlov 3y ago
  Which raises the question of why do the other kind of interview at all. I mean the leetcode nonsense whose end state is often a theatrical performance: “I’m pretending to invent this clever algorithm on the fly although I’ve practiced it for weeks”. Is there any evidence that candidates who do well on design interviews but fumble on leetcode would be any worse at the actual job?
  - slt2021 3y ago
    Leetcode is simply testing whether you studied Computer Science, took Data Structures & Algorithms course, and read the CLR book on algos and practices it. Nothing else. This is really freshman level cs work. very simple. people who cannot leetcode - a simple data structures & algorithms inteview - cannot understand runtime nuances of what they write. This is how you end up with N+1 algorithms and exponential runtime. For example look at all modern front-end in javascript - usually leetcode is more relaxed for front end, and you end up with ungodly gobbles of unnecessary loops inside loops wrapped in loops that traverse DOM for no good reason and freeze the browser. it is the javascript people who import node libraries that contain 3 lines of code, instead of writing it properly
    - Clamchop 3y ago
      Maybe. My experience is that a lot of the unprimed recall gets weak very quickly without practice. There's irony in testing for skills that a fresh graduate may do better at than someone with substantially more experience. Primed recall can remain strong for many years, but leetcode often penalizes googling around to refresh your memory, even though that is what almost everyone should do before taking any further steps toward an implementation. Depending, it's often also the correct thing to do before choosing a library, the parameters to a function, code base organization, and lots of other details. Of course, domain experts may be very strong in their specialty, but that's a special case with narrower scope. I can hypothesize that testing for a "fast study" may have more predictive power. I have seen some interviews that are designed for this, leetcode adjacent but less antagonistic. But anyway, I am spitballing, to be real with you.
    - remich 3y ago
      You don't need to be good at leetcode to make a performant and well written frontend. You don't even need to know data structures, algorithms, or Big O notation.
    - iwsk 3y ago
      what do you mean by N+1 algorithms?
photon_lines 3y ago
LeetCode has no correlation with great software development. Great development is more about paying attention to the end users, having an eye for usability and design and great communication & the ability to execute. The current LeetCode churning explains why Google hasn't produced anything worth using since Brin & Page checked out and why so much of software today is absolute garbage - but it is what it is I suppose. I suppose its better to screen for IQ and desparation than you know...people who love developing great software. Let them keep doing what they're doing while treating their own people like disposable garbage during hard times (like Google & Meta just did) and we'll see what they'll churn out over the next decade or so (I'm not expecting anything from either of these companies).
- josephg 3y ago
  > LeetCode has no correlation with great software development. Great development is more about paying attention to the end users You can’t make blanket statements about software like that. Our field is way too varied. For example, if you’re doing high frequency trading, then performance absolutely 100% matters. And knowing your data structures and algorithms backwards is part of that. On the other hand, if you’re building the website at a large company, the hard part of your job may be interfacing with the rest of the business. So networking and navigating corporate politics will be an incredibly important part of your job. And if you’re on a small team making a product for consumers, then your work will succeed or fail based on usability. We could brainstorm dozens of other skills which might be important. Which of these skills matter the most depends entirely on the company and the role.
  - photon_lines 3y ago
    I don't disagree with you and I agree with your take on understanding data structures and algorithms ... it is important, but making 80 to 90 percent of your recruitment process based on this and on playing games with quizzes and LeetCode is idiotic. There are lots of other factors that play a vitally important role in creating great software and most big companies do NOTHING to pay attention to these factors albeit I fully admit to this being hard to test for. That's why I offer every company I'm recruited into to do a paid (or free albeit open source) work sample test if they want to do so. Most don't take me up on this offer and I think its idiotic but it is what it is.
slt2021 3y ago
> gathering requirements, clarifying ambiguity, weighing up trade-offs, making sure code is clear if you dont do that in leetcode interview - you will not make it, or you will be graded as junior/entry level engineer. No senior engineer will be passed without doing what you described during the leetcode interview

fnands 3y ago

My understanding is that they use it to filter candidates a bit. FAANG positions get loads of applicants, so they have to find efficient ways of thinning the herd a bit. The correlation between people who are willing to grind leetcode and who turn out to be good engineers is high enough that it's worth it for them to keep as a tool to sort the massive pile of applicants they get. Of course, hiring someone purely on how good they are at leetcode would be... dumb.

dkdbejwi383 3y ago
> The correlation between people who are willing to grind leetcode and who turn out to be good engineers is high enough that it's worth it for them to keep as a tool to sort the massive pile of applicants they get. One "subtlety" this misses is that leetcode-style trivia tests only work for those who are willing _and able_ to grind leetcode etc. There are many who have the aptitude and experience but have e.g. children, or interests outside of programming which means they do not have the required free time to spend rehearsing for this kind of interview.
- fnands 3y ago
  The cynical part of thinks that that might be a feature, not a bug.
  - comprev 3y ago
    It is a feature. FAANG want dedicated engineers who don't have the distraction of family and/or sick relatives. They don't want people who need to finish _promptly_ each day to put their kids to bed. They want their pound of flesh in exchange for a high salary and ability to add "Worked at FAANG" on their CV. If you have the time and dedication to grind leetcode for months the you've passed their requirement.
    - jen20 3y ago
      This certainly does not match my FAANG experience.

a_humean 3y ago

The only justification is that its a filtering mechanism. You likely won't use any of this, but its a proxy to certain characteristics you might find desirable in a candidate - some baseline intelligence and motivation. That you have the capacity to sit down and rote memorise a bunch of different techniques and practice completing a these kinds of tests indicates the likeliness of success in absence of other hard evidence of likely future performance. In a way it is the same function as university entrance exams. That these companies continue to do this for experienced candidates and not just recent graduates without a track record in employment is more perplexing.

shagie 3y ago
> That these companies continue to do this for experienced candidates and not just recent graduates without a track record in employment is more perplexing. This assumes that they don't get similar number of people applying to the experienced positions who are lacking skills. For example, I know some Java devs who could put down 5+ years of professional experience but are still very junior when it comes to problem solving skills. They are capable of following precise instructions and there's enough work of that nature to do - but an open ended "there's a bug that has a null pointer exception when running in test but not dev or production" is something that they're not capable of doing. If they were to apply to a position that said senior java developer based on their years of experience and there was no code test as part if it, they might be able to talk their way through parts of it and there is a risk that they could get hired. For a senior java developer position at Google, would it be surprising if they got 500 applicants with 5+ years of experience? How would you meaningfully filter that down to a set of candidates who are likely to be able to fill the role?

faizshah 3y ago

The reason they do this is because there is a lot of debate over having some objective way to collect information about a candidate. So they have multiple rounds of standardized technical interview questions from which they can compare interview feedback. The rounds will be from different interviewers so they can control for bias of one interviewer. Then they are able to compare this standardized data across multiple candidates. Imo this process is flawed though because just one or two rounds of technical interviewing gives you enough information about whether the candidate can code. After that you need to understand how the candidate thinks since most of the job is spent doing things that aren’t coding. These are better probed by design questions, asking the candidate to critique some code, asking the candidate to explain a project from their resume and then propose alternatives and trade offs. Too often you get people who pass this interview process that can code at a basic level but hinder your team by giving poor feedback, having a fixed mindset, being a bad communicator, not being able to unblock themselves etc. It’s fine if you are just looking to grow a new grad though, although former interns are better.

PaulRobinson 3y ago

The problem is though how do you evaluate for real work without a portfolio of experience? Real work projects take weeks - perhaps months - to design, build, review and release. How do you test for that, really? I agree leetcode style interviews are artificial, but I think they persist because few people have identified and popularised effective alternatives. At least with leetcode you've shown people in front of you have been prepared to go learn arcane stuff and apply it. It's not good, but it's better than nothing. I was once asked to do the Gilded Rose kata[1] for one ~200 headcount Series D "startup", and it not only resembled real work - it's a refactoring problem - but it also showed their engineering culture. When I joined, I found smart people who weren't leetcode robots, but thoughtful engineers trying to solve tricky engineering problems. I "stole" Gilded Rose to use in other companies when interviewing until I joined my current employer (a FAANG, heavily prescribed process), with great success. I would like to see more katas that are as good at testing real world skills. Also, something I've only ever been interviewed for twice in 25+ years, which I think is underplayed: pair programming and handling code review feedback. Do this more, please. If you hire people not knowing how they're going to respond to a principal engineer telling them "we need you to think about 4 other things that weren't in the original scope given to you by the PM, can you please go deal with them", why are you surprised when toys are subsequently thrown out of metaphorical prams? [1] https://github.com/emilybache/GildedRose-Refactoring-Kata https://github.com/emilybache/GildedRose-Refactoring-Kata

dkdbejwi383 3y ago
Thanks for sharing, I've not come across this kata before. Seems like it'll be a fun one.
jebarker 3y ago
This seems like a better way to evaluate real-world coding skills. Did you use it in a standard 45-60 min interview or as a take home problem? It seems like it'd take a decent amount of time to read the requirements and just introduce the task.
- PaulRobinson 3y ago
  Take home and “please time box it to maybe an hour maximum, you’re probably doing a load of interviews and tech tests at the moment, so you don’t need to finish: I just want to see your approach”. In-person time I used to like to ask a question I got from here: “Tell me about your favourite coding work or side project”. We’d then dig into choices, trade offs, obstacles and how they got around them. My favourite answer to this was “an OpenGL implementation for the X Window protocol which I wrote in Common Lisp”. Just getting through the first layer of “Why [x]?”, took 15 minutes and we spent an hour talking about all the facets. Hired him, was a superb colleague.

sdfghswe 3y ago

Just use a library, but those who can implement the library are better than the ones who can't. And that's what leetcode aims to distinguish. You thought the point of leetcode was to simulate live work conditions? lol

thereisnojesus 3y ago
What is it for. I don't think anyone here understands its purpose anymore.

onion2k 3y ago

All of this "clever shit" is exceptionally bad programming. In a company like Google (or Google 15 years ago really) there are problems with many possible solutions, but some solutions are better than others. The aim of leetcode recruitment is that it filters for people who can not only solve hard computer science problems, but also recognize what problem they're solving and find good solutions rather than just solutions. "I can implement this with a library" is only a good solution if the library is solving the problem in the right way. If the library is solving the problem but solving it in an inefficient-but-working way that is not good programming. At the end of the spectrum where Google exists you need developers who know the difference. The problem with leetcode is that it doesn't actually filter for people who can understand problems in a general sense. It filters for people who know leetcode problems.

josephg 3y ago
> If the library is solving the problem but solving it in an inefficient-but-working way that is not good programming. Yep. And even then, you need to know what you’re looking for. Years ago I wanted a library which implemented occlusion on vector shapes for plotter art. I had no idea what terms to search for because I don’t have a strong enough background in graphics. Turns out there are algorithms which help - but it was years before I found a good enough library. And if you know what to search for, there are so many terrible implementations out there. Look for priority queues on npm. Half the libraries implement custom binary trees or something, despite the fact that using a heap (an array) is way faster and simpler. If you don’t know why a heap is better, how could you possibly evaluate whether any given library is any good?

varjag 3y ago

Not a fan of LeetCode but arguments like this almost sell me on it.

gumby 3y ago

I'm not going to defend "leetcode grinding" and its pathologies but TBF this is problematic: > "make a linked list" no, just use a library like everyone else. > "Implement addition in python but with string inputs", "no you can't use the built in x" All of that "clever" shit should be filtered out at PR/MR/diff review time. Sure, those statements (just use an existing library) are what you'll do in practice especially as a beginner. But there is value in asking these kinds of questions. One is "do you know what's going on under the hood?" On another post I just saw a comment in which someone advocated counting the number of occurrences of something in a list by filtering it and then getting the length of the result. This is almost certainly a terrible solution as it allocates memory (which has to be freed) in what can be done in a single quick pass. By asking you such a question the interviewer can learn if you have some idea of the tradeoffs and why something might be a good or bad idea. These are the kinds of decisions that can have order of magnitude impacts on runtime, which can have huge impact on the company's costs. Likewise doing arithmetic with strings as inputs would expose interesting but not super complicated questions about how arithmetic works, how you parse a numeric value out of its written representation (detest the word "conversion" for this), what are interesting bounds. If the job is really so high level that you don't have to think that there's an actual machine involved, then yes the questions aren't useful. But how many jobs are really so abstract? > We don't live in the 80s anymore. we don't need to make our own sort algorithms. No, but sometimes you have to make a choice based on the data to be operated on.

KaiserPro 3y ago
> Sure, those statements (just use an existing library) are what you'll do in practice especially as a beginner The more code you write, the more you have to maintain. Sure, of course there are times where you need to re-implement something from scratch. But those times are rare (or should be). Making something from scratch without strong justification is a strong signal, just not a positive one. Now, as you point out, "when would you write x from scratch" is a great question to ask someone. I am vary wary of people that are willing to overspend innovation tokens. But thats a design/systems/culture question, not a coding question. the signal I want from a coding test is the following: o Can they demonstrate and understanding of the programming language? o Do they create readable code? o Do they ask questions? o Do they follow the style of the programme they are modifying? o Do they say "I don't know"? o Do they push back on weird or silly requirements? all of those things make working with someone much easier. None of those questions require "implement algorithm that only exist in Computer Science courses". They can all be answered by something like: "here is a program that fetches a json document, but it breaks often, please make it more reliable" That is far more realistic, and more likely to what they'll be doing. The dirty little secret about most coding jobs is that actually, the important thing is getting something functional and stable for the business, so it can make money. Then after that its responding to feature/bug requests. As a programmer, your job is to convert business logic into computer logic. 99% of the time, this doesn't mean making artisan libraries that improve some tiny metric by 20x.

hardware2win 3y ago

You realize that somebody wrote that lib and maybe they want ppl with skills to build stuff instead of just reusing? People always make weird arguments about lc, but whats the point? Just put effort into it or not, no excuses needed

PartiallyTyped 3y ago
My team is doing things for which libraries do not exist, things that are very much leetcode-esque, deeply into theoretical CS, lots of applied science. Some other teams here are doing data plumbing others do UI stuff. Our team can get to be very picky about people because ... well, we need to be.

foldr 3y ago

I think a fair number of Leetcode 'medium' problems are reasonable as augmented versions of FizzBuzz. In most cases, someone who can code should at least be able to write a brute force solution to one of these problems and explain why their brute force solution is slow. Where I think Leetcode-style questions become problematic is when they're used as test of whether someone can invent and implement a clever algorithm under time pressure. Unless you're hiring someone to do specifically that, then I think this style of Leetcode interviewing is of limited value. Also, some Leetcode problems just have unnecessarily unfriendly descriptions. For example this one, which is quite simple to implement, but which has an unnecessarily obscure problem description: https://leetcode.com/problems/count-and-say/ https://leetcode.com/problems/count-and-say/

slt2021 3y ago
some companies/teams use leetcode hard level problems to specifically select for ACM ICPC level talent to solve their particular problems, writing very tight compute kernels in constrained environment and unbounded input

catiopatio 3y ago

> "make a linked list" no, just use a library like everyone else. If you cannot sketch out a simple linked list on a whiteboard, you’re not an engineer and have no business being hired as one at a place like Apple, full stop. I was asked to sketch out a hash table on the whiteboard. It was trivial, because a trivial hash table is trivial.

KaiserPro 3y ago
> you’re not an engineer and have no business being hired as one at a place like Apple well, unless you have a engineering degree, you're not actually an engineer, but we'll gloss over that. (big hint CS isn't an engineering discipline, otherwise testing, requirements gathering and cost analysis would be a big part of the course. ) I was once asked to implement a distributed fault tolerant hashtable on a whiteboard. I'd still never make one from scratch unless I really really needed to. (and I've worked on distributed datastores....) but that wasn't part of the coding test, that was part of the design test. Which is my point, re-implementing things for the hell of it, is an antipattern. rote learning of toy implementations of some everyday function doesn't give you a good signal on if the candidate understands why you should use x over y. and again, my point is this: If I catch someone re-implementing something in a code review, they need to have a really good fucking reason to do it, otherwise it'll be rejected.
- whateverman23 3y ago
  > well, unless you have a engineering degree, you're not actually an engineer That's not a requirement in the US.
  - edgyquant 3y ago
    Nor is it a requirement for a majority of engineering types regardless of country. Civil engineers think they have a monopoly on the word; this should always be pushed back upon.
- OkayPhysicist 3y ago
  They're not asking you to re-implement it on a whiteboard so they can open a PR and shove it in their new app. They're asking you to re-implement it to demonstrate that you understand it, and that given an understanding of something, that you have the skills to implement it. If you can't hammer out a technical interview using off-the-top of your knowledge, you're in the group they're trying to weed out.

zyang 3y ago

Hiring should be a team level decision. Product roadmap should be an exec level decision. Google has it completely backwards. That's how you end up with hoards people gaming the hiring process by spending months on leetcode. And 3 chat apps from Google competing against each other.

slt2021 3y ago
gogle's product failure is failure of executives and product managers, not engineers.
compiler-guy 3y ago
Teams at Google are very fluid, there are many of them, and they change regularly. So it makes a lot of sense to be sure a candidate could be successful in a wide variety of teams.
deleted 3y ago
[deleted]

hotnfresh 3y ago

What’s funny is that in most positions the hard work has nothing to do with any of that. It’s communication, empathy, navigating people-problems and organizational dysfunction, and working with/around awful systems that you can’t change, while limiting their blast-radius to protect the business (and your own sanity). You can always just google how to invert a binary tree or whatever and get a solid answer in no time. Which means it’s easy shit. Unless you’re one of a few devs doing PhD level work in the industry, that CS-heavy “mathy” stuff’s not the hardest thing you’re dealing with, and being good at that indicates almost nothing about your ability to deal with the hard problems you will encounter on the job. (or else you’re greenfielding at a startup and are doing everything on easy-mode anyway, aside from problems you create for yourself on purpose or by accident)

nh23423fefe 3y ago
Sure, you can pretend developers don't read and write code. Just like people who complain about leetcode pretend the questions are hard and that performance is uncorrelated somehow.
- hotnfresh 3y ago
  > Sure, you can pretend developers don't read and write code. Weird. Why would someone pretend that?
varjag 3y ago
Communication, empathy and navigating people is easy: there's a deluge of people capable of doing that. Writing code is hard. Not many people can code at all; even fewer are any good at it. This is why you can easily be unemployed after BA in Communications but have little problem getting a job after high school if you can code.
- remich 3y ago
  In my experience, it's relatively rare among software engineers. So, even if it's over-represented in the general population (which I'm skeptical of), having actual skill at that makes you leaps and bounds more effective than others, once you get up to senior+ level.

jeffbee 3y ago

Adding 1 to an ASCII decimal strings is a great icebreaker and I always use it. It is not leetcode. It is a filter for people who have actually encountered computers before. Even though our industry is maturing there are still a huge number of candidates who present themselves without ever once having written a program. I find the question has a massive signal. Either the candidate aces it in 15 seconds, or they immediately ask a bunch of on-point clarifying questions, or they are stumped.

marliechiller 3y ago
I have written countless programs but would not be able to answer that without first turning to google. You might have screened out plenty of valid applicants with this
- pphysch 3y ago
  You don't know how to transform the string "12345" to "12346" in a mainstream PL? I don't think "valid applicant" and "doesn't really grok strings/types" are compatible, outside of intern/maybe junior positions. The filter works.
  - marliechiller 3y ago
    The filter works perhaps for whatever niche you might be working in. I cant imagine asking this to one of my candidates and then assessing their entire professional experience off of something like this though.
    - pphysch 3y ago
      What domain do you program in where handling strings/bytes is not a weekly if not daily task?
      - marliechiller 3y ago
        The point is not whether an applicant can or cannot do it, the point is that the question is deliberately rephrasing to obscure a candidates understanding. If you ask your average candidate to do that in laymans terms or they were given 5 seconds to google this would be a trivial task and you would have a different outcome. All this selects for is the candidate to have a working definition of an ascii decimal string in their head, it represents no ability to problem solve whatsoever.

gaoshan 3y ago

Agreed. At our company the technical interview involves walking a dev through a working app that uses the same stack we develop with. There are bugs to solve, potential optimizations that exist and the dev explains and walks through the client/server/database portions (leaning into one or the other as needed). No tricky questions or puzzles... just actual code (a simplified subset but still real, working code).

circuit 3y ago

You do know we hire people who have to _write_ these libraries, and they can't just defer to something else with no consideration to time or space constraints. None of the questions are designed to be brainteasers or 'gotchas' but to get you to start discussing the problem and show your depth of knowledge/expertise. If I ask you a question along the lines of "write me a function to tell if two number ranges intersect" and your solution is to grab a library instead of writing a simple predicate...then perhaps the role is not a good fit. "Use a library for everything" is how we ended up with left-pad on npm.

KaiserPro 3y ago
> "Use a library for everything" is how we ended up with left-pad on npm. bollocks, that's because javascript doesn't have a standard lib. > You do know we hire people who have to _write_ these libraries I know, because I'm there. I'm working in VR/AR. We have a number of people who are world experts for doing what they are doing. Do I go off and re-make a SLAM library because I don't like the layout? no because I have to ship something useable in a normal time frame. I can't just drop 3 months replicating someone else's work because I think the layout is a bit shit, or I can't be bothered to read the docs (I mean obviously there are no docs, but thats a different problem) But, and I cannot stress this enough, having more than one person making similar or related libraries is a disaster. Nothing gets shipped and everything is devoted to "improving" the competing libraries.

TillE 3y ago

If you can't explain in detail how a linked list works, that's an enormous red flag that you've probably never studied data structures. It's a FizzBuzz level question. I'm sure some companies have lousy interview practices, but algorithms and data structures are super important if you want to hire someone who's actually competent, who can think for themselves.