Dan Abramov’s recent comments and blog post, really proves that you can’t get a gauge on a potential developer’s value with the kind of one-size-fits-all tech interview that’s become conventional from Google, and more sadly, from companies who think they are Google but only solve smalltime problems.
A couple of years ago I had a coffee with a former coworker who was in charge of hiring in a startup who had recently raised a $12 million Series A. I was lukewarm about the product they were building, but she was trying to get me to apply regardless. She went on to tell me about their interview process, and that it’s incredibly complicated because “good developers love being challenged”.
I remember thinking that’s kind of a misconception. Developers love challenges, but they also love building something of high value — if the interview questions don’t match the skillset that has made them provide value, they’re not going to like it. Developers don’t tend to like challenges for the sake of challenges.
They do however, love being challenged along the road to building something of high value. Whether that’s a highly used open source library, an innovative feature, or a revolutionary new product with a large user acquisition rate. I remember leaving that coffee thinking that there was no way I wanted to apply there! It’s a shame, because I’d love the chance to work with her again.
Back to Dan Abramov, his blog posts and contributions to React have helped me a ton in learning React Native, as they have the whole industry. His knowledge on React and JS, often comes across as unmatched in my opinion — it is the benchmark. Yet he probably would’ve been passed by a Facebook/LinkedIn/Uber clone startup all because he couldn’t implement an interview problem they asked for but 100% don’t actually need.
Then they would’ve missed out on someone who could exceed their expectations in building a breakout product, with outstanding UX, and the user adoption to match.
I regularly swing between thinking that the state of the tech industry in this regard is either hilarious, or truly sad.
Because I can’t stand criticizing without offering solutions, the 2 most qualifying metrics that I’ve come across that have been absolutely flawless in deciding on new hires, or when working with the best developers are:
That’s it. When shaping my interview questions, even technical questions, they all stem from the above 2 assertions! Although my experience is limited in hiring, I’ve also noticed the same qualities in standout coworkers I’ve worked with.
Perhaps these assertions will need refinement some day, if I ever find them to be untrue. These are not concrete, and I try to embrace the open minded mindset of the best developers I’ve been influenced by. But so far they haven’t been untrue, and they only came from the patterns I observed first.
I’m not sure where this arrogance comes from in the startups, banks, and obsolete tech monoliths who are delusional in thinking they’re creating first-time globally innovative solutions. I’ve made the case before if you’re not building an operating system from scratch, you rarely need a deep knowledge on DS and algorithms, and so have countless others.
How many times do new hires have to pass these interview questions before realizing they’re working on nothing but button bugs for weeks at a time, before the joke becomes an embarrassing stain?
The only good that comes from this is that they’ve now become a strong indicator on whether a company is infested with B players — if they care more about hazing rituals designed to turn off the A players and protect the gatekeepers, than the product they’re actully building, it’s a redder flag than any red state red flags in the US.