6 ms·

My advice? Start memorizing the riddles. Consulting jobs require case interviews - they're pale imitations of actual projects that translate loosely at best. A

My advice? Start memorizing the riddles. Consulting jobs require case interviews - they're pale imitations of actual projects that translate loosely at best. And every company uses them. Trading jobs ask probability questions - they're idealized versions of what traders do all day, requiring tangential (at best) skills like mental math and memorizing niche formulae. And (almost) every trading firm will ask them. Tech jobs ask leetcode questions - they're vaguely correlated with tech skills (you can't learn leetcode without learning to program, I guess?). And (nearly) every company asks them. All of these industries put up somewhat-arbitrary filters just to get a manageable signal, however imprecise, on the endless morass of new grads trying to break in. They ask them because they work: the pool of candidates who pass them are of a higher average quality than the pool who fail. They're biased, arbitrary, and often quite silly. And they've persisted for a half century. Get used to 'em.

tsuujin 4y ago
> Get used to 'em. No. I’ve spent the last year or so reinventing the hiring process at my tech company to expressly avoid algorithmic puzzles and leetcode nonsense, and I was able to do this because I patently refused to accept the status quo. You can do this too. Anyone can. I’m basically a moron and I managed to convince our talent team to radically change how we do things; if I can do it I feel like the bar is pretty damn low. The only real requirement is that enough of us simply refuse to accept how things are today. Right now is a fantastic time for the tech industry to adopt change because your talent recruiters are probably struggling to find and retain new developers and are almost certainly willing to listen to suggestions on how to stand out.
- rodenmonte 4y ago
  Would you be able to share the kinds of questions you ask and have had success with? :)
  - tsuujin 4y ago
    We basically adopted the MINASWAN interview, which Jesse Spevack can explain much better than myself in his talk [here](https://youtube.com/watch?v=c4K-ORZmrGk&feature=share https://youtube.com/watch?v=c4K-ORZmrGk&feature=share). The overview is that for each candidate we spend 20 minutes reading through code we provide to them to demonstrate comprehension, and then we give them 45 minutes to pair with us on reimplementing that same code from scratch. What that code is doesn’t really matter, it’s more about getting a chance to work with them and start a conversation, and starting with trying to explain a provided example really smooths the way into the pair programming.
    - kyawzazaw 4y ago
      How much time and resources does it cost to successfully hire one candidate?
      - tsuujin 4y ago
        Substantially less than our previous process. We went from a process that took weeks to get through (multiple interviews, about an hour each, with a full code day at the end) to a two step process. Talent reaches out to the candidate and has a thirty or so minute chat to make sure the candidate meets basic hiring requirements, and then we have our MINASWAN process which is a single three hour interview, including two breaks for the candidate to get off camera and catch their breath. The participants are: - the candidate - a hiring manager - between two and four developers for pairing - an open invitation to the hiring team’s devs for a closing panel interview. The feedback we’ve received from candidates has been overwhelmingly positive, even for those who didn’t receive an offer.
    - erik_seaberg 4y ago
      > 45 minutes to pair with us Do you require pairing on real work? How do you handle candidates who need quiet to think? Going by the continual complaints about open plan offices, there seem to be a lot of us.
      - tsuujin 4y ago
- deleted 4y ago
  [deleted]
- bluedevilzn 4y ago
  > I’m basically a moron Google and other companies are actively trying to avoid hiring morons.
  - tsuujin 4y ago
    I’m not sure if you’re just being snarky or you’re trying to make an actual point here, but I can tell you that this kind of commentary reinforces the egocentric interview process we currently suffer through. Solving puzzles doesn’t prove that you’re smart, and not memorizing them ahead doesn’t prove you can’t do the job. Unless you’re really on the edge of the industry—designing rockets for NASA or surgery tech or something—most dev jobs aren’t really all that hard, and we should stop pretending they are.
    - missedthecue 4y ago
      Solving complex riddles may not prove you're Einstein, but it's a pretty good filter for morons.
      - tsuujin 4y ago
        Disagree. I’m very good at puzzles.
        fsckboy 4y ago
        then you shouldn't have said you're a moron. You seem somewhat contrary, which leads to its own problems, at least for me.
        tsuujin 4y ago
        Disagree. I’m highly agreeable.
    - bartread 4y ago
      > most dev jobs aren’t really all that hard, and we should stop pretending they are. I agree with you about GP's commentary, but I don't know that I agree with this statement. Getting something working is often relatively easy. Shipping v1.0 is often relatively easy. But it starts to get gnarly as you build out capabilities, add services, split concerns up, have to maintain compatibility with previous versions, dependencies multiply, the amount of data you're dealing with massively expands, and so on. Most problems have one or more inflection points, whether that's around performance, or scale, or volume of data, or whatever, that when you pass them make that problem substantially harder to solve. Still, these are all issues that come with a certain amount of success. Not necessarily crazy success: I'm just talking about the kind of traction that companies that grow to earn millions to tens of millions of dollars or pounds per annum experience. The really hard part of being a dev, of course, is knowing what the right thing is to build. Often, because users tend to struggle to articulate their needs, the only way to find out what to build is to start by building something that you know is probably going to be at least a bit wrong, if not massively wide of the mark, just to get some feedback. And then you have to iterate, sometimes quite painfully, towards an actually good solution from there. Of course, this isn't something you can assess with a leetcode interview. I don't hate interviews where the candidate is asked to write some code. I think writing code is a valid form of assessment because I've encountered enough jokers over the years who couldn't program if their life depended upon it - yet still manage to carry a job title like "software developer" - that I need some way of weeding them out of our hiring process. One reason for this is that I simply don't have gobs of spare cash to pay large salaries to people who are fundamentally incapable of doing the job they're asked to do. Note though that asking them to write code does not equate to leetcode. We'll generally give people access to an IDE containing a template project and common tooling they would use on a day to day basis in the job. We also select problems that have some relation to our systems rather than asking hardcore questions about algorithms and data structures: we give them internet access so they can look that stuff up if they need it to help them (just like the rest of us do in our day jobs). Cynically, a lot of interviewing I've seen over the years seems to be about the interviewer trying to appear to be the cleverest person in the room, and I think leetcode often falls into this category. I find this perverse and unhelpful but I guess these interviewers are just insecure, angry people.
- valar_m 4y ago
  So what'd you come up with?
  - tsuujin 4y ago
    I answered this in another comment before I saw this, feel free to respond to it if you want to chat about it: https://news.ycombinator.com/item?id=31453571 https://news.ycombinator.com/item?id=31453571
- deleted 4y ago
  [deleted]
- UncleOxidant 4y ago
  > now is a fantastic time for the tech industry to adopt change because your talent recruiters are probably struggling to find and retain new developers Unfortunately, this will likely change much sooner and more rapidly then most of us expect. The music is stopping and chairs are about to be removed. It was great while it lasted, but all good things come to an end.
  - tsuujin 4y ago
    I’m not sure I agree, but I’m positive this isn’t a barrier to adoption right now. Recruiters are really looking for an edge to provide differentiation, and “friendlier, faster process” is a big one.
    - danachow 4y ago
      What has changed in the past 20 years? Because this sounds like the same shit I’ve heard since entering the industry. And it isn’t like this topic is new at all.
  - rejor121 4y ago
    Sure. Someday. Same thing has been said since the 90s
    - sorry_outta_gas 4y ago
      After working though the dotcom bust and the subprime fiasco it seems a bit dramatic although I'm also not beyond my means and have some savings this time (didn't last time and it got hairy) in general i worry more about other people in much worse situations that I'm unable to help
    - UncleOxidant 4y ago
      And it's happened a couple of times since the 90s.
- ssalka 4y ago
  Yeah, I've worked in tech 6 years now and never had to do Leetcode to get by in interviews. That being said, I never interviewed at FAANG. But many teams set a bar easier to pass than leetcode that still ensures good engineering skills
- beej71 4y ago
  > I’ve spent the last year or so reinventing the hiring process at my tech company to expressly avoid algorithmic puzzles and leetcode nonsense, and I was able to do this because I patently refused to accept the status quo. I think companies that break out of the leetcode habit are going to do well. There's a lot of great talent out there that's being passed over by these tests. If the job is to solve leetcode problems, by all means, test the candidates for that. If the job is to solve real life problems, there's almost certainly a better measure. I will never judge someone based on that kind of problem. I believe the data that results is just bad. Edit: I should add that leetcode is useful for developing programming and problem-solving skill. I've done tons of problems, myself, and have fun solving them... and learn from them. So I do recommend it for a challenge. But not for interviews.
  - tsuujin 4y ago
    Strong agree with all of this. Ideally, interview questions should be directly related to the domain of the position. Show the candidate what they will actually be doing if they accept an offer. The whole process should be a two way conversation.
  - stutsmansoft 4y ago
    > I think companies that break out of the leetcode habit are going to do well. > There's a lot of great talent out there that's being passed over by these tests. Agreed. And there's a lot of great talent that doesn't even want to try with some of these companies solely due to the hostile interview process.
    - kabdib 4y ago
      I recently took a year off, and started interviewing in March. I spent a fair amount of time in fear of interviewing, doing LeetCode pushups and feeling miserable about my performance, and wondering if I could swing retirement rather than go through another fucking hazing ritual. Excuse my language. I resolved up front not to submit to any kind of take-home test, proctoring software, or algorithmic nonsense unrelated to the actual job of shipping software. A polite "No thank you" was what I planned. But the plan was thwarted! I was pleasantly surprised by the technical interviews I actually got. They were mostly nicely constrained problems that were real-world and not algorithmically nasty. One was a little unintended "collaboration" in the form of helping a senior dev debug their own "what is wrong with this code?" exercise (it probably went smoother for the next candidate they interviewed). In short, it was actually kind of fun. I started a new dream job this week. At 61 this is no longer easy, but the company is enlightened enough to support me while I get up to speed, and it's fun to help mentor the folks just getting into the industry. There are decent companies out there. Hopefully the terrible ones will start getting a clue.
- deltree7 4y ago
  Only on the internet, that someone working for a cost-center division, building an piece of internal software used by 20 users, gets to lecture how a $2 Trillion Dollar, building multiple Billion real-world user products, generating > $500,000 per engineer profit should run their hiring process
  - tsuujin 4y ago
    That’s making a lot of assumptions about who I am and what I do based on nothing.
- serenitylater 4y ago
- curiousllama 4y ago
  FWIW, happy you're doing this! A better process would make so many peoples' lives better. The ONLY people who should "get used to 'em" are new/recent grads looking for a junior-ish IC job. For them, it's just a fact of life: they had to learn history & biology to get their CS degree; they have to learn leetcode to get a job. Interviewers should make a better process, as you're doing.
  - tsuujin 4y ago
    Honestly, I think I would encourage junior devs to shop around before just accepting the leet code life. Unless they’re in dire need of income—in which case, do what you need to do—the kind of company willing to treat you like a game show contestant may not provide the best culture for learning and growth. If you can avoid the BS you should definitely do so.
diob 4y ago
The worst part is it's biased towards those who already have the time / security to devote to it, aka those from the upper class. Vicious cycle.
- rockemsockem 4y ago
  That bias is generally true for any education-based employment that requires a significant upfront investment.
rajup 4y ago
> My advice? Start memorizing the riddles. I don't have a strong opinion either way, I got with the Leetcode grind program for my current position, but I really wonder about this: is it really possible to memorize these questions? Last I checked Leetcode has over 2000 questions, anyone who can memorize the solutions to all those is some kind of genius savant and should be hired anyway. Or is memorizing meant in a different context here?
- jjav 4y ago
  > anyone who can memorize the solutions to all those is some kind of genius savant and should be hired anyway But that's the problem. Why should they be hired? The actual job will not consist of regurgitating those memorized solutions. I'm impressed by someone who can memorize 2000+ solutions, same as I'm impressed by the acrobats at Cirque du Soleil, but I don't want to hire from either group for a software engineering job because that's not what the job is about.
- bulldog13 4y ago
  Memorizing is meant in a different context. Ultimately the problems boil down into a few "types". So you are memorizing the types. https://dev.to/fahimulhaq/14-patterns-to-ace-any-coding-interview-question-d9g https://dev.to/fahimulhaq/14-patterns-to-ace-any-coding-inte... https://neetcode.io/ https://neetcode.io/
  - curiousllama 4y ago
    As a sidenote: this holds true for other types of arbitrary-interview-riddles. There's only 3-5 "frameworks" you need to memorize/apply for consulting case interviews. Finance probability problems typically test one of ~a dozen prob/stat formulae + ability to multiply 3-digit numbers in your head. After all, it has to be manageable for the interviewers to make sure all the questions are roughly equivalent in difficulty.
- bhavikkumar 4y ago
  I have used hackerrank/leetcode previously just sporadically to learn a new programming language. I used it for the first time to help me get another job earlier in the year. However, I have continued to solve 1 problem a night because what I realised is after 15+ years in the industry, I don't have a good grasp of some concepts anymore. I'm slowly getting better at identify types of problems and apply what could be the most efficient data structure/algorithm in solving the problem. Once I solve the problem I go have a look at the solutions to see a more efficient way of solving it and try to store it away in my memory banks for another day. The thing I don't like is when interviewer asks follow ups such as "Can you do the same solution but using O(1) space complexity". Unless the job has a restriction on running on limited hardware resources. I feel like it's unjustified asking such follow up questions because most of the time that is a very specific solution for the problem - or maybe I'm just not good enough to come up with such a solution yet.
jjav 4y ago
> They're biased, arbitrary, and often quite silly. And they've persisted for a half century. Half a century? Absolutely not. It's a recent phenomenon (in software jobs). All through the 90s and 00s it wasn't like this.
- mikelevins 4y ago
  For what it’s worth, it was like this in my interviews at Microsoft in the late 80s.
- curiousllama 4y ago
  The point is that leetcode is an instance of the class interview_riddles; the class has persisted for a half century.
gerash 4y ago
One big issue with these problems is that they are timed. So if for whatever reason you get stuck, stressed, distracted and take an extra 10m to reverse a linked list you're filtered out.
mhh__ 4y ago
If a trading job asks you a probability question they might be looking for you to be able to understand risk-neutrality. This is an important distinction because risk neutral pricing is a very important concept i.e. don't just try and memorize it.
WalterBright 4y ago
> you can't learn leetcode without learning to program A lot of people learn the jargon and sound like they know how to program, but don't. Failure to filter these out can be very expensive for a company. They have a strong incentive to ask for a programming demonstration to filter them out.
deleted 4y ago
[deleted]

tsuujin 4y ago

> Get used to 'em. No. I’ve spent the last year or so reinventing the hiring process at my tech company to expressly avoid algorithmic puzzles and leetcode nonsense, and I was able to do this because I patently refused to accept the status quo. You can do this too. Anyone can. I’m basically a moron and I managed to convince our talent team to radically change how we do things; if I can do it I feel like the bar is pretty damn low. The only real requirement is that enough of us simply refuse to accept how things are today. Right now is a fantastic time for the tech industry to adopt change because your talent recruiters are probably struggling to find and retain new developers and are almost certainly willing to listen to suggestions on how to stand out.

rodenmonte 4y ago
Would you be able to share the kinds of questions you ask and have had success with? :)
- tsuujin 4y ago
  We basically adopted the MINASWAN interview, which Jesse Spevack can explain much better than myself in his talk [here](https://youtube.com/watch?v=c4K-ORZmrGk&feature=share https://youtube.com/watch?v=c4K-ORZmrGk&feature=share). The overview is that for each candidate we spend 20 minutes reading through code we provide to them to demonstrate comprehension, and then we give them 45 minutes to pair with us on reimplementing that same code from scratch. What that code is doesn’t really matter, it’s more about getting a chance to work with them and start a conversation, and starting with trying to explain a provided example really smooths the way into the pair programming.
  - kyawzazaw 4y ago
    How much time and resources does it cost to successfully hire one candidate?
    - tsuujin 4y ago
      Substantially less than our previous process. We went from a process that took weeks to get through (multiple interviews, about an hour each, with a full code day at the end) to a two step process. Talent reaches out to the candidate and has a thirty or so minute chat to make sure the candidate meets basic hiring requirements, and then we have our MINASWAN process which is a single three hour interview, including two breaks for the candidate to get off camera and catch their breath. The participants are: - the candidate - a hiring manager - between two and four developers for pairing - an open invitation to the hiring team’s devs for a closing panel interview. The feedback we’ve received from candidates has been overwhelmingly positive, even for those who didn’t receive an offer.
  - erik_seaberg 4y ago
    > 45 minutes to pair with us Do you require pairing on real work? How do you handle candidates who need quiet to think? Going by the continual complaints about open plan offices, there seem to be a lot of us.
    - tsuujin 4y ago
deleted 4y ago
[deleted]
bluedevilzn 4y ago
> I’m basically a moron Google and other companies are actively trying to avoid hiring morons.
- tsuujin 4y ago
  I’m not sure if you’re just being snarky or you’re trying to make an actual point here, but I can tell you that this kind of commentary reinforces the egocentric interview process we currently suffer through. Solving puzzles doesn’t prove that you’re smart, and not memorizing them ahead doesn’t prove you can’t do the job. Unless you’re really on the edge of the industry—designing rockets for NASA or surgery tech or something—most dev jobs aren’t really all that hard, and we should stop pretending they are.
  - missedthecue 4y ago
    Solving complex riddles may not prove you're Einstein, but it's a pretty good filter for morons.
    - tsuujin 4y ago
      Disagree. I’m very good at puzzles.
      - fsckboy 4y ago
        then you shouldn't have said you're a moron. You seem somewhat contrary, which leads to its own problems, at least for me.
        tsuujin 4y ago
        Disagree. I’m highly agreeable.
  - bartread 4y ago
    > most dev jobs aren’t really all that hard, and we should stop pretending they are. I agree with you about GP's commentary, but I don't know that I agree with this statement. Getting something working is often relatively easy. Shipping v1.0 is often relatively easy. But it starts to get gnarly as you build out capabilities, add services, split concerns up, have to maintain compatibility with previous versions, dependencies multiply, the amount of data you're dealing with massively expands, and so on. Most problems have one or more inflection points, whether that's around performance, or scale, or volume of data, or whatever, that when you pass them make that problem substantially harder to solve. Still, these are all issues that come with a certain amount of success. Not necessarily crazy success: I'm just talking about the kind of traction that companies that grow to earn millions to tens of millions of dollars or pounds per annum experience. The really hard part of being a dev, of course, is knowing what the right thing is to build. Often, because users tend to struggle to articulate their needs, the only way to find out what to build is to start by building something that you know is probably going to be at least a bit wrong, if not massively wide of the mark, just to get some feedback. And then you have to iterate, sometimes quite painfully, towards an actually good solution from there. Of course, this isn't something you can assess with a leetcode interview. I don't hate interviews where the candidate is asked to write some code. I think writing code is a valid form of assessment because I've encountered enough jokers over the years who couldn't program if their life depended upon it - yet still manage to carry a job title like "software developer" - that I need some way of weeding them out of our hiring process. One reason for this is that I simply don't have gobs of spare cash to pay large salaries to people who are fundamentally incapable of doing the job they're asked to do. Note though that asking them to write code does not equate to leetcode. We'll generally give people access to an IDE containing a template project and common tooling they would use on a day to day basis in the job. We also select problems that have some relation to our systems rather than asking hardcore questions about algorithms and data structures: we give them internet access so they can look that stuff up if they need it to help them (just like the rest of us do in our day jobs). Cynically, a lot of interviewing I've seen over the years seems to be about the interviewer trying to appear to be the cleverest person in the room, and I think leetcode often falls into this category. I find this perverse and unhelpful but I guess these interviewers are just insecure, angry people.
valar_m 4y ago
So what'd you come up with?
- tsuujin 4y ago
  I answered this in another comment before I saw this, feel free to respond to it if you want to chat about it: https://news.ycombinator.com/item?id=31453571 https://news.ycombinator.com/item?id=31453571
deleted 4y ago
[deleted]
UncleOxidant 4y ago
> now is a fantastic time for the tech industry to adopt change because your talent recruiters are probably struggling to find and retain new developers Unfortunately, this will likely change much sooner and more rapidly then most of us expect. The music is stopping and chairs are about to be removed. It was great while it lasted, but all good things come to an end.
- tsuujin 4y ago
  I’m not sure I agree, but I’m positive this isn’t a barrier to adoption right now. Recruiters are really looking for an edge to provide differentiation, and “friendlier, faster process” is a big one.
  - danachow 4y ago
    What has changed in the past 20 years? Because this sounds like the same shit I’ve heard since entering the industry. And it isn’t like this topic is new at all.
- rejor121 4y ago
  Sure. Someday. Same thing has been said since the 90s
  - sorry_outta_gas 4y ago
    After working though the dotcom bust and the subprime fiasco it seems a bit dramatic although I'm also not beyond my means and have some savings this time (didn't last time and it got hairy) in general i worry more about other people in much worse situations that I'm unable to help
  - UncleOxidant 4y ago
    And it's happened a couple of times since the 90s.
ssalka 4y ago
Yeah, I've worked in tech 6 years now and never had to do Leetcode to get by in interviews. That being said, I never interviewed at FAANG. But many teams set a bar easier to pass than leetcode that still ensures good engineering skills
beej71 4y ago
> I’ve spent the last year or so reinventing the hiring process at my tech company to expressly avoid algorithmic puzzles and leetcode nonsense, and I was able to do this because I patently refused to accept the status quo. I think companies that break out of the leetcode habit are going to do well. There's a lot of great talent out there that's being passed over by these tests. If the job is to solve leetcode problems, by all means, test the candidates for that. If the job is to solve real life problems, there's almost certainly a better measure. I will never judge someone based on that kind of problem. I believe the data that results is just bad. Edit: I should add that leetcode is useful for developing programming and problem-solving skill. I've done tons of problems, myself, and have fun solving them... and learn from them. So I do recommend it for a challenge. But not for interviews.
- tsuujin 4y ago
  Strong agree with all of this. Ideally, interview questions should be directly related to the domain of the position. Show the candidate what they will actually be doing if they accept an offer. The whole process should be a two way conversation.
- stutsmansoft 4y ago
  > I think companies that break out of the leetcode habit are going to do well. > There's a lot of great talent out there that's being passed over by these tests. Agreed. And there's a lot of great talent that doesn't even want to try with some of these companies solely due to the hostile interview process.
  - kabdib 4y ago
    I recently took a year off, and started interviewing in March. I spent a fair amount of time in fear of interviewing, doing LeetCode pushups and feeling miserable about my performance, and wondering if I could swing retirement rather than go through another fucking hazing ritual. Excuse my language. I resolved up front not to submit to any kind of take-home test, proctoring software, or algorithmic nonsense unrelated to the actual job of shipping software. A polite "No thank you" was what I planned. But the plan was thwarted! I was pleasantly surprised by the technical interviews I actually got. They were mostly nicely constrained problems that were real-world and not algorithmically nasty. One was a little unintended "collaboration" in the form of helping a senior dev debug their own "what is wrong with this code?" exercise (it probably went smoother for the next candidate they interviewed). In short, it was actually kind of fun. I started a new dream job this week. At 61 this is no longer easy, but the company is enlightened enough to support me while I get up to speed, and it's fun to help mentor the folks just getting into the industry. There are decent companies out there. Hopefully the terrible ones will start getting a clue.
deltree7 4y ago
Only on the internet, that someone working for a cost-center division, building an piece of internal software used by 20 users, gets to lecture how a $2 Trillion Dollar, building multiple Billion real-world user products, generating > $500,000 per engineer profit should run their hiring process
- tsuujin 4y ago
  That’s making a lot of assumptions about who I am and what I do based on nothing.
serenitylater 4y ago
curiousllama 4y ago
FWIW, happy you're doing this! A better process would make so many peoples' lives better. The ONLY people who should "get used to 'em" are new/recent grads looking for a junior-ish IC job. For them, it's just a fact of life: they had to learn history & biology to get their CS degree; they have to learn leetcode to get a job. Interviewers should make a better process, as you're doing.
- tsuujin 4y ago
  Honestly, I think I would encourage junior devs to shop around before just accepting the leet code life. Unless they’re in dire need of income—in which case, do what you need to do—the kind of company willing to treat you like a game show contestant may not provide the best culture for learning and growth. If you can avoid the BS you should definitely do so.

diob 4y ago

The worst part is it's biased towards those who already have the time / security to devote to it, aka those from the upper class. Vicious cycle.

rockemsockem 4y ago
That bias is generally true for any education-based employment that requires a significant upfront investment.

rajup 4y ago

> My advice? Start memorizing the riddles. I don't have a strong opinion either way, I got with the Leetcode grind program for my current position, but I really wonder about this: is it really possible to memorize these questions? Last I checked Leetcode has over 2000 questions, anyone who can memorize the solutions to all those is some kind of genius savant and should be hired anyway. Or is memorizing meant in a different context here?

jjav 4y ago
> anyone who can memorize the solutions to all those is some kind of genius savant and should be hired anyway But that's the problem. Why should they be hired? The actual job will not consist of regurgitating those memorized solutions. I'm impressed by someone who can memorize 2000+ solutions, same as I'm impressed by the acrobats at Cirque du Soleil, but I don't want to hire from either group for a software engineering job because that's not what the job is about.
bulldog13 4y ago
Memorizing is meant in a different context. Ultimately the problems boil down into a few "types". So you are memorizing the types. https://dev.to/fahimulhaq/14-patterns-to-ace-any-coding-interview-question-d9g https://dev.to/fahimulhaq/14-patterns-to-ace-any-coding-inte... https://neetcode.io/ https://neetcode.io/
- curiousllama 4y ago
  As a sidenote: this holds true for other types of arbitrary-interview-riddles. There's only 3-5 "frameworks" you need to memorize/apply for consulting case interviews. Finance probability problems typically test one of ~a dozen prob/stat formulae + ability to multiply 3-digit numbers in your head. After all, it has to be manageable for the interviewers to make sure all the questions are roughly equivalent in difficulty.
bhavikkumar 4y ago
I have used hackerrank/leetcode previously just sporadically to learn a new programming language. I used it for the first time to help me get another job earlier in the year. However, I have continued to solve 1 problem a night because what I realised is after 15+ years in the industry, I don't have a good grasp of some concepts anymore. I'm slowly getting better at identify types of problems and apply what could be the most efficient data structure/algorithm in solving the problem. Once I solve the problem I go have a look at the solutions to see a more efficient way of solving it and try to store it away in my memory banks for another day. The thing I don't like is when interviewer asks follow ups such as "Can you do the same solution but using O(1) space complexity". Unless the job has a restriction on running on limited hardware resources. I feel like it's unjustified asking such follow up questions because most of the time that is a very specific solution for the problem - or maybe I'm just not good enough to come up with such a solution yet.

jjav 4y ago

> They're biased, arbitrary, and often quite silly. And they've persisted for a half century. Half a century? Absolutely not. It's a recent phenomenon (in software jobs). All through the 90s and 00s it wasn't like this.

mikelevins 4y ago
For what it’s worth, it was like this in my interviews at Microsoft in the late 80s.
curiousllama 4y ago
The point is that leetcode is an instance of the class interview_riddles; the class has persisted for a half century.

gerash 4y ago

One big issue with these problems is that they are timed. So if for whatever reason you get stuck, stressed, distracted and take an extra 10m to reverse a linked list you're filtered out.

mhh__ 4y ago

If a trading job asks you a probability question they might be looking for you to be able to understand risk-neutrality. This is an important distinction because risk neutral pricing is a very important concept i.e. don't just try and memorize it.

WalterBright 4y ago

> you can't learn leetcode without learning to program A lot of people learn the jargon and sound like they know how to program, but don't. Failure to filter these out can be very expensive for a company. They have a strong incentive to ask for a programming demonstration to filter them out.

deleted 4y ago

[deleted]