At Google we are pursuing efforts that champion awesome user experiences across all platforms in the Content Management Systems (CMS) space. One of those efforts focuses specifically on the WordPress platform. As part of Google’s commitment to these efforts, we are growing a team focused on WordPress Developer Relations. The goal of this team is to pursue scalable WordPress development efforts laser-focused on two main areas:
- Advancing the WordPress platform along the progressive road: accelerate the adoption of coding and performance best practices, integrate relevant modern Web APIs with WordPress core (e.g. Service Workers API), development of tools (e.g. plugins, progressive themes starter kits), work closely with the WordPress community, etc.
- Making the experience of Google products in WordPress (i.e. Analytics, Search console, etc.) awesome: develop tools and plugins, that enable the WordPress community to have free high-quality options for leveraging Google technologies such as Analytics, Search Console, and others.
If you are a strong WordPress developer, you love the web in general and WordPress in particular, and you feel passionate about contributing to making those platforms better, you may be interested in joining our team. That would be awesome! And if you decide to do that, you must go through the interview process at Google.
DevRel Interviews @ Google
The WordPress Developer Relations team we are building is part of our Web Content Ecosystems initiative, which itself is part of the Developer Relations (aka DevRel) part of Google.
DevRel at Google is engineering-driven, and therefore the interviews for the positions related to (WordPress) Developer Relations at Google are technical interviews. In this post I offer my perspective into what these interviews are all about, what do they seek to achieve, and how to go about preparing for one. This guidance is applicable to most technical DevRel interviews settings at Google, not only the ones for our roles.
Every interview and interviewer at Google is different, but the interview process is in general well defined. In a nutshell, the process is a technical interview with the majority of questions focused on the basics and fundamentals of the skills associated with a given role. The interview process also seeks to get a glimpse of how you think, how you approach problems and unknowns, and how you interact with your interviewer.
An interview for a DevRel position has two main components, with varying degrees of weight and volume depending on the specific role: Developer Advocacy and Engineering Skills. Once you engage with the interview process, you will be guided to which is the right balance according to the position you are interviewing for.
In the context of developer advocacy, there will be some questions related to areas such as communication skills, community engagement experience, and other questions related to open source projects that you have been involved with, and the development of APIs to be used by the developer’s community. We are looking for strong communicators: engineers that like to engage with community efforts, ideally have a track record of collaborative work, and have a voice in the community — past talks, presentations, etc., are all strong assets. Furthermore, you need to feel comfortable in this role, as you’ll be expected to represent Google around the world — that’s a key requirement.
And in the context of engineering skills there will be a number of technical coding questions related to software development knowledge (algorithms, coding, design); this is where an understanding of fundamental algorithms and data structures is important.
How to Prepare
Succeeding in an interview depends on many factors and I know many extraordinary people that have failed interviews at Google and elsewhere. So, failure is not an option, but it is a possibility. And preparing well is the best we can do to maximize the chance of success.
If you have been involved in the WordPress developer’s community, or have been developing on the WordPress platform for a while, you likely understand the advocacy aspects entailed in working with such an open, large, and vibrant community. But in any case, once you engage with the interview process, your recruiter will give you details on what to expect.
Preparing for the engineering part of the interview is in certain ways harder because it involves bringing to your head’s cache memory the fundamentals of Computer Science. This approach to interviews is effective but it is not perfect. Several of the best engineers I know have no formal CS background, and in spite of being able to build a castle on a browser, they can too be vulnerable to this part of the interview process. Nevertheless, knowing this, and no matter what your background is, you can prepare well for an interview anywhere. If you are a good developer, you certainly know the fundamentals, even if the names you use for them are different. Let’s roll up our sleeves, and prepare well.
In most interviews you will be expected to write code in one way or another. In a phone interview you may write the code on a Google doc; whereas in an onsite interview you will write code on a whiteboard. For many people it is often challenging to write code on a medium other than an editor/IDE. It is very important that you practice writing code on paper or on a whiteboard as you study.
Regarding the code you will be asked to write, it will be expected that you know a fair amount of details about your favorite programming language. Your code should be well written, consistently styled, and as close to compilable as possible. This does not mean that you will fail if you forget a semicolon or an indentation, but coding style and approach are important signals of how you work.
Depending on the role you are interviewing for you will be expected to know more or less about API’s, OOD/OOP, how to test your code, as well as coming up with corner cases and edge cases for your and other people’s code. My approach to this is: prepare as if I was interviewing for the highest level I can possibly seek; doing that forces me to do my best and be as strongly prepared as possible. I am totally fine being over-prepared for an interview because that mitigates the anxiety and pressure I (and others) experience during interviews
I like to think of engineering jobs as jobs in the construction industry; I mean the jobs of the folks that actually build things. All the things we know: algorithms, data structures, design strategies, etc., are tools at our disposal in a toolbox. When you are asked a technical problem your task is two-fold:
- Extract the essence of the problem asked and bring it to its fundamental pieces that enable you to propose a solution.
- Determine which tools in your toolbox you could use to solve the problem elements. Many actual Google problems are solved in terms of essential components of such a toolbox, such as Sorting (plus Searching and Binary Search), Divide-and-Conquer, Dynamic Programming / Memoization, Greediness, Recursion or algorithms linked to specific data structures.
Part of your goal in preparing for a technical interview is to make sure you understand the fundamental tools that should be part of the engineering toolbox to fulfill the role you are seeking. If you want to build a wooden house, you better have some nails and a hammer in that toolbox.
You should study up on as many data structures as possible, including those such as Arrays, Stacks, Queues, Hashing, Dictionary, Trees, Binary Trees, Heaps, and Graphs. Ideally you should know these data structures well, the runtime complexity for most their operations, and what algorithms tend to go along with each of them. Knowing this enables you to identify patterns in problems and map them to a domain where the application of a given technique is easier. For example, many problems become easier to solve once their input has been sorted, effectively enabling the application of sub-linear searching strategies (i.e. Binary Search); where easier means, for example, bringing down a quadratic, O(n^2)), time complexity to a more manageable (i.e. O(nlogn)) one for very large input datasets.
Keep in mind that the interviewer will be evaluating not only your technical abilities but also how you approach questions, how you derive the answers, how you communicate, and how you interact with them. We don’t expect you to know the answer to every problem thrown at you in an interview setting; that’s not how the real-world works. We are trying to assess whether we would be willing to sit with you side-by-side in the future and work on a problem that neither of us knows the answer to: we want to see what tools you have in your toolbox, how you use them, and how you handle uncertainty. And at the same time, the interview is an opportunity for you to get a sense of how it would be to work with a Googler.
During the Interview
During the interview make sure to ask questions any time you need clarity. Don’t worry if you don’t know something at first. In such cases, the technique I apply is to bring the problem specification to its fundamental components and engage with the interviewer to clarify what is needed. Often interview questions are deliberately underspecified because interviewers are looking to see how you engage the problem and find a solution. The goal is to show that your answers are organized, demonstrate that you follow a process, and that you take risks and edge cases into account, and can clearly communicate your ideas.
When you are developing an answer to any question it is very important to talk aloud through your thought process. The way I have done it in the past, is to keep the reasoning dialogue in my head flowing with the speakers on. I ask questions aloud to myself (i.e. with constraint X, then I may have options Y and Z; let’s see what happens if…).
Notice that more often than not, a perfect solution is not the ultimate goal. It is very valuable to arrive to a suboptimal solution following a solid reasoning path, and then understand the parts of the solution that could be improved. Therefore, do not hesitate to build upon your answer/solution if you think of ways it can be improved or more efficient. In many cases, the first answer that springs to mind may not be the best or the most elegant solution but it opens the path to arrive at a better solution; refine your answers as you feel necessary. Also, often the interviewer points out with questions towards aspects that may require attention; reasoning about those cases with the interviewer is very useful as well.
Ready, Set, Go!
It is true that the interview process for tech roles in general is often a grueling experience for many; it has certainly been that way for me sometimes. Nevertheless, understanding what the interview process is all about, and preparing very well prior to tackling it, makes the chances of succeeding much higher and, at the very least, guarantees that you gain the most towards your career capital no matter the outcome.