adrianstoll

Good SREs can support a service without being familiar with the details. They use generic mitigations (e.g. rollback to a know good release, request an emergency quota increase, etc) to quickly stop the bleeding without needing to understand the root cause. Later the SWEs who understand the code can debug at their leisure. Having a deep understanding of the service obviously helps but is not essential. I expect agents are already applying these generic mitigations at bleeding edge companies but do not have firsthand experience as an SRE to confirm.

Ben Franklin did this as well. He writes about this exercise in his autobiography.

If you expand your scope enough eventually you’ll find someone. For example, my first job was from someone who knew my dad.

I’ve had multiple Thinkpad X1 carbon laptops with whatever the most recent Ubuntu LTS version. The hardware is well supported by Ubuntu, however I have experienced a few bugs with Gnome and the keyboards on newer X1 carbons are not as reliable. Since much of what people do these days is in a web browser, the difference between operating systems is not as meaningful these days.

> You rarely knew if the people you interviewed were hired or not

Perhaps this has changed over the years. I recall there is a website listing all the people you have interviewed and their status (e.g. upcoming interview, rejected, application withdrawn etc)

This does not prevent geo-blocking, because the relay's IP is still in the same region as the user.

I only use sed on version controlled files and immediately run git diff afterwards to check the results.

In 2016 Dyn DNS suffered a DDOS attack and sites including Twitter and Spotify became inaccessible. Higher TTLs would have extended availability from browsers with cached resource records.

Samsung provides authentication software for their sd cards too.

This is the idea behind sitemaps which have existed forever.