4 ms·

What’s your suggested alternative? Please remember that while some of us would do well and prefer some live pair programming or debugging sessions, it stresses

What’s your suggested alternative? Please remember that while some of us would do well and prefer some live pair programming or debugging sessions, it stresses the hell out of some folks and penalizes them unfairly. Take home tests penalizes people with families and other responsibilities and probably has a racial bias as well in countries where different races have different societal loads. In the end, even if these coding challenges might not reflect the actual work you do, they might still be predictive of success in the job, as much as any other method can be when we look for unbiased markers. This is similar to how the entrance exams to the IITs in india are pretty much completely discordant to what you actually end up having to know, the rigor and preparation you need to do ends up reasonably selecting for well performing students anyway. Not perfect though. Any system can be gamed but it works alright.

rmbyrro 5y ago
> they might still be predictive of success in the job Basing an assumption out of thin air like this, we can throw the opposite argument: 'they might be predictive of failure in the job'. Writers of bad code and choices mentioned by OP were likely hired out of a fantastic hacker rank score, and yet failed to produce good output.
synthos 5y ago
grinding leetcode is just as bad, if not worse, than a take-home test
- majormajor 5y ago
  Perhaps not everyone has to grind it so much. (I would wager they're the same people who do regularly find themselves thinking about computational and space complexity, and about using different datastructures and algorithms for problems, vs the ones who never see reason to!) A take home test requires spending free time for everyone. A whiteboard interview requires variable amounts of free time. I would wager that, on average, the people inside companies using these processes require less time to "grind leetcode" than the people outside those companies do. You gotta be able to convince the folks on the inside, not the ones on the outside. To them, it being hard to "grind" might even seem like a good thing! "It's hard to cram for this compared to other sorts of tests!"
  - erik_seaberg 5y ago
    I’ve passed almost every interview loop I’ve had without ever studying leetcode. I have a (maybe uncharitable) suspicion that people who find they need to study are spending all their time at work gluing software together without actually writing any from scratch.
    - Apocryphon 5y ago
      Seems like most of the industry is made up of such roles these days.
    - saagarjha 5y ago
      (Speaking as someone who uses theoretical computer science fairly often) I wonder what the solution to this would be, honestly. It seems like there are a lot of jobs where we just expect that gluing things together is an acceptable, productive, necessary task to be done. Should we interview for these differently? Can we avoid a stigma being attached to this (productive) work?
      - erik_seaberg 5y ago
        I think we should automate this work away, or at least figure out what’s preventing that. Boilerplate is a problem, not a good investment of human effort.
    - rakejake 5y ago
      Knowing the data structures and algorithms is different from actually passing these interviews. Interviews are designed in a way that you are going to have to commit a lot of stuff to memory that you would have just looked up if you were just coding up a problem. A common example brought up here on HN is binary search. It is usually simple to figure out that a problem requires Binary search and even which variant. But the differences between the variant are really small and you can very easily make a mistake when implementing it. I have passed enough of these interviews myself and used to think similarly (all you need to do is learn the fundamentals and the rest will follow) but my hit rate went up substantially when I realized that I had to do the same problem again and again and it almost became part of my muscle memory. Looking at a new problem, analyzing it and then coming up with a novel solution takes a lot of time, and there are several mistakes you can make on the way. The interviewing culture today is to reject "false positives" so anything apart from a perfectly coded response results in a mixed/negative response. This whole leetcode thing is a farce and has to end. Let's be honest, the Google guys used it because they wanted "like-minded people". In short, they discriminated based on their own criteria and successfully brushed it off as a "fair and unbiased" way of selecting people.
- filoleg 5y ago
  > grinding leetcode is just as bad, if not worse, than a take-home test For leetcode, I can study once for a week or so, and then do a bunch of interviews at different companies, where each onsite is gonna take me a single day (4-5 hours or so). For take-home projects, it usually takes way more time than that (about a whole week of a few hours every day). And it doesn't reduce the more I study or do those projects. So no, thank you, I would rather take a single day to do a full loop with a company, as opposed to spending a week doing the same. Back when I was heavily interviewing last year, I could easily do leetcode interviews with about 1-2 companies a week without breaking a sweat. I did a take-home project a couple of times, and I am never going to do it again. The time sink on take-home projects is insane, and it is a much weaker signal. Given a lot of people here heard those stories last year where people were even trying to cheat on leetcode interviews (by asking other people to take those for them, and they eventually got caught), I imagine the cheating on take-home project is much more common and is much more difficult to detect.
mkl95 5y ago
Take home OR coding challenges is a false dichotomy. > In the end, even if these coding challenges might not reflect the actual work you do, they might still be predictive of success in the job They are snake oil. You cannot predict success at some job by asking candidates to prove their ability at something that is only tangentially related to the actual job.
- barry-cotter 5y ago
  General mental ability is general, that’s the point. > The Validity and Utility of Selection Methods in Personnel Psychology: Practical and Theoretical Implications of 100 Years of Research Findings > On the basis of meta-analytic findings, this paper presents the validity of 31 procedures for predicting job performance and the validity of paired combinations of general mental ability (GMA) and the 29 other selection procedures. Similar analyses are presented for 16 predictors of performance in job training programs. Overall, the two combinations with the highest multivariate validity and utility for predicting job performance were GMA plus an integrity test (mean validity of .78) and GMA plus a structured interview (mean validity of .76). Similar results were obtained for these two combinations in the prediction of performance in job training programs. A further advantage of these two combinations is that they can be used for both entry level hiring and selection of experienced job applicants. The practical utility implications of these summary findings are substantial. The implications of these research findings for the development of theories of job performance are discussed.
  - cutenewt 5y ago
    Do you have any insights on what kind of "integrity test" they used?
  - mkl95 5y ago
    > General mental ability is general, that’s the point I've seen PhDs melt under pressure at two different jobs. Which tells me that an exceptional IQ or work ethic doesn't necessarily equate with success in the industry. Those two people had something in common, and it was their poor communication skills, both input and output. If your brain cannot process some coworkers feedback efficiently and it cannot spit out feedback efficiently, the logical / mathematical side of your brain is not going to make up for it.
gwbas1c 5y ago
> What’s your suggested alternative? I generally give (mostly) simple questions where I explain how to solve them. Assuming you're a competent programmer in the language we're dealing with, you should be able to figure out how to solve the problem in your head in a minute or two. The trick is that I'm gauging accumulated skill, not memorized algorithms. For example, I'll explain how to use a data reader, explain the constructor for a simple object, and provide a SQL statement. Then you need to write the code that reads a few values from the data reader and constructs and object. After that we discuss edge cases and error handling, and if you should throw an exception or return null. Easy-peasy! (And if it's not easy-peasy, you really shouldn't be here.) Another example: I'll explain an older API for running a lambda in a background thread, and then an API for running a lambda in the main (UI) thread. (Mac, Windows, iOS, and Android all have the same threading model for their UI.) Easy-peasy if you understand basic scoping and threading. (And if it's not easy-peasy, you shouldn't be working in any job where you have to deal with threads.) In both cases, the candidate can ask any many questions as they want, and I'll happily steer a candidate. The point is, I'm not relying on memorized algorithms, or requiring prep. What I'm doing is relying on, and judging accumulated skill. Only a novice will have trouble with my questions; and I wouldn't use these questions when hiring interns or entry-level engineers. If you've programmed with a database before, you should understand the basic concept of a data reader. If you've programmed for awhile, you should understand scope. And, if you've programmed with threads, you should understand running a lambda on another thread. (You probably should understand lambdas, too.)
- webmaven 5y ago
  > I generally give (mostly) simple questions where I explain how to solve them. Assuming you're a competent programmer in the language we're dealing with, you should be able to figure out how to solve the problem in your head in a minute or two. The trick is that I'm gauging accumulated skill, not memorized algorithms. That's a decent way of interviewing. It depends on the skill of the interviewer though, I can easily imagine someone handling it very poorly.
game_the0ry 5y ago
> What’s your suggested alternative? In my experience, any alternative to leetcode provides a better signal-to-noise ratio. You are better off asking trivia questions. Additionally, this is the common narrative among leetcode advocates - "If no leetcode, then what?" As a hiring manager, you think harder and do better, that's what. > Please remember that while some of us would do well and prefer some live pair programming or debugging sessions, it stresses the hell out of some folks and penalizes them unfairly. So does leetcode. And a candidate that is truly a good fit for the role would be more at ease with the interview than if they saw a leetcode question they haven't seen before. > Take home tests penalizes people with families and other responsibilities... So does studying for leetcode for hours. > ...and probably has a racial bias as well in countries where different races have different societal loads. Share some sources before making a claim this ridiculous. > In the end, even if these coding challenges might not reflect the actual work you do, they might still be predictive of success in the job, as much as any other method can be when we look for unbiased markers. In my 6-ish years of experience, this is false. I have actually tested this theory in practice, and through my anecdotal experience, leetcode is a poor signal for job performance. I can usually usually accurately screen a candidate for success in about 45 mins. And, unlike leetcode, you can't pretend like you haven't seen the question before, bc I can push the candidate to their limit, which is where you will find hire / no-hire signals. I love talking about this stuff, but I find that my peers engineering peers do not give a shit and would prefer to stay in leetcode hell.
- whimsicalism 5y ago
  > You are better off asking trivia questions Bet you most people would disagree with just trivia. > So does studying for leetcode for hours. You honestly do not have to do this to pass the LC interview. I didn't. Certainly not as much as a takehome test.
  - game_the0ry 5y ago
    > You honestly do not have to do this to pass the LC interview. I didn't. You were able to prep for 2-4 hours and still pass LC interviews? I find this hard to believe given that I, and peers I know, took much longer to prep.
deleted 5y ago
[deleted]
rakejake 5y ago
The system works "alright" if the end goal of the system is to whittle down candidates in a 100:1 ratio. As someone who has been through both the JEE nonsense and passed FAANG interviews, I really question if this is at all necessary. In the case of JEE, kids spend pretty much anywhere from 2-6 of their teen years preparing for the exam. Leetcoding on an average, takes a few weeks to a few months depending on the person. And you're going to have to repeat the prep every time you interview (maybe spending less time than you did in the beginning but the ramp up takes time). I see only one "scalable" solution to this problem: Something like a bar exam that people can take at regular intervals. This could have different levels that could unlock different jobs. Companies require that you pass the exam at a certain level and if there are too many applicants, a lottery picks the lucky numbers.

rmbyrro 5y ago

> they might still be predictive of success in the job Basing an assumption out of thin air like this, we can throw the opposite argument: 'they might be predictive of failure in the job'. Writers of bad code and choices mentioned by OP were likely hired out of a fantastic hacker rank score, and yet failed to produce good output.

synthos 5y ago

grinding leetcode is just as bad, if not worse, than a take-home test

majormajor 5y ago
Perhaps not everyone has to grind it so much. (I would wager they're the same people who do regularly find themselves thinking about computational and space complexity, and about using different datastructures and algorithms for problems, vs the ones who never see reason to!) A take home test requires spending free time for everyone. A whiteboard interview requires variable amounts of free time. I would wager that, on average, the people inside companies using these processes require less time to "grind leetcode" than the people outside those companies do. You gotta be able to convince the folks on the inside, not the ones on the outside. To them, it being hard to "grind" might even seem like a good thing! "It's hard to cram for this compared to other sorts of tests!"
- erik_seaberg 5y ago
  I’ve passed almost every interview loop I’ve had without ever studying leetcode. I have a (maybe uncharitable) suspicion that people who find they need to study are spending all their time at work gluing software together without actually writing any from scratch.
  - Apocryphon 5y ago
    Seems like most of the industry is made up of such roles these days.
  - saagarjha 5y ago
    (Speaking as someone who uses theoretical computer science fairly often) I wonder what the solution to this would be, honestly. It seems like there are a lot of jobs where we just expect that gluing things together is an acceptable, productive, necessary task to be done. Should we interview for these differently? Can we avoid a stigma being attached to this (productive) work?
    - erik_seaberg 5y ago
      I think we should automate this work away, or at least figure out what’s preventing that. Boilerplate is a problem, not a good investment of human effort.
  - rakejake 5y ago
    Knowing the data structures and algorithms is different from actually passing these interviews. Interviews are designed in a way that you are going to have to commit a lot of stuff to memory that you would have just looked up if you were just coding up a problem. A common example brought up here on HN is binary search. It is usually simple to figure out that a problem requires Binary search and even which variant. But the differences between the variant are really small and you can very easily make a mistake when implementing it. I have passed enough of these interviews myself and used to think similarly (all you need to do is learn the fundamentals and the rest will follow) but my hit rate went up substantially when I realized that I had to do the same problem again and again and it almost became part of my muscle memory. Looking at a new problem, analyzing it and then coming up with a novel solution takes a lot of time, and there are several mistakes you can make on the way. The interviewing culture today is to reject "false positives" so anything apart from a perfectly coded response results in a mixed/negative response. This whole leetcode thing is a farce and has to end. Let's be honest, the Google guys used it because they wanted "like-minded people". In short, they discriminated based on their own criteria and successfully brushed it off as a "fair and unbiased" way of selecting people.
filoleg 5y ago
> grinding leetcode is just as bad, if not worse, than a take-home test For leetcode, I can study once for a week or so, and then do a bunch of interviews at different companies, where each onsite is gonna take me a single day (4-5 hours or so). For take-home projects, it usually takes way more time than that (about a whole week of a few hours every day). And it doesn't reduce the more I study or do those projects. So no, thank you, I would rather take a single day to do a full loop with a company, as opposed to spending a week doing the same. Back when I was heavily interviewing last year, I could easily do leetcode interviews with about 1-2 companies a week without breaking a sweat. I did a take-home project a couple of times, and I am never going to do it again. The time sink on take-home projects is insane, and it is a much weaker signal. Given a lot of people here heard those stories last year where people were even trying to cheat on leetcode interviews (by asking other people to take those for them, and they eventually got caught), I imagine the cheating on take-home project is much more common and is much more difficult to detect.

mkl95 5y ago

Take home OR coding challenges is a false dichotomy. > In the end, even if these coding challenges might not reflect the actual work you do, they might still be predictive of success in the job They are snake oil. You cannot predict success at some job by asking candidates to prove their ability at something that is only tangentially related to the actual job.

barry-cotter 5y ago
General mental ability is general, that’s the point. > The Validity and Utility of Selection Methods in Personnel Psychology: Practical and Theoretical Implications of 100 Years of Research Findings > On the basis of meta-analytic findings, this paper presents the validity of 31 procedures for predicting job performance and the validity of paired combinations of general mental ability (GMA) and the 29 other selection procedures. Similar analyses are presented for 16 predictors of performance in job training programs. Overall, the two combinations with the highest multivariate validity and utility for predicting job performance were GMA plus an integrity test (mean validity of .78) and GMA plus a structured interview (mean validity of .76). Similar results were obtained for these two combinations in the prediction of performance in job training programs. A further advantage of these two combinations is that they can be used for both entry level hiring and selection of experienced job applicants. The practical utility implications of these summary findings are substantial. The implications of these research findings for the development of theories of job performance are discussed.
- cutenewt 5y ago
  Do you have any insights on what kind of "integrity test" they used?
- mkl95 5y ago
  > General mental ability is general, that’s the point I've seen PhDs melt under pressure at two different jobs. Which tells me that an exceptional IQ or work ethic doesn't necessarily equate with success in the industry. Those two people had something in common, and it was their poor communication skills, both input and output. If your brain cannot process some coworkers feedback efficiently and it cannot spit out feedback efficiently, the logical / mathematical side of your brain is not going to make up for it.

gwbas1c 5y ago

> What’s your suggested alternative? I generally give (mostly) simple questions where I explain how to solve them. Assuming you're a competent programmer in the language we're dealing with, you should be able to figure out how to solve the problem in your head in a minute or two. The trick is that I'm gauging accumulated skill, not memorized algorithms. For example, I'll explain how to use a data reader, explain the constructor for a simple object, and provide a SQL statement. Then you need to write the code that reads a few values from the data reader and constructs and object. After that we discuss edge cases and error handling, and if you should throw an exception or return null. Easy-peasy! (And if it's not easy-peasy, you really shouldn't be here.) Another example: I'll explain an older API for running a lambda in a background thread, and then an API for running a lambda in the main (UI) thread. (Mac, Windows, iOS, and Android all have the same threading model for their UI.) Easy-peasy if you understand basic scoping and threading. (And if it's not easy-peasy, you shouldn't be working in any job where you have to deal with threads.) In both cases, the candidate can ask any many questions as they want, and I'll happily steer a candidate. The point is, I'm not relying on memorized algorithms, or requiring prep. What I'm doing is relying on, and judging accumulated skill. Only a novice will have trouble with my questions; and I wouldn't use these questions when hiring interns or entry-level engineers. If you've programmed with a database before, you should understand the basic concept of a data reader. If you've programmed for awhile, you should understand scope. And, if you've programmed with threads, you should understand running a lambda on another thread. (You probably should understand lambdas, too.)

webmaven 5y ago
> I generally give (mostly) simple questions where I explain how to solve them. Assuming you're a competent programmer in the language we're dealing with, you should be able to figure out how to solve the problem in your head in a minute or two. The trick is that I'm gauging accumulated skill, not memorized algorithms. That's a decent way of interviewing. It depends on the skill of the interviewer though, I can easily imagine someone handling it very poorly.

game_the0ry 5y ago

> What’s your suggested alternative? In my experience, any alternative to leetcode provides a better signal-to-noise ratio. You are better off asking trivia questions. Additionally, this is the common narrative among leetcode advocates - "If no leetcode, then what?" As a hiring manager, you think harder and do better, that's what. > Please remember that while some of us would do well and prefer some live pair programming or debugging sessions, it stresses the hell out of some folks and penalizes them unfairly. So does leetcode. And a candidate that is truly a good fit for the role would be more at ease with the interview than if they saw a leetcode question they haven't seen before. > Take home tests penalizes people with families and other responsibilities... So does studying for leetcode for hours. > ...and probably has a racial bias as well in countries where different races have different societal loads. Share some sources before making a claim this ridiculous. > In the end, even if these coding challenges might not reflect the actual work you do, they might still be predictive of success in the job, as much as any other method can be when we look for unbiased markers. In my 6-ish years of experience, this is false. I have actually tested this theory in practice, and through my anecdotal experience, leetcode is a poor signal for job performance. I can usually usually accurately screen a candidate for success in about 45 mins. And, unlike leetcode, you can't pretend like you haven't seen the question before, bc I can push the candidate to their limit, which is where you will find hire / no-hire signals. I love talking about this stuff, but I find that my peers engineering peers do not give a shit and would prefer to stay in leetcode hell.

whimsicalism 5y ago
> You are better off asking trivia questions Bet you most people would disagree with just trivia. > So does studying for leetcode for hours. You honestly do not have to do this to pass the LC interview. I didn't. Certainly not as much as a takehome test.
- game_the0ry 5y ago
  > You honestly do not have to do this to pass the LC interview. I didn't. You were able to prep for 2-4 hours and still pass LC interviews? I find this hard to believe given that I, and peers I know, took much longer to prep.

deleted 5y ago

[deleted]

rakejake 5y ago

The system works "alright" if the end goal of the system is to whittle down candidates in a 100:1 ratio. As someone who has been through both the JEE nonsense and passed FAANG interviews, I really question if this is at all necessary. In the case of JEE, kids spend pretty much anywhere from 2-6 of their teen years preparing for the exam. Leetcoding on an average, takes a few weeks to a few months depending on the person. And you're going to have to repeat the prep every time you interview (maybe spending less time than you did in the beginning but the ramp up takes time). I see only one "scalable" solution to this problem: Something like a bar exam that people can take at regular intervals. This could have different levels that could unlock different jobs. Companies require that you pass the exam at a certain level and if there are too many applicants, a lottery picks the lucky numbers.