DEV Community

loading...
Cover image for Help Desk Intern to SRE @Google in Five Years

Help Desk Intern to SRE @Google in Five Years

tseknet profile image Dan Tsekhanskiy Originally published at tseknet.com ・5 min read

Five years ago I was a help desk intern. Last week was my first week as an SRE at Google.

Let's start with the understanding that working on the help desk puts you in the perfect position to eventually transition into one of these roles. Help desk affords you the ability to see how the technologies that the business relies on function, as you're often tasked with troubleshooting when they don't work. Learning through reverse engineering, especially in IT, is often an overlooked method of gaining a deep understanding of new technologies. Reverse engineering requires you to get your hands dirty and take a deep dive into what you're troubleshooting. This is where learning happens.

Next, what's SRE? SRE started in 2003 at Google and is often compared to DevOps (coined around 2008). SRE is what you get when you treat operations as if it’s a software problem.1 These two disciplines share the same foundational principles but have subtle differences.2 I've found these to involve themes such as code-based configuration, reliability, and service (rather than server) management.

Let's dive right in with themes I've kept in mind throughout my career. If you're interested in the actual positions I've held as a reference, check out my LinkedIn.

Always be Learning

Throughout my career, I've found one theme to be ever-present: Always be learning.

Regardless of the position, I've always aspired to go above and beyond what was "written on the tin" of the job requirements. Are there tasks that you find mundane and repetitive? Automate them. I've often found the quickest way to learn a new programming language is to find a simple problem and start looking up potential solutions to that problem in a given language. Try to replicate those solutions, and work through the issues you run into along the way.

Once you've fixed your first problem, odds are you've become at least familiar with new technology, and provided value in the process. Here's where I note that value is subjective. For example, a side project I worked on to get my feet wet with Go sends friends daily emails of the cutest pictures from Reddit. Did that provide value to anyone other than the person who's day was most definitely improved by receiving cute pictures? Definitely. It helped me get familiar with a programming language that I had never seriously touched before.

Every toolbox starts with one tool. What's important is you keep adding multipurpose tools to your toolbox. For example, Puppet, Terraform, Git, etc. can be used to solve a wide variety of problems. Notice I did not mention problems for a company here.3 Learning these tools will take some effort, but this is your toolbox. It's got your name right on the front in big bold letters. You can take it with you wherever you go.

These tools can be used to automate your company's fancy new rollout or even automate your grandparent's software updates. You'll soon see your toolbox overflowing with tools. Every tool you master will put you in a significantly better place in the job market than you were, or at the very least, grow your toolbox and
help you solve the IT problems you are facing.

Passion

It helps if you're passionate about what you do.

I am passionate about all things IT, job-related or not. I've been fortunate to pick a career that allows me to explore my passions, and a company that allows me to explore new ideas and designs that are fueled by my passions.

I often say that I'd be doing IT-related side projects even if I wasn't in the IT industry. Ever since playing with (and on) my dad's computer at five years old, I've had a passion for all things technology. I enjoy taking things apart (read: breaking things), figuring out how they work, and (sometimes) putting them back together.

I often work on side projects on GitHub or my home lab (stay tuned for an upcoming post), in addition to my day job.

Ask questions

Be comfortable not being the smartest person in the room.

Especially since joining Google, it's clear to me that there will always be someone more knowledgeable than you. Reach out to those people.

I've been lucky to hold positions where curiosity could be endlessly fed by fantastic peers and mentors. Often when troubleshooting issues, even during my internship, if I had questions, I could just turn to a peer and ask away. I've found that people love talking about things they're experts in. If you're fortunate enough to have peers such as these, make sure to thank them early and often.

Learning when to ask questions is a skill in and of itself (and a good interview question). There's no definitive answer for when is the right time to reach out. What's certain is you will find yourself reaching out, especially as you learn new technologies, programming languages, etc. Just know that questions are part of the learning process. If you find yourself spending endless cycles on a problem, that's probably a good sign that you could reach out for some help.

Finally, asking questions is part of the process of how a junior member of a team becomes a senior member. Eventually, that junior member asking questions becomes the senior member fielding them. The cycle continues.

Take Charge

Set goal. Set aside time. Accomplish goal. Repeat.

I've adhered to the principles of S.M.A.R.T goals4 and calendar blocking5 to meet those goals. Being intentional with your time is a productivity "hack" I wish I'd learned long ago. If you're serious about an endeavor, set aside time to accomplish it. Remove all other distractions from your life, and focus on achieving what you've set to achieve. Set goals, and keep yourself accountable for achieving your goals.

Life will always get in the way. Be reasonable with your goals. Everyone is different, and timelines are likely to slip. It's important to be realistic and kind to yourself when goals slip.

Set aside time to set overarching goals for your career. Some example questions should help you get started:

  1. Do I want to work until retirement?
  2. Do I want to run my own business?
  3. Do I want to work from home?
  4. Do I want to work full time or part-time?
  5. Do I want to move?
  6. What do I need to start working on to achieve these goals?

What's Next?

An unending thirst for knowledge, fantastic mentors, and taking advantage of opportunity have led me to this point in my career. What's next for me? My toolbox still has plenty of room. My career still has plenty of room to grow. What's for certain is I'll continue to ask questions, break things, and share my journey with you along the way. Check out my twitter if you'd like to follow along.

Now get out there and take charge of your career πŸ’ͺ

Footnotes

  1. What is Site Reliability Engineering (SRE)?
  2. DevOps vs SRE
  3. Career vs. Job
  4. SMART Criteria
  5. Be Intentional

Discussion

pic
Editor guide
Collapse
wwfromga profile image
Wayne Whitaker

Congratulations on your career, and thank you for your thoughts included this article. I would encourage any article writer to write out any possibly unfamiliar abbreviations the first time they are used. I had no idea what an SRE was until I got to a footnote.

Collapse
bobbyiliev profile image
Bobby Iliev

That is amazing! Congrats! πŸ™Œ

This is quite similar to my personal story actually, 7 years ago I also started as a support agent representative in a web hosting company, and now I've been working as a DevOps engineer for 2 years already.

And I just published my first opensource eBook:

Collapse
ben profile image
Ben Halpern

Congrats!

Collapse
tseknet profile image
Collapse
qainsights profile image
NaveenKumar Namachivayam ⚑

Congratulations πŸŽ‰