1 Feb 21 TechOps
- Written by John Beesley, Senior Recruitment Consultant at Burns Sheehan, DevOps Team.
2020 brought about seismic changes in the way many of us live our lives. COVID-19 forced Western governments, businesses, and populations alike to adapt to change like never before in the post-WW2 era. The role of technology in smoothing out some of these adaptations cannot be overstated, and it’s for that reason that the IT sector as a whole has been so robust throughout multiple lockdowns. If current trends are anything to go by, my ‘desk’ in Cloud & DevOps is likelier to be busier in 2021 than ever before.
With organisations of all shapes and sizes increasingly looking to modernise and find a competitive advantage, the adoption and implementation of cloud & automation technologies is a high priority across the board. This brings about its own challenges. Experienced cloud & DevOps practitioners are in extremely high demand. It’s difficult to attract and retain talent in a crowded marketplace. On the other end of the spectrum, I deal with many candidates finding it a real struggle to get their proverbial foot in the DevOps door.
I’ve been discussing some of these challenges with some fantastic leaders within the DevOps/SRE space. One of these conversations was with David Stockton, Engineering Lead at Confluent. Lead by the creators of Apache Kafka, Confluent delivers enterprise event streaming services to a raft of stellar clients across the globe. David joined Confluent in 2019 after a distinguished period at MoneySupermarket and he is focused on expanding his team in 2021.
David Stockton: “60% to 70% of Confluent’s staff were already working remotely prior to COVID. Switching to fully remote wasn’t really an issue as it was already engrained in our culture. With staff split across the UK & USA we’ve always had flexibility via Zoom, for instance. When I interviewed here, I was able to do my day job and speak to Confluent in the evening due to the time zone difference. Our process hasn’t changed, we just aren’t interviewing people on site at the moment.”
DS: “We’re able to set a high bar for the quality of engineer we hire. It’s a fairly traditional process for an organisation headquartered in California, split across multiple stages. It’s flexible enough that an entire process can be completed in an afternoon, but equally someone can piece it out over a week if it suits.
Our internal recruitment co-ordinators do a great job of maintaining communication with candidates throughout the process, whether that’s over email or via WhatsApp.”
DS: “The look & layout of the CV is important, I want to see some thought and effort. Get the basics right: often I see people listing roles without the dates they worked for a particular business, for example. A poorly constructed CV may not eliminate you at this stage, but it’s part of a bigger picture of the candidate we develop throughout the process.
I also like to see more than just lists of technologies you’ve worked with. Don’t just tell me you’ve used AWS. I want to know if it’s EC2, S3, RDS…and to see some detail of how you’ve used it and the projects you’ve worked on. This would give me confidence the candidate has used these technologies daily, rather than just being familiar with them. When the CV lacks this sort of detail it often comes out during the interview process.
More generally, I’d advise people to make their CV as concise as possible. I don’t have a specific page limit but put the bulk of your detail into your most recent work. If the way you describe your current role isn’t particularly compelling I’m not likely to scroll through 20 years and be blown away by your Windows 2000 experience.”
DS: “It really depends. If someone just adds a link without explanation I tend not to look, unless the CV is on the borderline for progressing; a good career history but not much detail, for example. If an SRE has a link to their GitHub and all of their projects are for front end type work, it could put me off. Equally, that person could be a polyglot who dabbles in a wide range of projects. It all just adds to an overall picture.
If someone calls out that they have contributed to open source projects and here’s a link to them, I will generally visit. It can be a good way of expanding on themes from your CV. I once talked to a candidate who had added full stops to Kubernetes documentation. That’s all he did, but he was honest about it and was really excited by his contribution, as minor as it was. On the flipside, if you talk yourself up as a Golang engineer and I see that your GitHub contributions are a bunch of punctuation, that would annoy me.”
DS: “We assess candidates across a range of competencies. First and foremost, we look at their coding ability. If there’s no coding we can’t really move forward. We then look at Linux, Networking & Cloud, as well as cultural fit.
I’m probably slightly biased, but my background is in software engineering and my degree was in software engineering. I always wanted to be a software engineer, from the first time I sat at a computer, as sad as that sounds! So, I always look for those skills and I find that really good software engineers tend to have an appreciation for Ops anyway.
Typically when I’m recruiting I’ll be asking for a software engineer with a passion or flair for Ops, rather than a sys admin type person. We don’t tend to hire traditional ‘Ops’ roles anyway. In Site Reliability it tends to come with an expectation that you will have software engineering experience. I will typically probe in to this quite deeply as I’ve touched upon most of the languages a candidate may refer to in an interview.
It’s really important that people are honest in their CVs. It will usually come out fairly quickly if not. If you mention Java, expect to be asked a question about it. Which version? How did you manage your dependencies? If you used Maven, again, which version did you use the last time you worked with it? These are really simple questions if you’ve done it, but they will expose you if you’re just listing technologies to puff up a CV.”
DS: “Generally, nobody is an absolute perfect fit for the role they’re interviewing for. A lot of candidates will worry that they lack exposure to Kubernetes, or to public cloud. The rise of open source has made it easier to access this tooling but finding them in the proportions you want is rare. I’m really keen for people to demonstrate that they know what they know, in depth. If you’re deploying on an IBM mainframe, I like to hear exactly how this is being done, what you chose to and why. We may have absolutely no interest in IBM mainframes, but I like to see that people know what they’re doing and properly understand it.
I personally need my team members to have strong Kubernetes experience, but not everyone with Kubernetes exposure will have used it at the kind of scale we do. If they’ve worked with hundreds, rather than thousands of clusters, that’s fine so long as they can demonstrate enough competencies elsewhere.”
DS: “It really depends. I’m quite fond of seeing junior engineers demonstrating a passion or enthusiasm for Cloud/DevOps by collecting certifications. However, when I see experienced people collecting them 15 years into their careers, I wonder if it’s actually necessary. It does sometimes make me wonder if the depth of their actual experience matches up to the CV.
For me personally, I pursued a few early in my career as I felt they would help me on the path I wanted to follow. Now though, I feel my work and experience speaks for itself. On the whole, the candidates who tend to be successful with us generally don’t have a raft of certifications.”
David Stockton spoke to me in a personal capacity and his views & opinions do not necessarily reflect those of Confluent.