Hacker News new | past | comments | ask | show | jobs | submit login

What levels of SDE usually have hire for fire at Amazon? SDE I? II?



Hire for fire feels like an urban myth. We do a lot of work to find you, interview you, hire you, and train you. Managing someone out is also a lot of work.

That being said a company as big as Amazon will always have edge cases.


The myth I heard was: Manager has 10 employees who are absolute rock-star engineers. They love their team, work great together, and deliver amazing results.

This manager obviously doesn't want to hurt this awesome team or lose any members, but Amazon wants them to churn out the bad engineers (which this team may not have).

So instead of finding faults where they don't exist, our manager hires 2 engineers with little to no chance of working out in the team long term, give them some busy work, puts them on a PIP, then eventually fires them, only to soon replace them with two new victims.

It sucks to be a victim, and it sucks to knowingly do that as the manager, but it does work out great for the team and the manager - so I think it could happen (maybe not super common, but it isn't unrealistic in my mind).


That's the problem with applying a curve as a rule. In a large org it's probably true across the board. But there will be outlier teams. How does an org handle those?

You can critique Amazon for basically saying "don't worry about it" so managers may invent plans like hire-to-fire to game the system and overall someone's gonna get screwed on that team, but it's a tough problem to solve - otherwise, what's to stop managers from all simply claiming "no, my team's a special case"? Introduce special cases and it'll just be gamed through that mechanism.

I'm a firm believer that if you want to avoid things like that you have to avoid large organizations. A large organization is highly incentivized to be bureaucratic so to minimize the effects of unexpected losses and to keep the money machine running.


>otherwise, what's to stop managers from all simply claiming "no, my team's a special case"? Introduce special cases and it'll just be gamed through that mechanism.

You lost me. Why should we want to stop managers from saying that?


You got the myth part right: having a single team with 10 rock-star engineers.

1. Amazon isn't so special that even they can control the distribution curve to only have rockstars,

2. This is too big for a single team in the first place, let alone 10 rockstars,

3. You don't want any rockstars, let alone only rockstars on your teams,

4. Managing low performers is a magnitude more work than solid performers; no manager would do this to themselves on purpose. It would be easier to cut their 2 least rockin' stars.


I hate that some people say rockstars and mean ‘really great developers that write beautiful working well documented code quickly and work great as part of a team’.

And other people say rockstars and mean ‘assholes that churn out new features really fast with incomprehensible code and then leave others to maintain their monstrosity as they move on to the next thing”.

I assume Amazon is large enough to have a team somewhere with 6-10 of the ‘good’ version, and also a team somewhere with 6-10 of the assholes.


> Managing low performers is a magnitude more work than solid performers; no manager would do this to themselves on purpose. It would be easier to cut their 2 least rockin' stars.

Then what do you do a year (and a half for Amazon) later for the next cycle?

One of the many problems with stack rank cull N% of your employees every year is that "every year" part. At whatever level it's mindlessly applied, if the company wants to keep it at the same head count you by definition have a steady churn of hires, which I'll grant you won't always be good, and fires.


If 2 pizzas can’t feed 10 people, the chances are there are some health questions to be asked about a given team.


> Hire for fire feels like an urban myth. We do a lot of work to find you, interview you, hire you, and train you

Your unspoken assumption here is that recruiters, HR and managers have perfectly aligned incentives. It is trivial to find instances when this is not the case - e.g. a high-performance team being forced to fire their "least effective" member[s]- this relies on the theory that talent is uniformly distributed across Amazon.


Amazon manager here: I just did a mental count of our URAs while I have been at Amazon. More than 3/4 are new hires fired in less than a year.

Hire-to-fire is neither a conspiracy nor a conscious tactic. It's the natural consequence of what we managers are put into.

If HR wants you to URA someone out, who would you rather lose? The experienced SDE who is productive and is responsible for projects you don't want delays in; or the new hire who's still trying to learn company tools.

That's why hire-to-fire is a thing.


It's cheaper to allow an employee on the low end of HV transfer in from another team.


I wouldn't say it's a "usual" thing at all, but more common the lower your level. L4 or SDE 1 has highest risk for negative personnel actions in general for 2 reasons: there are a ton of people in this level and many of them are early career and don't know how to protect themselves from corporate politics.


Early-career person here. How do you protect yourself from corporate politics?


You don't have a lot of control over that if you're not a manager. Early career politics is basically your relationship with your coworkers and your manager.

Ideally you'll have coworkers that want to succeed and want you to succeed so that you are all open to learning from each other.

Sometimes you have a coworker who has gaps in their knowledge and is insecure (or sometimes that person is you). To avoid politics there, just help that person feel secure -- find things to learn from them or find ways they can help you.

Maybe a coworker is burnt out and doesn't have the energy to work as hard as you can. Learn what you can from them too, help them feel important.

Maybe your manager is overloaded with work. Figure out what their responsibilities are so you can prioritize what you work on in a way that makes their life easier.

Basically: politics is inevitable but you should just be new, make friends, have empathy, and let things fall into place.


This advice to avoid politics by becoming a people pleaser is not a bad strategy to attain the goal, but it might come at the cost of your sanity. The only way to be not involved in politics is to totally accept the current situation and to align your goals and interests with those in power.

This is the type of behavior that causes mid-life crises.


> The only way to be not involved in politics is to totally accept the current situation and to align your goals and interests with those in power.

At a small, young, growing company, that's what the company needs - if your goals aren't aligned with the company's, you are going to be spending scarce resources on the wrong things.

If there's a way, in a larger company, to prevent "necessary alignment" from turning into "political gamesmanship," I've never seen it. If the people in control of your fate have goals that aren't perfectly aligned with "overall health of company" then now it's games and bullshit and it gets real hard on the individuals. And that can happen very easily: Director X wants to be promoted to VP, needs to show results in their domain, maybe doesn't care if this has knock-on effects on other orgs; the company is 99% likely to be fine anyway, and it'll help them move up... do you get on board, or do you push back because it's a bad overall strategy? Good luck... :|


>At a small, young, growing company, that's what the company needs - if your goals aren't aligned with the company's, you are going to be spending scarce resources on the wrong things.

Implying management doesn't do the same...


This is extremely true. I should have also added that sometimes situations and people are just toxic, and when that happens all you can do is try to get out of those situations. If you have burnt out coworkers and an overworked manager -- these might also be red flags


Understand the motivations of your managers, and your managers manager.

Figure out who the internal competitors are.

Learn what gets rewarded in an organisation. This often has little correlation to actual value.

Optimise for political capital, not whats right.

Don't make a scene. Don't cause drama. Don't be stupid enough to lead anti-company movements, e.g. discussing pay inequality, or unionisation.

Be cordial and respectful to everyone, even if they don't deserve it.


This is really good advice (sadly) but I will disagree/add one point:

> Optimise for political capital not what’s right.

Yes and no. Often what’s politically valuable is short term and misaligned with what the company’s values are.

Pushing back diplomatically might be the smarter thing in the mid to long term. be mindful of where the request comes from and from whom.


Some people strongly disagree with playing the game this way: however parent is fantastic advice because you need to know how others are playing to win, and you need to recognise those players and fit your game style appropriately to adjust for that.


Ouch. Where do you work?


Any company with more than 100 people will display these behaviours.

Companies with > 1000 employees will operate completely like this. Where there will always be 3 “priorities” for every manager: what they were told by the C-level, what they know to be important to their manager and what _they_ want to get out of their position.

The amount of times I have been caught totally off guard because I couldn’t fathom why a certain team or individual would be actively doing something to the detriment of the business… only to later understand it was to the benefit of their unit/selves.


I'm not the grandparent poster you replied to, but this is pretty standard operating procedure for political success in almost any large organization.


This is dark. But it definitely rings true.


The biggest issue I've seen with new engineers is a mismatch between what behaviours they think the company should reward them for, vs the actual things the company judges performance on. Pay attention to some senior people who are doing well and see what it is that they're doing to be successful. Hint: it's usually not writing the best/most code.


Often what is considered success at L6 is different than at L4 so this should be done very carefully. Generally at lower levels writing good code is much more important.

I’ve seen new engineers that tried to rush senior eng behaviours and they didn’t do well in performance reviews until they corrected their behavior. You need to prove you can be a baseline contributor before you start dreaming big.


Levels are another thing that are management done poorly, like management by stack ranking. "Levels" are usually made up with little concern for actually creating value or helping employees be awesome. Rather, they serve as a formalism for forcing objects of various shapes and sizes through round holes because 0) they can't think of anything better and 1) other large companies do it, so it must be right.


Work on things that the firm values[1], for bosses who will reciprocate your work at making them look good, by making you look good.

Your manager has a huge amount of impact on your career. If you're working for an asshole/moron who won't reciprocate in this way, find a different one.

[1] Not the same thing as work that's valuable for the firm.


This is a super important distinction! Great way to phrase it too--thank you.


That's an enormous topic that is hard for me to treat here. Knowing that it's a thing you should do is a great first step though. Find more experienced people in your context willing to mentor you and critically listen to what they say.


Don’t go to companies with corporate politics. If you’re going to such a company (where politics are important, like Amazon) you must participate: you cannot protect yourself from them.


Any company develops corporate politics. Corporate politics stems from the corporation ultimately being a non-human entity that doesn't really have desires and needs, while its individual humans do have them.

At some point what's "good for the company" will not align with what certain (powerful) individuals want or need.


Flattery until you get past the BS peddler managers. Once you’re in cahoots with the senior leadership you’re good. Honestly low and mid level managers are the worst, most of them suck at programming even if they won’t admit it, and their only strength is saying a bunch of words most of which are bullshit. They are there to be scapegoats, and you can safely ignore them.

Once you’re among the senior leadership flattery won’t work and honestly they’ll see right through it. If you play your cards right you’re free to prove your technical prowess and get placed into top performing teams with the best managers. As long as the senior leadership knows your name, and you don’t overextend like a noob, you’ll get what you want pretty quick.

Or you can quit in two years and get another job.


* Be the only one who understands a particular codebase * Listen when people give you advice, so that they fee they have some hand in guiding you, perhaps even carefully encourage advice-giving * Make some friends just outside your immediate team * Avoid letting people get frustrated at you or your work. * Gossip nice things about people, they'll hear about it


Watch the first four seasons of Game of Thrones.


I work at small startups (up to 25 people), where there isn't time or space for much of that.


Either you don't work for corporates or only work as a contractor.


Being a contractor isn't a magical get out of politics card, it just means that you often have even less ability to protect yourself from them.




Join us for AI Startup School this June 16-17 in San Francisco!

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: