7 ms·

I've been giving a lot of interviews lately. It has been really difficult to come up with questions that don't end up turning into "guess my magic answer". As

I've been giving a lot of interviews lately. It has been really difficult to come up with questions that don't end up turning into "guess my magic answer". As a result, I spend the majority of the time talking through work they did in the past with the primary goal being to determine "what did the applicant actually do on this project?" As opposed to simply hanging around the team or flipping switches to enable pre-packaged features.

ng12 10y ago
Here's the problem I have -- how do you avoid hiring professional bullshitters? Wouldn't the guy who put together the PowerPoint for upper management sell himself better than the guy that actually wrote the machine learning system? I've just known too many people who are better talkers than coders. at least with CtCI-type questions you can't really lie or stumble your way through it. I'd rather take a few bad rejects than a few bad hires.
- ktRolster 10y ago
  I've heard that at one company, the interviewer sits down with you and you program together for an hour. That is the extent of the interview.
- serge2k 10y ago
  > I'd rather take a few bad rejects than a few bad hires. This is the root cause of interviewing being shitty.
  - ng12 10y ago
    And it's the totally right thing to do. Bad hires are disastrous and have a much greater impact than missing out on a few pretty good engineers because they didn't think to use dynamic programming. Programming interviews aren't perfect, but the reality is there aren't better alternatives.
    - vonmoltke 10y ago
      > Bad hires are disastrous and have a much greater impact than missing out on a few pretty good engineers because they didn't think to use dynamic programming. Citation needed. I frequently see the dangers of false positives exaggerated and the costs of false negatives downplayed.
      - ng12 10y ago
        Aside from the monetary cost of hiring them, you're making the team less productive. Time is spent training, on-boarding, doing their code-reviews, and after all that it takes at least a few months of settling in to see how they actually perform. Tthere's also the opportunity cost -- whatever project you had hoped they could tackle is now months behind and at best all you have is some slapshod code you'll need to rewrite anyways. Of course there are gradients to bad hires, but the really bad ones are a terrible experience for everyone involved.
        serge2k 10y ago
        Do you have any actual numbers? Links to studies? The rhetoric is that a bad hire is pretty much the worst thing ever, and it's used to justify absurd interview practices.
        ng12 10y ago
        https://business.stackoverflow.com/blog/how-hiring-has-an-effect-on-your-bottom-line-what-ctos-should-know https://business.stackoverflow.com/blog/how-hiring-has-an-ef... Several citations in there, but it seems like a common sense thing to me. Why interview at all if you're so willing to take on the risk of a bad hire? Just take them out for lunch and ask them how they like coding. It's also bad for recruiting purposes. If I have an easy interview I'll be reasonably assured that my future coworkers went through that same process -- what metric do I have to assume they're going to be good engineers to work with?
        danieltillett 10y ago
- jakebasile 10y ago
  What is the end game for this hypothetical professional bullshitter? Let's say you hire someone who can successfully bluff past your interview. They come in on the first day, do all the HR forms, get their computer and start setting it up. Eventually they will be assigned a task, or pairing, or whatever it is you do. At this point what happens? If they are able to do the job they did not bullshit you. If they are able to do the job but not as well as you wanted, then maybe it wasn't bullshit but slight exaggeration. If they completely cannot do the job, they were obviously bullshitting. At this point, what happens? If they can actually do the work, then you are fine. If they can actually do the work but not as well as you want, maybe they can be trained. If they are completely incapable of doing the work, every state is At Will, and though I know from personal experience firing someone is no fun, that is the risk you take. I believe the threat of someone talking a good game but being unable to produce is vastly overstated. It absolutely happens, but the harm is minimal.
  - ng12 10y ago
    This relies on being able to accurately identify poor performing engineers, which is very tough at a big company. What I've seen happen is they hang around for a year or two, jump from failed project to failed project, until they either find a niche role where they can do no harm or run out of options and get fired -- but at that point they have a year or two on their resume and will find it that much easier to get the next gig.
    - vonmoltke 10y ago
      > This relies on being able to accurately identify poor performing engineers, which is very tough at a big company. "Very tough"? The only big company I ever worked at was a more traditional engineering company, but identifying the poor performers was easy. The problem was the politically-savvy poor performers who used their savvy to shield themselves.
      - ng12 10y ago
        Fair enough -- but the bullshitters are generally pretty politically savvy :)
- vonmoltke 10y ago
  > Here's the problem I have -- how do you avoid hiring professional bullshitters? You poke at their bullshit until the stench is overwhelming. I personally find a variation of "Five Whys" questioning very useful. Bullshitters can only go a level or two deep and so trip up fairly quickly.
- kafkaesq 10y ago
  Here's the problem I have -- how do you avoid hiring professional bullshitters? I don't know, specifically. But not asking bullshit questions would seem to be a good place to start.
DashRattlesnake 10y ago
> It has been really difficult to come up with questions that don't end up turning into "guess my magic answer". Yeah, that's a really hard thing to do. I try to think of many solutions to the problem I'm giving ahead of time, but that takes a lot of time and I know I'm not going get each one.
InclinedPlane 10y ago
There are two kinds of questions worth asking in a coding interview, in my opinion. Very straightforward questions that should be solved by anyone with familiarity with the relevant techniques (basic programming, bit-wise operations, multi-threading, depending on the level you want to hit) basically as fast as they can write. And open ended questions which require a lot of back and forth dialogue and design and give you a chance to gauge the experience and overall maturity of the candidate. These are depth / basic competence versus breadth questions. You simply can't expect to get a much better read than that in an hour, even working side by side with someone for a year you won't necessarily have a good sense of how good a dev they really are, you're not going to find that out in an hour or a day for sure. The best you can hope for is to gauge basic competence and make a guess at sophistication and maturity then hope for the best.

ng12 10y ago

Here's the problem I have -- how do you avoid hiring professional bullshitters? Wouldn't the guy who put together the PowerPoint for upper management sell himself better than the guy that actually wrote the machine learning system? I've just known too many people who are better talkers than coders. at least with CtCI-type questions you can't really lie or stumble your way through it. I'd rather take a few bad rejects than a few bad hires.

ktRolster 10y ago
I've heard that at one company, the interviewer sits down with you and you program together for an hour. That is the extent of the interview.
serge2k 10y ago
> I'd rather take a few bad rejects than a few bad hires. This is the root cause of interviewing being shitty.
- ng12 10y ago
  And it's the totally right thing to do. Bad hires are disastrous and have a much greater impact than missing out on a few pretty good engineers because they didn't think to use dynamic programming. Programming interviews aren't perfect, but the reality is there aren't better alternatives.
  - vonmoltke 10y ago
    > Bad hires are disastrous and have a much greater impact than missing out on a few pretty good engineers because they didn't think to use dynamic programming. Citation needed. I frequently see the dangers of false positives exaggerated and the costs of false negatives downplayed.
    - ng12 10y ago
      Aside from the monetary cost of hiring them, you're making the team less productive. Time is spent training, on-boarding, doing their code-reviews, and after all that it takes at least a few months of settling in to see how they actually perform. Tthere's also the opportunity cost -- whatever project you had hoped they could tackle is now months behind and at best all you have is some slapshod code you'll need to rewrite anyways. Of course there are gradients to bad hires, but the really bad ones are a terrible experience for everyone involved.
      - serge2k 10y ago
        Do you have any actual numbers? Links to studies? The rhetoric is that a bad hire is pretty much the worst thing ever, and it's used to justify absurd interview practices.
        ng12 10y ago
        https://business.stackoverflow.com/blog/how-hiring-has-an-effect-on-your-bottom-line-what-ctos-should-know https://business.stackoverflow.com/blog/how-hiring-has-an-ef... Several citations in there, but it seems like a common sense thing to me. Why interview at all if you're so willing to take on the risk of a bad hire? Just take them out for lunch and ask them how they like coding. It's also bad for recruiting purposes. If I have an easy interview I'll be reasonably assured that my future coworkers went through that same process -- what metric do I have to assume they're going to be good engineers to work with?
        danieltillett 10y ago
jakebasile 10y ago
What is the end game for this hypothetical professional bullshitter? Let's say you hire someone who can successfully bluff past your interview. They come in on the first day, do all the HR forms, get their computer and start setting it up. Eventually they will be assigned a task, or pairing, or whatever it is you do. At this point what happens? If they are able to do the job they did not bullshit you. If they are able to do the job but not as well as you wanted, then maybe it wasn't bullshit but slight exaggeration. If they completely cannot do the job, they were obviously bullshitting. At this point, what happens? If they can actually do the work, then you are fine. If they can actually do the work but not as well as you want, maybe they can be trained. If they are completely incapable of doing the work, every state is At Will, and though I know from personal experience firing someone is no fun, that is the risk you take. I believe the threat of someone talking a good game but being unable to produce is vastly overstated. It absolutely happens, but the harm is minimal.
- ng12 10y ago
  This relies on being able to accurately identify poor performing engineers, which is very tough at a big company. What I've seen happen is they hang around for a year or two, jump from failed project to failed project, until they either find a niche role where they can do no harm or run out of options and get fired -- but at that point they have a year or two on their resume and will find it that much easier to get the next gig.
  - vonmoltke 10y ago
    > This relies on being able to accurately identify poor performing engineers, which is very tough at a big company. "Very tough"? The only big company I ever worked at was a more traditional engineering company, but identifying the poor performers was easy. The problem was the politically-savvy poor performers who used their savvy to shield themselves.
    - ng12 10y ago
      Fair enough -- but the bullshitters are generally pretty politically savvy :)
vonmoltke 10y ago
> Here's the problem I have -- how do you avoid hiring professional bullshitters? You poke at their bullshit until the stench is overwhelming. I personally find a variation of "Five Whys" questioning very useful. Bullshitters can only go a level or two deep and so trip up fairly quickly.
kafkaesq 10y ago
Here's the problem I have -- how do you avoid hiring professional bullshitters? I don't know, specifically. But not asking bullshit questions would seem to be a good place to start.

DashRattlesnake 10y ago

> It has been really difficult to come up with questions that don't end up turning into "guess my magic answer". Yeah, that's a really hard thing to do. I try to think of many solutions to the problem I'm giving ahead of time, but that takes a lot of time and I know I'm not going get each one.

InclinedPlane 10y ago

There are two kinds of questions worth asking in a coding interview, in my opinion. Very straightforward questions that should be solved by anyone with familiarity with the relevant techniques (basic programming, bit-wise operations, multi-threading, depending on the level you want to hit) basically as fast as they can write. And open ended questions which require a lot of back and forth dialogue and design and give you a chance to gauge the experience and overall maturity of the candidate. These are depth / basic competence versus breadth questions. You simply can't expect to get a much better read than that in an hour, even working side by side with someone for a year you won't necessarily have a good sense of how good a dev they really are, you're not going to find that out in an hour or a day for sure. The best you can hope for is to gauge basic competence and make a guess at sophistication and maturity then hope for the best.