Hacker News Reader

Comment by EpicEng | Hacker News Reader

I don't know where you work, but I have never had the luxury of 2.5+ months to get a position filled if we can help it (and it's silly to assume that the work required behind the scenes to get this all working would result in no gaps between candidates, so more than 2.5 months).

I also don't typically have the luxury of having great candidates in front of me who will wait multiple weeks to get into some weird one week eval (and they usually have a job already, so how are they going to get away for a week?). This is a time consuming and expensive proposition which would require buy in at multiple levels from multiple departments and would probably end up not working out so well.

View on HN

I've never worked in any company that was able to fill any position faster than 2.5 months. Everyone clamored that we needed to fill positions fast, but then endless, nauseating political debates about minutiae on resumes and tiny flaws during in-person interviews took over, and it would just drag on.

I once was taken almost completely away from my engineering duties for a period of a whole month to help almost full time with what was a "critical" position that needed to be filled "now". A year and half later, when I decided to leave that company, they still had not hired for that position, and had an endless list of why every candidates didn't make the cut (and we had interviewed some excellent candidates who got thumbs up from all of the technical staff who had interviewed them).

It's different everywhere, but in general for a competent tech worker with about 3+ years of experience, I'd say you're looking at at least 6 months to find someone, probably closer to a year, not because there fails to be a supply of good candidates, but because that's just the time penalty for internal politics.

While this particular anecdote happened at an established firm, I experienced nearly the exact same thing in start-ups as well, literally the same political bullshit excuses used to reject otherwise great candidates even when we were "desperate" to hire someone.

Thank you, this was almost exactly what I was going to respond with. My only addition:

"Alternatively, we can write/review some code on a whiteboard."

It's well documented that whiteboard exercises are terrible for evaluating candidates. A lot of people, developers especially, don't perform well under pressure (stress reduces cognitive ability). Not only that, but you will also alienate a great many experienced candidates.

If you are OK with all that, fine I guess. But I thought it was widely agreed upon that the software industry needs better hiring practices.

If by "well documented" you mean "lots of people have whinged about it at great length", then I guess you're right. It's also a "tried and tested" method, too, so it's got that going for it.

I think if you approach them correctly (like the author suggests), then actually they're fine for their intended use. (Not perfect, but this is the real world, nothing's perfect).

If you can't cope with scrawling some pseudocode on a whiteboard because that's "too much pressure" then you're going to really struggle when a deadline looms and we "absolutely must get this code out to the customer by Friday because a $50M contract is on the line."

> If you can't cope with scrawling some pseudocode on a whiteboard because that's "too much pressure" then you're going to really struggle when a deadline looms and we "absolutely must get this code out to the customer by Friday because a $50M contract is on the line."

First, "scrawling some pseudocode on a whiteboard" and "we absolutely must get this code out to the customer by Friday because a $50M contract is on the line" are not the same thing and it is fallacious to use performance on one to infer performance on the other. "Stress" is not some universal feeling that differs from situation to situation only in amount. It has types, which different people handle differently.

Second, related to my response to a sibling comment, if "we absolutely must get this code out to the customer by Friday because a $50M contract is on the line" has a high enough probability of occurring that it is worthwhile to screen candidates for ability to handle this, your company is fundamentally broken and you are trying to use your hiring to compensate for the real problems.

> If by "well documented" you mean "lots of people have whinged about it at great length", then I guess you're right. It's also a "tried and tested" method, too, so it's got that going for it.

You are wrong. Just because it's most used currently doesn't mean it's better. And it is actually well documented.

@tokenadult posted this numerous times: https://news.ycombinator.com/item?id=4879803

What do you mean by "well documented" exactly? Are you referring to the numerous blog posts where people in the industry complain about it? I wouldn't call that extremely convincing.

I understand that some people get stage fright, but I'm not expecting them to come up with a perfect solution; I'm only trying to get an idea of how they think (and whether or not they can actually write code). If they can't do this sort of thing in front of a small group then how are they going to perform in group meetings? Are they just going to sit quietly in the corner the entire time?

I can't have that either, and I need some sort of measuring stick. I'd rather lose a good candidate than take on a bad one.

Admittedly, whiteboard exercises are not good, but what better alternative is there that will not take an order of magnitude more time?

> A lot of people, developers especially, don't perform well under pressure (stress reduces cognitive ability).

A lot of places value people who work well under pressure. (A bad push taking down all the server's I'd stressful)

Meaning a lot of places have shitty processes and architecture and try to compensate by hiring people that fit their broken system. Case in point: having an architecture so fragile that a bad push is capable of taking down all your servers.

Trivial to have a breaking DB change or a software push where the only part of the app that works is the little part that tells the load balancer, "yep, I'm alive and healthy; send some traffic my way".

There are probably way more successful (100-million to couple billion dollar revenue) companies that can be brought offline with a bad push than can't.

Or a load balancer push that ignores the 'yep, I'm alive and healthy' bit and sends traffic anyways.

Oh please. Even the best systems will have issues, and there will always be high pressure situations, regardless of the competency of management. It shouldn't be a way of life, but it's simply not practical to expect easy sailing at all times.

Reply on news.ycombinator.com