Building out your IT talent? That’s great. It’s a sign of growth and forward momentum. It’s an indicator that your firm is doing something right for your clients or customers.
However, it’s also something that too many companies get wrong, particularly when it comes to hiring software engineers. Sure, your hiring process probably includes a long list of questions about the languages they like to use, how they like to vet code written by their team members, and the like.
It’s unlikely that you have very many ops-related questions on your slate, though. That’s unfortunate because without asking those questions, it’s pretty likely that you’re going to hire talented engineers that don’t really grasp what they’re doing in terms of their impact on the wider custom software development project.t
Join other businesses to get the latest insights from Softrizon delivered right to your inbox.
Why Do Software Engineers Need to Know Operations Engineering?
Traditionally, software engineers (SWEs) and operations engineers (OEs) served two distinct roles within an organization. SWEs focus on specific components of the software development lifecycle, whereas OEs take a broader view of the entire lifecycle. The problem here is that no one works in a vacuum. Everything a person does affects everyone else in some way. That’s not New Age-y thinking, either – it’s reality.
Let’s take a look at an example. You’re focusing on custom software development. It’s a big project, with a lot of moving parts and both company-facing and public-facing elements. You have several software engineering teams working on the project, as well as operations engineers.
Now, let’s say that one of the software engineers doesn’t code their portion of the project well. It works, but the code is messy – the infrastructure looks more like a plate of spaghetti or a massive interstate interchange than clean code designed to play well with other components. That code makes it past the engineer’s team and into the project itself.
What do you suppose happens when that functional but incredibly messy code gets out into the wild? If you’ve ever been a part of a custom software development project, you know what comes next: faults skyrocket, causing the software to spend more time resolving issues than doing what it was supposed to do. In other words, thrashing.
Sadly, this situation could have been avoided if the software engineer had any inkling of the operations side of the coin. In custom software development, too many people forget that software engineers should be responsible for the code they develop even after its deployment. There needs to be a much greater focus on achieving operational excellence for the entire project, rather than just shipping “code that works.”
What to Know About Interviewing Software Engineers
These days, most IT hiring is done in a committee-like setting. You have the primary interviewer, probably, but you also have others in the loop. The chances are good that you have software engineers sitting in on many interviews, including site reliability engineers, but do you have operations engineers sitting in on interviews with potential software engineers? Because of the traditional (but false) assumption that SWEs and OEs are distinctly different, the chances are good that you do not. And that’s a problem.
With an operations engineer in the interview, it becomes possible to ask important questions, particularly of software engineers who will take on key roles or fill senior positions within the organization. By asking operations-focused questions, you also ensure that all engineers you bring onboard understand the importance of owning their code and that every line they write has an impact down the line.
Who Should You Ask?
Which engineers should you ask operations questions during the interview? Should it only be those who will be in leadership positions? No, you should ask all of them.
Every engineer in your organization, from senior leads to those working on app development for Android or iOS devices, must embrace the philosophy that their code is more than the mere output of their position. Their code is an integral part of the whole project, and as such, they are responsible for the outcomes it causes once it enters production.
What Questions Should You Ask?
Unsure what to ask of engineers as they join your custom software development project? Here are a few basics to help get you started:
- Have them solve a problem. Give them an idea of a new feature that you want to build into your application. Require them to discuss what infrastructure choices would be required to support it. Make sure they also explain the dependencies and ramifications of those choices. In their answer, listen for the following:
- Do they ask about languages the team supports?
- Do they ask about databases in use by the team?
- Do they ask about frameworks required for the project?
- Do they speak about tools for observation and monitoring?
- Do they ask about best practices for local instrumentation?
- Put together a full deployment pipeline. During the discussion, ask probing questions about the following:
- Generating artifacts
- Versioning
- Canarying
- Green/blue deploys
- Rollbacks
- Deploy tool design
- Rolling restarts
- Ask about their favorite programming language, database, or API. Have them explain what it is that they love about it, and then follow that up with what they dislike about it.
- For accountability, ask about the last time they caused an outage in production. What did they do to cause it? What did they do to rectify it? What did they do moving forward to ensure it didn’t happen again?
Wrapping It Up
If you want your custom software development project to be successful, you must create teams that look beyond their own borders. That means asking operations questions when hiring software engineers and making sure that they value operations and can see the bigger picture. Because, ultimately, it’s not just getting the code written. It’s creating code that flows well, that doesn’t cause undue problems once it enters production, and understanding that ownership of their code is not optional.
