9 ms·

I really wish there was more work done in changing the terrible interview culture in software, instead of doubling-down on bad practices with low signal-to-nois

by dvt 6y ago

I really wish there was more work done in changing the terrible interview culture in software, instead of doubling-down on bad practices with low signal-to-noise ratios. It's clear that whiteboarding and impromptu coding have little-to-nothing to do with real-life coding capability (let alone with generating real business value), while actual signals (e.g.: GitHub projects, OSS contributions, StackOverflow, take-homes, etc.) are ignored by interviewers. I've interviewed dozens of engineers and it's always been a miserable experience because my hiring manager (or other senior engineers on my team) always insisted on using these kinds of "grilling" methods which were never good signals to begin with. It's a shame how our industry is the only highly-paid professional industry where this kind of sophomoric "intellectual hazing" is not only accepted, but also encouraged. I mean, hell, I have like three books on my bookshelf not about how to write good code, or scalable code, or performant code, but merely about how to pass interviews. Yuck.

tmpz22 6y ago
Github projects, OSS contributions, and StackOverflow questions, are imperfect measurements and can be inaccessible to a large number of developers. Github is banned in some countries, many OSS projects are english only, and stack overflow moderation needs no introduction, to name a few examples. Imagine if github became a ledger where you are now judged by the shitty code you wrote when you were 20. Remove older repos? You'll be scrutinized for having a "gap in your resume". The system is imperfect but is there actually a better alternative that fits the economic and cultural needs of our society? FWIW I'm on your side, interviewing gives me the worst anxiety in the world even though my career has progressed to the point where I can consistently get an on-site interview.
- alexandercrohde 6y ago
  Moreover, imagine for just one second that github became the defacto way to interview candidates. Now every candidate starts hacking their github full of all kinds of code, or even paying people to, or copying work to create a perfectly manicured "facebooked" version of what their work looks like (probably with fake timestamps too). Suddenly that signal becomes entirely worthless too. I think tech has one the best interviewing processes of all industries.
  - dvt 6y ago
    > Now every candidate starts hacking their github full of all kinds of code, or even paying people to, or copying work to create a perfectly manicured "facebooked" version of what their work looks like (probably with fake timestamps too). I'm of the opinion that going over someone's GitHub code (asking about design decisions, language alternatives, testing, algorithm choices) during an interview is probably orders of magnitutde more valuable than having them implement a linked list. But to each their own.
    - battery_cowboy 6y ago
      Not everyone likes to work on code in their free time, though, and code from work is often not public. How do you suggest people like that get jobs then?
      - karatestomp 6y ago
        Shit 40 hours is already 35% of my waking hours in a week, including weekends. Factor in that a lot of places extend hours by 30-60min to account for lunch ("9-5" my ass) and then commute time for most folks, and tons of people are already giving half their waking hours to their job. How much more time am I supposed to spend clickety-clacking code into a computer while ruining my health? Zero. Zero should be the answer. Because 40 hours is already a hell of a lot.
    - jkaptur 6y ago
      I think you're comparing an idealized version of a GitHub-based interview to a, at best, mediocre version of a whiteboard coding interview.
- dvt 6y ago
  > Github projects, OSS contributions, and StackOverflow questions, are imperfect measurements and can be inaccessible to a large number of developers. I fundamentally reject this premise and your arguments are orthogonal (GitHub being banned in like Syria and most OSS projects being in English is just flimsy hand-waving).
  - detaro 6y ago
    How do you intend to deal with developers that have little to no Github activity?
    - dvt 6y ago
      Take-homes, other OSS contributions, StackOverflow activity... GitHub isn't the only code outlet in the world. If I'd hire a writer, I'd like to see writing samples. If I hire a coder, I want to see coding samples.
      - devalgo 6y ago
        Excuse me sir, those writing samples are irrelevant. Could easily be plagiarized. I prefer to test my writers on arcane grammar in the languages they supposedly speak in high pressure situations.
        karatestomp 6y ago
        "Well these novels all look fine, Mr. Stephen King, but you see there are just so many fakers out there and even though you can talk very well about the process of writing a book in a way that only someone who either actually did know how to write or who was so wonderfully skilled at faking it that they'd be able to make more money applying that skill directly to a job that called for it (have you met our CEO, incidentally?), but oh my, yes, there are so many fakers, yes I'm sure there are a lot, it must be that our bad hires have been fakers who tricked us and not that environment, process, team, and management quality significantly affect people's performance in various ways and that we're badly deficient in some of those areas—anyway, point is, next we're going to quiz you on obscure citation format details across three different citation styles, have you sentence-diagram and label all the parts of speech of every word in the first chapter of Moby Dick (should only take you 5 minutes or we'll start obviously betraying that we think you're an idiot), and then write out for us the subjunctive mood conjugation of a few irregular French verbs." "Uh, will I be doing much of that on the job?" "Oh god no. Where do you think you are? This is Buzzfeed. You'll be hammering together barely-coherent prose that's just shy of stolen and publishing it as fast as possible." ^ your average programming interview with whiteboard grilling.
- nickdandakis 6y ago
  Yes, there is. Extract a piece of work from the project the new hire will be working on. Set up scaffolding and any boilerplate so that only have to implement one new feature (or fix one bug). Give it to another employee or yourself and solve it while recording how long it took. If someone that's familiar with the project took 4 hours, simplify. If someone that's unfamiliar with the project took 1-2 hours to solve, send it out to candidates. If you can't do any of the above, you might have process issues that you need to solve prior to getting a new hire in the first place. Oh, and if the take-home exercise is expected to take 4+ hours, pay the candidates to do the exercise.
  - renewiltord 6y ago
    How many hires have you made using this process? It is interesting in that the cost scales per person significantly. If I'm putting that much effort into the candidate, I think I've already determined I want him. I've definitely used a candidate's original work on Github to evaluate their skill but we still spoke about career objectives and culture. Honestly, I doubt that guy wouldn't have aced the technical interview anyway. It just saved us both time to not do it.
    - nickdandakis 6y ago
      I've hired a handful of people with this process, across two organizations. First time around, I identified and created the take-home exercise in one working day. Half of it was actually setting things up, the second half was solving it myself and tweaking it such that it takes the amount of time I was aiming for. Second time around it took a half day total. I'm not saying you shouldn't look at a Github profile or any code samples the candidate sends over. However, those metrics aren't good aptitude indicators. I feel the same way about algorithm-style coding tests that a lot of companies follow. Sure, let me find all the anagrams in a set of words only to land a job writing REST APIs... I don't see how the cost scales per person significantly. You create one take-home exercise per role you're hiring for. You send the same take-home exercise to any candidates that apply for the role. Worst-case scenario, it takes too much time to compile this take-home exercise, in which case you've hopefully spent the time to smooth out your processes which leads to an easier onboarding. Best-case scenario, you've compiled a take-home exercise in a reasonable amount of time, which verifies that onboarding will be smooth for the new hire. To your point, the take-home is for candidates in the 2nd or 3rd round of interviewing where you've verified their experience, you've verified their character/soft skills, and need to verify their aptitude/hard skills.
save_ferris 6y ago
The only way I’ve gotten around this is to pursue opportunities at smaller companies run by people with a similar mindset. Tech, like most other industries, can be a bit incestuous when it comes to competitive thinking because so-and-so company does it and therefore we must do it too. Smaller companies tend to have to compete more in the labor market and therefore don’t rely as heavily on these tactics. And while it is sophomoric and ineffective, at least you’re not explicitly judged by where you went to school, etc. like you see in finance. It’s not like other high-paying industries are more meritocratic than tech. I still think tech is by far the most meritocratic industry to be in, despite the interviewing culture. The only way we change the interviewing culture across the industry is by no longer making the FAANGs of the world the standard to aspire to, because it’s them pushing this misguided thinking.
Apocryphon 6y ago
Having had to deal with this process for a long time, I've come to accept it. Fundamentally it's a scaling problem, the big tech megacorps can't do careful tailored screening of those personalized signals you mention for all of interviewees they get, coupled with a cargo cult problem with everyone else from unicorns on down to stealth garage startups all imitating the megacorps. One optimization I'd suggest though is to standardize the process. Algorithmic/data structure more theory-oriented problems are unrepresentative of "actual work" and are annoying, but what's more annoying is how the process is 1) opaque, and 2) repetitive. So you end up with candidates grinding through 80+ Leetcode problems to both master the skills necessary to ace these problems, as well as covering as many commonly-asked problems in a bid to game the system by preempting their interviewees questions. Goodhart's law abounds. This basically makes the process into an interview version of standardized testing. But- despite the standard prep process and a standard bank of questions, it can all easily fall apart because of subjective interviewer opinion, and so all the preparation is for naught. Candidates end up having to do the interview gauntlet for each company they apply at. So standardize it. Put out clear, industry-standard rubrics for how one's performance is graded. Don't say "we only want to know how you think" and then ding candidates for not getting the right solution. You obviously care about the right answer as much as the thought process- don't be disingenuous about it. Maybe even standardize the level of difficulty of problems. And most of all: Make this process a one-time thing. Or rather, a once every five year thing. Outsource the ds/a interviewing section to a third party testing organization, like what Triplebyte is attempting to do, and have the actual interview be personalized to the company. Ask domain specific questions, relevant experience questions, system design, and culture fit questions during the company interview. And leave the DS/A portion be akin to the licensure tests that other engineering disciplines and STEM professions already have. Software engineers may hate credentialism, but if it's a credential that you only need to take once or twice in a decade, then it's already far superior to the current system that forces candidates to undergo this each time they change jobs.
thih9 6y ago
The "grilling" methods are not without benefits, they’re great at showing how much the candidate is willing to do to work at a given company. Perhaps some workplaces rely on that, consciously or not.
zerr 6y ago
It's a legal way for: 1. Ageism - not many seniors are desperate enough or have a free time for competitive programming preps. 2. Making switching jobs harder - for every next job one have to prepare again, because nobody is using competitive programming stuff during real work, so you forget.
- monksy 6y ago
  > Ageism I agree with that as that the knowledge they're questioning is more of a recency to being in school. Outside of school you don't write these things. You rely on frameworks and librarys. Why? They're mature and have been verified by others. In addition: if you don't know that software has to be well verified, you are VERY in-experienced in the field.
opportune 6y ago
Here’s a counterpoint: I don’t want to be forced to do OSS as part of my resume. I already write software over 40 hours a week for my job. And I won’t do a take home that takes longer than a regular interview unless the place has really good pay (I’ve never heard of a take home place paying top of industry). Meanwhile I’m very good at competitive programming, I actually find it enjoyable because of the challenge, and I don’t need to practice it much even when interviewing. Also to be perfectly blunt I think this just ties into people generally being uncomfortable with tests. All the examples you gave have the benefit of allowing unlimited time. What’s wrong with a test that challenges your knowledge of data structures and algorithms? I actually find that in general the very smart people I know are good at them and most of the people who “don’t test well” aren’t. And even then they can just practice them. They might even learn something. Sorry if that sounds mean, I don’t mean it to be, just blunt.
- frequentnapper 6y ago
  Counter to your counterpoint. I don't do competitive programming. I already write software 40 hours a week for my job. I don't want to spend months learning how to hack interviews when I know I can do a good job and I have done so in the past based on my resume and references.
  - alecbenzer 6y ago
    Yeah but there's got to be some give in the name of getting signal. Resumes are incredibly noisy signal. I think references are pretty noisy too... a bad reference is very bad, a better than average reference is really good, but I think the average reference, which most people give, is very low signal.
- Benjammer 6y ago
  >What’s wrong with a test that challenges your knowledge of data structures and algorithms? It's not a good signal for who will provide good business value through software engineering. >I actually find that in general the very smart people I know are good at them and most of the people who “don’t test well” aren’t. Is "smart" just directly 1:1 with "provides good business value" for you? I'm not so sure it's that simple... >And even then they can just practice them. They might even learn something. Sorry if that sounds mean, I don’t mean it to be, just blunt. It "sounds mean" because you are being selfish about your personal situation and then saying "it's not really that bad, come on," to people in different situations. It has nothing to do with you being "blunt."
simsla 6y ago
> GitHub projects, OSS contributions, stack overflow All of these are great signals IF present, but IMO not beyond. I have a decent track record in the software industry (FAANG and other), but I don't tend to work beyond work (the results of which are mostly private). Likewise, I've worked with amazing developers who prefer to focus on family/hiking/baking/etc. in their free time over OSS/private projects. It's great if you have the passion to go above and beyond in your free time, but it shouldn't be expected.
runawaybottle 6y ago
What evidence have we seen that Leetcode translates to people that write clean, sensible code? It feels like Leetcode is more of an aptitude test, but there’s tons of people that do great on the SATs but don’t necessarily excel in college. From my experience, the number one thing a team should be assessing for is sensibility. Give someone the shittiest piece of code you’ve encountered at work and have that person write their true feedback about it. If it’s mostly what your team would have said, there, you found someone with the right sensibilities. Then hit them with a few easy/medium Leetcodes as a fizzbuzz, and feel good about making a good hire.
- perfect_wave 6y ago
  "a few easy/medium leetcodes" I thought you were talking about removing Leetcode as a requirement....
  - runawaybottle 6y ago
    I can’t change the world all by myself. It’s a suggestion to weigh the Leetcode less.
- deleted 6y ago
  [deleted]
alecbenzer 6y ago
> It's a shame how our industry is the only highly-paid professional industry where this kind of sophomoric "intellectual hazing" is not only accepted, but also encouraged. I mean, hell, I have like three books on my bookshelf not about how to write good code, or scalable code, or performant code, but merely about how to pass interviews. Yuck. I don't think it's hazing so much as it is a test, and we're definitely not the only profession that has tests. I'm sure medical professionals and lawyers might have books on their shelves on how to pass the MCAT, LSAT, or Bar exam. If anything, we've maybe not matured as a field enough to have an actual standardized test for this kind of stuff, which would maybe make things better. But that's doubling-down on the "test-y" nature of coding interviews.
- Apocryphon 6y ago
  As mentioned elsewhere, I think the problem is that it's a decentralized, unstandardized approach, lacking in a transparent rubric, and more inconveniently it has to be taken at every single company rather than one and done, unlike those other license exams. https://news.ycombinator.com/item?id=23420733 https://news.ycombinator.com/item?id=23420733
non-entity 6y ago
> It's a shame how our industry is the only highly-paid professional industry where this kind of sophomoric "intellectual hazing" is not only accepted, but also encouraged. I agree for the most part, but in fairness, most other high paying fields rely solely on credentials that can often be pay-to-play (at least in the US)
- amznthrowaway5 6y ago
  Exactly, there is still a lot of corrupt credential signaling in the tech industry, but tech is one of the best due to leetcode interviews.

by dvt 6y ago

tmpz22 6y ago

Github projects, OSS contributions, and StackOverflow questions, are imperfect measurements and can be inaccessible to a large number of developers. Github is banned in some countries, many OSS projects are english only, and stack overflow moderation needs no introduction, to name a few examples. Imagine if github became a ledger where you are now judged by the shitty code you wrote when you were 20. Remove older repos? You'll be scrutinized for having a "gap in your resume". The system is imperfect but is there actually a better alternative that fits the economic and cultural needs of our society? FWIW I'm on your side, interviewing gives me the worst anxiety in the world even though my career has progressed to the point where I can consistently get an on-site interview.

alexandercrohde 6y ago
Moreover, imagine for just one second that github became the defacto way to interview candidates. Now every candidate starts hacking their github full of all kinds of code, or even paying people to, or copying work to create a perfectly manicured "facebooked" version of what their work looks like (probably with fake timestamps too). Suddenly that signal becomes entirely worthless too. I think tech has one the best interviewing processes of all industries.
- dvt 6y ago
  > Now every candidate starts hacking their github full of all kinds of code, or even paying people to, or copying work to create a perfectly manicured "facebooked" version of what their work looks like (probably with fake timestamps too). I'm of the opinion that going over someone's GitHub code (asking about design decisions, language alternatives, testing, algorithm choices) during an interview is probably orders of magnitutde more valuable than having them implement a linked list. But to each their own.
  - battery_cowboy 6y ago
    Not everyone likes to work on code in their free time, though, and code from work is often not public. How do you suggest people like that get jobs then?
    - karatestomp 6y ago
      Shit 40 hours is already 35% of my waking hours in a week, including weekends. Factor in that a lot of places extend hours by 30-60min to account for lunch ("9-5" my ass) and then commute time for most folks, and tons of people are already giving half their waking hours to their job. How much more time am I supposed to spend clickety-clacking code into a computer while ruining my health? Zero. Zero should be the answer. Because 40 hours is already a hell of a lot.
  - jkaptur 6y ago
    I think you're comparing an idealized version of a GitHub-based interview to a, at best, mediocre version of a whiteboard coding interview.
dvt 6y ago
> Github projects, OSS contributions, and StackOverflow questions, are imperfect measurements and can be inaccessible to a large number of developers. I fundamentally reject this premise and your arguments are orthogonal (GitHub being banned in like Syria and most OSS projects being in English is just flimsy hand-waving).
- detaro 6y ago
  How do you intend to deal with developers that have little to no Github activity?
  - dvt 6y ago
    Take-homes, other OSS contributions, StackOverflow activity... GitHub isn't the only code outlet in the world. If I'd hire a writer, I'd like to see writing samples. If I hire a coder, I want to see coding samples.
    - devalgo 6y ago
      Excuse me sir, those writing samples are irrelevant. Could easily be plagiarized. I prefer to test my writers on arcane grammar in the languages they supposedly speak in high pressure situations.
      - karatestomp 6y ago
        "Well these novels all look fine, Mr. Stephen King, but you see there are just so many fakers out there and even though you can talk very well about the process of writing a book in a way that only someone who either actually did know how to write or who was so wonderfully skilled at faking it that they'd be able to make more money applying that skill directly to a job that called for it (have you met our CEO, incidentally?), but oh my, yes, there are so many fakers, yes I'm sure there are a lot, it must be that our bad hires have been fakers who tricked us and not that environment, process, team, and management quality significantly affect people's performance in various ways and that we're badly deficient in some of those areas—anyway, point is, next we're going to quiz you on obscure citation format details across three different citation styles, have you sentence-diagram and label all the parts of speech of every word in the first chapter of Moby Dick (should only take you 5 minutes or we'll start obviously betraying that we think you're an idiot), and then write out for us the subjunctive mood conjugation of a few irregular French verbs." "Uh, will I be doing much of that on the job?" "Oh god no. Where do you think you are? This is Buzzfeed. You'll be hammering together barely-coherent prose that's just shy of stolen and publishing it as fast as possible." ^ your average programming interview with whiteboard grilling.
nickdandakis 6y ago
Yes, there is. Extract a piece of work from the project the new hire will be working on. Set up scaffolding and any boilerplate so that only have to implement one new feature (or fix one bug). Give it to another employee or yourself and solve it while recording how long it took. If someone that's familiar with the project took 4 hours, simplify. If someone that's unfamiliar with the project took 1-2 hours to solve, send it out to candidates. If you can't do any of the above, you might have process issues that you need to solve prior to getting a new hire in the first place. Oh, and if the take-home exercise is expected to take 4+ hours, pay the candidates to do the exercise.
- renewiltord 6y ago
  How many hires have you made using this process? It is interesting in that the cost scales per person significantly. If I'm putting that much effort into the candidate, I think I've already determined I want him. I've definitely used a candidate's original work on Github to evaluate their skill but we still spoke about career objectives and culture. Honestly, I doubt that guy wouldn't have aced the technical interview anyway. It just saved us both time to not do it.
  - nickdandakis 6y ago
    I've hired a handful of people with this process, across two organizations. First time around, I identified and created the take-home exercise in one working day. Half of it was actually setting things up, the second half was solving it myself and tweaking it such that it takes the amount of time I was aiming for. Second time around it took a half day total. I'm not saying you shouldn't look at a Github profile or any code samples the candidate sends over. However, those metrics aren't good aptitude indicators. I feel the same way about algorithm-style coding tests that a lot of companies follow. Sure, let me find all the anagrams in a set of words only to land a job writing REST APIs... I don't see how the cost scales per person significantly. You create one take-home exercise per role you're hiring for. You send the same take-home exercise to any candidates that apply for the role. Worst-case scenario, it takes too much time to compile this take-home exercise, in which case you've hopefully spent the time to smooth out your processes which leads to an easier onboarding. Best-case scenario, you've compiled a take-home exercise in a reasonable amount of time, which verifies that onboarding will be smooth for the new hire. To your point, the take-home is for candidates in the 2nd or 3rd round of interviewing where you've verified their experience, you've verified their character/soft skills, and need to verify their aptitude/hard skills.

save_ferris 6y ago

The only way I’ve gotten around this is to pursue opportunities at smaller companies run by people with a similar mindset. Tech, like most other industries, can be a bit incestuous when it comes to competitive thinking because so-and-so company does it and therefore we must do it too. Smaller companies tend to have to compete more in the labor market and therefore don’t rely as heavily on these tactics. And while it is sophomoric and ineffective, at least you’re not explicitly judged by where you went to school, etc. like you see in finance. It’s not like other high-paying industries are more meritocratic than tech. I still think tech is by far the most meritocratic industry to be in, despite the interviewing culture. The only way we change the interviewing culture across the industry is by no longer making the FAANGs of the world the standard to aspire to, because it’s them pushing this misguided thinking.

Apocryphon 6y ago

Having had to deal with this process for a long time, I've come to accept it. Fundamentally it's a scaling problem, the big tech megacorps can't do careful tailored screening of those personalized signals you mention for all of interviewees they get, coupled with a cargo cult problem with everyone else from unicorns on down to stealth garage startups all imitating the megacorps. One optimization I'd suggest though is to standardize the process. Algorithmic/data structure more theory-oriented problems are unrepresentative of "actual work" and are annoying, but what's more annoying is how the process is 1) opaque, and 2) repetitive. So you end up with candidates grinding through 80+ Leetcode problems to both master the skills necessary to ace these problems, as well as covering as many commonly-asked problems in a bid to game the system by preempting their interviewees questions. Goodhart's law abounds. This basically makes the process into an interview version of standardized testing. But- despite the standard prep process and a standard bank of questions, it can all easily fall apart because of subjective interviewer opinion, and so all the preparation is for naught. Candidates end up having to do the interview gauntlet for each company they apply at. So standardize it. Put out clear, industry-standard rubrics for how one's performance is graded. Don't say "we only want to know how you think" and then ding candidates for not getting the right solution. You obviously care about the right answer as much as the thought process- don't be disingenuous about it. Maybe even standardize the level of difficulty of problems. And most of all: Make this process a one-time thing. Or rather, a once every five year thing. Outsource the ds/a interviewing section to a third party testing organization, like what Triplebyte is attempting to do, and have the actual interview be personalized to the company. Ask domain specific questions, relevant experience questions, system design, and culture fit questions during the company interview. And leave the DS/A portion be akin to the licensure tests that other engineering disciplines and STEM professions already have. Software engineers may hate credentialism, but if it's a credential that you only need to take once or twice in a decade, then it's already far superior to the current system that forces candidates to undergo this each time they change jobs.

thih9 6y ago

The "grilling" methods are not without benefits, they’re great at showing how much the candidate is willing to do to work at a given company. Perhaps some workplaces rely on that, consciously or not.

zerr 6y ago

It's a legal way for: 1. Ageism - not many seniors are desperate enough or have a free time for competitive programming preps. 2. Making switching jobs harder - for every next job one have to prepare again, because nobody is using competitive programming stuff during real work, so you forget.

monksy 6y ago
> Ageism I agree with that as that the knowledge they're questioning is more of a recency to being in school. Outside of school you don't write these things. You rely on frameworks and librarys. Why? They're mature and have been verified by others. In addition: if you don't know that software has to be well verified, you are VERY in-experienced in the field.

opportune 6y ago

Here’s a counterpoint: I don’t want to be forced to do OSS as part of my resume. I already write software over 40 hours a week for my job. And I won’t do a take home that takes longer than a regular interview unless the place has really good pay (I’ve never heard of a take home place paying top of industry). Meanwhile I’m very good at competitive programming, I actually find it enjoyable because of the challenge, and I don’t need to practice it much even when interviewing. Also to be perfectly blunt I think this just ties into people generally being uncomfortable with tests. All the examples you gave have the benefit of allowing unlimited time. What’s wrong with a test that challenges your knowledge of data structures and algorithms? I actually find that in general the very smart people I know are good at them and most of the people who “don’t test well” aren’t. And even then they can just practice them. They might even learn something. Sorry if that sounds mean, I don’t mean it to be, just blunt.

frequentnapper 6y ago
Counter to your counterpoint. I don't do competitive programming. I already write software 40 hours a week for my job. I don't want to spend months learning how to hack interviews when I know I can do a good job and I have done so in the past based on my resume and references.
- alecbenzer 6y ago
  Yeah but there's got to be some give in the name of getting signal. Resumes are incredibly noisy signal. I think references are pretty noisy too... a bad reference is very bad, a better than average reference is really good, but I think the average reference, which most people give, is very low signal.
Benjammer 6y ago
>What’s wrong with a test that challenges your knowledge of data structures and algorithms? It's not a good signal for who will provide good business value through software engineering. >I actually find that in general the very smart people I know are good at them and most of the people who “don’t test well” aren’t. Is "smart" just directly 1:1 with "provides good business value" for you? I'm not so sure it's that simple... >And even then they can just practice them. They might even learn something. Sorry if that sounds mean, I don’t mean it to be, just blunt. It "sounds mean" because you are being selfish about your personal situation and then saying "it's not really that bad, come on," to people in different situations. It has nothing to do with you being "blunt."

simsla 6y ago

> GitHub projects, OSS contributions, stack overflow All of these are great signals IF present, but IMO not beyond. I have a decent track record in the software industry (FAANG and other), but I don't tend to work beyond work (the results of which are mostly private). Likewise, I've worked with amazing developers who prefer to focus on family/hiking/baking/etc. in their free time over OSS/private projects. It's great if you have the passion to go above and beyond in your free time, but it shouldn't be expected.

runawaybottle 6y ago

What evidence have we seen that Leetcode translates to people that write clean, sensible code? It feels like Leetcode is more of an aptitude test, but there’s tons of people that do great on the SATs but don’t necessarily excel in college. From my experience, the number one thing a team should be assessing for is sensibility. Give someone the shittiest piece of code you’ve encountered at work and have that person write their true feedback about it. If it’s mostly what your team would have said, there, you found someone with the right sensibilities. Then hit them with a few easy/medium Leetcodes as a fizzbuzz, and feel good about making a good hire.

perfect_wave 6y ago
"a few easy/medium leetcodes" I thought you were talking about removing Leetcode as a requirement....
- runawaybottle 6y ago
  I can’t change the world all by myself. It’s a suggestion to weigh the Leetcode less.
deleted 6y ago
[deleted]

alecbenzer 6y ago

> It's a shame how our industry is the only highly-paid professional industry where this kind of sophomoric "intellectual hazing" is not only accepted, but also encouraged. I mean, hell, I have like three books on my bookshelf not about how to write good code, or scalable code, or performant code, but merely about how to pass interviews. Yuck. I don't think it's hazing so much as it is a test, and we're definitely not the only profession that has tests. I'm sure medical professionals and lawyers might have books on their shelves on how to pass the MCAT, LSAT, or Bar exam. If anything, we've maybe not matured as a field enough to have an actual standardized test for this kind of stuff, which would maybe make things better. But that's doubling-down on the "test-y" nature of coding interviews.

Apocryphon 6y ago
As mentioned elsewhere, I think the problem is that it's a decentralized, unstandardized approach, lacking in a transparent rubric, and more inconveniently it has to be taken at every single company rather than one and done, unlike those other license exams. https://news.ycombinator.com/item?id=23420733 https://news.ycombinator.com/item?id=23420733

non-entity 6y ago

> It's a shame how our industry is the only highly-paid professional industry where this kind of sophomoric "intellectual hazing" is not only accepted, but also encouraged. I agree for the most part, but in fairness, most other high paying fields rely solely on credentials that can often be pay-to-play (at least in the US)

amznthrowaway5 6y ago
Exactly, there is still a lot of corrupt credential signaling in the tech industry, but tech is one of the best due to leetcode interviews.