4 ms·

For example: The idea that there are many programmers who cannot even write fizzbuzz sounds like a very strong claim. It seems far more likely that there are ma

For example: The idea that there are many programmers who cannot even write fizzbuzz sounds like a very strong claim. It seems far more likely that there are many programmers who have socially-induced anxiety.

strken 5y ago
It's entirely believable that many programmers couldn't write fizzbuzz without searching Google in the days before it was universally memorised. The modulo operator is somewhat rare in real code and is defined slightly differently in different languages.
- alpaca128 5y ago
  > The modulo operator is somewhat rare in real code Even if a candidate didn't know that modulo even existed they could still get the remainder with simple division and subtraction. Modulo might be slightly different depending on the language, but for fizzbuzz that's not important and most likely not what you're expected to know in such an interview question. And while it is not the most common operator it is still one of the most basic ones and present in all languages you'd use during a job interview.
  - strken 5y ago
    > Even if a candidate didn't know that modulo even existed they could still get the remainder with simple division and subtraction. And they'd probably fail some interviews for doing so. > And while it is not the most common operator it is still one of the most basic ones and present in all languages you'd use during a job interview. This is true, but I also expect some otherwise-competent programmers would fail a test that expected them to remember the specifics of bitwise operators or bitshifting. It's been years since I've needed to use any of the three in a paid job - they're just not very common in my day jobs, whereas they crop up a lot in side projects.
sokoloff 5y ago
I have interviewed senior candidates (more than two, fewer than five) who couldn’t write code to sum an array of ints (ignoring overflow). * Not in the sense of missed a bit of punctuation, but rather in the sense of “couldn’t get started with anything that vaguely smelled like an answer, didn’t understand the type system of the language they claim 5 years of experience with, etc”. I’ve probably interviewed fewer than 400 candidates in-person and maybe 200 of those would be senior ICs. To have more than a percent of them be utterly incapable here is a signal that there are candidates out there taking their best half-court buzzer-beater shot to try to land the prize. If you’ve done 100 first round in-person interviews and never run into someone that causes you to check up on how the phone screen happened, your screening processes work pretty well. Is it possible that these candidates are capable programmers in daily work? Sure, it’s possible, but I’d bet against it. * We used to ask a candidate to average an array of ints. It’s a question that was designed to tease out whether the candidate would discuss/inquire about overflow, what the return type should be, etc. After a couple years, we realized that candidates would stumble on the loop and sum more than anywhere else and we got more signal/minute from asking the vastly simpler summation question. Candidates who could fluently write the loop usually knew about overflow and the fact that the average of ints isn’t mathematically an int but that many times an int is what you want and can discuss the reasons.
- Jach 5y ago
  I love this because I agree 100%. I accepted the idea that they were "out there" but only really internalized it after I interviewed someone with a Masters in physics who couldn't make any progress on my simple problem. (The problem does assume you can understand the concept of a geometric line, but I give the two line equations most people first run into in junior high, among other things, I'm not testing recall.) Especially on the part about making a question even simpler in the name of getting what you actually care about faster. I've also found it useful to combine things from separate questions into one question that can answer both in less time. I still wonder if we couldn't remove most of these games though if we improved our hiring, onboarding, and firing processes in other ways than just trying to make a better hiring filter. Accidentally letting in someone wholly unsuitable for the job shouldn't be a big deal if 1) you can detect that like in the first day, or at least first week 2) the amount of damage they can do before detected is small 3) they actually start very soon after the decision to hire is made 4) you can fire them immediately after deciding a mistake was made and they don't work another day. Startups can handle this better already and I think is reflected in a lot of them still doing more casual "single lunch conversation" style interviews before a "welcome aboard, see you on Monday" decision. For big cos, work will have to be done on getting away from the mentality of "it's ok if you're not contributing much of anything for the first x days because onboarding" where x is high (I've seen over 30), and firming up access controls (no facebook style all-access of new hires (or anyone if possible) being able to just query the production db and access the private messages of exes or whoever), and removing the "ok you're hired, see you in x weeks" policies where new hires can only start after a significant delay or all on a certain date for whatever reasons, and only getting rid of someone through a long and drawn out PIP process... Maybe it can be done some day.
rmah 5y ago
I have screened or interviewed hundreds of people over the past three decades. That is not a strong claim, it is simple truth. There is a large minority of so-called "professional" software developers who literally don't know what they're doing and can't anything but the dead simplest code. They may only represent 2% of the population, but they are a much larger % of candidates searching for jobs. If you think about it a bit, you'll see why.

strken 5y ago

It's entirely believable that many programmers couldn't write fizzbuzz without searching Google in the days before it was universally memorised. The modulo operator is somewhat rare in real code and is defined slightly differently in different languages.

alpaca128 5y ago
> The modulo operator is somewhat rare in real code Even if a candidate didn't know that modulo even existed they could still get the remainder with simple division and subtraction. Modulo might be slightly different depending on the language, but for fizzbuzz that's not important and most likely not what you're expected to know in such an interview question. And while it is not the most common operator it is still one of the most basic ones and present in all languages you'd use during a job interview.
- strken 5y ago
  > Even if a candidate didn't know that modulo even existed they could still get the remainder with simple division and subtraction. And they'd probably fail some interviews for doing so. > And while it is not the most common operator it is still one of the most basic ones and present in all languages you'd use during a job interview. This is true, but I also expect some otherwise-competent programmers would fail a test that expected them to remember the specifics of bitwise operators or bitshifting. It's been years since I've needed to use any of the three in a paid job - they're just not very common in my day jobs, whereas they crop up a lot in side projects.

sokoloff 5y ago

I have interviewed senior candidates (more than two, fewer than five) who couldn’t write code to sum an array of ints (ignoring overflow). * Not in the sense of missed a bit of punctuation, but rather in the sense of “couldn’t get started with anything that vaguely smelled like an answer, didn’t understand the type system of the language they claim 5 years of experience with, etc”. I’ve probably interviewed fewer than 400 candidates in-person and maybe 200 of those would be senior ICs. To have more than a percent of them be utterly incapable here is a signal that there are candidates out there taking their best half-court buzzer-beater shot to try to land the prize. If you’ve done 100 first round in-person interviews and never run into someone that causes you to check up on how the phone screen happened, your screening processes work pretty well. Is it possible that these candidates are capable programmers in daily work? Sure, it’s possible, but I’d bet against it. * We used to ask a candidate to average an array of ints. It’s a question that was designed to tease out whether the candidate would discuss/inquire about overflow, what the return type should be, etc. After a couple years, we realized that candidates would stumble on the loop and sum more than anywhere else and we got more signal/minute from asking the vastly simpler summation question. Candidates who could fluently write the loop usually knew about overflow and the fact that the average of ints isn’t mathematically an int but that many times an int is what you want and can discuss the reasons.

Jach 5y ago
I love this because I agree 100%. I accepted the idea that they were "out there" but only really internalized it after I interviewed someone with a Masters in physics who couldn't make any progress on my simple problem. (The problem does assume you can understand the concept of a geometric line, but I give the two line equations most people first run into in junior high, among other things, I'm not testing recall.) Especially on the part about making a question even simpler in the name of getting what you actually care about faster. I've also found it useful to combine things from separate questions into one question that can answer both in less time. I still wonder if we couldn't remove most of these games though if we improved our hiring, onboarding, and firing processes in other ways than just trying to make a better hiring filter. Accidentally letting in someone wholly unsuitable for the job shouldn't be a big deal if 1) you can detect that like in the first day, or at least first week 2) the amount of damage they can do before detected is small 3) they actually start very soon after the decision to hire is made 4) you can fire them immediately after deciding a mistake was made and they don't work another day. Startups can handle this better already and I think is reflected in a lot of them still doing more casual "single lunch conversation" style interviews before a "welcome aboard, see you on Monday" decision. For big cos, work will have to be done on getting away from the mentality of "it's ok if you're not contributing much of anything for the first x days because onboarding" where x is high (I've seen over 30), and firming up access controls (no facebook style all-access of new hires (or anyone if possible) being able to just query the production db and access the private messages of exes or whoever), and removing the "ok you're hired, see you in x weeks" policies where new hires can only start after a significant delay or all on a certain date for whatever reasons, and only getting rid of someone through a long and drawn out PIP process... Maybe it can be done some day.

rmah 5y ago

I have screened or interviewed hundreds of people over the past three decades. That is not a strong claim, it is simple truth. There is a large minority of so-called "professional" software developers who literally don't know what they're doing and can't anything but the dead simplest code. They may only represent 2% of the population, but they are a much larger % of candidates searching for jobs. If you think about it a bit, you'll see why.