Life is too short to work with assholes if it can be helped.
Life is too short to work with assholes if it can be helped.
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".
> 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'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.
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.
"Did their solution to FizzBuzz coded within 20 minutes produce the correct output?" has far fewer mines than "did they communicate clearly throughout?"
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.
[0] https://github.com/EnterpriseQualityCoding/FizzBuzzEnterpris...
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.)
I think determining whether the candidate is kind of a person that I would like to work with in one team should be everyone's area of interview
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.
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.
Or these days, possibly the people with excellent webcam setups?
"Life is too short to work with assholes if it can be helped."