5 ms·

I wonder ten years from now how common LeetCode like interviews are. These types of interviews favor those who have the luxury of ample time to prep for difficu

by cebert 6y ago

I wonder ten years from now how common LeetCode like interviews are. These types of interviews favor those who have the luxury of ample time to prep for difficult interviews and aren’t representative of most daily working environments. This process fails to consider candidates that would be good fits. When I help with interviews, I place much more values on communication skills, teamwork, mentorship, and a general passion for technology.

onion2k 6y ago
These types of interviews favor those who have the luxury of ample time to prep for difficult interviews... Interviews that test for anything that isn't directly related to the job the candidate will be doing are essentially codified discrimination - the expectation that someone will have a skill or significant knowledge outside of the job itself is effectively a way to filter out candidates based on arbitrary criteria even if they are capable of doing the work. In other words, Leetcode interviews favoring people with lots of spare time is by design, because that's who companies that use Leetcode want to hire. There is little reason to believe that will change.
- EvilEy3 6y ago
  Nobody obliged to give you work. They gave you a task and you couldn't solve it, fair and square. I can stretch your logic even further that giving BE task to FE person is a discrimination because they don't have luxury to work on BE. Why do we discriminate against QA people who don't have luxury to work on dev jobs? Why do we discriminate against people who don't work as developers at all?
  - onion2k 6y ago
    Asking someone whether or not they can do the job isn't discrimination. Asking someone if they know something basically unrelated to the job might well be. It could be designed to filter out people who wouldn't know that thing rather than filter in people who'd be better at the job. What is that if it isn't discrimination?
    - EvilEy3 6y ago
      Having algorithmic knowledge for a job is like having a common sense. You wouldn't hire someone who can't think, would you?
- 988747 6y ago
  That's one way of looking at it. But there's also another side of it: this type of interviews let you change career path. Imagine that you're run-of-the-mill java programmer, but you'd like to dive into Machine Learning, or BlockChain, or whatever. Some companies will require you to have 3 years of previous experience before considering you for such job. Others will give you a Leetcode interview to ensure that you're smart, and then let you learn the actual tech stack on the job. Also, Leetcode problems might be removed from everyday development work, but most of us did learn those things at some point, i.e. in college, so asking them in the interview kind of makes sense, it's kind of "common denominator" for all programmers.
  - pjmlp 6y ago
    That is wishful thinking in most cases, because unless you are targeting a startup without ageism agenda, unless the techonology is listed as something that you actually worked on (side projects don't count), the CV won't survive HR review.
raffraffraff 6y ago
Hiring is hard. It takes serious effort to interview someone and (i) get enough confidence in them to make an offer and (ii) make them want to accept the offer. LeetCode seems to have become accepted by candidates as a way to do (1), leaving the interviewer more time for (2). At least, that how I assume people think it works. In reality, hiring is just hard, and if you lean too hard on shortcuts like LeetCode, you come across as lazy, and you end up hiring LeetCode assholes who you catch doing LeetCode during work hours "to stay sharp". One of the most useless team members I ever worked with was good at code challenges but terrible at real work because he didn't care. He wasn't invested in working on the actual problems we faced as a company or as a team. When we had an opening for an infrastructure engineer I created a handful of gitlab projects (terraform, puppet, python) and put some effort into building some baseline infrastructure. I allowed the candidate to choose one to work on, and then gave them a real world challenge. Not some tricksy bullshit to catch them out, just a realistic task they might encounter. They were given access to an environment where they could run the code. So at the end, I had a runnable merge request to review. Why? Because, to me, the purpose of a code challenge isn't to find the top 10%, it's to weed out the bullshitters. The rest is about figuring out what makes them tick, whether or not they're a good personality fit etc.
EvilEy3 6y ago
> This process fails to consider candidates that would be good fits. Not to dismiss your opinion, but where are the proofs?
sumtechguy 6y ago
I do not think they are going away. They are a filter some like to use. I personally use a dead simple 'leetcode' style program because I want to see they have the basics and can communicate them. I have had to filter more than a few people just because of that. If you can not handle some simple if's and for loops you are in for some real trouble later on. Sometimes they will come in and bust on through it quickly. Which actually helps me decide. Because I can then say 'oh you got through that semi quickly which site/book did you learn from?' That opens up what they know and gives me a good handle on how they are technically. I can then move quickly on to 'let them brag about previous work'. That shows if they were passionate for or was it just a job to grind out. Some cases it matters others not so much. If they come in and really give it a good try but struggle a bit and can say why I may recommend making them a bit more junior and pairing them with someone. I also do not see it going away. I recently proctored some classes in my org. By the time the 'class' was done most had not bothered to even do 1 or 2 chapters. It was mostly just watching a 20-30 min video with whatever level of homework you wanted. I watched many of them for a few months after. The ones who bashed it all out were ones who tended to be tech leads and suggesting better things to happen.
- phist_mcgee 6y ago
  Dude come on... 1. You seem to think that your interview version of basic concept of 'simple ifs and for loops' is the base tier of programming. It's not man, everyone has their blindspots and you are selecting for candidates who are most similar to you. 2. You display hubris in your skills test by assuming that people who can brag the most are somehow more qualified than those who are more humble. Protip, people who code outside of work are not better developers. They are just enterained by their work skills in their personal time. 3. You display immense superiority claiming that your 'class' could not achieve what you wanted them to achieve. You attach meaning to this result. Not many people really want to study at work.
  - sumtechguy 6y ago
    1. it is the base. If you can not do that you have more learning to do. I have seen many fail it. I am nice about it but they just need more training. Most of they type of code they will be writing is little more than enterprise glue code. It is not that complex but it takes a bit of logic skill and base coding skills to do. It can help me help them with what sort of training they need. 2. The interview is not about the code. I want to see them in action and see how personable they are (a grump/huckster will ruin a team). I usually have very little time with them so the test has to be simple (something someone who is semi competent can do in 10 mins). That they are studying outside shows they are at least willing to do the work (and a bonus and helps shortcut many things). Learning to do things is usually part of the job. I do not expect them to do it outside of work. But it shows passion if they do (which is not a bad thing but is sometimes needed to grind out more glue code). I am usually more interested in what they used to work on and can they describe what they did. I do not even really care what the thing is. I want them to explain it to me. Explaining what is going on is part of the job many times. As in 'hey so and so wants a powerpoint presentation of what you have been working on for the past 3 months'. Some are good at it many are terrible at it. I am not looking for slick presenters but people who understand what is going on and show that they can do it. Interviews are about time management too. So you have usually 40-70 mins to decide if someone is worth it. You have to divvy up that time into chunks. That is on the interviewer. I usually spend the first few mins just trying to calm the person down. Then the next few with a semi simple test and explanation. The rest of the time is them showing off and hopefully asking questions about the job (not all do). Them not interviewing me shows something too. 3. The whole class was voluntary. I could have snapped the whip and made them do it. But that was not the point of the class. It was to be a group thing where we learned from each other. It was up front that you can do this on the clock or off. It was up to them. It was very free form. I do not think it was too much to ask them to watch some training videos for a framework they were going to soon be using? My 'meaning' that I attached was many do not want to put in the work but still reap the reward. Honestly it kind of shocked me the numbers. It was not like a couple of people dropped out. It was 95% of them. All of the other people helping with these similar classes had the similar results. My 'bar' for them was to watch 1 video per week over 12 weeks (for 9 videos) and some (optional) simple code test. Is that hubris? I was not expecting much at all. 'Not many people really want to study at work' Well then that will be a problem for many. If both 'do not want to study outside of work' and 'do not want to study at work' are both true you will find your skills rusty and long term unable to do the job. I have watched it happen over and over. At some point the tech stack will change. You will need to learn it. I can honestly say I have not gone many days in my career learning something. Reading docs, reading tutorials, watching vids, classes, prototypes, whatever.
jeffreyrogers 6y ago
It's not that different than lawyers needing to take the Bar exam (have to study on your own, and not all of it covered in school), or doctors having to pass boards. In both those fields practitioners spend a lot of time outside of "work" preparing. There will always be some sort of arbitrary selection screen as long as there are more people who want these high paying jobs than there are actual high paying jobs.
- Taylor_OD 6y ago
  I really don't know but isnt the bar generally the same types of questions every year? Like the SAT? It feels like preping for interviews is hard in part because you could be asked anything from reverse a doubly linked list to design facebook. If it was a smaller set of questions it would be a lot easier to study for.
- walto2 6y ago
  In software you do this every time you change jobs, and the randomness of the process ends up dictating which company you work at. As an attorney, when you change jobs you've already passed the bar.
vladimirralev 6y ago
Don't count on it going away ever. The programming languages/frameworks landscape is set to explode. It won't be possible to hire people based on experience with you specific languages and frameworks. The only equaliser is core knowledge - algos, data structures, OSes and design.

by cebert 6y ago

onion2k 6y ago

These types of interviews favor those who have the luxury of ample time to prep for difficult interviews... Interviews that test for anything that isn't directly related to the job the candidate will be doing are essentially codified discrimination - the expectation that someone will have a skill or significant knowledge outside of the job itself is effectively a way to filter out candidates based on arbitrary criteria even if they are capable of doing the work. In other words, Leetcode interviews favoring people with lots of spare time is by design, because that's who companies that use Leetcode want to hire. There is little reason to believe that will change.

EvilEy3 6y ago
Nobody obliged to give you work. They gave you a task and you couldn't solve it, fair and square. I can stretch your logic even further that giving BE task to FE person is a discrimination because they don't have luxury to work on BE. Why do we discriminate against QA people who don't have luxury to work on dev jobs? Why do we discriminate against people who don't work as developers at all?
- onion2k 6y ago
  Asking someone whether or not they can do the job isn't discrimination. Asking someone if they know something basically unrelated to the job might well be. It could be designed to filter out people who wouldn't know that thing rather than filter in people who'd be better at the job. What is that if it isn't discrimination?
  - EvilEy3 6y ago
    Having algorithmic knowledge for a job is like having a common sense. You wouldn't hire someone who can't think, would you?
988747 6y ago
That's one way of looking at it. But there's also another side of it: this type of interviews let you change career path. Imagine that you're run-of-the-mill java programmer, but you'd like to dive into Machine Learning, or BlockChain, or whatever. Some companies will require you to have 3 years of previous experience before considering you for such job. Others will give you a Leetcode interview to ensure that you're smart, and then let you learn the actual tech stack on the job. Also, Leetcode problems might be removed from everyday development work, but most of us did learn those things at some point, i.e. in college, so asking them in the interview kind of makes sense, it's kind of "common denominator" for all programmers.
- pjmlp 6y ago
  That is wishful thinking in most cases, because unless you are targeting a startup without ageism agenda, unless the techonology is listed as something that you actually worked on (side projects don't count), the CV won't survive HR review.

raffraffraff 6y ago

Hiring is hard. It takes serious effort to interview someone and (i) get enough confidence in them to make an offer and (ii) make them want to accept the offer. LeetCode seems to have become accepted by candidates as a way to do (1), leaving the interviewer more time for (2). At least, that how I assume people think it works. In reality, hiring is just hard, and if you lean too hard on shortcuts like LeetCode, you come across as lazy, and you end up hiring LeetCode assholes who you catch doing LeetCode during work hours "to stay sharp". One of the most useless team members I ever worked with was good at code challenges but terrible at real work because he didn't care. He wasn't invested in working on the actual problems we faced as a company or as a team. When we had an opening for an infrastructure engineer I created a handful of gitlab projects (terraform, puppet, python) and put some effort into building some baseline infrastructure. I allowed the candidate to choose one to work on, and then gave them a real world challenge. Not some tricksy bullshit to catch them out, just a realistic task they might encounter. They were given access to an environment where they could run the code. So at the end, I had a runnable merge request to review. Why? Because, to me, the purpose of a code challenge isn't to find the top 10%, it's to weed out the bullshitters. The rest is about figuring out what makes them tick, whether or not they're a good personality fit etc.

EvilEy3 6y ago

> This process fails to consider candidates that would be good fits. Not to dismiss your opinion, but where are the proofs?

sumtechguy 6y ago

I do not think they are going away. They are a filter some like to use. I personally use a dead simple 'leetcode' style program because I want to see they have the basics and can communicate them. I have had to filter more than a few people just because of that. If you can not handle some simple if's and for loops you are in for some real trouble later on. Sometimes they will come in and bust on through it quickly. Which actually helps me decide. Because I can then say 'oh you got through that semi quickly which site/book did you learn from?' That opens up what they know and gives me a good handle on how they are technically. I can then move quickly on to 'let them brag about previous work'. That shows if they were passionate for or was it just a job to grind out. Some cases it matters others not so much. If they come in and really give it a good try but struggle a bit and can say why I may recommend making them a bit more junior and pairing them with someone. I also do not see it going away. I recently proctored some classes in my org. By the time the 'class' was done most had not bothered to even do 1 or 2 chapters. It was mostly just watching a 20-30 min video with whatever level of homework you wanted. I watched many of them for a few months after. The ones who bashed it all out were ones who tended to be tech leads and suggesting better things to happen.

phist_mcgee 6y ago
Dude come on... 1. You seem to think that your interview version of basic concept of 'simple ifs and for loops' is the base tier of programming. It's not man, everyone has their blindspots and you are selecting for candidates who are most similar to you. 2. You display hubris in your skills test by assuming that people who can brag the most are somehow more qualified than those who are more humble. Protip, people who code outside of work are not better developers. They are just enterained by their work skills in their personal time. 3. You display immense superiority claiming that your 'class' could not achieve what you wanted them to achieve. You attach meaning to this result. Not many people really want to study at work.
- sumtechguy 6y ago
  1. it is the base. If you can not do that you have more learning to do. I have seen many fail it. I am nice about it but they just need more training. Most of they type of code they will be writing is little more than enterprise glue code. It is not that complex but it takes a bit of logic skill and base coding skills to do. It can help me help them with what sort of training they need. 2. The interview is not about the code. I want to see them in action and see how personable they are (a grump/huckster will ruin a team). I usually have very little time with them so the test has to be simple (something someone who is semi competent can do in 10 mins). That they are studying outside shows they are at least willing to do the work (and a bonus and helps shortcut many things). Learning to do things is usually part of the job. I do not expect them to do it outside of work. But it shows passion if they do (which is not a bad thing but is sometimes needed to grind out more glue code). I am usually more interested in what they used to work on and can they describe what they did. I do not even really care what the thing is. I want them to explain it to me. Explaining what is going on is part of the job many times. As in 'hey so and so wants a powerpoint presentation of what you have been working on for the past 3 months'. Some are good at it many are terrible at it. I am not looking for slick presenters but people who understand what is going on and show that they can do it. Interviews are about time management too. So you have usually 40-70 mins to decide if someone is worth it. You have to divvy up that time into chunks. That is on the interviewer. I usually spend the first few mins just trying to calm the person down. Then the next few with a semi simple test and explanation. The rest of the time is them showing off and hopefully asking questions about the job (not all do). Them not interviewing me shows something too. 3. The whole class was voluntary. I could have snapped the whip and made them do it. But that was not the point of the class. It was to be a group thing where we learned from each other. It was up front that you can do this on the clock or off. It was up to them. It was very free form. I do not think it was too much to ask them to watch some training videos for a framework they were going to soon be using? My 'meaning' that I attached was many do not want to put in the work but still reap the reward. Honestly it kind of shocked me the numbers. It was not like a couple of people dropped out. It was 95% of them. All of the other people helping with these similar classes had the similar results. My 'bar' for them was to watch 1 video per week over 12 weeks (for 9 videos) and some (optional) simple code test. Is that hubris? I was not expecting much at all. 'Not many people really want to study at work' Well then that will be a problem for many. If both 'do not want to study outside of work' and 'do not want to study at work' are both true you will find your skills rusty and long term unable to do the job. I have watched it happen over and over. At some point the tech stack will change. You will need to learn it. I can honestly say I have not gone many days in my career learning something. Reading docs, reading tutorials, watching vids, classes, prototypes, whatever.

jeffreyrogers 6y ago

It's not that different than lawyers needing to take the Bar exam (have to study on your own, and not all of it covered in school), or doctors having to pass boards. In both those fields practitioners spend a lot of time outside of "work" preparing. There will always be some sort of arbitrary selection screen as long as there are more people who want these high paying jobs than there are actual high paying jobs.

Taylor_OD 6y ago
I really don't know but isnt the bar generally the same types of questions every year? Like the SAT? It feels like preping for interviews is hard in part because you could be asked anything from reverse a doubly linked list to design facebook. If it was a smaller set of questions it would be a lot easier to study for.
walto2 6y ago
In software you do this every time you change jobs, and the randomness of the process ends up dictating which company you work at. As an attorney, when you change jobs you've already passed the bar.

vladimirralev 6y ago

Don't count on it going away ever. The programming languages/frameworks landscape is set to explode. It won't be possible to hire people based on experience with you specific languages and frameworks. The only equaliser is core knowledge - algos, data structures, OSes and design.