Becoming a Developer Advocate at Google

Interviews and Expectations

"So, I heard you're moving to a non-Engineer role." I heard variations of this comment at least five times in my transition out of my role as a Full Stack Engineer at ActionIQ. It shouldn't bother me so much what other people think of the role I am transitioning into, and yet the discrepancy comes off to me as a violation of my identity as an engineer. As a Developer Advocate (DA), I am required to be an engineer. Only through intimate familiarity with the struggles of a Software Engineer can I adequately communicate with them to understand and amend their issues with the Google API I will represent. It takes an engineer to debug the mysterious exceptions and behaviors that developers find in their code, to help them understand best practices by creating examples and tutorials to guide their development experience, and to recognize and fully comprehend faults or opportunities in the API to then work with Product and Engineering teams to enhance that API for the benefit of the developers who integrate with it.

I lay out these expectations based purely on what I have read online and my conversations with current DAs at Google, but it will be another few months before I can speak confidently from my own experience. Starting on September 14, I will be a DA at Google on the Ads API team. The first few weeks will consist mainly of general Google employee onboarding and engineering-specific onboarding. The following six months or so will have me onboarding into my role and building an understanding of the Ads API so that I can better service the external developers who use it. By the end of that six months, I'm told, I will start to assume responsibility for specific clients – I will internally represent the developer teams at companies that employ the Adwords API and I will become their technical point person on questions and qualms related to the API. We shall see after six months whether reality matches expectations; granted, I am keeping my expectations with a large grain of salt and the overarching expectation that experiences in the DA role vary widely from person to person and team to team. Until I have the experience to verify one way or another, I hope this post will serve to clarify the DA role, including what sort of experience and skill set was necessary to become one.

How Does One DA?

What Ashley McNamara, a DA at Microsoft, describes in her Medium post aligns well with what I have heard from the DAs and recruiters I've spoken with at Google, for the most part. She summarizes the role well,

I like to say that it’s my job to ask dumb questions so you don’t have to, but the real goal of a Developer Advocate is to become the voice of the user. We gather feedback in a way developers can’t (since they know the codebase too well), then use that feedback to shape the product to become what it needs to be.

One caveat to Ashley's post, which might be Google-specific, is that some aspects of the role can be more or less prominent depending on the proclivities and skills of the DA. In this way the role is, as one interviewer told it, a choose-your-own-adventure. That very well may be an exaggeration intended to advertise the role to prospective employees, but it was at least consistent with what everyone else had told me. So, for someone like me who wants to not loathe public speaking and yet never got over my disdain for the experience, the "We’re not afraid of public speaking" header of Ashley's article does not apply. Sure, I am open to the possibility of acclimating to the experience so that I can represent Google more visibly at conferences and community events, but I am hoping to have the option of [and have been led to believe that I will have the option of] limiting my public speaking to smaller, workshop-style settings and panel discussions, rather than solo on-stage presentations. Still, there are other aspects that are inextricably linked to the title, namely the focus on constant learning and a foremost desire to help developers. Developer Advocacy is a relatively new branch within Engineering that exists to serve the relatively new need for an engineer's perspective at the product level of products whose users are engineers, e.g. APIs and client libraries. Thus, a Developer Advocate must be willing to learn continually – about the vast tools and languages that exist in the developer landscape, the problems that developers face in using the API or library, and the intersection of those spaces – to appreciate, represent, and address the engineer's struggle with using the product.

Interviewing for the Developer Advocate role

With expectations laid out and caveated, allow me to add more clarity to the role by detailing my interview process to become a DA at Google.

Attempt #2

So, yeah, this successful attempt was not the only attempt – actually, it was my second time going for a Developer Relations role at Google. The first time was January of 2019, when I interviewed and ultimately was rejected for a Developer Programs Engineer position. The distinction between the two roles is a bit blurry (see this explanation by DA Dustin Ingram), but for the sake of the interview process they are almost identical. The only difference I experienced was that the Developer Advocate interview required an additional step for the onsite, which was a presentation that would showcase my ability to explain and engage an audience around a technical concept of my choosing.

Stepping back a bit, my journey to Google has spanned quite some time, and still less time than what I have heard from others. From what I gather, it is completely normal to interview multiple times for Google before getting hired, sometimes 4 or 5 times (or more)!  Two rounds of on-sites doesn't sound so dreadful in comparison! Starting from my first encounter with the recruiter almost two years ago, I present to you a timeline of my journey to Google:

The Interviews

Out of respect for the process (and because I signed an NDA), I won't go into detail on what exactly was asked in my interviews. But I can share loosely what I felt they were looking for through their interviews:

1. Technical acumen: Part of each interview was what you would expect for any software engineering role: coding. The amount of time dedicated to this piece varied from fifteen minutes to a half hour or so, and the difficulty of the questions varied as much. This felt intended to measure not only my coding ability, but also my general problem solving skills, my ability to think on my feet and adapt to changing requirements, my methodology in approaching a complex problem, my understanding of time and space tradeoffs, and my ability to communicate all of the above clearly. Unlike some technical interviews I have done in the past, coding was not the only piece dedicated to measuring technical know-how. Each interviewer also asked me to explain technical concepts, which showcased both my understanding of the technologies and my ability to communicate that understanding effectively.
2. Communication skills: This is something that the interviewers could gauge throughout the entire interview, whether through a technical or behavioral question. There were a few questions that were more explicitly looking to measure communication (e.g. how would you explain x to y?), but any question was fair game as a representation of how I communicate. After all, how you communicate with an interviewer, even at the beginning and end of the interview when the conversation is more casual, can be taken as a sample of how you would communicate with your coworkers or clients on the job.
3. Interest in the role: I was prepared with several reasons why this particular role and Developer Relations in general was of interest to me, and went into each interview with a list of questions to pull from – both to elicit as much information as possible while I had access to Googlers in the role I was interviewing for, but also to demonstrate that my interest in the role was genuine.
4. Relevant experience: Given how new this sort of role is, I would be shocked if more than 5% of Developer Advocates came from Developer Relations roles prior. Without DevRel experience myself, I leaned heavily into examples that translated clearly into the role, mainly: communicating with clients, writing technical documentation, mentoring coworkers and interns, tutoring Computer Science students, engaging with open source software and OSS communities, and writing code myself for side projects and as a Full Stack engineer.
5. Empathy for developers: By speaking to my Full Stack development experience and clearly articulating how I overcame problems as a developer, and specifically as a developer using tools provided to me by other developers, I proved that I could empathize with the developer experience. For this criteria, it was especially helpful to have thought in advance of examples of times I enjoyed or struggled to use an external piece of software, as well as what could have been useful to overcome those struggles (how could my developer experience have been improved in those instances?)
6. "Googleyness": This is one of those terms you hear but can only guess what it means from the outside. Do they have questions that measure this in isolation? Is it defined anywhere? Did I receive a "Googley" rating? So many questions! The recruiters framed this to me as "culture fit and leadership" ¯\_(ツ)_/¯. If you know, you know.

This is obviously a limited list, and heavily biased towards my own experience, but I hope it serves to help others prepare for their own Developer Relations interviews, and to clarify what even is required for this type of role. In case it will be helpful for you, here is my resumé at the time I landed a job as a DA at Google:

Notes on COVID-19

While it was strange to have a fully remote interview process this time around, I actually felt as relaxed with my interviewers as I remembered feeling during my on-site in Chelsea. Somehow, that feeling of friendliness and patient support that my interviewers conveyed in my first attempt (was this their "Googleyness"?) permeated Google Hangouts and made me about as comfortable as I could hope to be during six hours of intellectually demanding interviews. Still, knowing that the interviewers could not feel my presence as well as they would in person, I tried to make up for the communication impediments by speaking loudly and clearly, sitting up straight, and erring on the side of over-communication when it otherwise might not have been clear what was happening (e.g. I would let my interviewers know that I was looking off-screen to consult a list of questions I had prepared for them).

Interviewing remotely was just the first step of an initially-remote journey through Google. As far as I know, I may not be allowed in the office until July 2021 (almost a full year from now!!!) A brief moment of pause for the absence of in-office perks and orientation that Google is so beloved for. (Sigh). Looking on the bright side, starting out remotely will allow me to separate the amazingness of the in-office perks Google offers from my enjoyment of the work. I found it hard at my previous job to separate my love for the work from my love for the company and all the lifestyle benefits it offered. It is important to value both the company and the work in any job, but I can see how it will be beneficial for me to observe my enjoyment of the job as a direct outcome of the work itself in order to get the clearest sense of whether Developer Advocacy is "right" for me.

See You Soon, Google

The other side of interviewing remotely and working remotely through COVID-19 is that what would normally feel unreal feels especially unreal due to the lack of a change of scenery. I didn't stop going into my old office, there were no in-person Goodbyes (unless Zoom is the new "in-person"); this might as well be a brief vacation before I return to ActionIQ. I have to convince myself that I am starting a job at Google in a week. I am starting a job at Google in a week. I am starting a job at Google in a week.