Hacker News Reader

Comment by JimmyRuska | Hacker News Reader

A young recruiter asked me how I interview people. I asked him what his favorite video game was. Super smash brothers, he said. I asked if he could ask enough questions to gauge how much of an expert someone was. He said, "of course!" Asking a lot of general questions about a number of things and encouraging them to go into detail often shows if they've been there, done that, and shared in the same blood sweat and tears. Especially when people get excited, it's great to see how they thought about things and how they'd approach the same problems knowing what they know now.

Hiring bad people in engineering can cripple your services. Adding code that's hard to understand, has poor time complexity, or is over-engineered can add more technical debt that any one feature is solving for, and reworking that code can cost way more time than it originally took to write once it's part of some production service.

View on HN

That's a great metaphor. I think your "do they get excited" test is likely going to fail for a number of neurodiverse folks nervous about their big interview for the pro Smash circuit in exactly the same way. They've bled the same way but they're more likely not to pass your filter, which is the problem.

But you need a filter for exactly the reason you described, so the mystery is what kind of filter lets in the smash experts who best contribute to your team and not just the ones who get excited in the right way in conversation. And that's a flippin' hard problem, hard like learning to take priority into account. What the hell, Fox's blaster has transcendent priority? How is that even a thing?

> Hiring bad people in engineering can cripple your services. Adding code that's hard to understand, has poor time complexity, or is over-engineered can add more technical debt that any one feature is solving for, and reworking that code can cost way more time than it originally took to write once it's part of some production service.

So use code reviews prior to merging, and prevent that code from becoming part of that production service. If they're then unwilling to incorporate that feedback into their code, it might be time to review their contract.

Edit: Assuming people are capable of reviewing each other's code.

Yes, of course. Problem is: senior supervision is a limited resource.

So even if you had perfect code review, you'd only want to hire people that produce code that actually makes it through the review with less hassle for the reviewers than it would be for the senior folks to write the code themselves.

In practice, code review is imperfect. You want to hire people with good taste and good skills.

The last place I worked, the junior engineers reviewed the interns code. There weren't enough senior engineers to review the junior engineers code, so we ended up reviewing each other's code.

I was pretty green at the time, so we just ended up with a terrible codebase after being there for a few years.

It was already bad to begin with, but that's because it seemed like what that company does is churn through junior engineers and interns at the nearby university to get their shoddy projects done.

TLDR: If you hire too many bad or junior engineers, you're going to lose control of your project since you might not have time to review all their code.

Strong support from technology alleviates the problem.

If your linter already complains about bad indentation, your senior devs can concentrate their limited time on more substantive issues.

Of course, that scaling by technology has limits.

Reply on news.ycombinator.com