ex_amazon_sde

> How well this does this work for Amazon?

Not so well. Some teams have a high threshold for hiring, some don't, but overall it's been going down because it becomes more and more difficult to find new employees.

Private companies and banks see coops as the devil [for very obvious reasons] and fight them using regulatory capture and not engaging in business with them. It's pretty well-known in the coop world.

Coops sometimes mitigate this disadvantages by networking with each other.

> graduating without programming skills is impossible

I interviewed a lot of people and quite a few could not implement fizzbuzz.

Amazon.

It uses an internal tool but the implementation is not important. Applications and libraries and packaged independently just like any Linux distribution.

> APT shuts down daemons and keeps them down for an unreasonably long

Are you doing live upgrades on production servers? Don't.

If you are doing updates anywhere else a couple of seconds of downtime is negligible.

Ex Amazon here.

I've been in companies that owned their datacenters and it was much, much cheaper than using any cloud service.

Poorly managed datacenters exist but that's an organization problem. Remove the datacenter and you'll have poorly managed cloud instances and services costing millions.

Matrix always felt like an unnecessary company-driven reinvention of XMPP.

Now I start to see why.

Debian has a big CI system to do end-to-end integration test https://ci.debian.net/ and https://wiki.debian.org/ReproducibleBuilds

It also provides continuous snapshots: https://snapshot.debian.org/

It's standard practice in many large companies.

> who ... understand the OS internals? ... How about write a library for their fav language? How about actually troubleshoot a misbehaving *nix process?

Ex-Amazon here. You are describing standard skills required to pass an interview for a SDE 2 in the teams I've been in at Amazon.

Some candidates know all the popular tools and frameworks of the month but do not understand what an OS does, or how a CPU works or networking and do not get hired because they would struggle to write or debug internal software written from scratch.

[added later] This was many years ago when the bar raiser thing was in full swing and in teams working on critical infrastructure.

I cannot generalize for the whole company. When writing jobspecs in my team we never made lists of the "popular frameworks of the month".

> and that's unthinkable

Google seems to be better in some ways, but I met plenty of ex-Googlers complaining about the stress and the competitive environment.

Ex-Amazon here: burnout due to stressful work and on-call duties is the n. 1 reason for attrition.

It's very well known that people leave FAANGs in general due to stress.

> So I can't fault people for trying to avoid this mess.

Ex-Amazon here. Being deeply familiar with OS fundamentals and internals, "low level" tools, and so on is crucial.

A lot of candidates show to interviews with CVs filled with names of popular frameworks and fancy devops tools and often don't understand what really happens behind the curtain.

People are becoming less familiar with the basics and tend to reinvent the wheel. In many teams this does not get you hired.

Ex-Amazon here. One thing than Amazon really understands is that if you build you also create the opportunity to develop skill and knowledge.

Also you avoid vendor lock-in. Even Open source projects cause lock-in especially if they are overcomplex and fast moving.

> transferring jobs out of the country entirely

Or IN the country, depending on where the place-of-birth lottery put you.

This *really* depends on the company.

And yet I've seen plenty of people leaving for less stressful companies.

The world-wide pool of *good* developers is not infinite and both Amazon and Google have been lowering the hiring bar...

I used the same tool an the numbers were very similar 7-8 years ago.

The amount of people that I saw leaving matches that attrition rate. Many were put on unjustified PIPs.

The 6% in the article is incredibely underestimated.

Ex-Amazon here: indeed the level of skills, management, code quality and so on changes a lot across teams.

Unfortunately people outside of Amazon make sweeping generalizations about the company.

The "median citizen" is an absurd concept given the income distribution. It completely fails to capture income inequality.

Also access to free education, free healthcare and so on.

It's not.

> Also make software self-destructing with a warning

This is not how forensic analysis works. Data is copied to read-only supports before any attempt of access is made.

> I work for a large (not FAANG but spatially close) ecommerce company, and I’ve yet to see substantial changes or learnings after outages or mistakes.

I worked for Amazon and postmortems were taken seriously and done regularly - but things can be different in other teams.

If people warned about a risk in the past this would be noticed.

If nobody flagged the risk people would start asking why.

Ex-Amazon here. The joke hits too close to be funny. Plenty of people would also do on-call or other work from home in the evenings or early mornings.

You are ignoring the protections against "tivoization", patent trolling and passing software freedom down to the end users.

Often we are the end users. Because of permissive licensing phones, routers, iot devices have a lot of closed or otherwise locked own components that I cannot trust nor modify.

The same apply to SaaS.

> The real world is constantly at risk of disruption

Only for workers being replaced by automation and such. For whole social classes - no.

All key indicators show how social mobility is not high in most countries and it's even decreasing in many.

Installations on Debian are perfectly reproducible as long as you don't just pull random packages from Unstable/Sid.

You can use Stable or https://snapshot.debian.org/

> Hiring managers are DESPERATE For people. And they will beg barter and steal for hires, and try to convince bar raisers to lower the bar to get people in.

You just described something that comes very close to "hire to fire".

I've been in Amazon for long enough to see the hiring bar float up and down a lot, with big differences based on the team and the country.

Once you put together URA and the staggering attrition rate that exists in many high-pressure teams the managers are left with only two options:

A) Hire very skilled and productive engineers and then find ways to push them out of the company later on B) Let the bar slip sometimes and keep the good engineers for a bit longer

By all means, "A" happens far more frequently than "B" and, in many ways, it's even worse.

5%? I've seen many engineering teams having an attrition rate well above 25%, where only few people would stay for longer than 3 years.