I gave my 100th Developer Relations interview this week. I’ve also been on Google’s Developer Relations hiring committee for almost two years. After writing up or reading about all these interviews, I feel like I can offer some general tips on how to do well on DevRel interviews. Of course, standard caveats apply. I’ve only done DevRel at Google and only know Google’s hiring process inside and out. But, I believe the tips below are general enough to apply to many other companies as well.

Know What Job You Are Interviewing For

Developer Relations is an umbrella term that covers a lot of different job titles and roles. Also, the field is still new enough that not everyone agrees on what titles, like “Developer Advocate” or “Community Manager,” actually mean. Because of this, you need to do some research before your interview.

Ask the recruiter or interview coordinator what they know about the job. What is the title? What are the core job responsibilities? Does this job report up through marketing or engineering or other? Find out as much as you can about the job because if the interviewers are any good, the questions they ask will be tailored to the day-to-day work in the role.

While all companies and teams are different, there are some generalities I can share. Community Manager roles are often a specialized program manager role. Thus, you’ll be asked typical program management questions. You may also be asked about fostering diverse communities, organizing volunteers, and prioritizing tasks. Some roles may also require knowledge of open source software or training and education.

Developer Advocate roles vary a lot. Usually, teams that report up through engineering are more likely to ask technical questions than jobs on the marketing team. But that isn’t always true. Your recruiter should let you know if technical questions are part of the process. If they don’t proactively tell you, it is okay to ask. The expectations for coding and technical questions vary a lot between jobs, too. At Google, we have a high coding bar for Developer Relations Engineering roles (DA and DPE). We often ask traditional software engineering interview questions, but we may weigh the readability and clarity of the code slightly higher than a software engineering interviewer would.

Tailor Your Message to Your Audience

One of the most critical skills in all Developer Relations roles is knowing how to change your message based on your audience. “Failure to adapt their message to the audience” is a common reason I recommend “No Hire” for a candidate. Developer Relations roles work with a variety of audiences, from students to executives, and each audience has unique needs. Developer Relations teams must be confident that you will give presentations and explanations that are appropriate to the audience in front of you.

There are two main things to keep in mind to ace this part of the interview. First of all, talk to your interviewers the same way you’d speak to potential customers. That means don’t say racist or sexist things. I really shouldn’t have to include this, but I’ve learned this isn’t as obvious as I would like it to be. This includes not saying things that some folks think of as compliments, like, “You know a lot about containers for a [insert minority group here].”

Related to this, don’t talk down to your interviewer, even if you are smarter than they are. Good DevRelers can explain technical things without making the listener feel dumb. If a candidate can’t do that during the interview, I most likely won’t recommend hiring them. Use polite, respectful language. If you disagree with the interviewer, do so carefully and be prepared to explain your reasoning and back your assertions with data. Part of a DA’s job is to get folks to consider new ideas and approaches, but you have to do it without pissing people off.

The other thing to keep in mind is the background of your audience. I ask most candidates a question of the form “explain [technical concept] to [specific audience].” For example, “explain containers to the CEO of a small consultancy.” or “explain Python list comprehensions to a physicist.” Good candidates start their answers by clarifying the background that the audience has. They might ask if the CEO understands VMs or whether the physicist knows Python. Excellent candidates ask for more information and then repeat back what they heard to verify they fully understand the problem before answering. This doesn’t have to be awkward or take a long time, by the way. A candidate can simply say, “since the CEO has experience with VMs, I’ll start by…”In contrast, candidates who don’t do well make unstated assumptions about my background or the background of my hypothetical listener. And if you give a presentation as part of your interview process, you need to be able to clearly state the intended audience of that presentation, including the background they had with the topic.

Communicate Clearly

Developer Relations is all about communication. Even jobs that seem very technical on the surface, like SDK development, require that you communicate how to use your product through your code. Because of this, communication skills are weighted heavily in all Developer Relations interviews. This doesn’t necessarily mean that your English (or another language) needs to be perfect. But it does mean that you must be able to make yourself understood and that you can understand others.

Most general interviewing tips can help with improving your communication skills, but there are a few things to keep in mind specific to DevRel. First, try not to use jargon. Every company has internal jargon, but not everyone is aware of what is internal jargon and what is a standard industry term. You can practice communicating with folks from outside your company by going to meetups or participating in online communities and open source projects. This is especially important if you haven’t had a lot of jobs or have been at the same one for a while.

You can also check with your interviewer occasionally to ensure they understand what you are saying. And I recommend using CS terminology and being extra precise with your language. With friends, I have a habit of saying, “I’ll new up an object.” I picked that up at a previous job. In an interview, though, I’d say, “I’ll instantiate an object” or “I’ll create an object.”

Also, any code you write or submit as part of a portfolio needs to be clear. When I do interview coaching, I remind folks “in Developer Relations, we teach through code.” Your code should be idiomatic. That means Python should be Pythonic. Ruby shouldn’t look like C. Use the data structures and libraries built into your language where appropriate unless you are told to do otherwise. Variable names and function names should be long enough to be descriptive in most languages (I see you GoLang). As a rule of thumb, an advanced beginner in the programming language should be able to understand your code on their first reading. Be wary of things that you know trip up beginners like meta-programming, multiple layers of callbacks, and unusual, but valid, syntax (I see you, Ruby).

Other Tips

I could keep going, but most of my other advice is just standard technical interview advice. There are tons of books and sites available on general interview skills. A number of my questions are common interview questions given a bit of technical flavor.

If you are nervous about coding questions, the best advice I have is to practice coding. Don’t spend hours memorizing since good interviewers won’t use questions that are directly from books or websites. For practice, I like problems that can be completed in less than two hours and don’t have any competitive aspect. I commonly recommend exercism.io, Project Euler, and Rosalind. Advent of Code is a bit harder but can be fun too. If you practice enough, you’ll notice that many interview questions are variations on a couple themes like text parsing, counting, trees, etc. I also recommend that folks get really comfortable with the text parsing and collections (array, associative array, etc.) classes built into their language.

If you have specific questions or think I’m wrong about some aspect of this, let me know in the comments or reach out to me on Twitter.