Disclaimer: This post is the sole opinion and experience of the author and not intended to be specific responses to interview questions. The goal of this post is to help frame the readers mind to answer in creative ways to help shape the discussion.
It is needless to say that everyone is different. With an ever flattening world job market, many different cultures are now coming together and needing to communicate more and more.
On top of cultural difference, engineers often face a slight disadvantage in the opening interview process. The past several interviews I have experienced were all three round interviews. In each case the first interview was soft-skill communication evaluation. The "culture fit" type of discussions. The second interview was technical in nature (what I focus on the most in my content), and the final was usually a leadership (Director level or above) discussion to confirm what the previous two interviews had established.
Soft-skills are typically underrated in the tech community, and for some good reasons. If you are technical super star, or in a field like DevOps where jobs can't be filled fast enough, it's often easy to overlook working on our communication.
In my last post and video, I covered some of the primary tech skills for a Remote DevOps job posted by Therapy Brands. In this post, I will follow up with the soft skills listed in that posting. Here is the full listing from glassdoor.com:
DevOps/Site Reliability Engineer
"This candidate will need to have a fervor for empowering support, development and product teams to help set the company up for success!"
- Be part of software architectural discussions that will influence site reliability
- Be able to effectively communicate with engineering team, product management team, customer support team, as well as business leaders
- Implement centralized logging
- Build monitoring systems that support large SaaS products
- Build efficient and secure cloud infrastructure
- Create and build deployment processes that scale
- Improve site performance amidst growing user bases.
- Keep cloud infrastructure costs in check.
- 5+ years of experience in a DevOps, System Admin and/or Development role
- Good Linux skills
- Familiarity for immutable infrastructure.
- Familiarity with tools like Terraform, CloudFormation
- Experience with building CI/CD pipelines
- Experience with database tuning
- Experience working with cloud platforms (AWS, Azure)
- Passionate about source controlling everything
- Experience building applications in the healthcare space
- Experience/familiarity with test automation frameworks
- Experience with docker toolset: (kubernetes, ECS)
- Problem solver
- Detail oriented
We’re serious about team member well-being. That’s why we are proud to offer the following employee benefits including but not limited to:
- Unlimited paid time off for eligible employees
- Generous Maternity and Parental Leave Plans
- 11 paid Company Holidays
- Comprehensive medical, dental and vision insurance available on day one
- 401K Safe Harbor plan with company match and 100% vesting on day one
- Meeting-Free Fridays
- Quarterly paid Community Service day
For more information, visit us: https://www.therapybrands.com/
I highlighted the particular traits that I will cover here.
Now, before we begin, this is a DevOps role and it would be a good idea to refresh our definition and understanding of the most fundamental DevOps concept, the figure 8 loop.
I really like Atlassian's graphic -
In my most recent interview, I was asked the following question by the Director of Infrastructure:
"Let's say you and I meet at an event and I have no technical understanding at all. We are talking outside and my Uber is on the way. One minute before the Uber arrives I ask you to tell me what you do for work. What would you respond with"?
By relying on the top graphic, as well as Gene Kim and team in the DevOps Handbook, I formulated my answer in this way,
"Well, software products, as well as client demands, are a very complicated matter. When a project is being developed and varies issues, including client requirements changing, happen, the tension between an organization's operations and development teams becomes more and more tense, resulting in unhappy workers, poor delivery, and ultimately client dissatisfaction. DevOps bridges the gap between the two worlds and allows for secure, efficient, code rolls. We maintain the entire lifecycle of the project and make it easier to make multiple major deployments into stage environments daily. We also monitor production and ensure the end user has the best possible experience. This results in a happier environment for all and critical delivery expectations being met, ultimately producing a happy client."
In that quick under a minute response, we effectively just gave a general overview of our objectives and goals to someone who would otherwise not understand.
So with that general understanding of the role we are interviewing for, we can confidently frame our answers for the following traits.
The obvious response here is "coding and scripting experience". But I would challenge you to use specific examples and not dwell on this one too much. Your technical skills will definitely come up soon.
Lean on examples from your personal experience or if you are looking for your first role, theoretical.
Typically within the devops space, where do problems often arise?
- Build Phase - Perhaps you ran into an issue where you needed to create your own AMI with Packer.
- CICD - Creating Pipelines means you are troubleshooting pipelines. How did you overcome those issues?
- Monitoring - Setting up effective monitoring is difficult enough let alone understanding every response it provides. Consider answering involving monitoring and troubleshooting systems.
One major thing to consider is making sure that you mold your discussion around future facing improvements. Think BIG here. In the last post, Immutable Infra, we covered the requirements around this job's technical areas. You could formulate your responses to show problem solving abilities as follows:
"At my current/previous organization, we were spending a lot of time and resources on our deployment server. Patching took hours, managing space became very manual, and there was a lot of unaccounted for stored on it. I create a terraform and ansible repository and configured it with Jenkins to easily create, modify, and destroy that operational resource that was becoming a cost pit."
In a response like that (assuming it's true and can back it up with supporting contextual evidence) you show that you are able to identify issues that the organization faces and can take initiative and act on it. A great engineer sees a problem, fixes it, and says "Hey boss, there was a problem but i've got the solution. Employers love it when you,
- Take the initiative
- Speak with authority of a subject (from knowledge that you have) and;
- Concern yourself with the results the stakeholders and clients care about
This is always a tricky question because so often as engineers we feel the need to continually justify our time. But for an interview/discussion sake, we want to formulate our answers to show that we understand what it takes to be a "self starter" and engage in the day/week/months objectives.
Consider the following discussion points:
Time management is critical for advancing your career. Not in a micro management way, just simply knowing thyself. Account for what you do, when you do it, and how to improve it. One of the primary qualities of a leader/self starter/executive are that they are aware of where their time goes. Find a way to relate this back to the employer. If there are tickets in the queue, do you organize them in the morning? Do you assign them out to yourself and others? Are clients waiting on you? These are some points to make clear. Expressing self control and awareness of the goals and objectives of the organization.
Continual learning and improvement is one of the easiest ways to show your self starter abilities. Starting this process now while looking for a new role is key. Show that you have pursued the newest technology, common accolades and certifications, as well as attending meetups (virtual or in person) and networking with professionals in your line of work.
- Setting your own goals and KPI's is a bonus and something I was taught early on by my leadership. Being able to define your own performance indicators is what will separate you from the competition. Figure out a metric and talk about it. The easiest one is SLA time on tickets in the queue. "We met SLA time 99.99% of the time in 2020. We did this by utilizing Kanban boards and following a daily routine in which I would vet each ticket before leading our daily standup call and ensuring no ticket was left in the 'To Do' column at the end of the day."
Proving you are a self starter is not so hard when you bring ideas to their minds.
You should refer back to the graphic and notice around the 8 is "collaboration and communication". You could word it like this:
"Communication and collaboration happen all along the lifecycle of the project. In a specific example, I have personally experienced situations where a developer would try to include a last minute 'critical' change into a production release cycle. In this case I had to work quickly and effectively with the developer, QA, change management, and the release manager to determine if it was something we could do. Ultimately we made the change and it met the client's requirement."
Problem = last minute code included in the release cycle - client requirement
Solution = working through the proper channels and system to make sure you were as helpful as possible while being protective of production.
Ponder Agile continuous feedback, also part of the DevOps figure 8. Identifying problems at the end of a project and improving them for next time is a fantastic display of collaboration and team effort.
Again, it is tricky to not sound like every other candidate here. Try to use specific examples surrounding the movement to production as well as maintaining queues and limiting work in process (another key point from the DevOps handbook).
Change Management is crucial to organizations of any size. Understanding the process, proposing changes with the correct format and verbiage, and mitigating risk by identifying changes that could pose a risk to production. Being able to review Pull Requests effectively, comparing what is changing to what is in prod already, and identifying typos in submissions (including configurations). Relaying this level of detail will go a long way.
- Maintaining large amounts of information, such as tickets that are work in process (or WIP), is another key focus and strategy of the DevOps department. Being aware of those metrics and limiting the number of tickets taking up time in the WIP category (or 'To Do' column) is very important. This can be hard to prove if you haven't been in a situation where you have queried data from a system like JIRA or Service Now. But nevertheless, it is good to mention an interest in.
Have a relentless attitude. Making it clear you are a very flexible person, but don't quit (unless required) when facing difficult tasks is important. The good thing about this quality is that to be in the position to even apply for a role like this, you have already expressed some evidence of diligence. Learning new tech, concepts, and languages puts you at an advantages over other typical candidates.
You see problems through, but also know when to seek assistance. Part of being diligent means that you are aware of time. Diligence does not mean that you sit on an issue until you figure it out. Asking for help and/or delegating to someone more knowledgeable in this area on the team is an amazing skill and trait that not many utilize. You should absolutely make it clear that you are a team player and are able to put the teams objectives above your own personal pride. The team as a whole should be considered diligent.
The final trait listed in that section is looking for a display of proactivity. Here are a few things I consider discussing when conveying this concept.
Make the hardest phone calls first. When I was at my first major job out of college, I was managing the release process and screwed up big time. I allowed a last minute change through that was "critical and non-impacting" and I didn't vet it properly, just took the project managers word for it. It broke everything. I pulled a late night rolling back that change and had to wake up QA. The next morning I immediately called my boss in San Francisco and said the following: "I screwed up, I know I screwed up and I am sorry for making that call. Today will be better than yesterday and tomorrow will be better today. That same mistake will not happen again." Believe it or not, even though I broke Prod, client sites were down, and I had an entire team on after hours, his response was "That's refreshing to hear. Thanks, Scotty. Have a good day". Be proactive with your management.
Proactively set and then exceed client expectations. Don't write checks that will bounce. Make an SLA 3 days for standard incident tickets. Have them done in 1-2 days. This is a pretty simple concept that so many people refuse to abide by. Also, it goes without saying to proactively maintain that queue so that you can get them done within the allotted SLA time.
- Generically, identify issues quickly and fix them before the client even knows. Implementing good monitoring, abiding by firm change management guidelines, and being care about code rolls, means you will be able to catch issues before clients become aware. Consider the time changes are scheduled, the QA test results, and finally, config changes made to Prod that might negatively impact the deployment.
Only YOU can bring your own personal stories and personality into an interview, but hopefully you gained some insightful responses and new ways of forming discussion points around these DevOps qualities.
Best of luck in your next interview!