33 ms·

Stop Interviewing with Leet Code

• scrapheap 4y ago
  Leet Code tests can be a great way to find good engineers - after you've told them what complex puzzle you want them to code, you can reject any that don't ask you why you need it! :)
• dwenzek 4y ago
  I love this idea to check how quickly a candidate can learn: if blocked on some coding/refactoring question, show the candidate how to do it, erase everything and ask him to redo it alone.
• djstein 4y ago
  I've decided I'm going to start interviewing with a set of PR's per each role we hire for. each PR will have obvious mistakes, complicated logic problems, as well as code that could be "refactored" once the whole PR has been read. this provides a few things; it gives us an ability at how the interviewee problem solves. next we can see how they respond too obvious fixes (would they be someone you'd want to send a PR too?). finally, it tests their knowledge of the language and APIs, hopefully much better than Leet Code can. I would also like to see if the user can spot obvious bugs in the setup code (say, package.json, pyproject.toml, etc) I am going to make an example PR for: - frontend (React/NextJS, TypeScript, CSS) - backend (Django, Python) - DevOps (potentially some Pulumi code for deploying to a Kubernetes cluster?)
  • yieldcrv 4y ago
    I think there are flaws with this approach too, but I wish this approach was more common so that there was industry wide rapid iteration to a more optimized version of this. What I’ve seen are time trials, which don’t show you how well a candidate will adapt to a codebase, wont show you how they will do tickets for your sprint. Only reinforces a flawed idea of the employer about how they wont “hit the ground running” despite having that job opening for 8 months. What you described might not be a time trial, its what ive seen though.
  • djmips 4y ago
    Although this is better than leet code, PRs have been shown to be a poor way to prevent bugs. I find they are mostly useful for disseminating knowledge.
  • aitchnyu 4y ago
    I once a test with badly written code and gave my comments. A bot immediately asked me to implement those changes, but I assumed a human would respond. I made a YAGNI change, trying not to disturb existing code too much. They responded saying the comments raised during PR were good, but writing a big switch statement for all subclasses violates Liskov Substitution Principle.
• yieldcrv 4y ago
  > Alternatively, look at under-performing people and find what they are lacking This is great suggestion. While the “look at their github” one is a bad suggestion. Github polishing is theatre more suited for theatre majors instead of people actually working with integrity before coming to your company. Its very similar to the issue with the leetcode interviews as its geared towards people with time to optimize that instead of a day to day job.
  • livinglist 4y ago
    A software engineer should tell easily whether or not one’s GitHub is authentic by looking at commit history, ownership of repo etc…
    • yieldcrv 4y ago
      Oh you focused on the “polishing” and not the “there’s nothing to show” part People good at their jobs because they do their job: nothing on github People in the business of performance theatre because they dont have a job to be good at: plenty on github. It can be legit code they wrote, that was not the point at all.
      • DarkWiiPlayer 4y ago
        I half agree with this. I don't like the idea that every developer has to have code on github. If they want to code for work and nothing more, then that's fine and shouldn't disqualify them from any jobs. We shouldn't expect people to spend years of employment building up a portfolio for the next time they're looking for a job. However, I don't see how looking at the code people write isn't informative. You can see many things, from small-scale code style decisions to how they structure an application just from looking through their github profile. Writing code isn't a performance, it's literally what you want to pay them for.
        • yieldcrv 4y ago
          Of the people with code on github, a lot of that is forked projects with small contributions, and the rest is small convenience or learning projects that werent meant for scrutiny. If its curated its because they are making a performance that also has nothing to do with being with an employee before meeting you. Github presence is just a non signal. Thats the only point. We agree that if you have a different way to see how theyll actually structure code for you, then its useful
• pjmlp 4y ago
  Right now, I get bombarded with headhunter requests, if you are going to ask me to leet code, my inbox is full of alternatives. Leet Code is only cargo culted because many candidates let it happen.
• 5350-uiop-1130 4y ago
  issue with leetcode is it designed to filter out 95% of people, companies dont want to know you they rather keep a set of leetcode, iq and personality test to remove you from the list of candidates root cause is bootcamps over saturation of devs in job market, especially in web
• lbriner 4y ago
  These articles always seem to have an underlying assumption that really great people are being denied access to jobs because they can't get through these interviews but it is implying that the people who do get through these are not also great but are less hassle, easier to measure their ability and so what if they have swatted up on LeetCode to help their application? That means they are driven, that they have learned stuff on the way and are more likely to get something right the first time. I have been on the receiving end of applying to an agency and being told I didn't make the grade technically. I was disappointed because I know I am a good engineer but I didn't expect them to magically know this. I can also see how my approach to the technical tests might have made me look less than what they were looking for, which is fine. I am also not sure of any good alternatives because someone will always object to any alternative which they cannot achieve for some reason. A "take home" project is good for real life work but some people cannot (or will not) invest the time even if they are paid for it; discussions can be great for helping nervous people but that is not how work usually is, there are challenges, pressures etc. and the able people object that it is not fair that people are getting in too easily.
  • nicoburns 4y ago
    A realistic problem similar to what they’ll be expected to d in the job followed by a discussion to ensure they actually understand it makes much more sense than leetcode. Ideally with time for them to complete some of it independently with full access to the internet, an editor, etc.
  • sdrothrock 4y ago
    > I am also not sure of any good alternatives because someone will always object to any alternative which they cannot achieve for some reason. When I was on the market, a couple of companies actually gave me a variety of options, which I appreciated. I don't want to spend hours on a take-home and I also don't want to do leetcode, but an open question/answer plus some code review and live debugging was an acceptable combination for me. Providing the options definitely has the potential to take up developer time, but I think the tradeoffs are worthwhile for both the interviewee and the hiring team.
• totorovirus 4y ago
  I keep seeing this kind of article that leetcode is not the answer. Yes it is not the answer but the best strategy to filter out not dumb, low IQ people who are going to panic when you give a vague, open ended problem. There are many people who call themselves engineers while trying to talk everything out instead of diving deep into problem.
  • franga2000 4y ago
    You know what else will filter out dumb people? A vague open ended problem that is relevant to the position you're hiring for. Have them write an abstraction layer for two different implementations of [insert relevant problem here] or refactor messy duplicated code into reusable [methods/components/modules]... Better yet, find an actual problem that your engineers actually had to solve in the past and see how they do it.
  • manuelabeledo 4y ago
    > filter out not dumb, low IQ people who are going to panic when you give a vague, open ended problem The article addresses this as well. Stage fright does not make someone “dumb”. Slow thinkers aren’t “low IQ”. And reversing a tree likely doesn’t make someone apt for a job.
  • lentil_soup 4y ago
    what part of leetcode gives you "vague, open ended problems"? It's a database of cookie cutter problems that have a one and only solution
• tick_tock_tick 4y ago
  I don't really understand the point almost all of the thing they list as downsides of using Leet Code are actually benefits. If someone can't manage to code some simple questions during an interview I can't imagine they'd ever make real contributions.
  • padjo 4y ago
    What if they suffer from social anxiety and they just struggle under the pressure of an interview? I’ve seen so many people over the years do terrible on these types of test that went on to be amazing contributors. We only found this out because we essentially ignored the outcome of these tests, which makes you wonder why you’re doing these tests at all!
  • bil7 4y ago
    if the "simple questions" are realistic problems they might face day to day, fair enough. But the classic example in these articles is an exercise like invert a binary tree, which most people never have nor will need to do, making it a poor test.
    • nicoburns 4y ago
      I think the worst part is that half the candidates will never have seen the problem before, and half of them will. Which makes it really hard to make fair comparisons.
    • charcircuit 4y ago
      >which most people never have nor will need to do That doesn't mean that someone would be unable to program it. Inverting a binary tree tests if you know how to traverse a tree. I may not traverse trees all day at work, but I can easily do a tree traversal if I needed to and I expect that to be true of most people who can actually program and not just talk the talk.
      • bil7 4y ago
        I understand what you mean, I could also probably pass the test. But what is the utility in an arcane test like this? If I'm hiring web developers, I'd want them to see how they apply their knowledge to a realistic scenario. There is a real chance that a potentially great hire with decent experience in a desirable technology will fail the inversion task.
• padjo 4y ago
  Just talk to the person, ask them about projects they’ve worked on, problems they’ve solved etc. you’ll learn far more about them that way than getting them to put on a dog and pony show at a whiteboard!
  • galoisgirl 4y ago
    Why not both?
    • padjo 4y ago
      Opportunity cost and candidate experience. I think an extra hour to talk will give me more information than watching them balance a binary tree. For many people the stress of the leetcode session is just awful, I don’t think it’s a nice thing to inflict on someone if you’re ultimately going to disregard the outcome anyway!
  • goodpoint 4y ago
    There are candidates that can talk circles around many questions and yet can't really write code.
  • AlexTWithBeard 4y ago
    Talk to the person and you will (1) hear a lot of bullshit and (2) filter out a ton of good but not really silver-tongued candidates. P. S. I hate coding interviews.
    • sdevonoes 4y ago
      If you hear bullshit, then that's easy: you filter out such people. Not really silver-tongued candidates? Well, what's the problem? Unless you are looking explicitly for silver-tongued candidates, you should ignore this "trait".
    • padjo 4y ago
      Right and it becomes your job to spot bullshit and bring people out of their shell. It’s not easy to do that, but who said hiring was easy!
• nivenkos 4y ago
  It's much better than the alternative and ideally only one part of the interview process. Ultimately the proof is in the pudding, I've had loads of candidates that could barely code and Leetcode-style problems are a great filter against that. Otherwise you risk just getting PM-style bullshitters as engineers, who talk persuasively about projects that other people actually implemented.
  • seer 4y ago
    People who can do leetcode challenges are only roughly correlated with great engineers. The more I learn about software development the more I try to _not_ have leet code style parts in my code - in the very rare circumstances would I see something like that and say - yes there is _no_ other library out there that has a battle tested algo to solve this particular problem, _and I have to code my own_. Worse people who excel at Leet Code could start to bring that sort of thing into your codebases, optimising small parts of your code to perfection, and then leaving the whole thing a mess or just plain reject to work on solving business issues and concentrate on polishing their small bit of algorithm. Of corse there are positions where that sort of mindset is welcome and sought after. Especially in very big companies, but for the most developers out there leet code is _just_ for the interview part and they would (should) never use that kind of problem solving in their day-to-day work. When I have to interview somebody, and there's leet code involved: a) they are _really_ comfortable with those types of challenges - that tells me they have spent a lot of time preparing - either for this interview or just generally, either way that wouldn't _really_ tell me much about their problem solving skills b) they feel uncomfortable and fail to solve anything due to stress or anxiety - again no really knowledge gained, as real-world work environments tend to try to minimise those, at least in the places where I work in. c) they feel uncomfortable but get the hang of it - now I _might_ have a glimpse of their problem solving skills, but I've put a human being in a very uncomfortable position just to _test_ them. There _has_ to be a better way. The way I like to conduct interviews where possible is to ask people to walk you through some of the code they've written and ask various questions about decisions - much more relaxed and I still get the sense of how they organise their stuff and how they work. If that's not possible - a take home task or something. Or even "hire fast fire fast" approach works too.
• meowtimemania 4y ago
  I think for large companies where they want to reduce the number of false positives, leetcode style questions work well.
  • lordnacho 4y ago
    Has this ever been tested properly? Has anyone ever given a failed candidate the job and monitored how they did compared to candidates who passed the LC?
  • davedx 4y ago
    That's an opinion with no data backing it up. I guess you didn't read the article either before commenting?
  • padjo 4y ago
    Yup! And they work well as a filter for candidates too. If a company leans heavily on these then you know it’s probably a dehumanising corporate hellscape.
    • teh_klev 4y ago
      > And they work well as a filter for candidates too I agree. A couple of years ago I was asked by two companies to solve leet code problems even before there was a screener meet-and-greet interview. They were quickly crossed off my list.
  • jeanloolz 4y ago
    Was contacted by Facebook recently for a data engineering position and was told I had to grind some leetcode to prepare for the interview process. I just could not be bothered and I can not be the only one who made that decision. My guess is that companies relying on leetcode style interview are also missing on some very capable engineers who just don't want to grind leetcode outside working hours.
    • islon 4y ago
      But that's not a problem. These companies pay so much that they have too many candidates applying all the time, so missing good engineers is not a problem, but filtering out false positives is. Though, I don't agree leetcode is a good interview practice.
• jamesdhutton 4y ago
  In a previous job of mine, we would show candidates a printout of some buggy code, and ask them to find the bugs. We would leave the room and let the candidate work through it on their own. The code in question was basic algorithms and data structure stuff in C++, such as inserting into a doubly-linked list. I always thought it was a good exercise. Suits slow-thinkers and nervous people, and it's a good test of coding ability since if you can spot a bug then you can clearly read and understand the code.
  • deleted 4y ago
    [deleted]
  • Sakos 4y ago
    Man, I would rock that so hard and I wish more companies would do this. My current job did a live coding exercise in the interview, which went okay. The interviewer gave me a chance to iterate on the code and improve it after our call and send it by email an hour later. My solution by then was far better than what I'd had at the end of the interview, once I had a chance to gather my thoughts in peace and think everything through thoroughly.
    • stevekemp 4y ago
      I've had a couple of sysadmin-interviews which were pretty interactive. You're presented with a laptop connected to a remote VM, and told "Fix MySQL", or "Rewrite the git history in this repository". Usually these are simple problems, which have obvious solutions. Every now and again you might get a surprise like an immutable-bit set on a file, or SELinux blocking access to specific files/paths, but the good thing about these kind of "challenges" is that you'll usually also have full google access. I guess l33tcoding isn't really a thing for sysadmins, but I do appreciate a (fair) simple test like that, especially being given the opportunity to talk through the process.
  • unwind 4y ago
    So you basically implemented an analog version of Stack Overflow? :) That sounds really nice, once you get over the idea that people will show deliberately broken code (most folks on SO just don't know better, or at least that's my hope). Thanks for sharing!
• oxff 4y ago
  A task you solve with someone (as part of your team if you get hired) > take home task > leetcode interview in my opinion
  • sdevonoes 4y ago
    Only the first one you mention (a task to be solved in real time with both the interviewer and the candidate on the same video call) is the only one that respects the candidate's time. The other ones do not. A take home assignment could mean hours or days of effort for the candidate, while it may take at most 1h or so for the interviewer to review it. Totally asymmetric.
    • davedx 4y ago
      I've done take home tasks before. One of them I had to do landed me a job at a really great company that I'm happy I didn't miss. I agree it's maybe a little less respectful of a candidate's time, but as long as it's not too big a task I don't think it's unreasonable either.
      • sdevonoes 4y ago
        I think it depends on the perspective (and the state of the market): two scenarios a) "candidates are willing to work for companies, therefore companies have a bit more of control over the whole interview process", and b) "companies are looking for (scarce) good talent out there, therefore candidates have a bit more of control over the whole interview process". When I was a junior developer I used to deal with a). Now that I have more years of experience I usually deal with b).
• cik 4y ago
  Instead, I offer to share a private GitHub repository, (if not some open source) with the prospective employer. It offers them the ability to see how my code changed over time, how it ended up, and the quality and calibre I may or may not devote to projects. It invites a conversation, in depth, about software construction, quality, and decision making from the point of view of real work. It also tells me if a company wants to simply filter. If the organization is unwilling to invest in a candidate interview, as I do to be interviewed - I in turn learn a lot, and decline to pursue accordingly.
  • ChrisMarshallNY 4y ago
    My experience is that employers refuse to do this (I have dozens of repos, with tens of thousands of lines of code, entire shipping applications, a decade of checkin history, dozens of Web articles, and hundreds of pages of documentation and project planning artifacts). I even had one indicate that “I probably faked it.” It was jaw-dropping. In fact, I have so much stuff out there, in the public realm (I’ve been doing open-source software for decades), that employers could easily evaluate me technically, without ever contacting me, and all they’d need to find out, is whether or not I’d be a decent team fit. I suspect that the main reason they ignore my portfolio, is that they have already decided that they aren’t going to hire me, and don’t want to waste their time, reviewing my work.
  • manuelabeledo 4y ago
    This is what I do as well. It also helps me filter out companies that are either too lazy, or too strict in their procedures, or both, i.e. there is no value in asking the same questions, regardless of candidate’s resume. As an example, a month or so ago I went through a couple rounds of interviews with this company. I told them forthright that I wasn’t doing any code assessments, and if they wanted to, they could take a look at my GitHub account. They seem willing to consider. Third round comes in and they ask me to write some sorting algorithm, to which I refuse. Ironically enough, one of my repos does have an implementation of an advanced data structure, so they could as well just take a look at it.
• rglullis 4y ago
  Benefit #175 of having some kind of open source project in your company: you can open all types of different issues and user stories, and use them to discuss with candidates. You can even attach bounties to them so that candidates don't feel like they are doing free work, and it would still be cheaper than paying a recruiter that will likely just source candidates by spamming different sites.
  • ttyprintk 4y ago
    I love this. Picking an issue from some well-organized dependency has worked for me (I wonder how I’d present this to AI/ML positions). I hadn’t thought of the positive signal of issuing a bounty.
• wtk 4y ago
  I recently failed interviews at Google and Amazon, exactly at this sort of algorithmic problems. And that's quite far from my client application daily job. I knew it's not my strong side, I would have applied before they approached me otherwise. Now I can tell everyone - I knew quicker than Google, that I'm not the right fit ;)
  • jason2323 4y ago
    I have mine at the Brazilian river company tomorrow! I look forward to coming out of that experience with lower self confidence
    • wtk 4y ago
      Haha, good luck! Some people say working for the big ones is a golden cage. Maybe I'm made for living in the wild ;)
• deadcore 4y ago
  Don't get me wrong I hate LeetCode-style interviews as much as the next guy. In fact I really, really, really suck at them! Not sure if that says more about my ability then anything but c'est la vie In the defence of LeetCode-style questions, I do think they work, and very well may I add - with the caveat you have the throughput of candidate to make it work well? Their ability to filter out 'those who can't code' in an efficient manor while sacrificing a small amount where it filters out 'those who can code' greatly out weighs the alternatives. The alternatives needing to fit into a 1 hour timebox, be objective while also favouring the positive cases (I think I got that the right way round). My two cents would be more around the way in which they are conducted; in my experience I've found conflict with the interviewer more then the process itself - with interviewers in my past lacking.... empathy (may not be the right word) for the person on the other end of the screen/table feeling flustered, nervous or down right stupid that they're struggling to solve a simple fizz-buzz/reverse string problem, leads to a snowball effect and pilling onto that can effect the candidate in quite a spectacular way. Best interviewer I've had asked if I was alright and got me a glass of water, props to that guy! I dunno - I've just come to terms with having to learn how to play the game, even if I find that part of the game really hard and to some parts unfair. Such is life
  • andrewingram 4y ago
    There's an assumption you're making that these challenges only filter out a small amount of qualified candidates. I suspect the percentage is actually quite significant. In my experience it's usually bigger "looks good on a resume" companies that do these challenges, which suggests they're getting enough candidates in the funnel to be able to afford turning away a lot of more-than-qualified applicants. I've failed more than my fair share of these challenges, but never (being subjective here) because I wasn't actually capable of (1) solving the problem or (2) doing the job. My take here is that I _may_ have been unqualified for these roles, but that the interview failed to actually uncover it, due to spending all the available time on low signal exercises.
    • quickthrower2 4y ago
      Big companies also have the headache of standardizing across thousands of interviews. That said you can do that more with practical exercises (build this thing…) than leetcode
• snickerer 4y ago
  I interviewed hundreds of C++ developers as a freelance assessment interviewer. The most candidates I interviewed wanted to work in the automotive industry in Europe. Many candidates (like: maybe the half) are fancy talkers without any skill in writing code. I really don't know why they are applying for dev jobs. It is easy to filter out these persons with a very simple coding test. I agree with the article that 'leetcode' tests (find that complicated algorithm in 30 minutes while I am staring at you) are bad. But I think coding tests are good! Give the candidate just a really simple coding task with stuff they normally do every day. Create and delete object, fill arrays, iterate over arrays, and so on. 50% of the candidates will fail! The rest are OK engineers.
  • gspr 4y ago
    Exactly. Give a simple coding task that the candidate does on their own time (but not one that's too complicated, it's rude to waste the time of people who aren't even working for you), and then, crucially, have them briefly explain their solution during the interview. The task can be so easy that reasonable solutions are just 10-50 lines of code – my experience has been that people's explanation of their own work very clearly tells you whether or not they're a decent coder.
    • quickthrower2 4y ago
      What if that test was done once by an external company, and then the stamp of approval is good for a year of job interviews. That would save the candidate and interviewer a lot of hassle!
      • koonsolo 4y ago
        I agree. You would expect that from a bachelor or master degree. But nowadays you have a lot of people coming out of coding bootcamps, and their level can vary a lot. A hole in the market!
        • quickthrower2 4y ago
• Dowwie 4y ago
  Someone who builds a truly novel technology solution involving hundreds of hours of effort gets filtered out of an interview involving contrived scenarios. You may have built the next generation X, but given an array of strings and a fixed width, can you format the text such that each line has exactly maxWidth characters and is fully justified -- in the next 30 minutes? Maybe you should have cultivated that skillset instead, because around here we value parlor tricks more than real world accomplishments.
  • throwaway2037 4y ago
    No joke: Isn't this the famous Donald Knuth text layout algorithm? I heard it is still used today -- it is that good.
    • WorldMaker 4y ago
      I've done that in interviews: "oh hey, the most efficient known algorithm is this classic named X". That tends not to win interviews either, but in the real world knowing the name of the best algorithm (or even just that a best algorithm exists and a general idea of what you'd google to find it) is more useful than knowing the details of it. If I need to reimplement a well known algorithm I can often reimplement it from the Wikipedia description, that's trivial and boring make-work (and will always be trivial and boring make-work). But I need to know which well known algorithm sometimes and that's a far more useful practical skill.
  • hiq 4y ago
    > Someone who builds a truly novel technology solution involving hundreds of hours of effort This person should already have enough of a reputation to get a job at many companies, if their work is public enough. What do you suggest for the 99%+ other candidates?
    • sai_c 4y ago
      > This person should already have enough of a reputation to get a job at many companies, if their work is public enough. But then why do people with that kind of reputation still (at certain companies) have to jump through these hoops? https://www.theregister.com/2010/04/21/ken_thompson_take_our_test/ https://www.theregister.com/2010/04/21/ken_thompson_take_our... > What do you suggest for the 99%+ other candidates? What about (instead of forcing a months long decision process upon the candidates and the company) bringing them into the company after a short interview (maybe 2hrs), and making sure they can afford housing, food and everything else they need. If you like their work, they stay employed. If, say after one month, you do not like what you see, you can easily let them go. Of course you tell them upfront what the deal is. We could call it, I don't know, maybe trial or probationary period.
• shadeslayer_ 4y ago
  I can relate so hard with the part which says it does not favour slow thinkers. I've faced this countless times - person at work asks me something, I reply "I'll think about it and get back to you", which inevitably leads to their disappointment. I am okay with disappointing people, but it can be unnerving when that disappointment means I miss out on a good opportunity.
• Cwizard 4y ago
  Having taken some interviews myself I can see some value in having the interviewee do some small coding exercise when they do not have any personal projects to show. I think it can filter out some false positives of candidates that can talk well but can’t actually write code (you’d be surprised how many candidates can’t) What surprises me most is the lack of flexibility in the process. If a candidate shows up with a broad portfolio I’d rather talk about that then doing some random coding problem. Yet our HR manager insists on the fixed program. This is worse when the candidate is interviewing for a senior role where I don’t really care. Then I am mostly interested in their past experiences and knowledge on how to build things that don’t fall apart after six months. Again it is definitely process over people here… not sure if it is better in other places. I would also say that these exercises are most effective when they are quite simple. They let you test ‘can this person write a function’. The complicated ones often filter more for people who have studied those type of problems. Harder problems != better coder. At least not for the projects I work on which are more integrating existing services than investing new novel highly efficient code.
  • lostcolony 4y ago
    Yeah; that's what I've preferred to do. Interestingly, I've had just as good results with the hires I've made regardless of the process used, from whiteboard coding that is little more than fizzbuzz, to actual pairing with an engineer on a real problem, to leetcode, across multiple different companies. Maybe the softer parts of the the interview, which was largely the same (and prioritized people who could talk intelligently about stuff on their resume, those who when led to places they had no experience were comfortable saying "I don't know" or similar, and those who seemed interested in learning new things), was better for distinguishing mediocre from excellent (with the coding being helpful for distinguishing imposters from everyone else).
• samrocksc 4y ago
  In my experience most companies using leetcode thinks their shit don't stink. So i'll leave this where it is.
• Keats 4y ago
  The best interview we've used was sharing a simple but very not idiomatic Python file with working (but slow) code and tests at the bottom. The task was to refactor and speed it up. This allows seeing the actual thought process and some basic skills, while at the same time being something any good dev could do in 20min without much pressure.
  • ttyprintk 4y ago
    I tend toward this, especially with some canned performance report. Sometimes I take something relevant from their GitHub and introduce a glaring bug, like an impossible dependency or infinite loop.
• shantnutiwari 4y ago
  We keep seeing posts like these on HN/Reddit, yet companies keep using them. And companies like Faang (or is it Manga now??), whose engineers I would think would hang out on HN So it either means: 1. HN's influence is even less than we thought-- even MANGA engineers /10x silicon valley types dont hang out here 2. Everyone agrees its a good idea, but no one cares. Like everyone agrees we should care about the environment etc
  • quickthrower2 4y ago
    MANGA engineers cant change shit. They are drones (not a criticism, I am saying like worker bees in a big colony). Startup Engineers can (but just for their startup) Also if you have been hazed you wont vote to stop the hazing
  • wiseowise 4y ago
    > We keep seeing posts like these on HN/Reddit, yet companies keep using them. Just because you see them, doesn’t mean they’re correct. They’re just a breeding ground for holy wars and discussions. On every post like that you can find tons of “I don’t like them, we need something better and no I don’t know what”. But if you dig into comments you usually find why those type of interviews are done.
  • ditonal 4y ago
    You are learning that perceived consensus on an upvote/downvote site doesn’t mean much because if 60% of people agree with something because of upvotes it seems like 99% do. Reddit rediscovers this every election. People often downvote thoughtful discussions they disagree with. It’s tiresome to see your text fade with downvotes so often people don’t bother. If you hang out on Hacker News you might also think every engineer thinks crypto is a scam and no engineers want to return to the office. Neither situation is the case but if you disagree with the majority on those topics you will get downvoted to oblivion, your comments won’t be visible after a point, so why bother? I personally don’t care about the endless leetcode debate but it’s a bummer there’s so much exciting technological advances in crypto that can’t be discussed on this site without an army of “crypto=scam” bros emerging from the woodworks.
• Distozion 4y ago
  People who call for Leet Code either never tried to hire actually high skill developers or fools themselves into thinking that they're the cool kid in town. You might think it's better than any other alternative. I agree - it's been an amazing filter to filter out companies who are on average, quite crap to work for. From my personal experience, they are overburdened with process to a degree that even if they hired the best devs out there, they wouldn't be able to deliver anything because of all the red tape. The best jobs I had to date, I met the person leading the company/project/team, we had a chat, talked what tech we like, dislike, how we'd structure a product, what are the preferences to the process around everything. And that's the key thing - it was always a discussion, no Q&A. The key is that the candidate is not the only one who needs to know his stuff - so does the lead. As a side effect, all of those jobs were way above the market. Again, personal experience, but higher up you go - less BS like "we need leetcode to hire" you get. Unless you're Facebook and you have a genuine problem of too many qualified engineers constantly applying, you should aim to only disqualify truly hopeless cases. The company can't hide behind process and expect great hires. Early in my career, in a small city I was working in (in return, in the dev community you know about what other devs are doing), our company denied so many devs that within a year or two were among the top performers, just because of the leaderships insistence of a take home tests, Q&A interviews and gotcha style questions... So please - do continue using leetcode, it makes filtering your company out so much easier and I don't need to go through bullshit stages to know that the leadership has no balls to make the hard calls when it comes to hiring & firing.
• twawaaay 4y ago
  As an interviewer I can tell you are absolutely missing the point. Why would I ever want to hire a developer without seeing them perform? And since being able to program a small piece of code to specification is such a basic, important part of development, why would it be bad for me to verify if you can do it? If your friends are so good developers, why would they have a problem reasoning around a relatively simple, toy problem? Is it possible that your evaluation of your friends' prowess is biased? Why do you think dealing with problems under pressure is not a valuable skill? Why do you think leetcode questions are supposed to tell about quality of code that the candidate will produce? Is it possible that you just don't understand what leetcode is for? It all seems to me like students complaining that the exam was hard. IT DOES NOT MATTER if the exam was hard. What matters is if you were better than other students. (And even that does not matter, because in the long run it only matters if you have learned something useful.) So what is the point here? I think people just complain too much rather than focus on figuring out how to succeed. Leetcode questions are supposed to tell me: - Can the candidate understand the question? Can they think about the problem analytically? (Somehow there are a lot of people that can have nice conversation but they fail when they are supposed to apply hygiene to their thinking.) - Can they follow instruction? (I explain the rules of the task and am interested in seeing if the person is able to follow basic instruction) - Can they program? (I met a lot of people over the years who are able to fake their way through the process EXCEPT for when they have to actually write some code. For example they learned standard library by rote but do not have ability to use those functions when needed.) - Can they plan? Are they organised? (A lot of people just do stuff at random that might work for very small change but will utterly fail for any larger task. Good developer inevitably have some kind of plan and organisation.) - Can they work with somebody else on the problem? (Some people don't know how to work with others even when offered help.) - Do they understand what the program they wrote is doing? (MOST people do not know if their program works or not or what it does. They need to run the program to be able to tell. All best developers I ever worked with can tell what the program will do before they run it. Any person that can't do this is destined to be creating huge number of bugs as they mindlessly retry code until it works in the process leaving every bug that did not stop it from working in their test environment.) - Are they intelligent (enough)? (Leetcode is sort of intelligence test. You typically need to be at least at some intelligence level to solve the problem.) The problem with leetcode is all those interviewers that do not understand how to use it as a tool to learn things about the interviewee. And that frequently is because they want to get information that you can't easily from leetcode. So what you can't learn from leetcode question? - Will they write nice code? You can't learn this because writing nice code is ability to adhere to the body of code you are already working with. Everybody's programming style is different and even best style might still be incomprehensible to a person that is not used to it. - Knowledge. Do not ask stupid questions like how to transform a binary tree in a certain way because they only thing you are testing for is whether the candidate is lucky to know the answer to your problem. - Can they solve complex problems? Do not give complex problems on interview. It is just too noisy and luck-driven. Perfect question is just complex enough to be novel and present some (but not too much) challenge to the candidate but not complex enough to run the risk of running out of time for a reasonable candidate.
• throwaddzuzxd 4y ago
  In my team we do technical interviews in three steps: - an algorithmic challenge. It's related to what we do day to day. I work in domain names so we ask to parse a domain name. There are oddities with domain names so we check multiple things: does the candidate know what basic string manipulation functions exist? do they ask questions to get more info? how do they react when we give additional info that break the code they did so far? What we don't check: whether the code compiles or actually works. We don't care. We explicitly tell the candidate they can write pseudo code or comments defining the steps of the algorithm. We're interested in their reflection. - an architecture challenge. We ask the candidate how they would scale an API worldwide. There's no code, it's an open discussion. They can talk about whatever they want: asynchronous, statelessness, load balancing, replication, anycast, whatever. We can also guide the candidate to know whether they know some specifics concepts (for example I can ask "what would you do if you have a GET REST endpoint that returns the same thing every time" and expect "cache its result", even with this question I get different answers (which is great), some will talk about HTTP cache headers, others will talk about Redis or in memory caching, rarely do candidates talk about both) - a refactoring challenge. We work with tons of legacy code. So we show the candidate a crappy piece of code with performance issues and no tests and ask them for what their strategy would be. No writing code here, just thinking and discussion. So yeah, just a quick screening to check if the candidate can write basic code (you'd be surprised of the results), and open discussions on our day to day problems.
  • jimbob45 4y ago
    >you'd be surprised of the results I wouldn't because my company has been burned before by hiring people who would otherwise have been filtered by your test. I'd say your test is the kind of responsible, yet reasonable test I'd like to see every company adopt some form of.
  • Doolwind 4y ago
    I really like the refactoring challenge idea. Any tips on what’s worked or not? Do you do domain specific code or try and keep it generic? I think having them not write code is particularly good way to handle this.
• rockbruno 4y ago
  With how often this topic shows up I'm surprised HN hasn't banned it. There are lots of suggestions on how to better evaluate a candidate, but they are either not true or involve needing the person to dedicate an enormous amount of time for the interview, which most people would not agree it. Coding exercises are a "least-worst" scenario in terms of evaluation versus time-spent interviewing and companies know that.
• andrewingram 4y ago
  Last xmas I worked on a side project that ended up requiring a moderately substantial algorithm; much more involved than anything I've ever had to do in a LeetCode interview - there's absolutely no way i'd be able to produce it under those circumstances. Yet, the algorithm wasn't the hard part. The hard part was all the exploration I had to do around the problem to get to the point where I understood the constraints well enough to solve it. I had to rewrite my attempted solution a number of times as my understanding grew. In my opinion, this represents the real thing we should be trying to test - a candidate's ability to unearth the true definition of the problem. When it comes to writing real world algorithms, whether you can solve it in 30 minutes or 3 days is (mostly) irrelevant, because it makes up such a small part of the overall engineering time. You could squint and make a case that this is what LeetCode challenges are doing, but I'd only agree if we removed the requirement/pressure to have working code passing all the tests within the time allocation; and to be honest, most of them just hand you all the constraints on a platter.
  • samsquire 4y ago
    I'm curious - could you tell us what the algorithm was?
    • andrewingram 4y ago
      It was somewhere between a sudoku solver and wave function collapse. Had to work out what tiles to use to accurately reproduce the slopes for rendering a Mario Maker 2 level. Most of the level tiles are just X/Y/TileID, but for slopes all you know is the start/end nodes. So you have to look at all the adjacent tiles to work out the correct TileID to use for each X/Y paid within the bounding box of the slope. But there's also ambiguity where there are multiple possible tiles with the same edge properties, so I had to work out the right priority/weighting to favour certain tiles over others. I had to derive and then write out all the edges rules by hand, which was many hundreds of lines.
• H4sh3 4y ago
  If you get a never before seen problem to solve, going trough the taught process and communicating the steps of solving it might display the skill of problem solving. Which should be what interviewers are looking for. The solution will probably not be the most efficient one, but can be refined later.
• natly 4y ago
  To be honest if I was an employer I probably would do leet code or similar. The logic would be that yes, many engineers are shy or nervous around people. But losing those is worth it since hiring someone bad that you have to fire (that wastes some months of productive time at the company) and then re-hire someone else is definitely worth that risk. Having made something impressive on github is somewhat fakeable since you can get a lot of help from the internet or even copy large chunks (that you may understand but didn't have to invent) from stack overflow. Someone who can do leet code at least have some hard-to-fake ability to reason and work under pressure. That said, I still don't like doing leet code interviews and I'm pretty bad at them, but that's the logic that imagine goes on in an employers mind (hence why "they're missing out on some types of candidates" logic likely won't sway anyone reading these comments I suspect).
  • shrimpx 4y ago
    > get a lot of help from the internet But this exactly what they’ll do on the job. Actually, searching for help and distilling what you’ve found into a clean solution is a skill in itself.
    • natly 4y ago
      Yeah but it's somewhat hard to determine how difficult a challenge it actually was to produce that piece of code from the outside. It may be a signal of competence, or it may be one of those things that seems really impressive but they actually just followed a youtube tutorial that explained most of it step by step. (Which is a fine solution if you found that for a particular problem you had to solve, but it's not a reliable signal they'll be able to solve arbitrary things in the future - not everything has been explained by someone else, especially when trying to tackle very novel problems.) The point is that code challenges are a pretty hard to fake test and the loss of some types of people is worth it for the employer (like me, who sucks at them).
• rideg 4y ago
  I think the LC interview measures how determined your are. Are you willing to spend hours and hours to solve boring/meaningless coding exercises in order to pass the interview or not? Because even if you are smart and a good coder if you haven’t seen the problem before it is extremely unlikely to give optimal solution to 2 LC medium or 1 hard problem within 45 minutes. Your only option is to practice. So if you willing to spend your free time mindlessly practicing, you will be a good ant at the company. Which is very desired since most of business programming is boring and repetitive and does not require creativity. Also, validating the solution is simple. Does not need too much effort and creativity from the person conducting the interview.
• przemelek 4y ago
  I'm not sure. Yep, I tanked several interviews because even when I got info at the beginning that "we will look for your way of thinking and this how you handle problems" finally I heard "Yeah, it was OK, but there exist better algo to do it". But still for sure those interview questions are close to checking raw IQ/algos, and if somebody shines in those probably will be OK employee. And now it is question of candidates pool size, if you are one of wanted employers like Google, Amazon you may use this filter, you will loose a lot of good candidates who aren't good in algos, but those who will pass your interviews are still good, and you have good amount of those. Smaller, less sexy companies may have problem finding people with this approach, but bigger and better know probably don't have problems here.
• jmyeet 4y ago
  This is a tired topic at this point. The mistakes people make are: 1. An interview proces exists to fill a position. It doesn't exist to fairly assess an individual candidate. Candidates would like that. That's not the point. If there are 10 candidates and the employer fills the role successfully, they've achieved their goal even if someone great was filtered out; 2. FizzBuzz came about because many people talked a great game but couldn't code a flor loop. Giving a simple coding problem is an excellent negative filter. Doing great at the problem means nothing; and 3. Interviewers make the mistake of thinking FizzBuzz is too easy so they give harder problems. This is a mistake that defeats the entire purpose of the filter. Stop doing this. These points remain constant in every such engineering hiring or interviewing thread.
  • andrewingram 4y ago
    And even FizzBuzz could end up challenging if you happen to have no familiarity with the modulus operator -- which isn't that implausible for junior programmers.
  • adregan 4y ago
    A simple problem with constraints can be really fun. For example, implement FizzBuzz without using any looping constructs.
    • foobiekr 4y ago
      The variant of fizzbuzz that I use is "read and categorize a line at a time from stdin." You'd be amazed how this one small change makes the discussion quite different.
      • adregan 4y ago
        In your variant do the integers increase in order? Also is the input always integers or is there some “junk” mixed in?
        • foobiekr 4y ago
• newshorts 4y ago
  I once failed a leet code graph problem because I solved it with a genetic algorithm. The problem wasn’t that I was incapable of solving the problem, it was the narrow view of possible solutions. The interviewer was looking for the CS101 solution. My biggest gripe with leetcode is they tend to filter diversity of thought.
  • dekhn 4y ago
    Yes, this is one of my big complaints- I've presented solutions as efficient as the interviewer's, but got dinged because it wasn't the one they were looking for.
  • zshrdlu 4y ago
    Have you written about the problem and how you thought about it? Sounds fascinating - like something I'd like to read :D
• hk1337 4y ago
  Whether someone gets a correct answer with a code challenge should only be a single factor in hiring. You should also look at how the attempt to solve the problem. Do they ask further questions? Do they talk it out? There’s probably other factors I cannot think of too.
• _448 4y ago
  In addition to these cookie-cutter style questions, I am also against asking questions related to some obscure language feature.
• dzyanis 4y ago
  Let's separate an idea from implementation. It really depends from how to conduct such interviews. A good example is Google and Bolt. Both use it but differently. And for me personally in both companies it showed clearly all my shortcomings. Even when I known how to solve the task in the best way and wrote code on a board which you can compile. And to be honest I have the same shortcomings when I solve problems bigger or harder. You know, unlike many others this experience was clear and useful for me. It needs practice but I like it.
• skeeter2020 4y ago
  Not arguing that LC problems are a poor, degrading way to filter but every single post HN about how "interviewing is broken" assumes the process is targeted at the applicant's experience. I don't hear HR departments making this complaint.
  • charles_f 4y ago
    I'm making the complaint as a hiring manager that this gives bad results.
• revskill 4y ago
  My favorite style of interviewing is through reviewing existing codebase, then ask question on it. Then i'll ask candidates how to improve their codebase (or someone else code). If possible, i'll let them code some small functions and ask them how they gonna do the unit test. To me, refactoring skills is a must, as most of engineering work is on refactoring.
• brhsagain 4y ago
  All of these supposed "flaws" of leetcode are by design. Big companies want people who are smart enough to do the work, but obedient enough to put up with all the bullshit that comes with working at a big company. What person better matches that than someone who's able and willing to study for and pass a tech version of the SAT? Every anti-leetcode article I read is some version of "leetcode is bad because it measures the wrong things." No, we all know it measures those things, and those are exactly the things the measurers want to measure. You might ask, so why do startups do leetcode too? I heard startups are supposed to be, uh, innovating, developing new technology, and working on hard, meaningful problems? Shouldn't they want brilliant, super effective people, instead of smart-enough, obedient workers? Apparently not. Apparently they want the same workers bigcos want. The implication of this is left as an exercise to the reader.
  • phailhaus 4y ago
    This is ridiculous. You yourself admitted that conspiracy theory doesn't explain startups. The answer is simple: leetcode interviews are stupid easy to give. There is no "nefarious conspiracy to keep workers obedient." It is simply the path of least effort.
    • abirch 4y ago
      You could use the ancient Microsoft logic questions. They are equivalent as easy. Leetcode is sticky for a reason even if it's not the intended reason.
    • ironman1478 4y ago
      I think leetcode style interviews being easy for the interviewer / company is the most rational explanation for why its so pervasive. Its easy for the company as an automated screener and an on-site because there is a clear pass / fail rubric that can filter people. If you have a bunch of people doing interviews that don't want to do it (Google and FB interviewers cough cough), then this style of interview is perfect for the interviewer to conduct if they just want to get it over with. I've noticed that Apple only uses simple leetcode-y style questions for its phone screens, but for their on-sites they ask very domain specific questions. It is interesting because if you're actually good at the domain you're interviewing for, they are very easy. If you're not they can be intractable. Its clear that each team puts a lot of thought into the interview process and I imagine Apple teams get a very high SNR, at least compared to Google / FB.
• mullikine 4y ago
  Pretty frustrating when 2 years ago you're solving leetcode problems with GPT-3, and can demonstrate it inside a facebook interview but the interview process doesn't factor in the 10x programmer, and doesn't recognise any TRULY out of the box thinking. Leetcode was dead when GPT-3 came out
• kanonieer 4y ago
  Considering the normalization of spending hundreds of hours grinding LC questions and the industry built around whiteboard interview preparation, my (n=1) conclusion is that LC interviews is not about technical assessment at all. It's an assessment that's designed to find people who are ready to submit to an endless grind with little to no skepticism. Developers who question the technical usefulness of LC interviews are simply not the target audience anymore. The target audience seems to be potential employees that are hungry and without leverage.
  • PragmaticPulp 4y ago
    > Considering the normalization of spending hundreds of hours grinding LC questions and the industry built around whiteboard interview preparation, my (n=1) conclusion is that LC interviews is not about technical assessment at all. The “hundreds of hours” grinding LC is largely for juniors without experience. I don’t know any senior engineers who had to grind LeetCode like that for their FAANG interviews.
    • anonymoushn 4y ago
      People frequently post here saying that they are senior and needed to do that or would need to do that.
      • adamors 4y ago
        Yeah, there are multiple blog posts from senior engineers who took 1-2 months off to grind LC just to get into Google/Meta etc.
        • PragmaticPulp 4y ago
          > there are multiple blog posts from senior engineers who took 1-2 months off to grind LC just to get into Google/Meta etc. Don’t read too much into blog posts. This is engagement farming to capture search traffic and trending topics related to LeetCode. Taking months off to grind LeetCode all day isn’t common and doesn’t even make sense. LeetCode can be done on a lunch break. Even one problem per day in the evenings is more than enough for a senior to prep for an interview. Having done LeetCode, I’m not even sure how a senior could justify spending 2 months doing all of the problems full-time.
• firstSpeaker 4y ago
  Do people actually pay for leetcode premium? If so, that whole business is byproduct of the interview industry to defeat it which is fun.
  • thenoblesunfish 4y ago
    I did - I paid less than I would for a video game, and had as much fun :D
    • firstSpeaker 4y ago
      Was it actually useful to improve your skills and you ending up with good solution in the coding round? And how many hours of practice does it usually take to get ok with these type of problems/solutions? :D
      • weezin 4y ago
        It definitely helps to look at solutions explained in detail, and probably has the best rate of return when tech company offers can differ in several hundred thousand dollars per year. As far as hours of practice it really depends on if you grasp the concepts of types of questions. I got hired at a faang with 2 hard, 13 medium, and 20 easy questions done, but I'm for sure an outlier. I also did these courses: https://www.udemy.com/course/js-algorithms-and-data-structures-masterclass/ https://www.udemy.com/course/js-algorithms-and-data-structur... https://www.udemy.com/course/coding-interview-bootcamp-algorithms-and-data-structure/learn/lecture/8546998?start=0#overview https://www.udemy.com/course/coding-interview-bootcamp-algor...
      • thenoblesunfish 4y ago
        Definitely leetcode helped with that. Not sure if I could directly attribute that to the extras I got from paying. I paid for access to more problems and less waiting to submit solutions, mostly. The solutions to the problems can essentially always be found in the comments.
• thenoblesunfish 4y ago
  I think that a blanket rejection of the "Leetcode" style interview is too broad. They are a tool, and like any tool, one should try and understand when they are appropriate for the job. If the "the job" is to try and provide a fairly level playing field on which to assess candidates on raw problem-solving ability and programming intuition, these are useful tools. There are the same problems as with any test of this kind (you can improve your results by learning the format of the test well), but there's still a lot of signal. If you're trying to hire based on the things these tests measure, you should you use them. As the post points out, correctly, those are far from the only qualities required for many jobs, and anecdotally it seems like some companies are overusing this one type of interview, but the solution is for interviewers to assess what they are trying to select for, and make sure that their selection process measures it as well as possible. Part of that process may well still be puzzle-style interviews.
  • charles_f 4y ago
    That's here at the top of the post > I don’t think it’s an all or nothing situation. You should use questions that provide data per whether the candidate will perform in the job they’re interviewing for. If that job is extremely algorithmic driven, e.g. in academia, or involves OS-level optimization, sure, maybe leetcode exercises are relevant
    • thenoblesunfish 4y ago
      I didn’t think that part went far enough. Companies could reasonably want to hire people who can do well on programming puzzles, even outside of those narrow cases.
• is0tope 4y ago
  I used to work in a bank and wrote an interview script for my department (kdb+/q market data). It mainly consisted of having the candidate sit in front of an interpreter, and walk them through a script which looked something like: 1. Load a data file here 2. Tell me some facts about the data 3. Here's another dataset, can we use both to figure something out. 4. One of the executions for this order is missing, how can we find which one. 5. Here is a data feed, can you write a process to ingest the data and calculate something in real time. I by far preferred this system to the alternative which was to ask trivia questions and see if the candidate memorised the docs. There is of course some value in asking basics, or to elaborate etc. But on the spot algo questions are usually only useful in filtering people who either like leetcode problems, or have grinded them for the last 6 months.
• jmartin2683 4y ago
  Pointless. All they do is confirm that you can remember algorithms you’ll never use in real life. I won’t work with anyone who uses them… I’d hate to work with a group of people who got their jobs solving riddles rather than building software.
• jmartin2683 4y ago
  They need us more than we need them. Don’t work for people who ask you to do party tricks for the privilege.
• gtsnexp 4y ago
  Is this a symptom that algorithmic/competitive coding will be considered the IQ test of future?
  • ttyprintk 4y ago
    My read was that it’ll function more like the LSAT.
• sva_ 4y ago
  Maybe doing leetcode style interviews is just a bias that gets you more young applicants (recent graduates).
• hexa00 4y ago
  This is crazy and needs to stop indeed it's like you have: - A degree (In which you've proven you can understand these algos and spent 4 years studying) I'm not going to redo all that in 1 week before your stupid puzzle! - Experience (That has to be worth something it's not like everyone is lying about it) - You may have open source contributions But no, some companies will not even start to look at that or not look at all, before they ask you this stupid puzzle. Personally I now filter those companies out, I mean 20 years of experience, contributions in major open source projects, if you can't recognize that? why would I interview? Were I work now we give code assignments, while they take longer to do you can actually see structure which I agree with the author is the top quality I'm looking for. They are also less stressful for the candidate.
  • _gabe_ 4y ago
    > A degree (In which you've proven you can understand these algos and spent 4 years studying) Unfortunately this means next to nothing anymore. I have a bachelor's degree in CS and Math, and I found it very useful. However, I host a fairly large community and provide tutorials on coding projects. I've had several people working on a masters thesis in CS reach out to me because they're following one of my tutorials for the thesis. They then ask a very basic question that indicates they don't know how a package manager works, or how to look up documentation on a library. I think these two tasks are some of the most basic programming tasks available, and if you can make it through 5-6 years of college in CS and still not have the most basic understanding of this, then a degree means absolutely nothing anymore. Some more anecdata, I've had several friends who graduated with me and can hardly code. It's unfortunate, but I think degrees are just an expensive piece of useless paper that tells you absolutely nothing about the individuals abilities.
• dadoge 4y ago
  Stop telling everyone to stop interviewing with Leet Code
  • charles_f 4y ago
    Stop leet coding everyone to interview telling
• bogwog 4y ago
  > you can pick a ticket and pair program. Have them review an actual PR. Etc. This seems so obvious. If you pick a leetcode question, there’s always the risk that your candidate has memorized the answer to that particular question. But if you pick an actual bug/PR from your codebase, that problem disappears completely, and you get to see how they would perform on the actual job you’re hiring for. Can anybody think of any negatives here? The only thing that comes to mind is that it might be seen as the employer trying to get free labor if they use a bug report that hasn’t been resolved yet.
  • bmelton 4y ago
    The easy way to get around exploiting free labor is to pay for the labor. Give the project a cost and time budget (e.g., "You've got six hours to try to resolve this issue that our [already trained and familiar with the codebase] engineers think will take ~2 hours to resolve, and we'll pay $100 an hour for the effort whether or not you succeed")
  • sumeno 4y ago
    I've never worked somewhere with a codebase simple enough for a new engineer to find and fix a non-trivial bug on their first day. Especially not with someone looking over their shoulder deciding whether to hire them.
    • bogwog 4y ago
      There are always bugs that don't require extensive familiarity with a codebase. Even if it's easier than most day-to-day work, it still shows the candidate's approach to problem solving, how effective they are at reading code, allows them to show off some relevant domain knowledge, etc. And as a bonus, it easily works to weed out those people who don't actually know how to code. > Especially not with someone looking over their shoulder deciding whether to hire them. That would help in this case, since presumably the person looking over their shoulder is familiar with the codebase (or at least as much is relevant to the question), and can answer questions. I think the signal-to-noise ratio on an exercise like that is going to be way better than with leetcode questions.
    • 4y ago
• benreesman 4y ago
  If people who had to study for the LSAT, or MCAT, or countless other high-intensity selection processes realized that we sat around bitching about LeetCode interviews as the only obstacle to making more annually than some of them ever do, oy vey…
  • jason2323 4y ago
    In the cases you mention, there is usually years of study (much longer than a CS degree) coupled with the fact that those exams you mention are meant to qualify a person to help save another persons life or their rights under law, not to optimize ad-reach by an additional tenth of a percent
    • lmz 4y ago
      But that's the point of the last part - some programming jobs still pay more and you only need leetcode.
  • occupant 4y ago
    What is the point of this comment? No process should be discussed or improved as long as some other comparable but worse process exists elsewhere in the world? We should hold a moment of silence for the lawyers at the start of any posting about hiring practices in tech?
• osigurdson 4y ago
  The process won't change until a new Google/Facebook/Amazon arrives on the scene that doesn't use leetcode. Then everyone will cargo cult whatever process they use.
• valdiorn 4y ago
  "you’re skewing the data with somebody’s ability to prepare for the interview" And I love it, and use it to my advantage. It's so much easier to prepare for a round of interviews, than it is to actually be good at your job. So this flaw makes it much easier to pass interviews, if you know its there. ...and believe me, I've used it :)
• ricardobeat 4y ago
  If you happen to find a landscaper that knows the reproduction period of Douglas Fir in the West Coast, odds are he is really into his job and very good at it.
• woopwoop 4y ago
  Leetcode is great for avoiding the bottom left of the von Manstein matrix.
  • ttyprintk 4y ago
    I presume your axis is hard-working in the left and laziness on the right. I don’t know if LeetCode (or any HR heuristic trying to couple algorithmic study to engineering design) is great for that. If Ferris Beuller is the top right of that matrix, does he score well for talking his way out of LeetCode without any coding at all?
• einpoklum 4y ago
  Was that blog post created with some kind of LaTeX-based tool? It sort of feels like it was...
• notacoward 4y ago
  A lot of comments theorize about what characteristic - for the most part other than coding skill - these kinds of interviews select for. Mostly it's to justify their use. OK, then: is there any evidence that this style of interview effectively or efficiently selects for any particular characteristic that matters? If these companies were really as data driven as they all claim to be, they'd rigorously analyze predictors of success (whatever that means) within the system they've built, and then design an interview process that can rationally be expected to select for those characteristics. Having worked at one, interviewed at another, and heard lots of stories about the rest, I don't get the impression that any of them have actually done that.
• bena 4y ago
  > All starts with showing some code, a class that does some stuff and its corresponding tests. The code is not glaringly bad, but it’s also not great on purpose. [And all that follows] This is worse than LeetCode in my opinion. Because all it is, is a shallow copy of LeetCode. You've constructed a puzzle by laying out a picture and cutting out particular pieces. It's "find the differences" between what you've given them and the image in your mind. > If I’m hiring a landscaper, I’m not gonna ask them to tell me about the classification of ficus in Fiji, or the specific reproduction period of Douglas Fir in the West Coast. I’m gonna ask them to trim a tree and see if the result suits me. And the landscaper will walk. They will not work for free. They'll give you references, they'll show you pictures of work they've done before, but they won't do work for you.
  • charles_f 4y ago
    > And the landscaper will walk. They will not work for free. They'll give you references, they'll show you pictures of work they've done before, but they won't do work for you. I didn't make this one up. That's how one of my friend got interviewed for his current job as a landscaper, he actually worked with the company for a day.
• 71a54xd 4y ago
  If you want to break the $200k TC barrier - leetcode seems to be the way to do it. Does it suck? Yes. Is it basically the only way to make real money in tech aside from toiling away with startup after startup. Also yes, from a person who spent five years thinking I was getting somewhere working for startups.
• cutler 4y ago
  "I don't do riddles" (DHH)
• gautamdivgi 4y ago
  I hear this all the time. Don’t use programming tests, don’t use LC or HackerRank, etc. What do other professions that demand high skill do? As an example - medicine. How are doctors interviewed when they switch jobs? The beauty of LC type interviews is that it requires no validation by your existing employer or no public record or demonstration of work. In the absence of LC, I’m afraid we have to settle for some of that.
  • nvarsj 4y ago
    Doctors are an interesting comparison, because they also have gatekeeping in terms of how difficult it is to get the credential in the first place. That early filter basically guarantees anyone with an MD has a certain level of competence. SW engineering doesn't have anything like that - it's a complete free for all, and the number of inadequate applicants vastly dwarfs the competent ones. Having said that, big tech interviews heavily bias against certain groups of people, especially older candidates and those with families. On the flip side, if you're young and have virtually no experience, you can still get a cushy big tech job simply by studying sets of questions. In that way, it's quite unique that "anyone" can get this great job simply by grinding exam style questions. No other high paying industry is like that.
    • gautamdivgi 4y ago
      I think Doctors are also at the mercy of their employer who must provide favorable references when they switch jobs.
• weezin 4y ago
  _Most_ of the people that complain about the hiring bar don't put in the effort to pass the hiring bar. That amount of effort depends on intelligence. Really smart people can quickly grasp the patterns of leetcode questions, but for someone less intelligent it requires a lot more studying therefore they are less likely to pass.
• foundart 4y ago
  I worked at a unicorn that did these type of interviews under the premise that they provided a way to reduce bias in the process. That seems reasonable if you believe that qualified engineers can walk in and compete these tasks without having practiced extensively. I don’t happen to believe that and thus believe it biases in favor of candidates who can devote considerable quantities of free time to preparation.
  • 1ark 4y ago
    Exactly. The follow up questions would be "Reduces what bias? And increase what other bias?"
• syspec 4y ago
  Strongly disagree. Leetcode interviews are not perfect, but they're vastly superior to the previous system of throwing away resumes which did not come from the right pedigree.
  • deleted 4y ago
    [deleted]
• lambic 4y ago
  I've been in the industry for many years and I've never had to do this. Is it mostly an American thing? I had to do a coding test for the job I'm doing now but it was a "take home" test and was directly related to the work I would be doing.
• tomp 4y ago
  > So What To Use Instead? > Deal with ambiguity, Reviewing code, understanding what it does, finding gaps, Testing, Code structure, Cleanliness, Learning new concepts Yeah, no. A lot of these are culture. I'm fairly confident I can teach someone smart and competent to write clean code, add tests, and properly modularise the project. It's called training (progression from "junior" to "senior"), I think more companies need to invest in it. What you can't teach someone, is how to be (1) smart, (2) understand how computers work, and (3) be passionate about tech. That's what interviews are supposed to test, and leetcode (and some deep discussions, e.g. "how does a hashtable work" then leading deeper into the details of CPU, memory, instruction scheduling, optimisation, ...) does that.
  • TrackerFF 4y ago
    Why not just use some proxy-IQ test, if a big concern is to hire smart people? Aptitude tests are perfectly legal - and much harder to rote memorize / "game" than LC questions.
    • tomp 4y ago
      When I was interviewing I always hated IQ tests but liked doing interesting coding questions.
• throwaway892238 4y ago
  Since some orgs don't seem to have time to interview without LeetCode (or just suck at interviewing), why aren't there professional interviewers that get paid to vet candidates? Is this just an untapped market?
• Tade0 4y ago
  I've come to the realisation that during those two hours at maximum that I get with the candidate the most I can do is: - Check their English - Confirm that they are not an impostor The former is an especially good predictor, because it tells me whether that person can read documentation. I suppose for native English speakers a reading comprehension test would do. The only thing Leet Code ever tests did for me is give false negatives.
• indymike 4y ago
  Dear Everyone, Please keep using Leet Code in interviews so I can continue to hire extremely talented developers with little competition from out of state companies that like to pay 60% more than local prevailing wages. Thanks.
• tru3_power 4y ago
  As someone who just went through this (finished up loop at fb and google) - I can honestly say at first I HATED the idea of leetcoding/having to learn this stuff, but after a while I started actually learning the real concepts behind the problems and started looking at them like puzzles. I enjoy puzzles so this approach made these problems more approachable and engaging.
  • byteware 4y ago
    yes, most comments here treat leetcode problems only as a means to an offer, but I too find them quite stimulating
  • jrjarrett 4y ago
    When do/did you have time to study LeetCode? After a day’s work at my actual job, I’m done. My brain is fried. Writing more code is the last thing I want to do.
• yoden 4y ago
  Every time this comes up, lots of people start with the assumption that coding problems have a large amount of false negatives. Because of this perceived "truth", I had the same worry when we started to implement a coding problem. Rather than guess, we decided to measure it: for the first six months, we used a wide filter (50% pass rate, actually like 65-80% of people who didn't cheat). What we found was that there were zero candidates in the bottom 66% who passed the rest of the interviews. The plagiarism detector also had no false positives (based on manual review). So at least on this sample, we found that we could screen out about 80% of applicants without having _any_ false negatives. I'm sure there are some bad employers misusing coding tests, just like with any tool, but I have to imagine many others have done similar experiments and found their tests to be effective.
  • jfim 4y ago
    The amount of false negatives really depends on where the bar is for passing the interviews. If the bar is "it looks alright and the person knows the language they're using," it's probably not generating a whole lot of false negatives. If the bar is "the candidate comes writes the optimal solution to a complex algorithmic problem in 45 minutes," then that's highly noisy and tends to filter for people who have done a very similar problem recently. Unfortunately, too many interviewers use the latter bar for passing or failing candidates.
• begueradj 4y ago
  Such algorithmic tests are used by FAANG as a means to discriminate candidates based on age: For example, if they want to get rid of old candidates, it's easier to do it by asking them to implement a BST algorithm which a freshly college graduate could do easier.
• scanny 4y ago
  Been an interviewer and interviewee recently, so being on both sides of the track has given me some perspective. This is the current process that I think is fair and holistic: 1. meeting with the candidate, our manager, and some devs talking about their past exp., our company, our team, and their wants 2. Take home coding task based on our day to day work: This is linear with direct instructions for inputs and outputs; there is an optional part at the end for testing more tricky concepts. They are instructed to write clean and clear, no stress if they don’t finish, take their time with a week to do it (it’s a few hours work). 3. Interview with them walking through their code on their machine and describing their thought process, field questions from them if any are left. Then we decide by a team discussion afterwards. Gives them their space to think, reduced pressure for candidates who are socially pressured. Thoughts? I personally detest leet code as a recruiting tool.
  • occupant 4y ago
    > there is an optional part at the end for testing more tricky concepts. If the candidates are anything like me then any optional or bonus features will be considered mandatory. I have no way of knowing what percentage of other candidates do the optional work and so I have no way of accurately assessing the risk of not doing the optional work myself. I will ignore your suggested timebox if the optional work will take longer and then I'll be a little pissed off at you for how long your take home assignment took me.
    • scanny 4y ago
      fair points, is there a way we could make this fairer to people in terms of their time? Scrapping it or just making it expected and defining it?
• gkop 4y ago
  No, you keep interviewing with Leet Code, and I will keep vacuuming up the fabulous sleeper candidates that cannot or will not pass your screens ;)
• angarg12 4y ago
  After hundreds of interviews for a FAANG I'm become more and more weary of this format. Particularly I find the the leetcode style "problem solving" question to have the higher rate of false negatives. It's common for candidates to bomb that question and do well on the rest. My favorite way to judge candidates now is by asking a “clean code” question. This doesn’t refer to Uncle’s Bob Clean Code, but to code that is simple, maintainable, and extensible. I give candidates a simple and slightly ambiguous problem statement, usually revolving around “write a library that does X”. I expect candidates to ask questions and clarify the ambiguities, then proceed to define the APIs and finally write the code. The implementation is straightforward, with no tricks or logical puzzles. Only use simple structures such as lists, hashmaps, and loops. Then I ask one or two follow-up questions for more requirements, such that they need to modify or extend their code. Depending on how this is organized this might be trivial or very complicated. I feel this format is the closest to on-the-job work and gives me a good feeling of what it would be like to work with these people. Also has a lot of freedom and allows one to peek inside the candidate’s mindset. How do they deal with ambiguity? How do they approach API design? how do they handle incorrect values? Do they care about corner cases? It is also mostly devoid of what developers hate most e.g. trick questions and obscure algorithms.
• lngnmn2 4y ago
  Leetcode tests how is your math, and math is hard because handwaving and virtue signalling does not work with it. Algorithms should be not memorized but derived on the go from well known mathematical models. This is what good schools like MIT used to teach.
• skyde 4y ago
  We need to upvote this to the top of HN :-)
• lubesGordi 4y ago
  The hubris of interviewing companies is just unreal. Someone can talk until they're blue in the face about the problems they've solved and things they've built, but no, I'm not going to believe any of it until I see that, what, they can traverse a binary tree post order? Give me a fucking break.
• blobbers 4y ago
  Isn’t preparing for an interview a skill? Seems like unprepared candidates who know there is a simple way to prepare should be cut. They don’t want it enough to go to the trouble of spending their time.
• marcus_holmes 4y ago
  Totally against using LeetCode for interviewing engineers. However, when asking around about why people who use it do so, I found out it does have one irrefutable advantage: it stops people who can't code at all. From an engineer's point of view, LeetCode is a complete waste of everyone's time because it measures things that aren't factors in successful engineering (as TFA says). Bu from the non-technical manager's point of view it's awesome because it gives a single, simple score for "how good is this engineer compared to the other ones?" and people who can't code at all can't complete it. The non-technical manager's worry when interviewing is that they hire a really expensive employee who can't do the job. But because they don't understand the tech, and the tech is complicated and even expert engineers spend lots of time fighting it to no apparent end, it's really hard to understand if an engineer is incompetent and bullshitting them, or actually good but the problem is hard. Having a nice, easy metric that stops the complete bullshitters from getting in solves a problem for them. What we need, obviously, is a professional association for software dev, that can then properly test us and verify that we can do the things we say we can do. But the industry has a lot of growing yet to do to get to a point where this is even possible.
  • ilc 4y ago
    That's ok. There will be a prep school for the best. People will study to the test, and we'll have "cracking the association". People will always study to the test. So it is essential that when you interview you test for what you ate looking for. This is why using 3x leetcode interviews is a bit silly. Testing if someone can code is 100% reasonable. If a company wants to waive their coding test for me, I tell them they shouldn't and that they should NEVER assume someone can code. Yes, that means your company needs to have questions, and interview design, that actually looks for what your company truly wants and desires. Amazingly, this CAN be done. Interview design is hard, but very possible, But asking a EASY leetcode question is 100% reasonable.
  • nkuttler 4y ago
    You don't even need leetcode easy level though to stop imposters, a trivial challenge with a loop and variable that you manipulate somehow will do.
• cmrdporcupine 4y ago
  I just tell recruiters I simply won't. Turned down continuing with an interview process with a company just last week for this reason. I'll do take-home programming, I'll do collaborative debugging and coding in a shared IDE with something that looks like a real project, I'll do system design etc. interviews, talk to you about programming, etc. and I'll show you my GitHub etc. projects and you can judge from that, and my 20 year long resume, whether I might be a fit. Want me to write CS-class algorithm & data structure problems on a timed clock on a whiteboard or equivalent? You've just told me everything I need to know about your engineering culture. I worked at Google for 10 years and I hated their interview process, it needs to stop spreading to the rest of the job market. If enough of us say to no to this process, it will end. And to hiring managers: most of you are not Google (thankfully) and don't have a bottomless pit of talent to choose from. Stop pretending otherwise. You'll get better results. If you feel you have to do it, save it for new grads and stop using it for senior talent. All you're testing for is whether people practiced leetcode or whether they're straight out of a CS program.
  • ejb999 4y ago
    >>I just tell recruiters I simply won't. Turned down continuing with an interview process with a company just last week for this reason. I've done the same - and got hired anyway after I told the recruiter was not interested in taking any tests - just happened to have the right in-demand skills at the right time I guess.
  • g9yuayon 4y ago
    Yeah, leetcode type of test got popular because hugely successful Microsoft and Google used to use them to pick the smartest geeks for amazing technical challenges for their times. Now that leetcode is being abused by both companies and candidates, we really should find a different way to interview.
  • 0x20cowboy 4y ago
    > If enough of us say to no to this process, it will end. I highly doubt it, but I do the same. So that's at least 3 of us.
  • tsuujin 4y ago
• TulliusCicero 4y ago
  Studies show that one of the most effective interviewing tools is a test for general mental ability: https://www.semanticscholar.org/paper/The-validity-and-utility-of-selection-methods-in-of-Schmidt-Hunter/0b25a19e275f2c27710beb02fda8f98ae509043e https://www.semanticscholar.org/paper/The-validity-and-utili... Now, IQ tests are of dubious legality, at least in the US, but algorithmic coding questions basically get you an IQ test crossed with a programming skill check: win-win. All the ire about how you don't actually invert binary trees or whatnot during your real job are rather missing the point.
  • deltree7 4y ago
    Bingo! I like how all these arm-chair HNers who have never run a successful company or built a public-facing product used by millions suddenly are experts at how to build a successful company. Yeah, you know how Search serves 4 Billion people or people created Chrome or gmail in their 20% free time? Because they could leet code and not use Stack Overflow as a crutch. Sure, not all companies need leet code. But someone who can leet code has demonstrated skills that has proven to be correlated with creating Trillion $$$ companies. Now go back to developing your CRUD app used by 20 internal users (because they are forced to) and let companies who are successful continue to use their successful methods
    • cmrdporcupine 4y ago
      Nah man, nice try, but you're wrong. I worked at Google on at least one of the codebases you're talking about, and I can tell you that the "skills" that most Google interviews test for are almost never applied there. Certainly not in an "on the spot" format either. Most of the work @ Google, especially on an established codebase like Chromium (my experience), is about slow incremental engineering in very small bits and pieces doing mostly really mundane administrative things. And when there's 'core algorithm' type stuff to do, there's plenty of time and space to stop, consider, read the literature, and move on from there. Nobody is going to put a gun to your head and put you on a clock and then score your results like in an interview. Most of the intractable difficult problems at Google are more "how to get there from here" and organizational; how can I pile up this series of code reviews over months to get to this final destination where this system is cleaned up or more efficient or this feature implemented/implementable. Google's use of algorithm testing in the coding interview is simply a result of the fact that they have hundreds of thousands of applicants and need a way to filter in some repeatable and measurable fashion. And it's worth pointing out that the interview process @ Google goes through a whole series of metrics & calibration towards that effort. It's not just "could solve this problem", it's "solve this problem according to interviewer X's satisfaction, but we've calibrated interviewer X's scores at level N, so adjust according to that" and so on. There's an attempt to be scientific about it. Most other companies applying "leetcode" are not doing that, they often simply have a highly reductionist mental model of what "software engineering" is, which IMHO doesn't accord with the reality of the profession. Are you lucky to work at a company that gets thousands of resumes from seemingly qualified people a day? Probably not.
• sharker8 4y ago
  I think the bias against Leetcode is not specific enough. My bias against leetcode: stop screening at leetcode easy/medium. Screen instead at Hard/Extra hard.
• mywittyname 4y ago
  > A first alternative is to look at some of the candidate’s code to begin with. This is biased towards people who code for free in their free time. I'd call this terrible advice for most companies, since it filters out the vast majority of qualified candidates. I have some open source contributions on my GH account, but none of them are representative of how I code since they are all bug fixes and/or small enhancements which are shoehorned into an existing codebase, since my goal is to add a feature with the smallest number of code changes (in order to increase the likelihood of a PR getting accepted).
• etblg 4y ago
  You know after going through like 10 or so interviews this year while trying to find a new job, I grew to appreciate leetcode tests as a candidate more. The first thing you start to realize when interviewing is that every company has their own unique process for interviewing. The second thing you realize is that you're not going to ace every process every time, it's a roulette wheel you're spinning to see if this specific process and this specific day and this specific set of interviewers and this specific mood you're in are able to align in a way that they feel confident giving you an offer (leetcode or no leetcode, doesn't really play in to this factor). The nice thing about leetcode tests as a candidate is that you can study for them, go through a few rounds of it with different companies, and get better at it and know how to improve for the next interview. When companies drop the leetcode tests you end up getting judged on the arbitrary criteria and testing that they devised in its place. If you come out of that interview not doing well, you can't really use that as practice for the next one -- because the next company you interview at may have a process/test that doesn't overlap at all with that previous interview. Now you don't have to practice leetcode and spend an hour doing something that's not directly applicable to your day to day job, but instead you're subjected more to the whims of randomness and whether you were prepared to satisfy the process they came up with instead -- which may not be shared by other companies. Leetcode isn't great, but it's also not that bad. Some companies (i.e. Google, Facebook) you will have to get very in depth with practicing and knowing data structures and algorithms to do well in the interviews. A lot of other companies you can pass the leetcode with a lot less work, just need to have a basic refresher on graphs, trees, linked lists, etc. Other companies yet, they won't ask you leetcode at all (but that doesn't mean the job/company is good in other areas either, it's always a tradeoff).
  • avidiax 4y ago
    It's quite true that companies that don't do Leetcode may not necessarily be more challenging to get into, but it is more random whether you will. And you often need to study especially for that one company, who may ask you, a backend developer, to do a pair coding exercise to implement a RESTful web API, even hiring for a backend position. I try not to be a part of the problem when I'm the interviewer, giving a problem that would be described as a Leetcode easy, with an optimal implementation that is below easy. But I want to see if the candidate can understand the problem, the big picture, talk about tradeoffs in the problem, properly analyze performance, properly test their code, etc. Most candidates struggle with this, many can't even code a working solution, and this is the talent pool for a "top-tier" software company.
• deleted 4y ago
  [deleted]
• daxfohl 4y ago
  More appropriate interview would be "figure out how to get permission to change this setting"
• raincom 4y ago
  Who is going to the bell the cat? Unless at least 20% of FAANG, unicorns, stop using leetcode, this show will go on.
• robotburrito 4y ago
  These threads are always so depressing. On one side you feel bad for the people that have to study leetcode so hard, but then again being good at leetcode offers you the ability to basically jump into a 6 figure software career that could very well change your life. Without the ability to get hired by just "being good at leetcode," does that make it harder for people to break into the industry?
• fredgrott 4y ago
  the last Leet Code interview was a time ago when some firm, RealNetworks, had the bright idea that they would inject their own codecs into Android OS kernel and perhaps be able to sell them to OEMs. Needless to say I stopped the interviewer when they started asking Leet code questions and have refused to do any of Leet code interviews since. Life and fun code and fun design is way to short to waste it on ineffective BS.
• kmod 4y ago
  The issue I have with these arguments is that they assume that just because a certain thing has flaws there must be a better solution. What if predicting long-term effectiveness using a limited amount of time is inherently approximate at best? I'm sure interviewing can be improved, but I think it's worth remembering that we are one of the few industries that actually tries to do skills-based interviewing. When people say "get rid of leetcode" or what not, are they really saying that the alternative that the rest of the world uses (resume screen plus vibes check) is preferable?
  • charles_f 4y ago
    I would suggest reading the end of the article related to that.
• olliej 4y ago
  I've interviewed at three FAANGs. None of them asked any leet code questions (I was actually looking forward to the silly puzzle questions MS was notorious for at the time because I love those puzzles, even if I think they're bullshit in an interview. Alas it turned out all those questions were basically for PM positions :( ). The only question I got that seemed particularly bullshitty was at Google, where it was one of those questions where basically you're expected to work out "the trick", it seemed to me to be very gotcha like. But that was just one question among many, across many people. I've also interviewed many people over the years, and no one has asked any of those stupid questions. They are completely and utterly useless - I see a few comments here saying we're testing for conformance and that has never been involved in any of it, because again it doesn't provide any knowledge of technical skill. As an interviewer you're also aware that the person on the other side of the table is often extremely stressed or nervous. So we understand that you might make mistakes, or stumble on answers, etc - failing to account for such issues simply means potentially discounting good candidates. As far a whiteboard coding goes, for myself, and I believe many of my co-interviewers a lot of what is actually being looked for is your thinking and problem solving - seriously, I cannot emphasize enough how you should talk through all your reasoning as you write. That allows us to know whether a logic error is a failure to understand/do the correct thing, or just a standard typo-style mistake that everyone does from time to time (again recall we know you're stressed). Also by and large we aren't looking for /perfect/ code (ok, some do but in reality it's worthless metric - I only got this from the gotcha interviewer at G). Personally my interviewing I often don't care about the language, I'm interested in the solution, and generally accept pseudo code, or your preferred language. Just a few general tips as an interviewer: * When asked a coding question, repeat back what you're being asked, you want to confirm it (I've had people try to solve the wrong problem before), and have (where reasonable) some follow up probe/clarification questions. * Follow on from above coding question. If you're answering on a whiteboard, remember that the interviewers know that the nature of the format means you might make simple/silly/"stupid" mistakes. Listen for any feedback they give you while answering. * Additional follow on. Another cannot be emphasized enough point. Write test cases for the problem you're solving. Do it before you start the solution. It demonstrates that you understand the need for them, and provides another opportunity to ensure there's agreement on the problem being solved. It also lets you clarify things like the expected API - not part of the actual problem, but something needed for any implementation. Try to make your test cases cover "normal" and edge cases. * Be aware that if you are nervous, stressed, or worried, the interviewers are aware of that, and know that that can cause errors you wouldn't normally make * Try to have a reasonable awareness of the job that you're being interviewed for, some of the relevant things the company does/how it does [software dev, engineering, product management, etc], if at all possible. Either so you can ask questions that indicate you have some understanding, or so you can tie in what the company does as it relates to a particular question (if appropriate, don't just shoe horn things in) * Be polite - this is a "be subservient" thing, this is just if you act like an asshole the interviewer won't like you, and that will impact what they report. I believe it's consistent across FAANGs that immediately post interview every interview send an email that is basically "Yes/No. Reason: .." * Don't be sexist, racist, homo-/transphobic, or just generally a bigot - I am aware of one woman interviewer having a candidate assume she was an admin, and treated her as such. Another case where a woman was interviewing someone for a position reporting to her, where a candidate asked who his manager would be, found out it was her. Then told her to her face that he didn't think he could work for a woman. That indicates not just incredible sexism, but also just a complete lack of judgement and common sense. The latter alone would warrant a no hire.
• maxfurman 4y ago
  On the flip side, I'm about to start interviewing some engineering candidates, and I have no idea what to do. I've been in the field for 8+ years now but interviewing for technical positions is hard and I've never seen a company really get it right. How do you have high standards without a ton of false negatives? How do you avoid reductive coding exercises without selecting for charming incompetence? Genuinely asking, are there any good resources on this?
  • charles_f 4y ago
    Would advise to read the end of the post regarding that.
• turtlebits 4y ago
  There has to be some sort of hiring "gate", what would be the replacement? It used to be a CS degree (which is even more restrictive). FAANG jobs are in high demand due to salary, so now we have 5+ round interviews and leetcode as a low effort filter.
  • charles_f 4y ago
    I would suggest reading the end of the post that answers the question
• deleted 4y ago
  [deleted]
• autokad 4y ago
  the writer forgot to say they discriminate against those who can't (or don't want to) practice leetcode questions in their free time. This includes those with families, caretakers, people with after work hobbies, etc.
  • charles_f 4y ago
    Mmh, isn't that what this says? > Another major issue: you’re skewing the data with somebody’s ability to prepare for the interview
• dandigangi 4y ago
  I'd kill for the industry to progress in this area. Really enjoyed when I interviewed at Netflix that they didnt put me through it as a manager. It was all about cross partner collaboration, working with and coaching devs, technical design/vision and handling customer/vendor relationships.
• coayer 4y ago
  As a student that practiced LeetCode for getting summer internships, I'm getting stressed reading these comments! It's not an enjoyable process at all.
• why-el 4y ago
  I don't know, risky answer but I will give it nonetheless. This advice is given to many candidates, and I agree that Leet Code interviewing is bad and the industry needs to work on something better, but in the meantime, if you are starting out, think of it this way (and I have friends younger by 10 years or so and straight out of college and I say the same thing), a few months of studying gives you a huge salary. It's a win-win, and in the meantime, people will complain and hopefully the industry will fix it, but do not "Skip Leet Code" just because it's the cause du jour. That's just my opinion.
  • iostream25 4y ago
    There are a whole slew of Stockholm Syndrome answers here that effectively repeat the precise point you make. If it gets you the 6 figure salary, who cares about the corrosive bad practice remaining prevalent?
    • why-el 4y ago
      I am not sure if you are agreeing or disagreeing. If you agree, I'll take it. If your point is that we should try and fix it and not succumb to "Stockholm Syndrome", I say precisely that also, in the second part of my comment. We can both work to fix AND have folks get their money by studying. Often times what happens is someone young enough will read this and conclude there is no point to studying, and that is not good career wise on average.
• jackielii 4y ago
  I've done a few interviews like this recently. I always thought I was a OK programmer, judging from the feedbacks I get from colleagues. But after these interviews, I felt terrible. Doing my daily Leetcode as we speak...
• throwaway0x7E6 4y ago
  that's an engineer's opinion about things beyond his understanding 75% of fresh grads are below mediocre, to put it very mildly. 50% of candidates with a seemingly OK employment record or portfolio are too. leetcode filters them out right away. that's the purpose it serves. it's not there to get you good candidates, it's there to make sure that you only spend time interviewing potentially good candidates. I would agree that it would be ideal to use coding challenges suited for the job you're hiring for, but that would take a lot more time and effort to make and review
  • iostream25 4y ago
    ... and as a result there are false negatives and you turn away actual top talent who can't Leetcode. Effort spent on hiring process is reflected in quality of employees.
    • throwaway0x7E6 4y ago
      top talent gets hired outright, based on their prior work potential top talent might get turned away yeah - if they can't leetcode and have nothing impressive on their resume, but that's acceptable
  • charles_f 4y ago
    That's a Microsoft engineering manager's opinion formed over his understanding over his past 10y of hiring. Leetcode doesn't act as an efficient filter. If you want actual talent you need to put effort into it.
• brianhorakh 4y ago
  Leet code definitely discriminates against slow thinkers and those who might be more inclined to use libraries and interfaces. It is biased against a certain types of developers who is usually not the best type of developer. Have you ever seen corporate codebases? Leetcode emphasizes the old way of thinking is/was prone to do what you are told, dont think, just do the task in the timebox allocated for the sprint, always reinvent the wheel, and each axel, multiple times, for each wheel, in the same codebase. This jira waterfall code now, dont think, and this might be fine for a unicycle, or even a bicycle, bad for trucks and trains. Hint: With factor t - all tech debt - Everything will become a truck or train.
• adam_arthur 4y ago
  Leetcode style questions are not a bad backdrop as long as you do a few things. 1) pick questions that are actually somewhat aligned with a problem that would come up for the role. Usually implementing a data structure of sorts is going to be way more predictive and relevant than a dynamic programming problem. 2) Ensure the question requires a fair amount and complexity of code to complete. 3) The question should just be a backdrop. Consider also how quickly and proficiently they can code. How intelligent they come across in conversation. Things they call out as side notes, testing, quality etc. Many interviewers seem to have forgotten the purpose of the interview is to be predictive to on the job success, not to invent some separate funnel and gauge how well the candidate did on that funnel. In practice, at scale, you will likely have enough correlation between success on a contrived interview system and general competency, but you're going to get a lot of false negatives/positives using that as a yard stick. My experience has been that leetcode "theory" is very weakly correlated with competency for most roles, and quality and speed of coding much more highly correlated. One of my best hires was a guy who couldn't implement a tree traversal in the interview
• anikom15 4y ago
  The best programmers are the ones who can solve problems without writing a single line of code.
• ystad 4y ago
  Nice article - Leet code style interviews give minimal signal. The fact that we use the word Leetcode makes me think the company is hiring for the masses and it's going to be a boring job. I call such a company a Dinosaur. I think companies should offer a choice to interviewers if they prefer to give code samples , an at home problem solving or an in-person exercise. This addresses careful thinkers, adapts for anxiety during an interview. I do appreciate when companies ask relevant questions that they have come across rather than mundane Sudoku questions. I have interviewed with a few companies, and Stripe's interview style stands out. Coding questions are relevant day to day style questions. I would say Google, Amazon and Facebook set this trend and have spoiled it for all. Unfortunately, some companies cannot think on their feet to set a different approach. Maybe it's in your best interest to avoid these places.
• mannanj 4y ago
  I still don’t understand why more companies don’t do interviews that include solving real problems that their engineers have had to solve (or will solve), modified by some or more of the following factors: 1) domain specific knowledge removed so someone without company proprietary data can grasp it in an interview 2) code setup, library installation, all the time consuming fat removed 3) some level of repeatability and possible algorithm space so different candidates strengths can shine. How hard would this be to do?
• MarquesMa 4y ago
  I don't think it will stop unless 1) It's illegal. 2) It's ineffective 3) It's not economical for the company. To stop the trend you have to achieve one of the three. Similar to algorithms itself, interviewing is essentially searching for people that the company wants. How a company interviews candidates define its effectiveness (hire the right person, less false positives, less false negatives) and cost (how much does the company spend on the interview process per hire). Interviewing with LeetCode is acceptable effective: candidates.filter(leetCode) gives you a much smaller set of people good at algorithm brain teasers, and this set of people have acceptable approximation with the set of ideal candidates. In other word, it's a lazy but effective enough. The majority of companies will only switch to alternatives when the cost is lower, or substantially more effective. It's broken from the candidates perspective, but not the companies'. Most companies will stick to "if it ain't broke don't fix it" unless we offer them 10x solutions - which is yet to be seen. But I can also see it the other way around, we can undermine the effectiveness or cost for all companies: if we can develop better courses and bootcamps, letting more people hack LeetCode problems quickly. And then companies will naturally go for harder problems. In the end, the problems will be ridiculously hard that the companies can only filter people who memorizes LeetCode, and those set of people have virtually no correlation of good hires (good problem solving skills). And of course, it's also a profitable business to teach people this.
  • justsomehnguy 4y ago
    Between #2 and #3 you missed the most important thing there: it should be not only ineffective but ineffective enough to be measureablre at the top of C-level. Untill that it is just another pointless KPI alonh many other ones
    • MarquesMa 4y ago
      You're right. But I also said in the following paragraphs which means the same thing: > Most companies will stick to "if it ain't broke don't fix it" unless we offer them 10x solutions It should also work if people undermine 1x solution to 0.1x solution. If there are a lot of bad hires at the company level, which they can't finish ordinary tasks other than LeetCode problems and keep screwing things - the team leads and managers will start to complain and eventually propagate to the top level.
• SergeAx 4y ago
  Leetcode tasks are just a starting point for discussion. Okay, you wrote that SQL query correctly (if you didn't - stop whining and go learn SQL, it was a pretty easy query). So, if those tables will grow with time, where will the performance bottleneck be? How will you avoid it? What types of indexes do you know? What is the difference? When you would use which? What do you know about data partitioning? Sharding? How do you avoid data resharding on growing cluster?
• crakhamster01 4y ago
  As an alternative to Leetcode, I have had a good experience with Byteboard. It's sort of a "project" based interview format, that comes with 2 parts. Part 1 is a design doc where a problem statement has been outlined with goals and notes from the development team. Your job is to respond to their questions and propose a high level architecture to solve the problem. Part 2 is the coding portion, you're dropped into a codebase that relates to the previous portion and are given a todo list of tasks to complete. It's basically feature implementation, ranging from trivial to somewhat involved. I really like this approach. As someone who has interviewed a lot of candidates using Leetcode style questions, I would love if my org moved towards this format. Unfortunately, it's pretty hard getting FAANG companies to drastically change hiring practices, but if smaller companies start adopting it maybe it will get some traction.
• iostream24 4y ago
  I’ve kind of had it up to here with the deliberate proposal echoed by many folks here that Leetcode interview hazing has anything to do with either software quality or the safety of safety critical systems. Safety critical systems already have legally defined coding standards. No really. The former notion is just not worth defending, but this thread will continue to grow, regardless
• faangiq 4y ago
  This is good. Managers need to leetcode to prove their IQ.
• psilotorp 4y ago
  This is very similar to my process and I've found it to be very effective. We hire engineers to work with a well known dynamic language's MVC-ish framework building a pretty standard fare web platform. We tell candidates they can look things up on the condition they tell us when they are doing so (basically, "think out loud and walk us through the process -- knowing where to find answers is a valuable skill!") And in most cases they're permitted to use pseudocode if they want to, e.g., if the situation demands any kind of obscure syntax or boilerplate, they just have to note it. Exercise 1 All candidates are shown some (poorly written) code and asked to pretend they're performing a code review for the author, who we describe as a novice programmer who is new to the language & framework. The code we use is a composite of real code pulled from many places in our system (basically, what the code would look like if all the mistakes we encounter were collected into one snippet). The functionality it implements is exactly the kind of functionality the candidate will be expected to implement on a daily basis. We ask them to identify antipatterns, suggest edits to make the code more idiomatic, discover bugs, point out security or performance flaws, improve names, etc, and reassure them by telling them that no one spots all of the issues. We're causal in demeanor and try really hard to remove stress from the situation, making jokes, etc. We help them if they get stuck. Exercise 2 We share a 90% working piece of code that is missing a single method. Without getting too detailed, something like "This will setup a form based on this model, but the way it is written right now does not provide a mechanism for allowing the options of the select box to depend upon which user is signed in. What would you change to enable that?" They don't even have to write the code (though they often do), they just need to understand conceptually why it doesn't work and then talk through a solution. Exercise 3 A very simple test of their ORM knowledge. They need to utilize a technique that they'll have used dozens of times if they are being honest about their experience but that they probably wouldn't learn in the most basic of tutorials. ..And so on. For candidates applying for senior roles we have an additional live-coding exercise, but most of the same rules apply -- they can look up docs, we help them if they get stuck, etc. We give them a starting skeleton app and they have more than enough time to solve the problem. They can use their own editor, copy/paste sample code they find on stackoverflow or in docs, etc -- basically everything they do when they are actually coding. The problem is a very realistic one -- a simplified version of a feature that had at one time been on our roadmap but which we eventually abandoned. We encourage them to add comments to indicate what they'd do if they had more time, and when they're done, we discuss the overall approach and ask questions about their decisions. I've found the above approach to work far, far better than any "whiteboard coding" or "leetcode"-style unrealistic (for the places I've worked and the roles I hire for) interview problems. We rarely regret hires and people stick around for a (shockingly) long time. I really wish other tech decision makers would adopt this style, for their own sake and for the sake of those seeking jobs.