18 ms·

> Most engineering interviewees fail to advance because of cultural/personality/communication issues and not technical competence. Not my experience. At least

> Most engineering interviewees fail to advance because of cultural/personality/communication issues and not technical competence. Not my experience. At least when hiring for programming positions, the typical fatal issue is that the candidate's coding is weak. In my first role as a hiring manager, I didn't stress coding tests for candidates with long work history on their resume. Since then, I learned better. I've seen candidates with anything between 1 and 15 years of full time coding work on their resumes fail to answer basic fizz-buzz level coding questions. At least for the candidates I've seen, the biggest single reason why they get rejected is failure to perform the one main function their job requires: coding.

mixmastamyk 8y ago
They can't code because you are looking figuratively over their shoulder---the clock is ticking next to a hundred grand in a suitcase. A single question is pulled from subjects vast enough to fill up years of college and there is no time to research, as one would in the real world. Binary pass/fail with your pride/livelyhood/family on the line. Please state your last exam conducted under such conditions? Oh and your questions probably stink. I've gotten plenty of them with recursion that might take ten minutes in seclusion but simply not possible under the gun.
- bsder 8y ago
  > They can't code because you are looking figuratively over their shoulder---the clock is ticking next to a hundred grand in a suitcase. There is a difference between me asking you how to optimize a graph algorithm (good luck--I probably couldn't do that on the fly with references in front of me) vs giving me a basic FizzBuzz. If I let you pick your language for your FizzBuzz, you need to demonstrate at least some of the following things: I/O of any flavor (I'll even accept Logging if you don't do standard I/O or console I/O) String formatting Modulus Operator Nested-If statements (or equivalent--Matching, case/switch, etc.) I'm not looking for production code. I'm looking for 10-20 lines of "A High School senior with a computer class could pass this." This is not limited to programming, sadly. I used to have to interview VLSI designers with "Draw me an inverter", and 70% of them couldn't pass.
  - bglazer 8y ago
    To be totally honest, I always find these stats about some x% > 50% failure to program at all totally unbelievable. What do these people do all day, if not design and build software? Yet they're apparently completely unable to write code? How is that possible? I understand that there is always a certain amount of slack and underperformance but any workforce would be completely paralyzed by 70% completely incompetent workers. And yet companies everywhere still produce software.
    - taneq 8y ago
      It's because some large percentage of your time at work is spent in meetings, writing emails, discussing things, etc. where actual ability to do the core task isn't necessary. And then some large percentage of "enterprise software development" is just hooking up buttons and text fields to a database, and doesn't require any more algorithmic complexity than a few if() statements. And then some large percentage of the remaining work can be performed adequately by just picking some appropriate ready-made solution off Stack Overflow. Put them all together and chances are, you can skate by for years (and actually perform acceptably) without ever actually needing to write FizzBuzz-level code for yourself.
    - bsder 8y ago
      1) Selection bias Good/excellent programmers rarely need to interview except as a formality. Consequently, you are, by definition, interviewing weaker programmers. 2) Tool use masquerades as programming Visual Basic 4/5/6 was one of the original sins in this genre, but it continues now with other tools and frameworks. Being able to point-and-click a tool and plumb it together isn't programming--but people will claim it is. Then when someone asks for an actual program--those people fail. This does not necessarily mean that those people are not productive. However, it does mean that they can't actually function in a position where they are expected to program.
    - dunpeal 8y ago
      > What do these people do all day, if not design and build software? Indeed this is a fascinating question, and I explored it a few times. Some folks who have multiple years of "software engineering" on their resume worked in a place where they did some form of "paint by numbers" programming, producing some work by modifying templates with limited (at best) understanding beyond the specific blanks they were filling. An example is folks who work with large frameworks that are designed to be extended with little to no coding, such as WordPress and Drupal. Then they want to advance to software engineering, so they recast their experience - of essentially configuring and deploying software, i.e. sysadmin - as "programming", and get those 5 years represented as "a full time programming position". There's variants of that, basically "developers" doing very limited ant-work with large frameworks they don't understand and couldn't rewrite from scratch if their lives depended on it. There's also a bunch of languages and frameworks invented for the explicit purpose that someone with little to no CS knowledge of programming talent could produce useful work. Most of us here live in a bubble of startups where we often create products from scratch using lean (or no) frameworks. In reality, a scary amount of the "IT work" out there appears to be what I described above. Possibly a substantial majority.
- taneq 8y ago
  We always get these kinds of responses when interview testing is mentioned. This isn't some high-level algorithm analysis on a whiteboard with a panel of examiners grilling you. This is a simple test of basic competence. It's like interviewing a candidate Formula 1 driver and asking them "so which bit's the brake pedal?" If they can't tell you that instantly then they shouldn't be applying for the position in the first place. > Please state your last exam conducted under such conditions? University entrance exams. University graduation exams. Any other test that you do which you need to pass to enter or continue your career.
  - mixmastamyk 8y ago
    > We always get these kinds of responses… Perhaps you should start listening. > This isn't some high-level algorithm analysis on a whiteboard with a panel of examiners grilling you. Happened to me just three months ago. The req is still open, wonder why? To reiterate: - Exams have a topic known in advance. - Exams never have a person sitting there waiting for the answer. - Exams are never 1 or 2 questions binary pass/fail with incredibly high stakes in unfamiliar territory. Which is the brake pedal? If only.
    - watwat1 8y ago
      No point in being bitter.
    - mixmastamyk 8y ago
      You'll get bitter when the rent is due, watwat.
    - taneq 8y ago
      We're talking about "basic fizz-buzz level coding questions". It sounds like you had a bad experience with something else that we weren't talking about. (As for 'topic known in advance', I'd suggest that if you don't know what topics that you might be asked about in a job interview, maybe you shouldn't be interviewing for that job.)
      - 8y ago
- Sophistifunk 8y ago
  One possible way to address this issue is by asking candidates to talk about some existing code you give them, rather than trying to cook something up off the bat while under scrutiny and not having access to their familiar tooling.
irq11 8y ago
”I've seen candidates with anything between 1 and 15 years of full time coding work on their resumes fail to answer basic fizz-buzz level coding questions.” I haven’t seen this. I have, however, seen lots of junior interviewers ask idiotic questions and wash candidates out for bad reasons, and then turn around and claim the candidate ”failed at fizzbuzz”, just to cover their own ass (or because they think TopCoder medium questions are “fizzbuzz”. Equally stupid.) Me personally? I’ve never interviewed a senior person who couldn’t code at all. Not after the phone screen, anyway.
- dunpeal 8y ago
  > I have, however, seen lots of junior interviewers ask idiotic questions and wash candidates out for bad reasons Why are "juniors" interviewing candidates? Let alone juniors asking "idiotic questions", and having decision-making capacity? > then turn around and claim the candidate ”failed at fizzbuzz”, just to cover their own ass Coding questions are among the most quantifiable and objective questions there are. If you know of something even more objective, let me know because I'd love to try it. They are repeatable and have well-defined success criteria. Ideally you have two interviewers in the same room, and it's very clear if the candidate did or did not solve the problem. You can't really fudge it, even as a single interviewer, unless you're willing to outright lie that the candidate didn't write a working solution when he did. > I’ve never interviewed a senior person who couldn’t code at all. Not after the phone screen, anyway. Yes, if you do a coding phone screen, then obviously you're screening out those who can't code. I'm sure you saw some impressive resumes fail that screen, though.
  - irq11 8y ago
    ”Why are "juniors" interviewing candidates?” I don’t know if you’ve noticed this, but the average age of programmers these days is just slightly above “right out of undergrad”. If you wait for the senior people to interview everyone, you’re going to be waiting a while. ”Coding questions are among the most quantifiable and objective questions there are.” Bullshit. Coding questions feel objective, and programmers love to pretend they’re objective, but like any other human evaluation process, they’re subjective. It’s not like you automatically get the job if you get the answer right. Unless you’re verifying that your team is generating consistent, reproducible outcomes, I can pretty much guarantee that they’re not.
PopeDotNinja 8y ago
I personally don't care that much on how well a candidate can code, as measuring that is itself quite hard (in my opinion). What I like to interview for is someone who really likes to code. I look for things that demonstrate recent personal growth, ability to explain & teach something they do know, a tendency to avoid claiming they are good at anything, open mindedness on trying new things, etc. In my experience, someone who really wants to code and shows a minimum viable capacity for doing so is the person I want to hire.
- dunpeal 8y ago
  > In my experience, someone who really wants to code and shows a minimum viable capacity for doing so is the person I want to hire. My comment referred specifically to candidates with at least one year of full-time hands-on development experience under their belt. The typical candidate I interviewed had 3+ years of experience. If you want to code, then you should have ample opportunity to do so during a year or more of full-time employment. If you were working in a full-time programming position for over 3 years yet you can't write even a trivial amount of working code during the interview, then clearly you either lack the capacity or the will to develop your programming skills. Programming nowadays is easy - everyone has a powerful laptop and internet access. It's not like you need privileged access to some $100k time sharing machine using punchcards, and learn machine-language from obscure mail-ordered manuals. What excuse does anyone claiming to "want to code" have for not coding already? I'd be quite suspicious of anyone waxing poetic about their genuine heartfelt love for coding who somehow couldn't demonstrate any coding ability. Would you believe someone who swears they "love long-distance running", but collapses after 50 yards and says they just didn't have the opportunity to put this great love to practice?
  - PopeDotNinja 8y ago
    > If you were working in a full-time programming position for over 3 years yet you can't write even a trivial amount of working code during the interview, then clearly you either lack the capacity or the will to develop your programming skills. Genuine question... What kind of question(s) would I ask to get someone to demonstrate they can code? If my questions are effective, I'm fine. But if my questions stink, it'd be easy to overlook that fact that many excellent people wouldn't be able to answer them well.
throwaway080383 8y ago
I also learned this not long after I started conducting coding interviews. People with resumes from the best schools and the best companies would fail in multiple interviews in a row. Nowadays I don't even look at the resume, though to be fair I am only tasked with evaluating coding ability, and not things like culture fit or pay scale.
jldugger 8y ago
> I've seen candidates with anything between 1 and 15 years of full time coding work on their resumes fail to answer basic fizz-buzz level coding questions. Like, how? I used to hire undergraduate student sysadmins / coders, and we had zero candidates fail fizz buzz. None! The worst we saw were people who maybe had an awkward solution to the problem, typically because of unfamiliarity with the modulus operator.
- dunpeal 8y ago
  I should stress I didn't ask fizz-buzz specifically, but similarly basic questions. I should also stress (again) that back then I brought candidates directly to onsites when their recruiters sent an impressive resume with 3+ years of "full time programming experience". I learned the hard way that most people who unknown recruiters are eager to push through your hiring funnel are unemployed for a reason.
PhasmaFelis 8y ago
True, but give them something they can do at a computer, in an hour or a day or a weekend. Coding on a whiteboard with someone staring at you counting the seconds is not natural. It's like asking someone to do their job backwards and underwater. You'll get a lot of false negatives.

mixmastamyk 8y ago

They can't code because you are looking figuratively over their shoulder---the clock is ticking next to a hundred grand in a suitcase. A single question is pulled from subjects vast enough to fill up years of college and there is no time to research, as one would in the real world. Binary pass/fail with your pride/livelyhood/family on the line. Please state your last exam conducted under such conditions? Oh and your questions probably stink. I've gotten plenty of them with recursion that might take ten minutes in seclusion but simply not possible under the gun.

bsder 8y ago
> They can't code because you are looking figuratively over their shoulder---the clock is ticking next to a hundred grand in a suitcase. There is a difference between me asking you how to optimize a graph algorithm (good luck--I probably couldn't do that on the fly with references in front of me) vs giving me a basic FizzBuzz. If I let you pick your language for your FizzBuzz, you need to demonstrate at least some of the following things: I/O of any flavor (I'll even accept Logging if you don't do standard I/O or console I/O) String formatting Modulus Operator Nested-If statements (or equivalent--Matching, case/switch, etc.) I'm not looking for production code. I'm looking for 10-20 lines of "A High School senior with a computer class could pass this." This is not limited to programming, sadly. I used to have to interview VLSI designers with "Draw me an inverter", and 70% of them couldn't pass.
- bglazer 8y ago
  To be totally honest, I always find these stats about some x% > 50% failure to program at all totally unbelievable. What do these people do all day, if not design and build software? Yet they're apparently completely unable to write code? How is that possible? I understand that there is always a certain amount of slack and underperformance but any workforce would be completely paralyzed by 70% completely incompetent workers. And yet companies everywhere still produce software.
  - taneq 8y ago
    It's because some large percentage of your time at work is spent in meetings, writing emails, discussing things, etc. where actual ability to do the core task isn't necessary. And then some large percentage of "enterprise software development" is just hooking up buttons and text fields to a database, and doesn't require any more algorithmic complexity than a few if() statements. And then some large percentage of the remaining work can be performed adequately by just picking some appropriate ready-made solution off Stack Overflow. Put them all together and chances are, you can skate by for years (and actually perform acceptably) without ever actually needing to write FizzBuzz-level code for yourself.
  - bsder 8y ago
    1) Selection bias Good/excellent programmers rarely need to interview except as a formality. Consequently, you are, by definition, interviewing weaker programmers. 2) Tool use masquerades as programming Visual Basic 4/5/6 was one of the original sins in this genre, but it continues now with other tools and frameworks. Being able to point-and-click a tool and plumb it together isn't programming--but people will claim it is. Then when someone asks for an actual program--those people fail. This does not necessarily mean that those people are not productive. However, it does mean that they can't actually function in a position where they are expected to program.
  - dunpeal 8y ago
    > What do these people do all day, if not design and build software? Indeed this is a fascinating question, and I explored it a few times. Some folks who have multiple years of "software engineering" on their resume worked in a place where they did some form of "paint by numbers" programming, producing some work by modifying templates with limited (at best) understanding beyond the specific blanks they were filling. An example is folks who work with large frameworks that are designed to be extended with little to no coding, such as WordPress and Drupal. Then they want to advance to software engineering, so they recast their experience - of essentially configuring and deploying software, i.e. sysadmin - as "programming", and get those 5 years represented as "a full time programming position". There's variants of that, basically "developers" doing very limited ant-work with large frameworks they don't understand and couldn't rewrite from scratch if their lives depended on it. There's also a bunch of languages and frameworks invented for the explicit purpose that someone with little to no CS knowledge of programming talent could produce useful work. Most of us here live in a bubble of startups where we often create products from scratch using lean (or no) frameworks. In reality, a scary amount of the "IT work" out there appears to be what I described above. Possibly a substantial majority.
taneq 8y ago
We always get these kinds of responses when interview testing is mentioned. This isn't some high-level algorithm analysis on a whiteboard with a panel of examiners grilling you. This is a simple test of basic competence. It's like interviewing a candidate Formula 1 driver and asking them "so which bit's the brake pedal?" If they can't tell you that instantly then they shouldn't be applying for the position in the first place. > Please state your last exam conducted under such conditions? University entrance exams. University graduation exams. Any other test that you do which you need to pass to enter or continue your career.
- mixmastamyk 8y ago
  > We always get these kinds of responses… Perhaps you should start listening. > This isn't some high-level algorithm analysis on a whiteboard with a panel of examiners grilling you. Happened to me just three months ago. The req is still open, wonder why? To reiterate: - Exams have a topic known in advance. - Exams never have a person sitting there waiting for the answer. - Exams are never 1 or 2 questions binary pass/fail with incredibly high stakes in unfamiliar territory. Which is the brake pedal? If only.
  - watwat1 8y ago
    No point in being bitter.
  - mixmastamyk 8y ago
    You'll get bitter when the rent is due, watwat.
  - taneq 8y ago
    We're talking about "basic fizz-buzz level coding questions". It sounds like you had a bad experience with something else that we weren't talking about. (As for 'topic known in advance', I'd suggest that if you don't know what topics that you might be asked about in a job interview, maybe you shouldn't be interviewing for that job.)
    - 8y ago
Sophistifunk 8y ago
One possible way to address this issue is by asking candidates to talk about some existing code you give them, rather than trying to cook something up off the bat while under scrutiny and not having access to their familiar tooling.

irq11 8y ago

”I've seen candidates with anything between 1 and 15 years of full time coding work on their resumes fail to answer basic fizz-buzz level coding questions.” I haven’t seen this. I have, however, seen lots of junior interviewers ask idiotic questions and wash candidates out for bad reasons, and then turn around and claim the candidate ”failed at fizzbuzz”, just to cover their own ass (or because they think TopCoder medium questions are “fizzbuzz”. Equally stupid.) Me personally? I’ve never interviewed a senior person who couldn’t code at all. Not after the phone screen, anyway.

dunpeal 8y ago
> I have, however, seen lots of junior interviewers ask idiotic questions and wash candidates out for bad reasons Why are "juniors" interviewing candidates? Let alone juniors asking "idiotic questions", and having decision-making capacity? > then turn around and claim the candidate ”failed at fizzbuzz”, just to cover their own ass Coding questions are among the most quantifiable and objective questions there are. If you know of something even more objective, let me know because I'd love to try it. They are repeatable and have well-defined success criteria. Ideally you have two interviewers in the same room, and it's very clear if the candidate did or did not solve the problem. You can't really fudge it, even as a single interviewer, unless you're willing to outright lie that the candidate didn't write a working solution when he did. > I’ve never interviewed a senior person who couldn’t code at all. Not after the phone screen, anyway. Yes, if you do a coding phone screen, then obviously you're screening out those who can't code. I'm sure you saw some impressive resumes fail that screen, though.
- irq11 8y ago
  ”Why are "juniors" interviewing candidates?” I don’t know if you’ve noticed this, but the average age of programmers these days is just slightly above “right out of undergrad”. If you wait for the senior people to interview everyone, you’re going to be waiting a while. ”Coding questions are among the most quantifiable and objective questions there are.” Bullshit. Coding questions feel objective, and programmers love to pretend they’re objective, but like any other human evaluation process, they’re subjective. It’s not like you automatically get the job if you get the answer right. Unless you’re verifying that your team is generating consistent, reproducible outcomes, I can pretty much guarantee that they’re not.

PopeDotNinja 8y ago

I personally don't care that much on how well a candidate can code, as measuring that is itself quite hard (in my opinion). What I like to interview for is someone who really likes to code. I look for things that demonstrate recent personal growth, ability to explain & teach something they do know, a tendency to avoid claiming they are good at anything, open mindedness on trying new things, etc. In my experience, someone who really wants to code and shows a minimum viable capacity for doing so is the person I want to hire.

dunpeal 8y ago
> In my experience, someone who really wants to code and shows a minimum viable capacity for doing so is the person I want to hire. My comment referred specifically to candidates with at least one year of full-time hands-on development experience under their belt. The typical candidate I interviewed had 3+ years of experience. If you want to code, then you should have ample opportunity to do so during a year or more of full-time employment. If you were working in a full-time programming position for over 3 years yet you can't write even a trivial amount of working code during the interview, then clearly you either lack the capacity or the will to develop your programming skills. Programming nowadays is easy - everyone has a powerful laptop and internet access. It's not like you need privileged access to some $100k time sharing machine using punchcards, and learn machine-language from obscure mail-ordered manuals. What excuse does anyone claiming to "want to code" have for not coding already? I'd be quite suspicious of anyone waxing poetic about their genuine heartfelt love for coding who somehow couldn't demonstrate any coding ability. Would you believe someone who swears they "love long-distance running", but collapses after 50 yards and says they just didn't have the opportunity to put this great love to practice?
- PopeDotNinja 8y ago
  > If you were working in a full-time programming position for over 3 years yet you can't write even a trivial amount of working code during the interview, then clearly you either lack the capacity or the will to develop your programming skills. Genuine question... What kind of question(s) would I ask to get someone to demonstrate they can code? If my questions are effective, I'm fine. But if my questions stink, it'd be easy to overlook that fact that many excellent people wouldn't be able to answer them well.

throwaway080383 8y ago

I also learned this not long after I started conducting coding interviews. People with resumes from the best schools and the best companies would fail in multiple interviews in a row. Nowadays I don't even look at the resume, though to be fair I am only tasked with evaluating coding ability, and not things like culture fit or pay scale.

jldugger 8y ago

> I've seen candidates with anything between 1 and 15 years of full time coding work on their resumes fail to answer basic fizz-buzz level coding questions. Like, how? I used to hire undergraduate student sysadmins / coders, and we had zero candidates fail fizz buzz. None! The worst we saw were people who maybe had an awkward solution to the problem, typically because of unfamiliarity with the modulus operator.

dunpeal 8y ago
I should stress I didn't ask fizz-buzz specifically, but similarly basic questions. I should also stress (again) that back then I brought candidates directly to onsites when their recruiters sent an impressive resume with 3+ years of "full time programming experience". I learned the hard way that most people who unknown recruiters are eager to push through your hiring funnel are unemployed for a reason.

PhasmaFelis 8y ago

True, but give them something they can do at a computer, in an hour or a day or a weekend. Coding on a whiteboard with someone staring at you counting the seconds is not natural. It's like asking someone to do their job backwards and underwater. You'll get a lot of false negatives.