Title is misleading. By “You Can’t Fix It” the author means “You Can’t Get an Interview Process with 100% true positive rate and 100% true negative rate”. OTOH, they conclude that you can improve your process.
Generally when we talk about fixing compound things rather than individual issues, we mean improving them. For example, fixing up one’s home does not mean making it perfect, but making it better. “I got my car fixed” does not mean my car is now perfect, it means that there existed some issues and I had the relevant ones resolved. On the flipside, fixing an issue in the bugtracker means that the issue is, y'know, gone (except when you use everyone’s favorite fix: WONTFIX). In some sense that is “perfect”, but within a very limited, tiny scope.
I would feel bad about being so pedantic about this, but the title comes off as almost clickbait in the sense that “and You Can’t Fix It” is just begging for attention, only to switch the bait with an unconventional-but-still-defensible definition of “Fix”
EDIT: Not trashing the content of the piece though; it is actually a pretty solid list of issues with common interview strategies.
Good point. I prefer the title “All processes are broken,” despite it giving inadequate context.
Generally when we talk about fixing compound things rather than individual issues, we mean improving them.
I’m not sure. A lot of rhetoric about “X is broken and the way to fix it is Y” takes fixed versus broken as binaries. Lots of start-up, in fact, bill themselves are the way to fix hiring. Saying essentially that there are problems here but no magic way to fix them is taking a somewhat different view I’d say.
The overarching point really resonates with me. Near the beginning of our hiring process I explain to the candidate all the steps in the process and why each step exists. I acknowledge the process isn’t perfect and express gratitude for the candidate bearing with our imperfect process. I also ask the candidate if she has any questions or concerns before we move on to the next step. The vast majority of feedback on the process I receive from candidates is positive, and good candidates do persevere to the end.
Hang out with them until you can get a bead on whether they are as good as they say they are. If you’re going to pay someone upwards of 70 grand, you can afford to spend some time connecting with that candidate. Hang around long enough that they loosen up at least a little bit. You’re not going to catch everyone, but you’ll do a lot better than companies who spend a very brief interview with a candidate. See how they interface with other teammates.
Also above all else, keep your questions relevant to the work at hand. If I don’t need to know it to do the job, why are you asking me this? I have and will always turn down jobs like that, simply awful.
This biases you towards people who are naturally sociable. Some people just never loosen up. Even after working with them for years and seeing them produce reams of fantastic code, they come across as uneasy. And that’s fine.
The problem is that you have, at best, a day or two to guess at the candidate’s ability. And while there’s often a ‘definite no hire’ within 15 minutes, it’s often hard to see how people you’re not sure about will perform. Any attempt to make the hiring process more accurate usually involves a trial period, which drives away many people who already have jobs or have multiple offers, and reduces your talent pool significantly.
I don’t know if the core problem – evaluating someone accurately, in depth, in a limited amount of time – is a solvable one.
I was quite unclear, and I’m sorry. My intention was not to shut out the socially inept, but if they are working in a team they need to be at least capable of communicating with their team, or at the very least capable of doing so in document form. Clammy is fine, being unable to work with peers isn’t.
Hang out with them until you can get a bead on whether they are as good as they say they are.
This is an approach that feels good but is actually just straight up a bad idea.
keep your questions relevant to the work at hand.
I sortof agree with this one but sortof don’t. It’s better not to match the questions too closely to the work at hand - e.g. I’ve had pretty good luck with coding questions where the candidate is explicitly told they can write the solution in whatever language they like (I usually combine this with the homework approach). In general, testing abstract skills that are probably relevant to the job is better than testing skills that don’t have anything to do with the job. e.g. testing someone can correctly read and implement a spec is good, testing someone can do fancy algorithmic juggling is probably a red herring.
I have and will always turn down jobs like that, simply awful.
I kinda get frustrated by people who do this. I understand where you’re coming from, but the world is full of bad opinions about interviewing, and full of bad interviews, and the way to figure out what the hell we’re doing is through experimentation. It’s much harder to experiment if when people get an interview question they don’t like they get offended and walk out.
OTOH there are a lot of bullshit interviews and sometimes life is too short, so *shrug*.
Respectfully disagree on the first point, you’re about to spend a few thousand dollars a month on this person, and if you mess up you’re out minimum several thousand dollars. What you’re ideally selecting for is someone who will work well with your team, and someone who is able to learn. I respect that there are risks for biases, but that’s why we have competency tests not just social interaction.
To the second, relevant doesn’t mean tightly match, so yes I agree.
To the third, if someone walks out it means your experiment gave you a very clear result. Gotta crack some eggs to make an omelette. Sure you might not hire them, but they probably weren’t a good fit with your culture anyway.
I was surprised that the article mentioned “homework” as a strategy but not the similar option of “pay them to solve a relatively small problem you’re actually having and judge their solution”.
I was also saddened that it had nothing to do with either of these two posts.