[corysama]

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]

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.

[jakebasile]

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]

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]

> 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]

Fair enough -- but the bullshitters are generally pretty politically savvy :)

[wolfgke]

Thus put them into a position where political savviness will be of no use. :-)

[jakebasile]

The difficulty of identifying poor hires scales with their impact. If they are hard to identify, they are minimally harmful. At a big company, poor hires are diluted by size and revenue. At a small company, it is easier to identify poor hires.

[FullMtlAlcoholc]

The successful bullshitter will prepare himself for the requirements of the job by using the two weeks as an opportunity to become familiar with the relevant tech and code base.

The first 90 days on the job usually don't require much code output. This is more than enough time to either learn what is required for the job. If it's too much, you still can find someone on Fiverr that you can outsource your work to.

[vonmoltke]

> 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.

[serge2k]

> I'd rather take a few bad rejects than a few bad hires.

This is the root cause of interviewing being shitty.

[ng12]

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.

[danieltillett]

Bad hires are not disastrous unless new people are put in charge of critical projects. I continue to take chances on people who might not workout - sure I fire a lot (never fun), but I have also found amazing people that are overlooked by everyone else.

[vonmoltke]

> 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]

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.

[kafkaesq]

After all that it takes at least a few months of settling in to see how they actually perform.

It does? I find incompetent people are generally easy to spot. As in, almost instantaneously (or at most, within a few hours). It's almost as if they want to show you how incompetent they are.

But the "long-term" bad kind? Generally that's not incompetence, per se, but personality issues ("I only wanna do it this way", "I don't want to learn / won't work with people who use X or even don't look down on it like I do", "I just don't give a fuck this company or any of youse", etc). Which by nature are of course much more difficult to spot.

And which are a completely different (orthogonal) set of issues than those addressed... "this idiot didn't immediately see the dynamic programming approach which I knew about already because, of course, I picked the problem. Even when I stared at him impatiently and distracted him with hints" style of filtering which seems to be the goal of the modern hiring process.

[Apocryphon]

Why shouldn't companies invest in training? What's with offloading job training to universities and to the applicants themselves? Yes, HN is a startup-focused site, -'d startups have limited resources. But large tech companies, or at least IBM, had historically trained engineers, at least in the 70s and earlier.

[serge2k]

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.

[ThrustVectoring]

It's a mixed bag. Not hiring good engineers will, ceteris paribus, give bad engineers more chances to luck through your interview process.

IMO, the key thing is that interviews are designed to give political cover for the interviewers to make the hire. If and when bad hires happen, the interviewer can say that their process was technically challenging, even if it did end up rejecting someone like Brendan Eich and passing someone who put 200 hours into Cracking the Coding Interview.

[eschutte2]

I disagree with this. You can get rid of bad hires easily. A single great engineer can transform your entire business.

[ktRolster]

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.

[kafkaesq]

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.

[InclinedPlane]

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.

[DashRattlesnake]

> 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.