Demystifying Getting a Job in Google DevRel
- 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)
- Machine Learning
- Developer Relations Programs (cross-team)
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.
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
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 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.
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.
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.