Can confirm as a senior engineer at a FAANG. I've rejected people for showing negative non-technical traits but being ok technically, and recommended people for hire with not the best technical skills but with excellent non-technical/leadership traits.
Life is too short to work with assholes if it can be helped.
Although this is welcome to hear, it's not something a candidate can count on reliably nor something they can really control. After all, a candidate can come off as likeable to one interviewer and unlikeable to another.
Versus just being able ace through leetcode problems - that's a more objective criteria a candidate has more control over.
Personal anecdote. I interviewed at a FAANG, got rejected. They actually offered feedback, and one of the key reasons I apparently got rejected was that "I asked too many (clarifying) questions" about the leetcode problem.
Fast forward a year, I retry. I take the above feedback to heart, and refrain from asking too many questions. I get rejected again, and given feedback. One of the reasons given? "I asked too few questions".
> candidate can come off as likeable to one interviewer and unlikeable to another.
> I apparently got rejected was that "I asked too many (clarifying) questions" about the leetcode problem.
> I get rejected again, and given feedback. One of the reasons given? "I asked too few questions".
It sounds like they didn't like you _personally_. If the rejection reason wasn't due to technical or behavioral mismatch but a fake reason like the ones above, it's the often the problematic "Airport test" (ie. They don't want to be stuck in an airport with you"reason).
And to be clear, I think it's wrong to reject candidates because you personally can't think of "being friends" with them. It's unfair to both the candidate, but also the company as it misses out on great engineers.
> I've rejected people for showing negative non-technical traits
I'm not an expert, but this can be a really slippery slope to implicit bias creeping in to your hiring decisions, especially if these traits are outside of your area of interview/expertise.
Not selecting or evaluating for soft skills is worse than potentially slightly increasing exposure to implicit bias.
Furthermore, I would bet that in the long run, selecting for soft skills helps drive down real observed implicit bias. (People with better soft skills are probably better at managing their own implicit biases.)
This assumes that your soft skills evaluations are more colored by implicit bias than your technical evaluations. Everything is colored by bias, it's just different kinds of bias. And stuff being inside your area of expertise is no defense against bias. You might subconsciously assume someone doesn't know certain technical things and simply not bother to ask the question.
Eh, seems to me some minefields have a lot more mines in than others.
"Did their solution to FizzBuzz coded within 20 minutes produce the correct output?" has far fewer mines than "did they communicate clearly throughout?"
I think reaching the correct solution is one of the least important parts of a technical interview.
I've interviewed candidates who will write the equivalent of enterprise level fizz buzz [0] and get to a correct solution, and candidates who will write much simpler code, but not quite solve the problem (it's a longer problem than fizzbuzz). I feel like I get better signal off the latter, as we can spend more time discussing their ideas, Vs writing boilerplate.
The "culture fit" interview which is standard in tech companies today is nothing but an avenue to introduce whatever bias the interviewer wants with no oversight, no explanation.
I can see how it can do just that, but I explain our "culture" as best I can before evaluating candidates against it.
Example: My workplace has a great deal of change, bordering on ambiguity. We need people who can deal with that and thrive in that environment. So, my interview questions aim to find out if the person is going to thrive in an environment where they might have to find their own way, or if they are the kind of person who likes to take directions and stay in a specified lane.
In this case, adaption to change is part of our culture - you're either a good fit or you aren't.
This isn't necessarily true. You can have rigor around your value/culture fit questions. In our process, we require strong reasons for both yes and no decisions (especially for culture fit). If an interviewer says no "because X" we look for similar signal to have shown up in other parts of the loop (performed by different people). If only one interviewer sees a signal, we are careful to analyze it for bias.
It's def a slippery slope, but all of hiring is bound by implicit bias. If random people are evaluating random people against a set of subjective metrics, you're always going to get _some amount_ of bias in your decision making.
In reality, I think a surprising amount of bias goes into "tech screening", maybe even moreso than evaluating "soft skills." If you're asking random engineers at your company to conduct tech screens, the odds that those engineers are emotionally and mentally reflective enough to be fair and bias-free in the questions they ask and the solutions to those questions are very low. This is why so many places struggle with tech interviews that feel like debates. Engineers dislike candidates that do well on the tech portion of the screen because those engineers feel it is a competition that they must "win". I've seen this time and time again at FAANG and non-FAANG. Random engineers from a team should not be assessing candidates, pretty much ever.
In some cases you are effectively screening out senior engineers that have pretty much reached their plateau. They won't learn anything new and they don't want to learn anything new.
There's a difference between 10 years of experience and 10x one year of experience.
What I meant is that I've met senior engineers who were senior by virtue of having spent a long time in the industry but not because they were any better than a fresh grad.
Also that some seniors simply stopped learning at some point, which is pretty bad for the majority of dev roles. They won't learn for the new role and push whatever they used at last N roles because that's all they know.
Not being an asshole, being able to help teams work together and not be assholes to each other, and having okay technical skills is my true value proposition.
Life is too short to work with assholes if it can be helped.