Live data from Hacker News

Technical Interviews Reject the Wrong Engineers

fagnerbrack.com

71–80 of 111 posts

Re: Technical Interviews Reject the Wrong Engineers

#71
post #50

Earlier quoted context omitted.

I don’t want to put my future coworker through six rounds of interviews. If it takes more than three rounds + a phone screen to figure out if someone is a good fit then the process is broken.

Depends how long the rounds are. 6 rounds of 20 minutes is only 2 hours. If you think that’s unreasonable, please go ahead and add a few fire sauce packets to the bag for me.

Whether it's reasonable depends on the distribution, not just the duration.

A 2 hour onsite with the candidate being rapid-fire interviewed by six different different teams and a 20 minute call every couple weeks for three months are very different (and select for very different types of candidates) despite having the same overall duration.

Re: Technical Interviews Reject the Wrong Engineers

#72
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.…

It often selects for a confident first shot, which is why we see these orgs drift towards lots of engineers who can blast out code but cannot maintain or evolve any existing systems proficiently. On rare occasion that is even the hiring goal!

This is the exact problem. Some people can flip between one shotting for interviews and going deep for real work, but they are extremely rare.

As a senior, I would much prefer a candidate who can discuss options more than write code - the writing itself is secondary, especially with AI. I want to see someone grapple with tradeoffs, clarify what they know and what breadcrumbs they want to follow before committing to a solution.

Re: Technical Interviews Reject the Wrong Engineers

#73
post #25

I don't understand why can't someone just come up with an interview where they propose an issue that is truly something that can be expected in the role, give the applicant a few hours to come up with an action plan and a solution architecture, put it down in writing, sketch some graphs, and then present it... Why is that so groundbraking? wouldn't that immediately tell you a lot about the applicant, regardless of th…

These are called take-home interviews. They exist and applicants HATE THEM for being too long/"free work".

In my experience most candidates actually love them. They prefer the lower pressure and better relevance to the job.

If you give candidates the choice between a short take home or a 1-hour on-site technical round, almost everyone picks the take home. We’ve tried it.

It’s only online that you get the rants about “free work”, but the people making those complaints usually hate on-site technical interviews equally.

Re: Technical Interviews Reject the Wrong Engineers

#74
I think there is a misconception that FAANG type coding interviews are trying to find stars. They aren't, otherwise they would not cap the difficulty and have a bank of approved questions which can be crammed via leetcode.

They are testing for diligence just like exams in Confucian based systems.

Re: Technical Interviews Reject the Wrong Engineers

#75

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…

Or there's potentially this: that the skills we think are universal and transferable ... are not. That our industry is so bespoke and different and non-standard around tech stack organization and work culture between shops that in fact someone could have been performing top tier at their previous jobs and just completely not function in your workplace. And because we have a recency and confirmation bias around your o…

We see this occasionally in consulting: a strong performer will sometimes land in a gig that turns out to just not be a good fit for them. We know it happens, we make a point of watching out for it, and we can correct for it when it occurs - but we can't reliably predict who it'll happen to, and in what circumstances.

Mostly, they simply move off to another gig where they return to their previous strong performance. Occasionally they take a hit to their self-confidence and take a while to get back up to speed (we try hard to mitigate this, but it does happen). But sometimes they'll take a break, work out what was causing the poor fit, and come back much stronger than before.

It's not unreasonable to expect a similar pattern outside of consulting - it's just that, for perm staff, the psychological barrier to cutting your losses and moving on are much higher.

Re: Technical Interviews Reject the Wrong Engineers

#77
"They found that avoiding a toxic worker generates roughly twice the return of hiring a star performer."

This is very true and one of the easiest ways to find that out is to put people into a pressure situation and see how they respond.

And of course, you need to find out if someone has a famous clue of how to go about solving problems.

Re: Technical Interviews Reject the Wrong Engineers

#78
post #18

This article repeats what we've long known about how technical interviews aren't great at evaluating technical skills and inadvertently filter for things that aren't important. But it doesn't offer a better way of evaluating technical skills. It talks about how to evaluate other things that do matter but aren't substitutes or proxies for technical skills. Also, this argument is some grade school smarty pants "I'm too…

I helped out with interview prep and coaching a while ago.

One of the unexpected hardest parts was getting people to open up to the idea that they needed to improve something about their communication in interviews. It's so easy to comfort yourself with fictions about the interviewer failing to recognize your qualifications due to their own ego or other explanations. There are a million blog posts, Tweets, Reddit posts, and angry internet comments that will validate these feelings. Getting rejected and then going to the internet to validate your feelings of being wronged is so much easier than trying to reflect on how you could have done better.

Doing mock interviews for people was exhausting due to the time commitment, but it's one way to try to get around the defensiveness that comes from being rejected for a real job. Even with that, some of the mock interview candidates would get angry with the feedback and try to argue with you. It's weird to see. Nobody likes feeling evaluated and judged, so imagining an explanation that shifts the problem to the other person protects their ego.

Re: Technical Interviews Reject the Wrong Engineers

#79
post #18

This article repeats what we've long known about how technical interviews aren't great at evaluating technical skills and inadvertently filter for things that aren't important. But it doesn't offer a better way of evaluating technical skills. It talks about how to evaluate other things that do matter but aren't substitutes or proxies for technical skills. Also, this argument is some grade school smarty pants "I'm too…

An easy way out might be to just ask the candidate how they got from one step to another. That way you can differentiate between “toxic, so smart i can’t communicate” and “non-toxic, so smart that i honestly thought the step seemed trivial, but would be happy to explain if i was mistaken about that”.

Re: Technical Interviews Reject the Wrong Engineers

#80
post #5

here's an idea for an "experienced" technical interview structure. "we care about x, y and z. you have forty five minutes to convince us that you will meaningful help us achieve our goals. we then will take 30 minutes to push on technical details as we see fit. you will be judged based on technical content, choices, taste and your overall approach and strategy for moving us forward and convincing us that you're the r…

> we care about x, y and z. you have forty five minutes to convince us that you will meaningful help us achieve our goals. we then will take 30 minutes to push on technical details This part is good. > as we see fit. you will be judged based on technical content, choices, taste and your overall approach and strategy for moving us forward and convincing us that you're the right person to do it. good luck! This part is…

I do agree with your assessment, on both parts, but I think it could survive with minor tweaking.

"We are going to push on the technical details, both those we agree with and disagree with. This is where the rubber meets the road. You've painted a picture, how does it stand up to scrutiny and challenge. In the end, while there may not be perfect alignment, we're looking to see how your ideas go through the process of validation and how we get there, communication, exploration, and collaboration-wise."

Post reply on HN