Practical advice for starting an IT career
I read this a great post by Alice Goldfuss, about how to get into Site Reliability Engineering (SRE). While most of Alice’s post was specifically about planning to end up in an SRE role, I felt that a lot of her advice was applicable to IT jobs in general. Here are a few sections which stood out:
On being a constant learner:
One part of my path that I think you can and should replicate is constant learning. My entire tech career has been one of two jobs: the job I have and the job I’m learning. I am constantly reading books, watching talks, taking classes, learning new languages, and talking to industry friends. I don’t rest on my laurels. If I’m not interested in what I’m currently working on during the day, I find something interesting at night and I do that. Eventually those new skills help me either in my current job or in securing the next one.
This resonates with me. I started learning Docker, and published Funky Penguin’s Geek Cookbook at night, because I was losing interest in the routine work I was doing during the day, and missed the challenge of learning a new skill.
Remember, a good interview is a two-way conversation, a first step towards a mutually beneficial relationship:
Now the fun part. There should be time left at the end of each interview for you to ask questions; that is, you get to interview the company. You should plan out these questions ahead of time and have them written down for reference. Note their answers, too. You want to get a sense of their work culture, projects, and general team health.
You don’t ask these questions to ensure you end up at the best possible company. You ask these questions so you know what you’re agreeing to.
This is great advice. Often you may find yourself so focused on landing the role, that you overlook the warning signs that this may not actually be a role you’d willing choose. Look out for statements / comments which hint at “eccentric” personalities, ongoing unrealistic deadlines, or financial insecurity. Joining an unhealthy team, or an organization with a bad culture, is likely to end badly.
On vaguely-defined roles (SRE, DevOps, etc):
You’ll also find companies with SRE teams that aren’t doing SRE work at all. I would encourage you to focus on the work itself and not get too tied up in the actual title. You can put anything on LinkedIn.
Don’t get hung up on titles - focus on the work.
And finally, on expectations vs. reality:
This is all a very long-winded way of saying: if you are in it for the power and glory, you will likely be disappointed. Become an SRE because the work interests you.
And this is true for any role. Power and glory soon turn to burnout and drudgery, if you’re not really interested in the work.
Read more, at how to get into Site Reliability Engineering (SRE)