4 ms·

If you really believe so, then I think you are failing to grasp how low "low skill" truly happens to be.

cmrdporcupine 6y ago
Nope, I think lots of people perform 'low skill' in a whiteboard scenario that are not. And the arrogance of their interviewers gets them on HN making very bold claims about other people's skill levels without consideration for the scenarios involved. Don't get me wrong-- I've worked with very incompetent people. Many of them would have passed a coding interview though.
- NationalPark 6y ago
  I felt this way too until I was made to start giving interviews. However low a bar you're imagining, I assure you I've seen "strong on paper" candidates who failed to meet a lower one. I don't know if people are lying, or people cheated through school, or talked other people into doing their work at the jobs they claim to have had, but it's really astonishing how unable to write code they can be. However, the particularly insidious candidates are the ones who have developed a skill for talking about software/programming but can't actually write code no matter how much help or prodding they are given. As soon as you accidentally hire one of those, the case for technical interviews becomes a lot stronger.
  - song 6y ago
    I was going to write a similar comment when I saw yours. We've recently hired someone who was great on paper, was adept at talking about software/programming and was able to present some code he allegedly wrote and explain it. He seemed like a great fit based on the discussions but we hadn't actually given him a whiteboard interview. Once he joined the company he proceeded to actually be completely unable to write a single working piece of code. Everything he wrote needed to be reviewed and had major glaring issues. When confronted about it, he would say that he couldn't figure it out so decided to just commit his unfinished code. That guy was senior, had worked for 20 years and is really good at talking but when it comes to actually developing software, he is completely utterly incompetent.
    - ryandrake 6y ago
      I am constantly surprised at how many Brillant Paula Bean [1] developers are out there successfully interviewing, getting hired and BS-ing their way through jobs. I've always wondered if this is as prevalent in other industries outside of software. 1: https://thedailywtf.com/articles/The_Brillant_Paula_Bean https://thedailywtf.com/articles/The_Brillant_Paula_Bean
- edanm 6y ago
  I don't know how many people saying otherwise would constitute sufficient evidence in your mind, but add me to the list of people that disagree with this sentiment. I've had candidates who couldn't code a loop. Not "did something suboptimal", I mean literally couldn't write a single line of code. I've had candidates who seemed incredibly accomplished when talking them, who showed amazing looking demos and could talk at length about them. But when given a task to do on the computer, given 2 hours alone to sit and code, couldn't do even the first part of the exercise - despite it being something you could literally copy and paste from the documentation that we gave them a link to!
  - grumple 6y ago
    I've frozen in interviews and been unable to think on simple problems just due to anxiety (which I've never experienced at work; if I can't think, I just say, "let me think about it" and I get back to the person in a bit). Other interviews I've completely demolished - solving problems that were supposed to take 30 minutes in 2 minutes, for example. I think the type of problem and structure we use for interviews is bad. Let the candidate code alone without you watching. Give them internet access. Come back in an hour or two, or let them do it remotely or as a take home. This is more like our real jobs; and gets rid of cutesy "do you know this algorithm?" questions, which many whiteboarding problems are. Instead of going for pure data structure / dp / search / sort algorithms, have them implement things like business rules.
    - edanm 6y ago
      I wholeheartedly agree. Note that my second example was exactly that type of interview - we leave the candidate to code alone, technically sometimes in the same room as us but sometimes in a separate room, but either way with only a few "check ins" every 15-45 minutes depending on how things go. They have internet access, a base file and console session open that can run the file, and an editor already set up (not necessarily their editor of choice, though we've had people install an editor at the start of this process). In this scenario, having someone literally be unable, in 2 hours, to replicate the first example code of some library, when they have access to almost identical code in the docs, is a pretty good filter.
- dmoy 6y ago
  My whiteboard coding interviews now mostly consist of asking someone to write a for loop with one state variable. That's my bar for low skill. If you can't write 6 lines of code in 45 minutes with one loop and one variable, then you and I are going to have problems working on logic problems on a whiteboard on the actual job. I've interviewed enough people who don't even know the syntax of a for loop for the language that they chose to use. As a general matter for how the industry as a whole interviews, I agree though; I am no longer a fan of tricky algorithmic or esoteric data structure questions in whiteboard interviews. The problem I find with other people's interviewing questions is that most people are still asking things that are way too difficult, and they don't end up judging anything other than "Did this person just cram hundreds of hours of algorithms questions?" or "Did this person get lucky and happen to know this type of problem ahead of time?". For better or for worse, my company schedules me for like >90% system design questions now, which I prefer anyways. Start with a very simple problem and system, and then just throw wrenches.
  - sobani 6y ago
    I'm only 90% sure I know the syntax of a for loop in my chosen language, C#. The reason for the missing 10% is that I never write this syntax. Most loops are covered by a foreach or by LINQ (think: map and reduce, buy nicer). The few times I actually need a for loop I type: "for" <press enter> <type the limit for i> <press enter> and then I focus on the loop body. If my needs are more complicated, I _modify_ the for loop my IDE gives me.
    - dmoy 6y ago
      Yea I meant a for-each loop.
      - dmoy 6y ago
        I'm not sure the last time I wrote a for loop that wasn't for-each.
- jjav 6y ago
  > Nope, I think lots of people perform 'low skill' in a whiteboard scenario that are not. And the arrogance of their interviewers gets them on HN making very bold claims about other people's skill levels without consideration for the scenarios involved. This is it, in a nutshell. In all my years of interviewing candidates, I've never run into the mythical experienced developer who doesn't know anything about programming. Yet according to HN lore, there are hordes of them out there. My theory is that the only thing there are indeed hordes of, is experienced developers who can be made to look dumb by subjecting them to whiteboard puzzles, algorithm trivia and other such questions which are completely unrelated to the job performance.
freeqaz 6y ago
There is a reason that "FizzBuzz" is a meme! I love the expression, "Job candidates who can't seem to program their way out of a wet paper bag." It's too true. A quick search found the source article that I read years ago here[0]. :) 0: http://wiki.c2.com/?FizzBuzzTest http://wiki.c2.com/?FizzBuzzTest
- jjav 6y ago
  > http://wiki.c2.com/?FizzBuzzTest http://wiki.c2.com/?FizzBuzzTest From that page: > We can't understand why so many people "fail" the Fizz-Buzz test unless we understand why it is "hard" (for them). But the article doesn't even talk about the environment, which is what it's all about. It's hard "for them" because they're being asked to write the code on a whiteboard, with a job/income on the line, with stress and anxiety dialed up to 11, with someone breathing down their neck watching, while expected to simultaneously provide cheerful ongoing commentary to "show how they think". Under those conditions, I totally believe close to 100% perfectly competent developers will fail at it. But of course it has nothing to do with the programming part. Most of us have heard of FizzBuzz while chillin at home reading articles and immediately thought "that can't be hard" and tried it and indeed it is laughably easy. So we can't understand how "they" could fail at it because we didn't experience it under interview hazing conditions. So the "them" is actually all of us. To me that is the key takeaway of FizzBuzz.
  - ciceryadam 6y ago
    In my case I failed at fizzbuzz because I was interviewing after spending a full day merging 2 versions of dbdumps into one, while getting rid of duplicate entries/foreign keys, etc. I could still do a pseudo code version of it, but I couldn't remember modulo function. At all.

Nope, I think lots of people perform 'low skill' in a whiteboard scenario that are not. And the arrogance of their interviewers gets them on HN making very bold claims about other people's skill levels without consideration for the scenarios involved. Don't get me wrong-- I've worked with very incompetent people. Many of them would have passed a coding interview though.

NationalPark 6y ago
I felt this way too until I was made to start giving interviews. However low a bar you're imagining, I assure you I've seen "strong on paper" candidates who failed to meet a lower one. I don't know if people are lying, or people cheated through school, or talked other people into doing their work at the jobs they claim to have had, but it's really astonishing how unable to write code they can be. However, the particularly insidious candidates are the ones who have developed a skill for talking about software/programming but can't actually write code no matter how much help or prodding they are given. As soon as you accidentally hire one of those, the case for technical interviews becomes a lot stronger.
- song 6y ago
  I was going to write a similar comment when I saw yours. We've recently hired someone who was great on paper, was adept at talking about software/programming and was able to present some code he allegedly wrote and explain it. He seemed like a great fit based on the discussions but we hadn't actually given him a whiteboard interview. Once he joined the company he proceeded to actually be completely unable to write a single working piece of code. Everything he wrote needed to be reviewed and had major glaring issues. When confronted about it, he would say that he couldn't figure it out so decided to just commit his unfinished code. That guy was senior, had worked for 20 years and is really good at talking but when it comes to actually developing software, he is completely utterly incompetent.
  - ryandrake 6y ago
    I am constantly surprised at how many Brillant Paula Bean [1] developers are out there successfully interviewing, getting hired and BS-ing their way through jobs. I've always wondered if this is as prevalent in other industries outside of software. 1: https://thedailywtf.com/articles/The_Brillant_Paula_Bean https://thedailywtf.com/articles/The_Brillant_Paula_Bean
edanm 6y ago
I don't know how many people saying otherwise would constitute sufficient evidence in your mind, but add me to the list of people that disagree with this sentiment. I've had candidates who couldn't code a loop. Not "did something suboptimal", I mean literally couldn't write a single line of code. I've had candidates who seemed incredibly accomplished when talking them, who showed amazing looking demos and could talk at length about them. But when given a task to do on the computer, given 2 hours alone to sit and code, couldn't do even the first part of the exercise - despite it being something you could literally copy and paste from the documentation that we gave them a link to!
- grumple 6y ago
  I've frozen in interviews and been unable to think on simple problems just due to anxiety (which I've never experienced at work; if I can't think, I just say, "let me think about it" and I get back to the person in a bit). Other interviews I've completely demolished - solving problems that were supposed to take 30 minutes in 2 minutes, for example. I think the type of problem and structure we use for interviews is bad. Let the candidate code alone without you watching. Give them internet access. Come back in an hour or two, or let them do it remotely or as a take home. This is more like our real jobs; and gets rid of cutesy "do you know this algorithm?" questions, which many whiteboarding problems are. Instead of going for pure data structure / dp / search / sort algorithms, have them implement things like business rules.
  - edanm 6y ago
    I wholeheartedly agree. Note that my second example was exactly that type of interview - we leave the candidate to code alone, technically sometimes in the same room as us but sometimes in a separate room, but either way with only a few "check ins" every 15-45 minutes depending on how things go. They have internet access, a base file and console session open that can run the file, and an editor already set up (not necessarily their editor of choice, though we've had people install an editor at the start of this process). In this scenario, having someone literally be unable, in 2 hours, to replicate the first example code of some library, when they have access to almost identical code in the docs, is a pretty good filter.
dmoy 6y ago
My whiteboard coding interviews now mostly consist of asking someone to write a for loop with one state variable. That's my bar for low skill. If you can't write 6 lines of code in 45 minutes with one loop and one variable, then you and I are going to have problems working on logic problems on a whiteboard on the actual job. I've interviewed enough people who don't even know the syntax of a for loop for the language that they chose to use. As a general matter for how the industry as a whole interviews, I agree though; I am no longer a fan of tricky algorithmic or esoteric data structure questions in whiteboard interviews. The problem I find with other people's interviewing questions is that most people are still asking things that are way too difficult, and they don't end up judging anything other than "Did this person just cram hundreds of hours of algorithms questions?" or "Did this person get lucky and happen to know this type of problem ahead of time?". For better or for worse, my company schedules me for like >90% system design questions now, which I prefer anyways. Start with a very simple problem and system, and then just throw wrenches.
- sobani 6y ago
  I'm only 90% sure I know the syntax of a for loop in my chosen language, C#. The reason for the missing 10% is that I never write this syntax. Most loops are covered by a foreach or by LINQ (think: map and reduce, buy nicer). The few times I actually need a for loop I type: "for" <press enter> <type the limit for i> <press enter> and then I focus on the loop body. If my needs are more complicated, I _modify_ the for loop my IDE gives me.
  - dmoy 6y ago
    Yea I meant a for-each loop.
    - dmoy 6y ago
      I'm not sure the last time I wrote a for loop that wasn't for-each.
jjav 6y ago
> Nope, I think lots of people perform 'low skill' in a whiteboard scenario that are not. And the arrogance of their interviewers gets them on HN making very bold claims about other people's skill levels without consideration for the scenarios involved. This is it, in a nutshell. In all my years of interviewing candidates, I've never run into the mythical experienced developer who doesn't know anything about programming. Yet according to HN lore, there are hordes of them out there. My theory is that the only thing there are indeed hordes of, is experienced developers who can be made to look dumb by subjecting them to whiteboard puzzles, algorithm trivia and other such questions which are completely unrelated to the job performance.

freeqaz 6y ago

There is a reason that "FizzBuzz" is a meme! I love the expression, "Job candidates who can't seem to program their way out of a wet paper bag." It's too true. A quick search found the source article that I read years ago here[0]. :) 0: http://wiki.c2.com/?FizzBuzzTest http://wiki.c2.com/?FizzBuzzTest

jjav 6y ago
> http://wiki.c2.com/?FizzBuzzTest http://wiki.c2.com/?FizzBuzzTest From that page: > We can't understand why so many people "fail" the Fizz-Buzz test unless we understand why it is "hard" (for them). But the article doesn't even talk about the environment, which is what it's all about. It's hard "for them" because they're being asked to write the code on a whiteboard, with a job/income on the line, with stress and anxiety dialed up to 11, with someone breathing down their neck watching, while expected to simultaneously provide cheerful ongoing commentary to "show how they think". Under those conditions, I totally believe close to 100% perfectly competent developers will fail at it. But of course it has nothing to do with the programming part. Most of us have heard of FizzBuzz while chillin at home reading articles and immediately thought "that can't be hard" and tried it and indeed it is laughably easy. So we can't understand how "they" could fail at it because we didn't experience it under interview hazing conditions. So the "them" is actually all of us. To me that is the key takeaway of FizzBuzz.
- ciceryadam 6y ago
  In my case I failed at fizzbuzz because I was interviewing after spending a full day merging 2 versions of dbdumps into one, while getting rid of duplicate entries/foreign keys, etc. I could still do a pseudo code version of it, but I couldn't remember modulo function. At all.