Hacker News Reader

> most of the senior engineers I know have spent considerable time on both sides of the interviewing table. At different points in their career, they've been the ones asking questions as well as the ones being interviewed. This leads to a lot of cross-pollination of interview techniques as well as different perspectives on what works vs. what doesn't.

I'm one of those engineers. The company I currently work at has no problem finding and hiring competent engineers. I also have no problem suggesting something better than what most companies do. And yet, whenever I interview at other companies[0], the most common interview experience I still have are the horrible ones described time and time again here.

The sort of "cross-pollination" you refer to is not widespread.

[0]: A few times a year, just to keep my feet wet.

> At one point, I tried directly asking candidates how they'd prefer to be interviewed in a way that best highlighted their talents.

This is really cool to hear from someone else. I've done a similar thing, asking "What do you think you could do during a technical interview to best showcase your skills?"

I too got a surprising number of terrible/generic answers, though it very likely could have been nerves in the moment.

>but I also had a number of "just trust me when I say that you should give me this job" type answers.

Is that really so far out? In many lines of work, you're expected to be trained into the position. My experience in software is that each company thinks they want someone who already knows X, Y, and Z, and can hit the ground running with no training.

But in reality, the hire will likely spend more time maintaining P & Q, and working on S, and will need quite a bit of domain knowledge as well as knowledge of the company's custom code and practices and internal organization before they're fully ramped up. And by the time they'd even get to work on X, Y, and Z, the company has likely moved on to A, B, and C, which almost everyone there is just learning.

It's a job that requires constant learning, and you're going to need to train your new hires whether you like it or not.

That's why when I'm called on to be the one asking questions, I mostly look for whether they enjoy learning and experimenting, whether they can have fun with old stuff and convey the differences between that and the new stuff (and why they're different), and whether they're open-minded or stubbornly convinced that they know the one true way.

That's the sort of thing you need when your old system has a decade+ of custom code and the dust hasn't even settled on the new system enough for the pros to know the right ways to do things with it yet. What you really need is someone with basic skills that's also open to being trained and learning new things.