In this episode, I tackle some questions from listeners, and provide my own answers to your DevOps Careers questions:

• What are red flags in job ads about DevOps?
• How can I best prepare for an interview?
• What can I do to prepare for a DevOps Director Role?
• How do we cope with the expectation that we need to be learning new technologies all the time?

Resources
The Daily Commit: Knowledge Options

Send your questions for an upcoming Q&A episode to jonathan@jhall.io.

Transcript

Intro: Ladies and gentlemen, the tiny DevOps guy.

[music]

Jonathan Hall: Hello, and welcome to this week's episode of The Tiny DevOps podcast. I'm your host, Jonathan Hall.

On this show, of course, we like to solve big problems with small teams, and this week I'm diving into a Q and A session. I actually recorded this earlier last year about DevOps careers, but I wanted to replay it for you here on the podcast. Of course, if you have other questions, I'd like to do this Q and A sessions every few weeks or every couple of months. If you have other questions that you'd like me to answer on the show, send them to me at jonathan@jhall.io. If you include a video of yourself or an audio recording asking the question, that's even better, but of course, any just written email is also a great way to send a question, and I'll try to answer that on an upcoming episode.

Also, keep in mind, if you have a question that's more detailed or maybe you don't want to go into the details on a public show, you can also borrow my brain. If you go to Jhall.io/call, you can see all the details there. It probably costs less than you would think. I'm happy to lend you my brain for an hour to talk about whatever struggles you have with software delivery, DevOps, agile practices, or my favorite color, or anything else that I have sorted my brain that might be helpful to you.

Without further a do, let's jump on into the Q and A session that was recorded last year. I hope you enjoy it.

First question I'm going to do here is, what are red flags in job ads about DevOps? This is a question I get asked, or some form of this, fairly often. There's different ways to think about this, but one thing I look for in job ads actually is the word DevOps. DevOps is such a confusing and broad term that it's easy for a job description to not know what they're asking for. If they say just DevOps engineer, for example, I wouldn't call that a red flag by itself, but it's maybe a yellow flag. What I look for then is the specific things that they're asking me to do in the job description.

Because DevOps is such a broad term, especially as it's used in job descriptions, what I want to learn from the job description is, what are they asking? Because a DevOps engineer might be somebody who does development and operations work, or might more often it's somebody who just does operations work. That's why DevOps is not a great title for that role. Look at the details, what are the things they're expecting you to do? What are your responsibilities? What technologies are you expected to be doing in that role? See if that matches what you want. That's not so much a red flag, it's just narrowing down what DevOps means.

Another thing to look for is whether you would be on a so-called DevOps team. If you're joining a DevOps team, that could be an indication that this organization hiring you or potentially hiring you doesn't understand that DevOps is meant to be about cooperation across roles. If you put all the DevOps people, so to speak, in the corner and expect them to do their thing, that's not really DevOps. The whole idea of DevOps is that Dev and Ops are working together, and that they're not separated. That might be the biggest red flag to look for, is, are they actually doing DevOps, or are they just using the word DevOps to describe operations in their own silo?

Let's move on to the next one here. How can I best prepare for an interview? This is, of course, a really broad question, and it depends a lot, I think on the stage of your career. If you're trying to lend your first job, you probably are going to approach this differently than if you've already been in the industry for 10 or 15 years and you have a lot of experience under your belt.

Let me answer that in reverse order. I've been doing development and operations work for many years. I tend to not really prepare for an interview beyond looking at the company's website to understand what they're doing. If it's a company I've never heard of before, and maybe a recruiter has contacted me, or I just applied on, say LinkedIn or something, I want a minimum amount of information about that company. I will look at their website, try to learn what technologies they use. Are they a Microsoft shop or a Linux shop, that sort of thing. Are they using AWS or Google or they have their own servers? That sort of stuff, to the extent that I can learn quickly. Of course, what industry are they in? Are they doing e-commerce? Are they doing blockchain or whatever, that sort of thing.

I try to, from that, make a short list of questions, three to five questions that I can ask them for more detail. That's really about the only preparation I do for an interview at this stage in my career. Earlier in my career, I might have done more of what I think a lot of people think about when they think of preparing for an interview, almost like cramming for a test. I still don't put a lot of faith in that preparation, and the main reason is because I believe that an interview should be about you learning about the company and the company learning about you. If you spend a lot of time building or, say cramming, so to speak, for an interview, you're probably not going to be giving a realistic representation of yourself.

In my view, it's better to, in an interview, say I don't know the answer to that thing, to that question, to that scenario, than to have a bunch of answers memorized that you can just spout off the top of your head. That's one thing I really wouldn't do a whole lot of, and maybe that depends on the company you're applying for, but I really think that most interviewers will be able to tell if you're just giving a memorized answer. If the question is, how do you iterate a map in JavaScript or something, you can just spout off an answer like that, that's probably not very valuable because they'll be able to tell that it's memorized.

I don't spend a lot of time with that preparation. The preparation I do is more researching the company, learning the things that would help me decide if I want to work there, and keeping a note of questions that I want to ask early the interview to also help me decide, do I want to work there. I hope that's a helpful answer.

The third question that has received an upvote. I'll do it next. What can I do to prepare for a DevOps director level role? This is a tricky question because I've never actually heard of a DevOps director. I have to imagine what this means, and this goes back to what I was saying a little bit earlier, that DevOps is about cooperation across roles, across development and operations and other areas, security, and data and quality assurance, and so on.

I'll tell you what, the way I'm going to interpret this question is, how do I prepare for a director level role that does DevOps? That's the way I'm going to try to answer this question, or that implements DevOps as a culture in our team. The way to do that is really no different than becoming a technical director or a director of software development or software engineering with or without DevOps. The key difference here is, in my view, is that DevOps is a better way of doing software engineering than without DevOps. If you want to become a director who is in an organization that's doing DevOps, you should learn the technical stuff. Maybe you have a development background or project management background, something like that, you need to know at least enough of the technical details to have a meaningful conversation with other engineers, whether they're developers or operations or data engineers, and so on, and you need really good people skills.

What might be an easier thing to look for, if you want more details than I can offer in a simple Q and A, would be, do a Google search for how to become CTO, because a director will generally report to a CTO. If you think about it, that a CTO is one step beyond where you want to go, you could focus on that track and then stop before you get there. Or maybe you don't want to stop, maybe become a director and then become a CTO after that. I think it'll be easier to find material out there about how to become a CTO than about how to become a DevOps director.

Then also the other thing, because DevOps is part of the question, is learn as much as you can about DevOps, and by that, I mean the culture of DevOps, because it's that culture that makes DevOps unique. It's not the tools, it's not the CICD pipelines or anything like that. It's the culture of DevOps, so learn as much as you can about that.

I know that this is a vague answer, so I apologize for that because it's such a broad question. It's really hard to get specific. Whomever asked this, feel free to reach out to me directly, and I will be delighted to give you more details once I hear more from you.

All right, I have one last question here in the pipeline. How do we cope with the expectation that we need to be learning new technologies all the time? This is a good question. I don't know if it's DevOps specific or if it's just IT. I think I have two answers to this question. The first one is that, to some extent, we honestly are expected to learn new technologies all the time. Whether that's good or bad, I don't know, but it is, of course, an expectation.

I guess one way to look at that is, the newest technology isn't always the best technology. Especially as you get older and more experienced in the industry, I think you start to appreciate tried and true technologies and not focus on the new upcoming thing.

The question is, how do we deal with that expectation? One thing you can do, I wrote about this recently on my daily list, but one thing you can do is something that I read about recently, is called a knowledge option. The basic idea of a knowledge option is that you learn just enough about a new technology or a new tool or a new technique that you know what it does and when it's applicable, but you haven't learned enough to actually do it yet.

Let's say Terraform is the thing. Maybe you go to a conference or a meetup, or you watch a YouTube video about Terraform, and you've never used it before, but you think it might be valuable. Learn just enough about Terraform to understand what it does, what problems it solves, and how much effort you would have to expend to learn enough about Terraform to actually use it. Maybe that means spending a day or two days, or maybe even a week learning about Terraform, but you haven't learned enough about Terraform to put it on your CV yet. You haven't learned enough that you could go to your employer and say yes, I can do Terraform now. You've learned just enough that you understand why it's useful and what you need to do to become capable in it.

Then you file that in the back of your brain. That way, you have of the option, when it becomes useful, maybe you then, in six months or a year, see a situation where, oh, Terraform would be great now. Then you have the option to exercise, you can exercise that option, that knowledge option, and then you invest the time to learn Terraform. If we all spent our time learning the new technologies as they come around, we would never be doing anything else. This is a way that you can learn just enough about some new technologies that you have a catalog of knowledge that you can learn when you need to without investing the months or the years it would take to learn everything sufficiently.

Maybe you spend a couple of days learning a little bit about Terraform, spend a couple days learning a little bit about AWS, a little bit about Google, a little bit about Azure, whatever. All the technologies out there, you could spend a day or two, or in some cases just an hour, learning enough to know what problem it solves and how difficult it would be for you to pick it up. With that, you can build your catalog of almost available knowledge without having to spend these months and months and months learning everything.

I think that's what I had to say about that. Are there any questions I can answer for you before we call an early day? Aha. Is there DevOps opportunities in freelancing? Yes, definitely. Well, I don't know where you're located. I don't know if it matters that much. I live in Europe in the Netherlands, and there are a lot of network engineers. I'm sure the same is true in the US. There are many, many freelance opportunities that relate to DevOps. As I said, now, a couple of times, DevOps is more of a philosophy of how to do software than it is a role. However, many job listings will ask for a DevOps engineer. What they usually mean is an operations engineer. If you're looking for the jobs that are typically advertised as DevOps jobs, that probably means operations probably in the cloud. Maybe something like AWS or Kubernetes, there are thousands of freelance jobs like that available.

I don't know exactly where I would tell you to go look for them. Stack Overflow is going to have job listings like that. Honestly, LinkedIn does. Basically any place that advertises DevOps roles will have some freelancing contract roles like that too. There are thousands of jobs like that. I've had some myself in the past. In Europe, there's a big freelancing culture because of different tax statuses that don't apply to the United States.

In the United States, it is much more difficult to be a freelancer, if only for the health insurance angle. In Europe, it depends on the country you're in. I'm in the Netherlands where we have private insurance, but it's very affordable. I think I pay 70 euros, which is like $90 per month, and I'm covered. Good luck getting a deal like that in the United States. That's one reason why freelancing is much less popular the US than it is in Europe, but it's definitely still possible in the United States.

For any of you watching the replay, thanks. Feel free to subscribe with the daily list. Send me a personal question anytime you want. I'd love to hear from you. Have a great day.

[music]

[00:14:35] [END OF AUDIO]