3 ms·

This book will at best get you an L5 gig at FAANG; for Staff eng positions (L6+) you need significantly more depth and rigor.

deleted 6y ago
[deleted]
dragontamer 6y ago
In my day-to-day work, I operate at a rather low level. Hardware guys + the occasional assembly code. However, my command of Linux / OS-level stuff is far superior over my peers, and I'm able to occasionally write up a shell-script or two in a few hours that replicates something a peer does over a week at a low-level. (Hardware guys don't necessarily know that "Tee" exists, or how to use Unix Domain Sockets or pipes to their fullest extend) Becoming the best in one field is almost impossible: there is always someone more studied than you. However, becoming "competent" in two or three different fields can lead to a strong advantage. Yes, you should reach for depth in your field. But you should also reach for breadth when its easy. There are sometimes easy ways to differentiate yourself over your peers. ---------- I feel like there needs to be a good collection of books that teach the "simplest tricks" of a field. Ex: Cryptography Engineering is the "simplest" explanation of cryptography. There's not enough math to understand any crypto-algorithm, but by just laying out the names of common algorithms + their common uses, the book teaches the "easiest" bits of crypto to those outside of the field. Maybe that's the niche for this book? I haven't read it, but if its written clearly enough, it can be used for someone like me to explore a field I don't work in on a day-to-day basis. -------- Breadth of study vs depth of study are two different styles of study. They're not necessarily more or less important... they're just two different ways of creating your own niche in your organization.
- phlipski 6y ago
  Can you recommend any good primers/tutorials on "Tee's", sockets or pipes in unix/linux? You know - for us "hardware" guys to brush up on? :)
  - dragontamer 6y ago
    So I'm not a really good systems guy. Its more like, knowing random stuff sometimes comes in handy. For sockets / pipes / terminal stuff in Unix, I ultimately just had to skim over "Advanced Programming in the UNIX Environment" cover-to-cover. There's just a lot of things the UNIX dudes have already implemented with regards to inter-process communications, files, threads, processes, signals, and the like. Once you know what UNIX (and Linux) have to offer, then you can start leveraging it. You don't really need to understand everything, you just need to know things to a level that "I can look it up later when I need it". Again: you're going for breadth, not depth. Skimming over concepts and "remembering them for later". You'll know when you need it, and can come back to the book for depth later on. --------- For "Tee", and "Awk", and "expect", and stuff... I followed blogposts at Linode and Slicehost back in the day which covered a lot of interesting sys-admin tricks. I'm pretty sure the Slicehost pages are lost (the company was bought out by Rackspace years ago. I don't know if any of that stuff was archived) I never was a professional sys-admin. But knowing about Awk, Tee, or various other "standard command-line tools" that web-developers use all the time allows me to script up a lot of things related to testing code, Makefiles, and the like. I basically got that experience from just messing with servers: trying to run my own mail server or web server on the side. Cronjobs, automation, etc. etc.
  - hackart 6y ago
    Book recommendation: https://man7.org/tlpi/ https://man7.org/tlpi/ It is available on O'Reilly/Safari
jazzkingrt 6y ago
I completely agree, but that population would be a pretty small readership.
Crash0v3rid3 6y ago
Can you give more details on how an L6 can pass these interviews? I’m planning a move to SRE sometime this month. I’ve been prepping quite a bit with this book so far.
- fizwhiz 6y ago
  I'm not an SRE, but for SWEs at that level you may expect a deeper discussion in: * Addressing scaling bottlenecks with a large focus on reliability and fault-tolerance. * Concepts orthogonal to the core ask (ex: security, privacy, auth n/z, compliance). * Cost. Ultimately the most scalable architecture may not be very cost effective; the 2nd best option might be much cheaper and merits discussion. These are for large scale design questions. Questions to L6 candidates are posed (deliberately) ambiguously to see if they can tease apart the important/finer details.
hkarthik 6y ago
At L6+ you also need experience and war stories during the interview process. And a significant number of wins with broad impact that can only happen if you have the soft skills to make large change happen.
- fizwhiz 6y ago
  Absolutely; my response was more geared towards expectations in a design round. If you have the option to draw from personal experience / war stories then even better.

deleted 6y ago

[deleted]

dragontamer 6y ago

In my day-to-day work, I operate at a rather low level. Hardware guys + the occasional assembly code. However, my command of Linux / OS-level stuff is far superior over my peers, and I'm able to occasionally write up a shell-script or two in a few hours that replicates something a peer does over a week at a low-level. (Hardware guys don't necessarily know that "Tee" exists, or how to use Unix Domain Sockets or pipes to their fullest extend) Becoming the best in one field is almost impossible: there is always someone more studied than you. However, becoming "competent" in two or three different fields can lead to a strong advantage. Yes, you should reach for depth in your field. But you should also reach for breadth when its easy. There are sometimes easy ways to differentiate yourself over your peers. ---------- I feel like there needs to be a good collection of books that teach the "simplest tricks" of a field. Ex: Cryptography Engineering is the "simplest" explanation of cryptography. There's not enough math to understand any crypto-algorithm, but by just laying out the names of common algorithms + their common uses, the book teaches the "easiest" bits of crypto to those outside of the field. Maybe that's the niche for this book? I haven't read it, but if its written clearly enough, it can be used for someone like me to explore a field I don't work in on a day-to-day basis. -------- Breadth of study vs depth of study are two different styles of study. They're not necessarily more or less important... they're just two different ways of creating your own niche in your organization.

phlipski 6y ago
Can you recommend any good primers/tutorials on "Tee's", sockets or pipes in unix/linux? You know - for us "hardware" guys to brush up on? :)
- dragontamer 6y ago
  So I'm not a really good systems guy. Its more like, knowing random stuff sometimes comes in handy. For sockets / pipes / terminal stuff in Unix, I ultimately just had to skim over "Advanced Programming in the UNIX Environment" cover-to-cover. There's just a lot of things the UNIX dudes have already implemented with regards to inter-process communications, files, threads, processes, signals, and the like. Once you know what UNIX (and Linux) have to offer, then you can start leveraging it. You don't really need to understand everything, you just need to know things to a level that "I can look it up later when I need it". Again: you're going for breadth, not depth. Skimming over concepts and "remembering them for later". You'll know when you need it, and can come back to the book for depth later on. --------- For "Tee", and "Awk", and "expect", and stuff... I followed blogposts at Linode and Slicehost back in the day which covered a lot of interesting sys-admin tricks. I'm pretty sure the Slicehost pages are lost (the company was bought out by Rackspace years ago. I don't know if any of that stuff was archived) I never was a professional sys-admin. But knowing about Awk, Tee, or various other "standard command-line tools" that web-developers use all the time allows me to script up a lot of things related to testing code, Makefiles, and the like. I basically got that experience from just messing with servers: trying to run my own mail server or web server on the side. Cronjobs, automation, etc. etc.
- hackart 6y ago
  Book recommendation: https://man7.org/tlpi/ https://man7.org/tlpi/ It is available on O'Reilly/Safari

jazzkingrt 6y ago

I completely agree, but that population would be a pretty small readership.

Crash0v3rid3 6y ago

Can you give more details on how an L6 can pass these interviews? I’m planning a move to SRE sometime this month. I’ve been prepping quite a bit with this book so far.

fizwhiz 6y ago
I'm not an SRE, but for SWEs at that level you may expect a deeper discussion in: * Addressing scaling bottlenecks with a large focus on reliability and fault-tolerance. * Concepts orthogonal to the core ask (ex: security, privacy, auth n/z, compliance). * Cost. Ultimately the most scalable architecture may not be very cost effective; the 2nd best option might be much cheaper and merits discussion. These are for large scale design questions. Questions to L6 candidates are posed (deliberately) ambiguously to see if they can tease apart the important/finer details.

hkarthik 6y ago

At L6+ you also need experience and war stories during the interview process. And a significant number of wins with broad impact that can only happen if you have the soft skills to make large change happen.

fizwhiz 6y ago
Absolutely; my response was more geared towards expectations in a design round. If you have the option to draw from personal experience / war stories then even better.