Hacker News Reader

Comment by hinkley | Hacker News Reader

The all day interview process selects for a kind of person who is confortable with arduous processes. With poor scalability.

IMO any team with an SLA should be avoiding these people like the plague, because they will tolerate bullshit manual processes that take all day. They have no motivation to make foolproof automated processes with good visibility and repeatability. The smartest of them will fight attempts to change the status quo because the status quo makes them look good and everybody else look like idiots.

Three of my favorite bosses were from the Fire All Heroes school of management. Two actually gave a speech to that effect in front of the entire engineering dept. They helped me get out of the hero racket.

It’s great to be needed. But it sucks being the bottleneck.

View on HN

My problem is that it's all cargo cult, and none of it is rationally thought through to pursue desirable qualities in an engineer.

Even within Google, Facebook, Amazon, and Microsoft, you're usually being interviewed by a fresh-out-of-school 20-something who has no idea how to do much of anything, let alone evaluate candidates fairly. And yes, they "train" these kids -- but you basically can't train someone to do something that relies heavily on intuition. That requires experience, but 20-somethings don't have experience. So instead, they're "trained" to do the one thing you can do repeatably: ask coding puzzle questions from a book, and reject anyone who doesn't regurgitate answers with 100% fidelity. It's the McDonald's food of interviewing: not the best (or even good), but consistent across a large organization. Sort of.

So while big companies need people who can work on a team, exercise good judgment, communicate clearly, write clean code and not be racist/sexist/evil jerks, they get...people who can memorize questions from a big book of programming questions. I can easily come up with tests that get to each of those properties...but they rely on interviewers having good judgment, and most do not.

I get itchy when I get asked to write code that I would veto in a code review.

My internal dialog when asked things like a linked list or a hash table is "Oh god, does this mean they like code like this? I bet some 'clever person' at this company wrote their own hash table/event queue/template engine* and forces everybody else to use it."

* Unfortunately my current employer is just like this but I didn't pick up on that in the interview process.

You and me both. And it feeds itself, too, because every line of code is an opportunity to reinvent the wheel or do something clever (it sometimes seems like they want to see that, or else this class of question wouldn’t be asked??).

The downsides of avoiding the algorithmic interview process is that you will end up hiring people who talk a very good game, but cannot write code to get out of a paper bag.

One of the most painful interviews I have ever seen was a guy who had a resume listing a number of interesting projects. He could talk energetically and in detail about them. Then we asked him to write some code to solve a simple problem. He said he didn't know our primary language, but was very familiar with Python. I know Python, I was good with that.

He didn't know Python. I tried to help him, but he didn't get much farther. I eventually called the interview, with a complete 180 of my hiring opinion. Nice guy, but he couldn't be what we needed.

This is a real problem. If you are hiring coders you have to have a couple people in the team go deep on coding chops to ferret out the charlatans. Personally I like to show people a piece of code from a big system they've never seen and let them walk me through what it does and what they would change to make it work better. Some teams I work with also give 'homework' exercises, which I believe is fairer than trying to do it in front of somebody else. (Unless that's how you actually write code on a day to day basis.)

Good interview processes reflect complementary broad and deep concerns. It's kind of analogous to the way a strong team is better than the sum its parts.

> Personally I like to show people a piece of code from a big system they've never seen and let them walk me through what it does and what they would change to make it work better.

This could be the first coding interview style that actually makes sense to me

You can easily do programming problems without algorithm questions.

I don’t think I’m against the algorithm part as strenuously as I am against the gauntlet part. You shouldn’t be locking someone in a room for 6-7 hours and then judging them on how they keep their cool, for many reasons, including those I mentioned above.

As I mentioned elsewhere I think you can ask questions that look like work but aren’t (go too far the other way and you’re into IP problems)

Can you please elaborate more on the Fire All Heroes philosophy? I looked into it and couldn't find anything describing it in depth

I’ve only met a couple people who say “fire”. That’s a little overwrought. The less dramatic version is “we are too big for heroes” which unpacks into something like this:

You don’t want an organization that relies on one or two or three people to swoop in and save the company every time there’s an emergency. A production issue should look like disaster preparedness. Document, train, drill, prevent.

More concretely, make the important parts as obvious as you can, as similar to production as you can, so anyone can set up a system and try to repro the problem. Config, build, and deploy should be push button (very robust scripts with every cheap sanity and safety check you can manage). No flakiness is okay. Nor obscurity. Everybody should understand how it works.

Document everywhere diagnostic data comes from and goes to. Don’t let your most senior people solve production issues; assign them to people one step down (and throw in some promising mid-level team members for diversity and longevity). Five why’s every outage and be sure your resolutions always involve making the problem easier to detect next time, not just prevent.

Thank you! That was a great explanation. I like it wrapped up in such a memorable phrase

Reply on news.ycombinator.com