Demystifying Getting a Job in Google DevRel

Publish date: 2022-06-08

Caveats

This post is written from my personal experience in Google DevRel for 12 of the last 16 years
This post is point-in-time, as are all blog posts. Meaning information in it might be out of date
I have not served in all Google Developer Relations teams
This post is written because I get a lot of inquiries about Google Developer Relations jobs. I’m hoping to cover the basics here

Step Zero: What is Developer Relations

My short definition: A team involved in establishing a relationship with a group of technical practitioners external to the organization that created it. That relationship is two-way. It is for the purposes of increasing adoption of and productivity using some tool provided by the original organization.

Developer Relations is an evolving discipline across a lot of companies. General information about Developer Relations is available in a lot of places. My favorite place to send people is the DevRel Collective where there’s a lot of information about developer relations. There’s also DevRelCon which makes past videos from their conferences available on YouTube. Including two of my talks :-).

At least at Google, developer relations isn’t specific to working with a “developer” or coder role. There are many roles that focus on other technical practitioners such as designers, security professionals, technical operations, and other kinds of job titles.

Developer Relations Teams at Google

DevRel teams at Google tend to be groups around platforms. Here are some of the teams I’m aware of.

Internal (my team, focused on Google Engineers, not 3rd party)
Chrome
Geo
Cloud
Android
Firebase
Machine Learning
Ads
Workspace
Developer Relations Programs (cross-team)

Each of these teams are quite substantial. Most of these teams are heavily involved in Google I/O. Cloud is heavily involved in Google Cloud Next.

Job Types at Google in Developer Relations

First, there are several different types of roles in developer relations. I’ll list some of the major ones. You may see other titles. I’ll suggest some sample searches as well. For each of these roles there are different levels, and manager equivalents. So don’t assume one job’s requirements are the same across all with the same job title.

DREs

I’ve grouped these together because they all fall on the same job ladder at Google, Developer Relations Engineer. Some titles: Developer Relations Engineer, Developer Advocate, Cloud Advocate, Developer Programs Engineer, Design Advocate (no current roles open), Developer Relations Developer. That last one is because “engineer” is a legally reserved word in Canada so job titles have to be different there. There are probably other titles I am missing.

Responsibilities: What each of these jobs can vary a lot based on a variety of factors including:

Job level
Product area they are working ong
External audience of the role
Product maturity in products they are working on

For most of these roles, they are a two-way interface between the technical community using the products, mostly external to the company, and the engineering and product management teams. What most people see externally is they present conferences, write content such as blog posts, code samples, videos, spend time on social media, engage in community forums, contribute to open source. But internally they are taking what they learn from the technical users and channeling that into changes big and small. Some ways that manifests:

Advocating for changes to products
Helping technical writers write better docs
Helping create products
Changing policies to unlock use cases
Helping teams fix bugs
Testing out products or features before they are released, to make sure they are working right
Writing friction logs to document difficulty using products

Technical Writers

Not all technical writers work in developer relations. And at many companies technical writers are considered part of other teams rather than developer relations. Some DevRel titles: Technical Writer, Technical Content Strategist I may have missed some. There’s actually a page that introduces the role pretty well. And courses you can take to help you become a technical writer.

Program Managers

Some titles: Program Manager, Technical Program Manager, Community Manager

Program managers tend to work across teams, creating and running projects to achieve specific goals. It can be internally facing, such as running content programs so that others are able to produce content on a regular cadence. It can be externally facing, such as interfacing with the community. It can be mixed. At some companies, they may also be involved in event planning, running conferences, that sort of thing. Generally at Google those are handled by marketing roles.

Manager positions

Note just so folks don’t get confused, Program Managers aren’t people managers, unless they are. That being a direct manager for a person is a separate role. You can be on the program manager ladder and manage people, or not. Managing people is something that you can do on each of the job ladders.

At Google, being a manager is not a requirement to advance. You can become very senior at Google, equivalent to the VP level, without managing people directly. This is true across many roles at Google. So don’t assume you need to be a manager to advance in your career. It won’t necessarily help you. If you’re a strong individual contributor who doesn’t care about being a manager, don’t seek out manager roles.

Applying for Jobs

The simplest way to apply for one of these roles is to find one, and apply for it. Once you’ve applied for a particularly job, the staffing team will do a first pass review of the role and ask the hiring manager if they are interested in you for their position. They may also find other hiring managers with similar roles and ask them. Basically at that point, you’re in the system.

If you know someone at Google, you can ask them for a referral. The more they know your work the better. Make sure it’s someone who thinks highly of you and can give you a strong recommendation. That person can then invite you to apply. If you’ve already applied, you can let your acquaintance know and they can contact the recruiter and give a referral. They get a nice bonus and you get some extra credibility. If your acquaintance doesn’t know your work, the most it’ll do is get a little more attention from recruiters. Not very much.

I won’t refer anyone I haven’t talked to. I’m pretty selective on who I refer in, and prefer only people that I know on a work level.

Preparing for the interview

If you get an interview, your recruiter can help guide you in any additional preparation you need to do. Here’s some additional resources.

Aja Hammerly has put together a great guide for the DevRel interview Acing the DevRel Interview. These are particularly important for Program Managers, DREs, and related jobs. Tech Writers should refer to Becoming a Tech Writer at Google.

In addition to the role specific roles, you should check out Googleyness and Leadership Interviews: The Basics . Every interviewer will be asking questions that can reflect on these traits. And generally there will be one interview (out of usually 4-5) that focus on Googleyness and Leadership.

If work you’ve done is in public, it can help to have a portfolio that showcases your work. This can include:

Open source contributions
Videos you’ve done
Writing such as blog posts, articles, books, etc.

Final thoughts

Developer Relations is a great field. And DevRel at Google has been a really wonderful experience for me. It’s also not for everyone. Bottom line, learn as much as you can about the role you’re applying for and use that to prepare for the interview experience.