Hacker News Reader

Comment by jghn | Hacker News Reader

> and they knew very little about non-proprietary technologies that we used on a day-to-day.

I had an eye opening experience several years ago. My group was partnering with a group at Google. Their developers were sharp, as one would expect. But were very lacking in what would otherwise be considered table stakes, the reason always wound back to they had a proprietary Google equivalent of X, so thus they weren't familiar with X. The one that really hit it home was that we had to teach them how to use Google Cloud, because at least at the time, internally Google folks didn't use GCP but instead used their own internal versions of things.

View on HN

This just shows how dumb it is to require specific knowledge of products of clearly qualified people.

If you're hiring for a specific skill set it might be because you have a target you're trying to hit. In my experience purse strings typically open because the company has a new project they want to complete in N time, and need X additional headcount to accomplish the goal in the time required. If it takes 3-6 months to onboard someone, you might not get your new headcount fully onboarded before v1 of the project ships.

It doesn’t take 3 months to do this even at wholly internal faang environments except in some special cases.

Most of what people are talking about can be learned in days because they’re 90% the same as other products. Sometimes it's hours as someone else said because they're just generic databases or a pubsub system.

And then you get an edge case bug with the new platform and the new guy takes N times longer to find the root cause because it's his first time using the platform.

Or the design is wonky because the new platform isn't a 1:1 match to the proprietary solution.

100% agreed that it's dumb to require extremely specific knowledge of one product, and 100% disagree that a Googler is "clearly qualified" simply because they came from Google. I have absolutely no idea why we've all just accepted the narrative that any FAANG employee is automatically better than the rest of us, despite evidence that FAANGs are nothing more than code mills optimizing for exploitable ambition over actual intelligence or engineering ability.

I'm running into this with increasing frequency, particularly people coming from Amazon. For example, they know nothing about something like Kafka because they've been using some Amazonified version of something similar instead. They of course we'll never be able to match what they used to make and it would be more risk than I want to take to have them use us as a stepping stone while they try to get back to that level.

You can learn everything most devs need to know about Kafka in a couple hours. I can't imagine why companies would ever hire based on current knowledge rather than problem solving skills and ability to learn.

We might be unique, but here's no situation we're using Kafka where someone unfamiliar with it would be able to design and support production level systems to the standards we do after a couple hours. That would result in a time bomb for someone else to clean up later when all the stuff you weren't aware you didn't know becomes a problem. These skills are common, some would say table stakes, so it's not hard finding them as long as you look outside the proprietary tech shops like FAANG, which is why I have no reason to prefer people that don't already have them.

You aren't unique, you're just really bad at training and documentation.

We don't train people on or write our own documentation for any widely used open source tools. We use them as they're provided and don't expect any unique knowledge beyond that. That's a large part of the value in choosing tech like this instead of proprietary solutions we'd have to document and train people on. It's also why a developer with those skills can take them with them from job to job over the course of their career and they're still valuable or start at a new company and make valuable contributions from day one before they learn the proprietary bits of the company.

My initial reaction reading this is that you really screwed up somewhere with your infrastructure. A pretty large company needs a Kafka team, a smaller company needs their infrastructure team to have a decent understanding with maybe one person / consultant with deeper knowledge.

Kafka for 99% of developers in the company should be "Can I use our internal library to read/write some topic".

My preferred size of company would not have the resources for a team dedicated to infrastructure. In companies this size, there would be multiple developers skilled enough with the tech to support it fully from installation, configuration, optimization, backup, DR, upgrades, troubleshooting, designing and implementing solutions, etc. Everything. I've worked at several companies of this size and much prefer the broader scope of responsibility and experience to what you get somewhere like you described.

you sound like a kafka system implementor. why would you hire software devs to implement kafka instead of kafka system implementors?

Outside of FAANG, roles aren't guaranteed to be this specialized. If you can't adjust and expect it to be done like they did it at your FAANG, you're going to have a tough time being productive.

I found my roles in FAANG were more general than my roles in medium/small companies. And typically I have seen one or two people in small companies become the defacto expert in X. Please tell me more about how my life experience is a lie. Each company is different.

> But were very lacking in what would otherwise be considered table stakes, the reason always wound back to they had a proprietary Google equivalent of X, so thus they weren't familiar with X

Occasionally X is an open source implementation of a Google paper, published after Google decided its proprietary tech no longer provides a competitive advantage and/or has moved onto a better architecture internally.

There's an astounding number of Google publications that spawned Billion-dollar industries.

Reply on news.ycombinator.com