Technical Interviews Reject the Wrong Engineers

techblueberry

> The deeper issue is tacit knowledge. Most of what a skilled engineer knows is not something they can articulate on demand. Why is it that everyone says that soft skills can be more important than hard skills, that engineers talk to people they don’t sit in rooms turning requirements into code, but then, it seems like one of the criticisms about the interview process is “well, engineers can come up with good solutions when alone in a room” That’s not the job. Articulating technical details when in conversation with your colleagues is.

a-dub

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 right person to do it. good luck!"

zipy124

The main problem is good engineers have no need to sit through your 12 step process. It actively selects only for the most desperate or money driven people (if you pay very well).

IshKebab

Of course. This isn't a secret. But nobody has come up with anything better. Doesn't seem like this guy is proposing anything either.

kadhirvelm

We’ve added collaboration and communication as big facets in our hiring loop rubrics, and reduced the complexity of our questions. We also tell candidates this ahead of time - been honestly working pretty well so far, it indexes more on those soft skills and gives us just enough insight into the hard skills to make a call. We’ve also been increasingly finding very few candidates know how to solve a complex question these days without LLM support lol. How are other folks changing their loops these days?

mathisfun123

don't you people get tired of reposting this take? don't you realize it's exactly like "attractive women reject the wrong suitors" ???

dkarl

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 smart to show my work" bullshit: > And because the interviewer can’t distinguish “skipped steps due to incompetence” from “skipped steps due to operating at a higher cognitive level,” they default to the interpretation that protects their ego. I thought the days of hiring toxic "so smart I can't communicate" superstars was over?

pelagicAustral

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 the final implementation being a 10 or not?

andrewstuart

Even harder with AI. How do you assess developers when AI makes it possible to create software without even knowing the language?

HarHarVeryFunny

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 course the difficulty is how do you assess what the candidate has honestly achieved in prior jobs - what was there personal contribution, and do they seem to have approached things in a way that suggests transferable/general skills that can be applied to the position you are hiring for. The graphic at the beginning of the article is certainly one problem - the interviewer needs to themselves have the experience to assess the candidate. There is no point having someone with 5 years of experience interview someone with 20 years, assuming you are hiring them for that level of experience. I think the best interviewing technique is just to go over the candidates experience, from most recent to as far back as you think is relevant, and get them to talk about each project. What was their role, what were their contributions, why did they make the decisions they did, what might they have done differently, etc. etc. Ask them to summarize and deep dive into the architecture, draw it on a whiteboard perhaps.

sanderjd

I was really hoping for a conclusion section with pragmatic suggestions for how to apply these insights to a real hiring process. I'm left thinking "ok this all makes sense, but what do I do with it?".

tptacek

This post is 2/3rds about accuracy problems with interviews (and, yes, I think the weight of the evidence is that interviews are effectively random functions), and then it culminates in a "FATE" metric that is mostly not about accuracy. Giving candidates feedback is good, but it has nothing to do with the likelihood or cost of a bad hire. Making timely decisions is good ceteris paribus, but it's of secondary importance compared to selecting the right candidate. Same with "effort".

m_m_carvalho

As a former IT instructor, I've seen students who performed brilliantly in exams and interviews but struggled when faced with real-world ambiguity. I've also seen quieter people who were average in interviews become excellent builders once they had a real problem to solve. Interviews are useful, but the ability to ship, maintain and improve real projects should probably carry more weight.

TheGRS

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. I'm wondering if this felt too slow to the interviewer. They sent me a summary document before the meeting, but I couldn't see the code until the interview. I felt like I identified the issue and where to make changes rather quickly, like 10 minutes of looking around and talking through how all the components and APIs fit together. Then the interviewer asked me to implement a datetime solution, which in this time-boxed window my mind raced around to multiple solutions that I talked through out loud: I could write it myself which would definitely take some time for me to remember all of the syntax involved and reason through the problem, I could download an existing library which would also take some time to read documentation, I could google around for existing solutions in somewhere like Stack Overflow which is pretty hit and miss, or I could prompt an AI agent to write a solution for me. I talked through all of these, they wanted to know how I'd do it by hand at first, which I talked through for a bit but admitted I wasn't sure if it was a good way to go about it. Then I said given the time constraints the AI prompt route would probably make the most sense. By the time we arrived at that and tried it for a bit our time was basically up. And I got the impression suggesting AI to help code didn't impress the interviewer at all. If others are able to stand out in this scenario then I guess I'll just admit I'm not the top candidate. My brain just doesn't work that quickly. I like to spend time gathering context and tinkering before really getting into the solution, and that probably doesn't come across well in these situations.

dzonga

let's say you make a saas for automatic birdfeeders. if you can scope out your problem to a simplified version & have a pen & paper / whiteboard discussion with a candidate. the candidate starts from a blank slate. they create their own constraints, validate their own assumptions etc. if they can't design something that works - u can prove this since you already have a working product in production. that way interview takes place in less than 1:30hr. saving time for u & candidate. you cover: communication, critical thinking, technical chops. 3 birds with one stone. but unfortunately most people don't want to do that - because 1. their products r fugazi (fueled by vc money), they're on ego trips (we gonna scale) & lastly want to make interviewing a hazing|humiliation ritual.

pcan77

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 what SOFTWARE engineers have to do to get a freaking job. They think it's asinine, quite frankly and all go "well what did you even go to school for? Don't they know you worked at a Fortune 500 company for over a decade? Why are they having you do trick questions from CS101 courses?" Y'all, it's not that difficult. You can just pretend we're like everyone else because gasp our profession simply isn't that special like we all think it is for some stupid reason.

SatvikBeri

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 disadvantages, but overall I find they're better at finding the people we're looking for than just about every other method. But I'm at a small company, hiring for a fairly specialized team. If the situation was different (e.g. I needed to hire 50 people/year) I'd use a much more standard process.

mattgrice

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.

type0

> Some companies try to add science to the process with personality assessments Soon they'll add phrenology assessments and will call it science

readthenotes1

"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.