Site Reliability Engineers (SREs) are a highly sought-after group, but most in the field are passive candidates. Furthermore, that doesn’t mean that the hiring process isn’t difficult. Companies hiring SREs have high expectations and want the best of the best. For any candidate with SRE experience or those seeking to become one, you’ll appreciate this honest, candid look from the perspective of an SRE/DevOps veteran recruiter.
Companies hiring SREs have specific requirements in mind.
SREs aren’t a one-size-fits-all kind of role. The original Google model from 2003 doesn’t define how all organizations leverage SREs today. These cross-disciplinary teams can work in several different models:
SREs are part of developer teams—typically one per developer. These SRE teams are either project- or time-bound and share space (physically or virtually) with developers. These SREs are very hands-on, changing code and configurations. You see this mostly in organizations that are just implementing SREs or scaling an existing one.
In this model, SREs act as consultants for reliability challenges for the entire organization. This structure is different from the embedded model because the roles have full accountability for reliability across the enterprise.
These SREs support developers by building platforms for them to measure and improve system reliability. These teams can overlap with infrastructure SRE teams, or in cases of smaller organizations, they may be combined.
These SREs are behind-the-scenes masters. They focus on ensuring the rest of the DevOps team can work faster and easier. Areas in which they contribute are continuous integration/continuous delivery (CI/CD) and monitoring.
These are broad buckets of how companies build SRE teams, but it provides some clarity from an employer's perspective. It’s less rigid if the company is younger or just beginning to construct an SRE team. But every organization is going to have specific requirements that they believe an SRE must meet, such as:
- Tool knowledge: There’s no standard set of tools for the industry, but organizations may have their own standards.
- Programming languages: Organizations may have rigorous requirements that SREs know a specific language.
- Industry-related specificity: SREs are becoming instrumental in more than just tech companies. Healthcare, finance, and retail businesses are leveraging SREs and may want someone with some background in their field.
Do you have the core skills companies hiring SREs expect?
While companies may have their list of must-haves, which can vary, they likely all have these core skills included. If you want to succeed as an SRE, at a minimum, you’ll need these proficiencies:
- Programming skills (traditional and new language proficiency). While SREs are not true developers, they must have a deep understanding of coding.
- Automation experience with a variety of tools and champion its adoption. The best SREs are master automators.
- Ability to work in parallel with business and technical stakeholders so that both sides achieve the outcome of a better, more reliable product that meets user needs. It can be hard to walk this line, but it’s essential to success for you, the product, and the company.
- Knowledge of multiple domains beyond development, including configuration management, test integration, and system administration.
- Troubleshooting experience and the aptitude and desire to investigate and respond appropriately while remaining cool under pressure. Patience and a calm demeanor are excellent attributes for problem-solving SREs to have.
- Excellence in both written and oral communication. You should be able to articulate the challenges and resolutions in tech- and business-speak.
Does your resume demonstrate your SRE aptitude?
Your resume is your career’s story. What it says and its presentation are integral in your consideration. Here’s what matters:
Length of Tenure
There are exceptions, but, in general, long tenure at positions shows stability and growth. Shorter periods could indicate you job hop. If your resume has shorter tenures, but there’s a reason beyond your control (bankruptcy, acquisition, etc.), add context
Experience with Tools, Projects, and Teams
Your resume should specifically illustrate what you’ve been responsible for and accomplished. Including sections for tool proficiency and achievements can go a long way in developing a narrative around your experience. If there aren’t any details, any reviewer might see red flags.
The companies you’ve worked for matters as well—particularly their reputation and growth, especially in the startup space.
Degrees don’t always matter. They seem to have more clout in banking and investment firms. Companies in New York tend to place more emphasis on this than Silicon Valley. When education is a top criterion, recruiters for these positions are looking for high GPAs from prestigious universities.
Are you a right fit for a DevOps culture?
Recruiters look at technical skills as well as cultural fit when assessing candidates. The DevOps culture is different from traditional software development. It’s an environment of rapid change and can be high-pressure. At the same time, it’s highly collaborative and communicative.
Many talented technical professionals have superior coding skills and operational knowledge. However, they just won’t thrive in a DevOps culture. If there’s a mismatch here, it’s best not to move forward with something that won’t benefit you or the company. That doesn’t mean you can’t evolve and broaden your soft skills. Recruitment firms should provide insights and recommendations to professionals that may need some support fitting into the DevOps culture.
See where the field is going and find your path.
SREs are talented individuals, but that’s not the only reason a company will hire you. There’s so much more to the career than technical prowess. You can continue to hone your hard and soft skills, gain more experience, and embrace the DevOps culture. Find out what companies hiring SREs expect by reading our whitepaper, Secrets Revealed: What Emerging Tech Companies Are Looking for in DevOps/SRE Roles.