Hacker News Reader

Comment by malvosenior | Hacker News Reader

This is a pretty good manifesto. Something that I rarely (never) see mentioned is that the ability to quickly evaluate a technical hire is a skill managers can and should cultivate. I never give coding tests. I sit down with a candidate and within 20 minutes of verbally discussing their prior projects I know if I want to hire them or not. This does mean that the manager has to be technical and have the ability to deep dive in these conversations. It's by far the most efficient and candidate friendly (and interviewer friendly!) method I've seen. I've never had a bad hire doing this and I've hired dozens of people

View on HN

I was hired with a very similar process. I was asked several technical questions that applied to the role and about my own history, etc. Three years later I'm still here and have survived several rounds of layoffs and a sale of the division of the company I work for. I still work with that manager.

Most interviews with tech screens that I've done have been fine, though. A couple of them have been bad where I've recognized the engineer testing me has been wrong but that never fares well for the person being interviewed.

Most calls I take are often an introduction before we even go to a tech screen, though, and I appreciate that chance usually. It's saved interviewers and myself a lot of time in the past.

Your story about surviving layoffs implies that you survived because the interview thoroughly vetted you. Wouldn't that be true of people that were laid off?

It doesn't imply anything except that I'm still working with that manager and we've worked well together. At the time I was the only technical hire under a technical manager. Much of the business isn't technical and weren't part of the same interview process.

I understand what you're trying to ask, but no—it doesn't apply in this case.

Even if we take your word that you have a zero false positive rate how would you even know what your false negative rate is?

I don’t understand why so many seemingly otherwise scientifically minded people swear by anecdotes when it comes to hiring.

What does false negative matter for? As you said, you cannot know it, so why bring it up as a missing metric? What matters is if they hired for their demand, and their hires met or exceeded expectations

We cannot know it by anecdote. We can know it using a well designed longitudinal study. Why settle for the former? Why do so many proudly refuse to read the literature?

The only other thing I can compare to the anti-intellectualism around hiring is a similar phenomenon around nutrition and dieting.

I mean, I think you're planting your flag in some intellectual what aboutism. The confidence in the strategy of the process here is only as anti-intellectual as it is simultaneously conducive to that actual work trying to be accomplished.

Say a man marries a high caliber lady. Beautiful, smart, great personality. If he says, 'I did great here'. Does anyone say to him, 'Well what was your false negative rate?'. I guess you might

You ever read one of those interviews with a centenarian where they ask him what his secret is and he answers something like “I smoke a cigar every Sunday”?

Yeah

As a manager my goal is to hire the team I need to accomplish the tasks we have to deliver. This method has worked really well for me. It also means my relationship with my direct reports starts out based on trust, which has also worked out great for me as I often re-hire people from old teams when I move to a new company.

I've often been surprised by what has come out in a coding test that hasn't emerged in a conversation. People who seemed dull and uninspired in conversation ended up being brilliant and vice versa. There's no substitute I think.

The trick is to get good at having those conversations so you can get to the bottom of someone's skills even if they're not outgoing, good at speaking... It's totally doable but it's on the manager to develop those skills.

There are a lot of excellent developers who do not code well in an interview context. Nerves, artificial restraints... coding is something that happens once you're in the flow. That's a state few can achieve in an interview.

It's rather like saying that you can interview a musician without asking them to play.

Yes, nerves play a part. That's why it's good to start easy and ramp up difficulty gradually, giving the interviewee a few easy wins to build up their confidence before getting them in to the harder stuff.

Frankly I find the most unnerving interviews (coding and questions) to be the ones where you have to second guess what the interviewer wants to hear. Where the question/task is difficult, but the desired outcome straightforward it's much less stressful.

It's closer to saying you can hire a songwriter without asking them to write a song in front of you. A musician gets paid to perform in front of people. Asking them to do that in the interview is exactly the skill they're looking for.

Spot on! Or take the Funnyman scene from Boondock Saints where a criminal boss tells a guy, "They tell me you're a Funny Guy. Tell me a funny joke." "Now? A joke? Uh... um, uh... A joke. Yeah, alright. Um... <awkwardly starts an offensive joke>... I'm not funny today. I-I know. I'm havin' a hard day. I-I-I- This joke sucks. It's-it's-it's a stupid joke."

That's kind of like how I code when sitting down for an interview, whereas I have no problem otherwise. My coding looks like an awkwardly told joke (oftentimes).

If all I had to do was pick some code I had memorized and practiced and "perform it", i.e. type it out, then yeah, sure, no problem. But I get asked to come up with the answer to something on the spot, something I usually take a little time to settle into, maybe do some Googling, etc, and always seems to be something I missed when spending several days to a week refreshing my memory on what I think I'm going to be asked ahead of the interview.

You’d probably ask a songwriter to share some prior songs, not ask “tell me about a time you had to work with a difficult co-worker” and trust your gut to tell you how that translates to song writing ability.

I don't know how hiring a songwriter actually works in the music business, but I would imagine it has the same issue that programming has. It's very difficult to objectively assess the quality of work in a vacuum. Discussing the process and mindset behind a work is often more helpful than only looking at the end product itself.

What kinds of things do you ask? I’ve interviewed and worked at FAANGs. I’ve done mostly coding and design interviews. I don’t doubt your ability but help me understand your model. Is it more open ended (tell me about your previous projects... candidate can speak to the problem domain, design, implementation choices, trade offs, or dive deeper into “Oh yeah we had to instrument events to feed into data processing pipelines for personalization...and XYZ failed so I had to do ABC.”) or is there something more critical?

I start pretty open ended, then ask specific questions about their choices. I almost always ask them to describe some of the schema of the db or how pieces of their project were communicating with each other... I also ask them what they like about their language of choice and why. I keep the questions specific to their projects and experience though.

I should add that I strongly favor candidate with open source experience, so most of the time I'll have also looked at their code myself and may have some questions about it.

The number one thing I look for is: can this person ship software? I'll ask a lot about the project lifecycle, what they did to get it across the finish line, how they supported and enhanced it... I try to do this in a non-leading way.

> "I should add that I strongly favor candidate with open source experience, so most of the time I'll have also looked at their code myself and may have some questions about it."

So, that's the most important part missing from your original comment. From that, I would assume that you never hired a developer without looking at their code before/after an interview. Is that right to assume?

Basically open sourced code (and not the interview) act as a substitute for coding tests in your process

No, I've hired plenty of people who haven't had open source contributions. It just makes the conversation easier when I can see their code beforehand. I also find that the really good people tend to do open source or personal projects, so there's a high overlap there.

So you so hired plenty of people without never looking on code they wrote?

How that variable affects the outcome? Is your hiring process any better/worse comparing when you can read their code and when you cannot read their code?

Reply on news.ycombinator.com