4 ms·

Yup, I don't enjoy coding interviews, but the number of people I've interviewed with ostensibly many years of programming experience who can't actually write so

by dmoy 9y ago

Yup, I don't enjoy coding interviews, but the number of people I've interviewed with ostensibly many years of programming experience who can't actually write some basic code with a for loop and a couple of variables makes me extremely hesitant to hire without a coding interview. If you haven't run across people like this yet, you simply haven't done enough interviews yet, or have somehow entered into an alternate fairytale land where everyone is honest (and if so please take me with you!).

jsjohnst 9y ago
> or have somehow entered into an alternate fairytale land where everyone is honest This won't likely be a popular answer, but more likely than what you described above is simply that you don't know how to weed out the bullshit a candidate might spew without shoving a code editor or dry erase marker in their hand. It's perfectly understandable that many don't have this skill as it's rarely ever taught before you start doing interviews at an employer.
- paulddraper 9y ago
  > you don't know how to weed out the bullshit a candidate might spew without shoving a code editor or dry erase marker in their hand I'm sure we could figure out a non-code non-marker way. I'm also sure I could figure out a commute involving only right turns. But why would I arbitraily constrain my solution like that?
  - jsjohnst 9y ago
    Continuing your strained analogy, so because you didn't want to make only right turns, everyone else should spend an extra 10min in traffic each morning? The reason to "constrain your solution" is to not rule out very capable candidates who have "stage fright" and not offend other very capable candidates who take offense to your crappy brain teaser problems that don't actually reflect anything they'd do in their real job.
    - paulddraper 9y ago
      > don't actually reflect anything they'd do in their real job I should hope the coding exercise would reflect what they would be doing! Finding logic bugs, munging data, using appropriate data structures, recognizing recursion, etc. If coding isn't a significant portion of the job (researcher, manager, etc.) then yeah, don't put it in the interview.
      - jsjohnst 9y ago
        > I should hope the coding exercise would reflect what they would be doing! Sadly, I have not found this to be the case almost anywhere I have worked or interviewed (seems to be especially relevant the bigger the company is).
- srean 9y ago
  Being particularly gullible, I sure would appreciate tips on how to weed out the lies.
markbnj 9y ago
I think the problem with this approach is you're actually selecting for a related skill that might have little to do with whether the candidate will be successful. Some people are very good at doing the work but don't perform well under "social" pressure, while others may be very good at dissecting a small thing in the interview context and yet be unable to follow through on a large, complex task. The company I work for solves that issue by combining front-end interviews with a homework project of reasonable scope, followed by a paid work-along day. It takes more time and investment than running through some coding exercises on the phone, but results in a more cohesive team because we know before we hire not only whether someone can do the work, but also whether they can do the work with us.

by dmoy 9y ago

jsjohnst 9y ago

> or have somehow entered into an alternate fairytale land where everyone is honest This won't likely be a popular answer, but more likely than what you described above is simply that you don't know how to weed out the bullshit a candidate might spew without shoving a code editor or dry erase marker in their hand. It's perfectly understandable that many don't have this skill as it's rarely ever taught before you start doing interviews at an employer.

paulddraper 9y ago
> you don't know how to weed out the bullshit a candidate might spew without shoving a code editor or dry erase marker in their hand I'm sure we could figure out a non-code non-marker way. I'm also sure I could figure out a commute involving only right turns. But why would I arbitraily constrain my solution like that?
- jsjohnst 9y ago
  Continuing your strained analogy, so because you didn't want to make only right turns, everyone else should spend an extra 10min in traffic each morning? The reason to "constrain your solution" is to not rule out very capable candidates who have "stage fright" and not offend other very capable candidates who take offense to your crappy brain teaser problems that don't actually reflect anything they'd do in their real job.
  - paulddraper 9y ago
    > don't actually reflect anything they'd do in their real job I should hope the coding exercise would reflect what they would be doing! Finding logic bugs, munging data, using appropriate data structures, recognizing recursion, etc. If coding isn't a significant portion of the job (researcher, manager, etc.) then yeah, don't put it in the interview.
    - jsjohnst 9y ago
      > I should hope the coding exercise would reflect what they would be doing! Sadly, I have not found this to be the case almost anywhere I have worked or interviewed (seems to be especially relevant the bigger the company is).
srean 9y ago
Being particularly gullible, I sure would appreciate tips on how to weed out the lies.

markbnj 9y ago

I think the problem with this approach is you're actually selecting for a related skill that might have little to do with whether the candidate will be successful. Some people are very good at doing the work but don't perform well under "social" pressure, while others may be very good at dissecting a small thing in the interview context and yet be unable to follow through on a large, complex task. The company I work for solves that issue by combining front-end interviews with a homework project of reasonable scope, followed by a paid work-along day. It takes more time and investment than running through some coding exercises on the phone, but results in a more cohesive team because we know before we hire not only whether someone can do the work, but also whether they can do the work with us.