[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. :-)

[azraomega]

If the person who has the power to do that knows it, might as well fire them... why even bother? The person is politically-savvy generally savvy enough to smell it ahead and get promoted else where...

[mattnewton]

I do - The not to be hired pile of resumes.

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

[candiodari]

Have you ever been at a big company where you found more than one or two exceptions to "I just don't give a fuck this company or any of youse", and which one, because I'd love to submit my resume there.

Issue with interviewers is that they invariably think themselves smarter than they are. For instance, just because something has a linear programming solution doesn't mean it doesn't just have a closed form solution too (most software engineers that have interviewed me would say "closed what ?", I feel). I've found, often, on interviews that you have to lower yourself to the interviewers' level to pass. Even when the problem is not so much that the interviewer doesn't know the stuff at all, the problem may be that they don't know it well enough to have a thorough understanding of the problem without preparation (and they never prepare), so they simply can't deal with other approaches. Or they provide a "warmup" question that is ridiculously hard or easy, and don't deal well with the fact that you approach it very different from what they expect for the real question.

Very few engineers, even at companies that claim to be different like Google or Microsoft, truly have a mathematical background in algorithms. This does not seem to stop them from often smugly pointing out the "right" solution from a blogpost that happens to be flat-out wrong, ill-specified and handwavy, to a Math PhD. Putting any math on the whiteboard in such situations is a bad idea. Even just pointing out the flaws in their assumptions ... Constructing a proof that it's equivalent to a well-known problem with lower complexity than their optimal solution does not often end well, as they neither can nor want to understand actual algorithm theory. They don't know the assumptions they use, and never once have I known one to question if the assumptions apply to the posed problem.

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

[munchbunny]

It's not that companies shouldn't invest in training, it's that bad hires will cost you more in training among other things and have little to show for it.

I would sooner invest in training somebody from the ground up, even straight out of college, if I knew that they had the humility to listen and apply their learnings to their job. It'll cost me team resources and it'll take time to get them to where I need them, but as long as I can find junior level work for them to cut their teeth on, I will take them over someone who doesn't learn any day.

The problem is that training is expensive, so I need to filter for people who will give me good ROI on training. I'm not afraid they'll leave. People who feel that they are learning a lot generally won't leave their job unless you're doing something shitty to them.

Which brings us to the common debate about how big the talent pool really is. On one extreme, you have the argument that competence is really rare and the applicant pool mostly sucks. On another extreme the applicant pool would be huge if companies would be willing to train employees. In my experience it's somewhere in the middle: there are a lot of okay people who can do certain jobs to a certain level, but most of them have an immediately visible growth ceiling because they are not as adaptable or reliable as they need to be, and as a manager it's very hard to give such a person more challenging projects to grow into.

Some of this is a managerial problem. Some managers are better at developing talent than others. Some managers are better fits for certain employees.

However, there are also employees that are just not reliable, or culturally toxic, or unable to deliver the level of results you expect for how much you're paying them. You pay the cost for such employees in taxes on team morale, project cohesion, and predictability of execution, all of them leading to projects weirdly taking far longer than they should and ending up far more complex than they needed to be.

So making a bad hire costs you much more than just the money you paid him/her. However, it's not clear that you have more to lose on a bad hire than you have to gain on a good one. That's how I ended up on the "fire fast" approach, but that had its own pros and cons.

[wyclif]

When I've asked this question in the past, the most common reason I've heard is that there's a fear, because of the prevalence of other companies poaching engineers, that money and time spent on training will benefit the company that manages to hire away the trainee (and sometimes a direct competitor).

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

[ng12]

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?

[shados]

really the only part that makes bad hires so bad is the impossibility to get them fired at most companies. Even if you hire someone and realize you've made a grave mistake thats obvious to everyone, some stupid moral value or company culture thing will force people to put up with it for 6 months, then have them be on probation for 6 months, then do an evaluation for 3 months, and by the time you finished the process to fire them, they quit first anyway.

That happened at multiple companies I worked at, both small and large, and it just makes me terrified to hire wrong.

If you're in an environment where you hire fast, but punt fast, you can give more people chances to prove themselves. Honestly, it would help with diversity, too. If people are as good as they claim, they don't have to worry about a thing.

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