Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Technical Interviews Reject the Wrong Engineers

fagnerbrack.com

Post reply on HN
Print view View original

81–90 of 111 posts

Re: Technical Interviews Reject the Wrong Engineers

#81

Post by eudamoniac »

TheGRS wrote: post #41

I'm thinking of a technical screen I did recently where I didn't move forward. The time to do the screen was 30 minutes, and it was where they had a full frontend/backend and I needed to navigate around to fix a pretty arbitrary issue. I'd say this is preferable to a leetcode problem for sure, but also, I do tend to take my time to understand the system a bit before committing to changes, I mean this is sight unseen.…

So it took you 15-20 minutes in an interview just to decide on the method by which you will begin to implement "a datetime solution"?

Re: Technical Interviews Reject the Wrong Engineers

#82

Post by eudamoniac »

pcan77 wrote: post #57

I love how people in this thread are ABSOLUTELY BAFFLED at "how do we do this a better way." How about the same way doctors, lawyers, and literally everyone else does it? Look at credentials, schooling, past experience, references and personality interviews rather than 99% leetcode? I have lawyer, doctor, etc friends (aka high up professionals who get paid what we do or more) and they think it's absolute insanity wha…

This doesn't work when there are terrible devs somehow stealing paychecks from big companies for years, not even mentioning interview fraud. I've interviewed credentialed people who can't write fizzbuzz. Until tenure and credentials indicate skill, they can't be used!

Some companies I think do indicate skill, like a L5 at Google can do fizzbuzz I'm sure, but somewhere like Cisco or random small startup might as well be nowhere. As for education, no CS program in the country is a guarantee.

Re: Technical Interviews Reject the Wrong Engineers

#83

Post by cmrdporcupine »

sanderjd wrote: post #69
Aurornis wrote: post #59

Earlier quoted context omitted.

Hiring based on gut feeling about how impressive the candidate feels can be misleading when you only do a little hiring. It can work for small samples sizes if you have a strong front end filter or you are primarily getting candidates through trusted referrals. Then one day you encounter a candidate who is great at impressing people. They leave you feeling excited with the possibility of working with them. You feel d…

I'm certain that this is true. It certainly sounds true. But honestly, does anyone here have experience with doing this kind of interviewing at scale, for experienced software engineering roles? I've been in the industry for coming up on a couple decades, and I have been involved in doing lots of interviews at times, and in that whole period of time, at every company where I've worked, we did the standard multi-round…

Yep.

When the money was raining from the sky and compensation bands were going up and you could land some job with, like, free food and microkitchens and massage points and whatever...

Then fine. I guess it's worth the drama in the interview. Those places had potential boatloads of false positives and could afford all the false negatives from potentially bogus interview processes. I trained to do interviews at Google twice and I thought the process was stupid, but it was the price of admission into their fish tank of privilege.

But now the whole process feels ridiculous. You'll grind through an interview and get the prize, and still feel in a state of total insecurity after you get the job.

Re: Technical Interviews Reject the Wrong Engineers

#84

Post by jghn »

eudamoniac wrote: post #82
pcan77 wrote: post #57

I love how people in this thread are ABSOLUTELY BAFFLED at "how do we do this a better way." How about the same way doctors, lawyers, and literally everyone else does it? Look at credentials, schooling, past experience, references and personality interviews rather than 99% leetcode? I have lawyer, doctor, etc friends (aka high up professionals who get paid what we do or more) and they think it's absolute insanity wha…

This doesn't work when there are terrible devs somehow stealing paychecks from big companies for years, not even mentioning interview fraud. I've interviewed credentialed people who can't write fizzbuzz. Until tenure and credentials indicate skill, they can't be used! Some companies I think do indicate skill, like a L5 at Google can do fizzbuzz I'm sure, but somewhere like Cisco or random small startup might as well…

This is such a tired canard. Do these people exist? Yes. Assuming you can hold an in depth, detailed technical conversation with them I'd contend the percentage of these people is astonishingly low. We spend way too much mental energy defending against them.

The real problem is not enough interviewers can discuss in depth technical bits themselves, and thus they can't get signal when talking to a candidate.

Re: Technical Interviews Reject the Wrong Engineers

#85

Post by HarHarVeryFunny »

tptacek wrote: post #34
HarHarVeryFunny wrote: post #26

The main goal of hiring someone should be to assess how well they can do the job you are hiring for, and for anyone with job experience (i.e. not fresh out of college) the best indicator of that is what have they previously achieved (especially in more recent years). How well someone can solve a whiteboard challenge or brainteaser is irrelevant unless you are hiring someone to solve 10min whiteboard challenges. Of co…

Experience-based interviews are a fantastic way to select for candidates who have "failed up" through a long series of jobs. The underlying dynamic is that it usually takes more than a year to sever a technical employee; you can faceplant in a role and still wind up with a resume improvement.

Sure, that's a risk, but that's part of the purpose of an interview - both to discover what they claim to have done, and to assess how accurate that is. This is the purpose of asking about decision making processes, alternatives, architectural summaries and deep dives, etc - if they really did everything they claimed then all relevant details should come rapidly and fluently.

The problems with the alternative - interviewing based on problem solving and coding challenges are:

1) For the most part it doesn't work. Companies like Google, that have reflected on and assessed their own interviewing success, have come to the conclusion that there is little correlation between how well people interviewed in this style do on the interview vs how well they perform on the job. This is a pretty low bar to beat!

2) If you are interviewing for 10-20-30 year senior with a track record of success and adding value, how can you possibly hope to assess that via problem based challenges, especially if conducted by a less senior developer who doesn't themself have the skill set and track record you are hiring for? How do you know if the person just talks a good game and can throw around high level concepts, or can actually deliver?

I do think there is some value to problem solving as a small part of the interview process, but certainly not if this comes at the expense of ignoring the candidate's actual experience and accomplishments which is the best indication of what they are capable of.

Re: Technical Interviews Reject the Wrong Engineers

#86

Post by JamesSwift »

SatvikBeri wrote: post #70

Every interview method has some glaring flaws, and I find you mostly have a choice of which flaws you pick. On my current team, I care a lot about the ability to write fast code. The most important part of my process is a take-home designed to take 2 hours where the main goal is to solve a relatively easy problem as performantly as possible. Answers have varied from 0.2ms – 50ms. Take-homes have some obvious disadvan…

Hmm thats a pretty interesting variant. I dont think it would apply directly to our team, but I like the potential playground it gives for both coming up with solutions as well as being a kickstarter for convos on alternatives.

Re: Technical Interviews Reject the Wrong Engineers

#87

Post by tptacek »

HarHarVeryFunny wrote: post #85
tptacek wrote: post #34

Earlier quoted context omitted.

Experience-based interviews are a fantastic way to select for candidates who have "failed up" through a long series of jobs. The underlying dynamic is that it usually takes more than a year to sever a technical employee; you can faceplant in a role and still wind up with a resume improvement.

Sure, that's a risk, but that's part of the purpose of an interview - both to discover what they claim to have done, and to assess how accurate that is. This is the purpose of asking about decision making processes, alternatives, architectural summaries and deep dives, etc - if they really did everything they claimed then all relevant details should come rapidly and fluently. The problems with the alternative - inter…

I have zero confidence in the ability of interviewers to reliably and repeatable parse out subtle characterological details in candidates. Like I said, the interviews you're talking about are essentially random functions.

Google has notoriously one of the worst hiring processes in the entire tech industry.

Re: Technical Interviews Reject the Wrong Engineers

#88

Post by TheGRS »

eudamoniac wrote: post #81
TheGRS wrote: post #41

I'm thinking of a technical screen I did recently where I didn't move forward. The time to do the screen was 30 minutes, and it was where they had a full frontend/backend and I needed to navigate around to fix a pretty arbitrary issue. I'd say this is preferable to a leetcode problem for sure, but also, I do tend to take my time to understand the system a bit before committing to changes, I mean this is sight unseen.…

So it took you 15-20 minutes in an interview just to decide on the method by which you will begin to implement "a datetime solution"?

I'm hand waving the exact times, it was probably talking through how to filter by datetime a specific way for maybe 5 minutes followed by some discussion around these other ways to go about finding a solution. It was filtering by date starting from the beginning of the week. I searched around for a little bit since I didn't really know how to do this off the top of my head. Found a function that did what I wanted, then ran into type issues, more flailing around trying to get this working. I'll fully admit I didn't ace this.

Re: Technical Interviews Reject the Wrong Engineers

#89

Post by HarHarVeryFunny »

tptacek wrote: post #87
HarHarVeryFunny wrote: post #85

Earlier quoted context omitted.

Sure, that's a risk, but that's part of the purpose of an interview - both to discover what they claim to have done, and to assess how accurate that is. This is the purpose of asking about decision making processes, alternatives, architectural summaries and deep dives, etc - if they really did everything they claimed then all relevant details should come rapidly and fluently. The problems with the alternative - inter…

I have zero confidence in the ability of interviewers to reliably and repeatable parse out subtle characterological details in candidates. Like I said, the interviews you're talking about are essentially random functions. Google has notoriously one of the worst hiring processes in the entire tech industry.

> Like I said, the interviews you're talking about are essentially random functions.

Only if you are REALLY bad at interviewing !

And what's the alternative - you want to hire someone to head up your infrastructure modernization based on acing LeetCode challenges and drawing a few diagrams on the whiteboard ?

Re: Technical Interviews Reject the Wrong Engineers

#90

Post by tptacek »

HarHarVeryFunny wrote: post #89
tptacek wrote: post #87

Earlier quoted context omitted.

I have zero confidence in the ability of interviewers to reliably and repeatable parse out subtle characterological details in candidates. Like I said, the interviews you're talking about are essentially random functions. Google has notoriously one of the worst hiring processes in the entire tech industry.

> Like I said, the interviews you're talking about are essentially random functions. Only if you are REALLY bad at interviewing ! And what's the alternative - you want to hire someone to head up your infrastructure modernization based on acing LeetCode challenges and drawing a few diagrams on the whiteboard ?

Google invests huge amounts of money and time into their process and I am repeating a conclusion they arrived at about their own process.
Post reply on HN