What a Senior Software Engineer at Google does in their own words, excellent read.

Have you ever wondered what exactly does a Senior Staff Software Engineer do at Google?

"I’m a Senior Staff Software Engineer at Google. This means that a) I have an engineering, not management, role, and b) that I’m pretty senior (in particular, the most senior engineer in my office – Warsaw).

I’m working on the Cloud Console team – the team responsible for building the UI for the Google Cloud Platform. I am a Tech Lead of an 8-person team focused on infrastructure for the Compute, Networking and Kubernetes sections of the console.

This answers what my role is, but not what do I really do. This is a somewhat complex question, because I do a lot of different things, so I’ll just give a rather long list of various things I did over the course of the last month.

I co-organize the work of my team. Google typically plans work on a quarterly cadence, and so we spent a few days discussing what are the important things for us to focus on, and what can we achieve. I was preparing the questions, asking them, driving the conversations, mediating when doubts show up, clarifying what do individual items actually mean – both in terms of benefit, and in terms of the actual work that needs to be done.

I spent a considerable amount of time in mostly informal conversations with team-members around design choices, both on a small scale (how do we attack a particular problem), and on a larger scale (designs that will take a quarter or a few quarters to come to fruition).

A large part of my time is externally-facing; both towards the broader Cloud Console community, and towards the backend teams we build frontends for. I’m writing this from Seattle, where I visited mostly to talk with the backend teams, listening and understanding various changes coming up and how they affect us, as well as explaining what makes our work harder, and collaborating on designing solutions – both short-term (things that can be implemented in a month), and long-term (things that are year-long programs). Similarly, I engage on a comparable level in some work that other Cloud Console teams do.

I effectively serve as a source of answers for our management. I do deep-dives into hairy topics, where there’s a lack of clarity what should the long-term direction be, and come out with designs. This, in terms of actually doing stuff, involves thinking, talking to people, prototyping things in code, leading others to prototype things, talking to people more, thinking, writing up documents and presentations, presenting the ideas, and ending up with answers.

I also engage in areas outside of the Cloud Console – over the last month, I’ve spent something like 4–5 days in one of the products I’ve been working on previously, figuring out a load-testing strategy (so, again, understanding the architecture and pain points, trying to make an informed guess of what’s most likely to break, and thus what really needs to be pressured with tests, overviewing the tools to test we have, and helping choose correct ones, and talking to various product-oriented people to figure out how much load do we have to be ready for).

I do a certain amount of community contribution. This covers interviewing, talking with people who want to go up for promotion about how to present their case well (and sometimes, unfortunately, telling them I don’t think there’s a promotion case to present), giving talks to the office I’m in, etc.

Finally, I sometimes code. Less often than I’d like, unfortunately. The most common case when I code is when I find something in the code that I think should be fixed, and I figure it’s probably simpler to just fix it than to organize the process that would lead to fixing it.

I hope that gives a decent overview"