Hacker News Reader

Comment by em500 | Hacker News Reader

“Moving down” can be more difficult than it looks. Anecdotally, employers can be reluctant to hire “overqualified” people (indicated by a high previous salary), because they believe these people will jump ship at the earliest higher paying opportunity elsewhere.

View on HN

I don't think an elevated salary at a FAANG implies over-qualified, though.

I phone-screened someone from a FAANG, and they knew very little about non-proprietary technologies that we used on a day-to-day. Any of the big-branded commercial apps, they weren't familiar with, and I can hire someone for a lot less with the required working knowledge AND know that they won't be resentful about it.

I think it's going to take a year for some of the young engineers to level-set their careers in some places.

I'm trying to remember how long it took after dot-com bubble busting, and back then I know a lot who went back for their MBAs, Law degrees, etc. during a softening market. And I know personally how long it took for me to recover to the same economic level.

Also, I get emails a few times a week from recruiters saying something like "Ex-Meta Employee/ex-Faang available for employment", leads....

> 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.

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.

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.

> 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.

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

Day-to-day tools are things that really takes no time to learn on the job imo. They take more time to get up to speed from scratch but when dropped into an environment using them I expect experienced folks to get up to speed very quickly.

If they resent not having the awesome dev tools though, like you mention, that's another thing entirely.

I think they resent the fact that they'll make 175K/year for senior level work.

Wouldn't anybody jump ship for a better job, though?

Sure, but an ex-FAANGer probably has a better shot at actually getting hired at another FAANG (when the job market improves) than someone who's only worked at no-name shops or local governments.

The implied logic behind that is "I know my company is a worse option than many of the other ones out there, so I'm going to only hire people who those other companies would not do business with." It's inherently a low self-esteem attitude.

People leave, sometimes suddenly and without warning. The high self-esteem way to deal with it is to do your best to provide an attractive working environment, accept that some people will leave, and try to learn from each departure. That way you have the option of profiting from the talented employee who totally could make more at a FAANG but happens to like your company because you provide good management, a worthwhile purpose, or the actual ability to write code rather than deal with company politics.

Reminds me of this chestnut: "We don't train our people! What if we do, and they leave?" "What if you don't, and they stay?"

Heck, having someone sharp with a new perspective even for a year could significantly improve things for the better. If you get out of their way of course.

New employer has no reason to know previous pay.

They can infer it from the employer name or just buy salary market data

Unless they're small they have HR, and HR has the time to do the research.

Which is logging into Glassdoor or levels.fyi and checking. Shit you can do that right now and get some rough ballparks.

If you were a Senior SWE at Google for 5 years, how do you imagine that a new employer won't realize that you were making a lot more than the $150K/yr they're proposing to stretch their budget to offer you?

Reply on news.ycombinator.com