What are you doing now?
I work for Google. My job title is SWE-SRE, which stands for Software Engineer – Site Reliability Engineer. At Google most engineers are Software Engineers – these people develop most of the code that runs Google applications. I was a Software Engineer for about 18 months, and I really enjoyed working on that project.
A smaller group of engineers are classed as Site Reliability Engineers. We take a bigger role in responsibility over Google’s production systems. We carry pagers while on-call which are used to alert us when a system is having issues; when we get paged we have to quickly troubleshoot and respond to the issue. There is further subdivision in SRE into two roles: SWE-SRE, and SE-SRE (Systems Engineers). The differing responsibilities are broadly the following: SE-SREs take care of high-level details of the system as a whole – its general structure, communication channels, monitoring, etc. SWE-SREs generally have a deeper understanding of the code that makes up the system, and take care of designing the modules that make up the higher-level design. However, take this with a pinch of salt: I think that it’s important to understand that nobody at Google is really pigeon-holed into doing X or Y; really the important thing is that the different members of a team come together to produce good results with whatever their disparate skillsets may be.
While part of an SRE’s job is being on-call for Google’s production systems, what personally really interests me is deep-diving into the system itself and refactoring (and in some cases rewriting big chunks of) the code to make the system as a whole more robust, or scalable, or have lower latency, or be more resource-efficient. I find this really interesting and rewarding, and that is why I have made the switch from SWE to SRE.
What is your favourite memory from your time studying Computer Science in St Andrews?
The final demonstration of my Senior Honours class’ dissertation projects. We had all gathered in the shared 3rd/4th year lab, where each of us was trying to set up our demos for our markers to see. My particular project was based on a peer-to-peer network, and so to lend some authenticity to the demo I had logged in and started up my demonstration on a bunch of machines – but because the whole class was there, these machines were dotted around the room and so I was running around trying to get it set up, in amongst my whole class all of whom were nervously trying to do the same.
Giving the demonstration was fun, but frustrating. Fun because this was more or less the culmination of (the practical part of) a year’s worth of work, which I’d finally be able to show off in a reasonably polished fashion. Frustrating because demos never go the way you hope them to – during the live presentation I think I discovered two or three bugs that hadn’t occurred in my prior testing!
In any case, this was a really great experience; particularly because we’d gone through the year seeing glimpses of each other’s projects and this was the first time that we really got a chance to see in full what everyone else had made.
What was your favourite module, and why?
There were a bunch of really interesting modules. However, if I have to choose a favourite, I’d have to say Programming Language Design and Implementation.
I didn’t really know before attending this class but it turns out that I find languages, and language theory, really interesting. This interest has stayed with me ever since; I enjoy learning new programming languages and their specific design points, and in particular I really like learning totally modern languages – my new favourite is Go, which has a bunch of nice features.
Kevin Hammond was a really excellent lecturer – I feel as though I learnt a lot from him and really enjoyed his teaching style.
“It’s easier to ask forgiveness than it is to get permission.” – Grace Hopper (who apparently developed the first compiler!)