Open Copyright and disclaimer

How to get a job at an Awesome Company

Copyright

How to get a job at an Awesome Company, by Alexander Williams is licensed under a Creative Commons Attribution-NonCommercial-NoDerivs 3.0 Unported License

Please go here to view this license: http://creativecommons.org/licenses/by-nc-nd/3.0/

Published in Okinawa, Japan by Alexander Williams, a1w.ca November 2024, Second Edition, v2.0

Published in Quebec, Canada by Alexander Williams, AlexWilliams.ca July 2011, First Edition, v1.0

• Website: https://a1w.ca
• Mastodon: https://ruby.social/@aw

DISCLAIMER

All trademarks are used with respect to their owners and are designated in italics wherever possible. We claim no affiliation with any of the people, software, companies or trademarks listed in this eBook, except for our own.

**While every precaution has been taken in the preparat

Open Acknowledgements

Acknowledgements

I want to thank GitHub for having such an awesome website and customer service. I also want to thank 37signals for being an awesome company and for providing this Writebook software for FREE.

This eBook, the second version, is dedicated to you guys, gals, and others.

Open What the heck?

What the heck?

I don't work for GitHub (anymore). After writing the first version of this eBook, GitHub contacted me, flew me to San Francisco for a day of interviews, and offered me their second sysadmin position soon after. It was a fun and interesting ride, but first I'll mention why I'm updating this book 13 years later.

Running a business

After a few years working at GitHub, we parted ways and I set off to start my own company. I bootstrapped the business for over a decade and had a blast doing it, but the urge to contribute more to society using my years of experience and knowledge, kicked-in. As a solo-entrepreneur, your attention is divided unevenly and interrupt-laden among a million different tasks, often unrelated to tech: the reason us tech people create companies in the first place. To keep your company profitable, you can't focus exclusively on the tech.

I wanted to get back to just being a tech guy. You know, hacking on systems, coding, idea-generating, pr

Open What to expect

What to expect

I didn't plan on rewriting the entire version 1 of this book, but I did anyways. Some of the content is still relevant today, so it was partly copy-pasted it into this version to save time.

However, the old and irrelevant text was removed.

Some content, although somewhat old, was simply modified. The name GitHub was replaced by Awesome Company in most places, to keep with the generic theme and title of this book.

Some new sections were added and graphics were painstakingly re-drawn because I don't have access to the software I was using 13 years ago when I first authored this book.

I hope you can learn a thing or two from this book. If it's helpful in any way, please contact me on Mastodon (https://ruby.social/@aw) and let me know.

Open Introduction

Introduction

What is an Awesome Company?

If you've worked at least a decade in the IT industry, at a "fast-paced startup" or a "big corporation", you'll likely know exactly what is not an awesome company. Here's my personal list of non-awesome-company features:

• Meetings. Long, dreadful, useless, meetings.
• Mandatory in-office, on-site, fixed desk, cubicles.
• Interruptions. Constant interruptions throughout the day.
• Little to no time-off. Expected to work 400 days a year.
• Disrespect of your personal life, goals, interests, ambitions.
• Way below market salary. When digging ditches starts to look appealing.
• Focus on just getting things out there, adding to tech debt.
• Moving fast, coding fast, no tests, cowboy force pushes to production.
• 10x co-workers, rockstars.
• Outsourced vendors who suck, and being forced to "deal" with them because they're "cheap".

I could write a million things here, but you get the point.

An awesome company is pretty much the exact oppos

Open Job requirements

Job requirements

To be a great Sysadmin, SRE, DevOps at an Awesome Company, you need specific skills and knowledge.

It's not a definitive list, but it's a good starting point:

• Coding: a good scripting language, such as Bash, Ruby, Python.
• Sysadmin: managing systems from a Linux command-line (although nowadays we don't use tel^H^H^Hssh anymore to manage systems).
• Networking: datacenters, racks, switches, routers, IPv6.
• Scaling: load-balancing, sharding, fail-over, distributed computing.
• Databases: relational databases such as MySQL, PostgreSQL, SQLite.
• NoSQL: in-memory and document databases such a Redis, memcached, RethinkDB.
• Virtualization: managing VMs using KVM, qemu, VMware, VirtualBox.
• Containerization: orchestration tools such as Docker and K8s.
• Version control: git.
• Monitoring: see what your servers are doing with Grafana, ELK stack, Graphite, Munin, rrdtool.
• CI/CD: automate builds, deployments, and tests with Je

Open Human requirements

Human requirements

Writing

I hinted at this earlier, but the ability to write well is probably one of the most important job requirements. You must not only comment your code, but also document your infrastructure plans, changes, operations, and troubleshooting tactics in a format which is useful for other people.

I'm partial to the Diátaxis documentation system, which separates documentation into four simple quadrants as shown below:

On-call

As a sysadmin/SRE/DevOps, we're often tasked with being on-call, which means potentially working outside our regular work hours. Waking up at 3am to fix a production issue affecting millions of users is very difficult from a physical and mental perspective. There's no fun in that, but there are ways to minimize those types of incidents. An awesome company will institute sane scheduling and global distribution to avoid waking people up at ungodly hours. Bu

Open Network architectures

Network architecture

The network architecture defines the logical and physical topology of the network equipment, the protocols used, devices, and various points of entry to the systems. Assuming the company's services are available under the SaaS model, it's safe to assume the first point of entry will be a CDN such as Cloudflare, Fastly, or Akamai. Those services protect from DDoS attacks and proxy data to the real network where everything is hosted.

In most cases only the most senior network engineer (or director/CTO) will be tasked with handling those services. However it's good to know they exist, and even better if you've dealt with them before.

The real network often starts with a router forwarding traffic to a switch, which forwards traffic to a server. But in the case of an awesome company, they'll likely have taken measures to add redundancy, failover, and load-balancing to the mix. Moreover, it is common to have services distributed across various physical locations. Someti

Open System architectures

System architectures

When discussing system architectures, in the context of this book we're more specifically talking about system administration, servers and their design and management.

A standard and fairly typical architecture includes redundant systems at all layers. There will be redundant application servers, databases, file servers, caches, proxies, and more. It's not unusual to see multiple systems on the same physical machine (ex: an in-memory cache on the same machine as the app server), but as the company's needs grow, it is sometimes necessary to move systems to dedicated machines.

The proliferation of containers and virtual machines has made this even easier, as it's now possible to quickly move workloads to different locations with a single command. This means it's even easier to homogenize the hardware and deploy machines with identical physical specs, regardless of what tasks they'll actually be running.

There used to be an exception to this regarding databases. Those typically

Open Software architectures

Software architectures

The software architecture of an application is beyond the scope of this book. However I will discuss some common things which can be found on an awesome company's servers.

At the time of this writing, it's safe to assume a server will be running one or more of:

• a web framework (Rails, NodeJS)
• an application binary (a compiled Go, Rust program)
• an SQL database (MySQL, PostgreSQL)
• an in-memory database (Redis, memcached)
• a document database (RethinkDB, CouchDB)
• a data visualization tool (Grafana, Munin, Kibana)
• a container orchestration tool (Kubernetes, Nomad, Rancher)
• a message queue (RabbitMQ, Mosquitto, Resque)

... and more.

There's an unbelievable amount of different frameworks, tools, databases, etc. Every company is different, so there's never an expectation for you to know them all. However if you know one, you practically know the others in its category because the concepts are relatively similar.

Open Ideas for the future

Ideas for the future

This is my favorite part of the book. I vividly remember writing this section in version 1 with much passion, and can't help but laugh at how my ideas were either never implemented, or just completely ridiculous (probably the latter caused the former hahaha).

So you landed a job interview at an Awesome Company? Congrats! But guess what, I'm convinced your job description will change within the first 6 months of working there. New tasks, new technologies, new challenges, new teammates. Again, that's where your adaptability will be pivotal.

If you want to be hired, you'll need to use your brain a little, but preferably a lot. You need to provide VALUE to your future employer. If you're just a cog who works aimlessly and then goes home, you're useless. You'll increase your chances of landing the job if you can provide them with some great ideas for improving their infrastructure, lowering latency, saving money, or even making more money.

Below is my personal list of ide

Open Fix your life

Fix your life

So you've made it this far, taken all my advice, learned a bunch of new software and interviewed for the awesome job, but you still didn't get it?

Well, I'm sorry to hear that. We've all failed job interviews, but it's not a reason to put your head down or go back to sleep. You should see it as a learning experience. Take advantage of the fact that you're still alive, and go learn something else. Perhaps a new spoken language, or learn how to take care of kids.

I'm going to provide you with a list of things I still do almost every day. These things keep me active and they keep my brain from losing too many cells. It has become part of my lifestyle and I think you should also do it.

• Read a book, tech blogs, news sites, something for your brain. The more you stay connected, the easier it will be to get back into the job market, or even to jump to a new job, or improve your current career choice.
• Watch a funny movie or TV show. Allow yourself to LAUGH, every day! Your brain n

Open List of awesome companies

List of awesome companies

Below is a list of companies I believe are awesome, however I can't confirm all of them.

Some may disagree with the names on this list, so just take it as my personal opinion which may be biased or completely wrong. In all cases, you're encouraged to find out for yourself.

• GitHub
• 37signals
• Valve
• Oxide Computer
• Tailscale
• Atlassian
• Shopify
• Netflix
• tonari

There are definitely more, perhaps companies I forgot or I'm not aware of. Feel free to contact me if you believe your awesome company should be listed here.

Open Conclusion

Conclusion

I hope you enjoyed this FREE book. Please feel free to distribute, copy, print (be nice to the environment though), share, repost, convert to audio, translate this book. Please don't sell this FREE book, also don't modify it without my permission.

Thanks!

Alexander Williams

https://a1w.ca