You’ve been hearing about DevOps as a career path, and you’re looking to to break into the field as a Jr DevOps engineer, but you don’t quite know if you’re qualified for it yet. You might be a recent grad, or maybe you’ve been in the industry a few years and you want to improve your skills. How do you know whether you need another 3 months to get some better experience under your belt, or whether you should have applied for that one DevOps job last month but didn’t because you thought you still had more to learn.

I currently work as an engineering manager at an ed-tech company focused on helping our teams ship their applications (APIs, websites) quickly and safely. Our DevOps engineers are responsible for building the tools that teams use to deploy and operate their apps in production hosted on AWS. Our team recently hired 2 junior devops engineers and a few interns so I wanted to share a few things that made some candidates stand out over others.

*Your mileage may vary, and different people and companies may have different expectations around a junior devops engineer based on how they’ve implemented their role. Here’s one more data point.

1. You’ve deployed a website or one of your own projects, and can talk about it

Examples: You’ve built an Android app, a website using ruby on rails, express for node, flask for python, react for the front-end, an npm package. It’s incredibly helpful for you to have experienced more than one.

You’ve got some projects under your belt whether they’re tinkering on your own, part of your grad course, or at your current job. Building and hosting a blog counts, but I’d expect to see one or two other projects that aren’t a blog. I also expect you to be to talk at length about it — please tell me about that HTTP 500 error you spent 4 hours chasing down. I honestly love hearing a good memory leak story.

The main thing I’m looking for in this respect is that you’ve gone through the full lifecycle of building a package, testing to make sure it works, releasing it, and then monitoring it to see if did what you expected. Always be shipping!

2. You know what its like to work as part of a team and what its like to interface between different people/teams to get something done.

This one isn’t quite so specific to DevOps but I think becomes a bit more important. You’ve worked in teams and people like to work with you and you like to work with people. There’s no room for egos or jerks, and it might be hard to judge in an interview (there’s even a Quora thread specifically around weeding out jerks). I mainly want to see that you’ve been able to deal with differing personalities on projects and how it may or may not have affected your success.

One helpful characteristic that I’ve seen from non-jerks is the willingness to teach and help someone else through their problem. For example, one engineer worked as a CS tutor and then put together a Slack channel where students could help each other on some school projects. Another engineer started working with another employee in the company guiding them through building features to automate some painful aspects of their job.

3. You’ve worked on multiple different projects and not the same project multiple times

Over the span of a few resumes, there were a handful of candidates that stuck out — for the wrong reasons.

• I had asked one engineer why he chose Jenkins for a particular solution and they responded by saying it was the only system he knew. I expect you to know of a few alternatives to your favorite tools and when you would recommend one over the other. If you’re a fan of Jenkins, I’d expect you to know when to recommend Jenkins over Travis/CircleCI/Insert-CI-Tool-Here.
• Another trend was that of an engineer (not a contractor) working on a team that worked on deployment pipelines using the same tools in 6-month to 1-year stints at multiple companies. If all you have is a hammer, everything looks like a nail. After the 3rd instance of it on a resume, I wonder whether they’re really good at using the hammer, or if everything just looks like a nail.

I’d expect a good candidate to have a curious mind and work on different types of projects over time. Maybe you like doing some Unity game development in your spare time, or you’ve been dabbling in data analytics or machine learning projects. Some candidates even have a handful of robotics projects. Not all our projects see life in production, but we still learned a good deal while figuring that out. In a DevOps role, you’ll see applications of different shapes, sizes, and color so its helpful to have seen some of that variety on your own before you see it at a new job.

4. You’ve used AWS (or other cloud provider at least) in some capacity for your projects

You’ve played around with some of what AWS has had to offer. You may have set up a website using S3, you’ve managed to get an application running on Elastic Beanstalk, or a nodejs backend hosted on EC2. For me, I had started learning with EC2 and Chef (if I would do it over again, I would start with S3). If you haven’t and all you’ve used is a hosted VPS, try migrating it to AWS — its a great place to start. A few candidates had built pet projects using S3 + RDS — that’s great to see.

If you’ve got some of these characteristics, you’re in great shape — stop thinking twice about applying for that job and take it. If you feel you’re a little short, you’ve got some direction with where to focus whether its building an app and deploying it to AWS S3, working on a different type of project like chef cookbooks, or working with other people on your projects.

Agree or disagree? How do you know if you’ve got enough experience to get into a DevOps gig? Let me know in the comments.

Originally published at www.intricatecloud.io on September 24, 2018.