Lots of things have happened in the last two years. And that has percolated through all aspects of life for me: relationships, work, priorities, and so much more. Now I am here, today, with all the learnings and changes, and excited about what is coming our way.
One of the things that resulted from all this, is a renewed desire of activating my creative output. This means that I am determined to start writing frequently about everything. This is the beginning.
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 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.
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.
If you only have one minute to read this post, here is the gist of it: WordPress users can get a first-class AMP experience without compromising the fidelity of their content or surrendering the flexibility of the WordPress platform. Get a glimpse of what is possible with AMP in WordPress by watching our AMP Conf 2018 talk! https://youtu.be/GGS-tKTXw4Y If you have a few extra minutes, follow me to the next paragraphs to learn more about the state of AMP in WordPress.
The WordPress Ecosystem
In a nutshell, WordPress is: a Content Management System (CMS) for websites; the largest player in the CMS space with ~59% of market share,powering about ? of the web; and a thriving ecosystem of plugins, themes, hosting providers, agencies, freelancers, all working together on the creation of WordPress-powered content. But when I think about WordPress I think about one thing: there are many users publishing and consuming content via WordPress-powered sites, and all of them should get an awesome UX on the platform.
And since AMP is all about enabling an awesome (fast) User eXperience to all users, in this post we discuss two things: (1) the case for AMP in WordPress; and (2) the state of the art of AMP in the WordPress Ecosystem. Curious? Read on!
Why AMP in WordPress
One of WordPress major virtues is the flexibility of the platform. You can accomplish basically anything you can imagine, as demonstrated by the large and ever expanding ecosystem of plugins available to add functionality and customize your website in a myriad of ways. However, this same virtue can also turn into one of the major challenges of the platform. Even taking into account plugins that are very good (i.e. follow coding/performance best practices and coexist nicely with other site components), the likelihood of having plugins colliding in their interactions (or impacting performance) when jointly activated in a site, is definitely not negligible.
This virtue/challenge duality of the WordPress ecosystem has its parallel in the open-web web publishing ecosystem. In the latter, there is nothing restricting a web developer to hamper the performance of a site by following counterproductive coding practices (e.g. loading scripts synchronously, render-blocking CSS). And even if the developer builds a site impeccably, adding a third-party JS library could spell a performance disaster.
AMP emerged as a response to that reality, bringing forward effective design principles and control mechanisms that enable sites to offer predictable performance. The effectiveness of AMP and its impact on UX is demonstrated by plenty of data and examples in the wild. And WordPress publishers would also benefit greatly from having more control of the UX of their sites. This could be achieved by adopting coding and performance best practices in WordPress development, and integrating AMP with the WordPress ecosystem to make the WordPress platform more performant.
The plugin work for enabling AMP in WordPress described in this post, was pioneered by the AMP Plugin initially developed by Automattic. Subsequently Google and XWP joint the open source development effort to help evolve the plugin significantly. Want to know what is possible with AMP and WordPress nowadays? Let’s see!
The AMP Plugin
The initial goal of the AMP plugin was to enable AMP for WordPress.com VIP sites. It certainly met its goals for VIP, and it was also adopted at some level by the general WordPress community either directly, or through other plugins built on top of it. In the context of its initial objectives, the main characteristics of the early versions of the AMP plugin make sense:
Developer oriented. The plugin provided a minimal set of core abstractions to enable AMP in WordPress, and allowed developers (i.e. agencies, plugin and theme makers) to modify it and extend it to tailor its capabilities to the needs of their individual sites.
Pair mode. The plugin adopted a simple-theme approach bypassing the WordPress template hierarchy and generating a separate AMP version of published content based on very basic theme template parts.
These characteristics worked well for sites that have good engineering support to tailor the AMP content to their needs. However, at a larger scale, the adoption of the plugin was more challenging because the baseline capabilities did not offer enough functional and visual parity between the two versions.
Google and Automattic started working together last year with the goal of bringing the AMP plugin to its maximum expression, and enable a rich AMP experience for all WordPress sites. A few months after, XWP engineering team also joined the project to push for the same goals with the expanded scope of integrating modern web technologies in general into the WordPress ecosystem. And since everything is opensource, the WordPress community has also been part of this work through many contributions. In the past few months versions 0.5 and 0.6 of the plugin were released, including bug fixes, expanded support for embeds, support for pages, parity with AMP library specification, better configuration capabilities, and much more. And after these, we have focused on one of our main initial goals; since the beginning we have had our sight set on enabling an organic AMP experience in WordPress; that is, an experience where there is no need for a pair mode (unless applied by choice) because there are no gaps, either functional or visually, between the AMP and non-AMP versions of content published in WordPress. Without such a gap, WordPress publishers are able to publish a single version of their content which is beautiful, feature-rich, all-around WordPress, and runs at the speed of AMP! We call this an all-AMP experience.
An all-AMP UX in WordPress
The aforementioned pair mode approach makes sense when there are functional and visual gaps between the AMP and non-AMP versions of a given content. In such a case the pair mode keeps a “version” of the original content and an AMP’d version of it. By enhancing the AMP plugin and devising the right mechanisms for theme/plugin integration, we can eliminate these functional and visual gaps an enable WordPress sites to offer a single, all-AMP experience.
An all AMP experience in a WordPress site requires: (1) a plugin that enables a seamless integration of AMP into WordPress; (2) a theme that integrates nicely with AMP (adds AMP theme support); and (3) the seamless coexistence of third-party plugins in an all-AMP site.
We have made good progress on the plugin work and by the time you are reading this post, many goodies will be available in version 0.7 of the plugin (release). We have also made progress on defining an approach for building progressive themes; that is, themes built following the latest coding and performance best practices, leveraging as much as possible progressive technologies in the web platform, and integrated seamlessly with the AMP plugin. The result on this work was presented at AMP Conf (video), and a prototype of an AMP-Compatible theme is available, and you can experience it live as well. And the cherry on top of the cake, is the work by Morten Rand-Hendricksen on the development of a Progressive Theme Boilerplate project, which enables theme developers to go from 0 to starter progressive theme in an easy way. Today, a native AMP experience in WordPress is possible!On the theme side of the story, native AMP support is enabled by:
Integrating with the standard WordPress templating system, as opposed to the AMP plugin’s initial paired mode bundled theme for post templates
Supporting standard site elements such as the Widget sidebar, native comments, and many others are fully supported
Providing opt-in choice for enabling the experience with fine-grain control: the theme works with or without AMP
And on the AMP plugin side of the story, the seamless integration of AMP into the WordPress workflow is enabled by:
Supporting all standard/default widgets; non-core widgets will also work, but anything they add which is not AMP-compatible will be stripped. And we encourage the plugin community to work with us on their integration
Providing AMP compatibility for all relevant WordPress actions / filters
Preventing WordPress from printing scripts/styles in the header and footer
Having an efficient “AMP preprocessor” ensuring AMP validity with maximum fidelity
Providing functionality in the AMP preprocessor to identify and flag incompatible plugins at runtime. Besides helping the publisher to keep their AMP content valid, this also will help guiding the community to work with us to make every relevant plugin AMP-compatible
Allowing three “use modes”: (1) legacy pair mode, with the pre-0.6 ad hoc post templating system; (2) new (enhanced) pair mode, integrated with the standard WordPress templating system; and (2) AMP Canonical, with a single AMPed version of the content and also integrated with standard templating system.
Supporting all default embeds; other embeds are also allowed but the AMP preprocessor may not make them AMP compatible in the best way (i.e. an may be used)
The combination of these features and capabilities allows WordPress publishers to run a pristine WordPress site that is all-AMP! The following screenshot shows a demo of an all-AMP WordPress site; there is no pair mode, and look at the console!
The Road Ahead
AMP integration with the WordPress ecosystem has come a long way. But there is still quite a bit of work ahead of us; very exciting work indeed! Some of the main areas currently capturing our focus include:
Continue expanding the capabilities and scope of the AMP plugin to fully enable an awesome AMP experience in WordPress at scale, and collaborate with publishers, WordPress users, and the WordPress developer community, to make all relevant plugins/themes AMP-compatible
Continue our work on Progressive Themes aimed at defining a systematic approach to building themes that provide AMP support, follow the latest coding and performance best practices, and integrate the latest advances in the web platform.
Align our efforts with the evolution of WordPress via contributions and integrations with Gutenberg, the new editing experience which is set to revolutionize content creation in WordPress. This includes supporting Gutenberg blocks, including blocks for AMP Components. For example, we’re looking to augment Gutenberg blocks with AMP-specific attributes, like the layout and media attributes, which would then inform the AMP preprocessor on how best transform an element into AMP.
Contribute our collaboration with the Tide project, to empower WordPress developers and site owners with the ability to choose themes and plugins based on concrete quality metrics
Advances in the web platform all aim at improving the user experience along different dimensions. AMP design premises focus on the performance of the mobile web and the associated quality of the perceived user experience. With the AMP plugin and a modern approach to building themes, WordPress-powered publishers are able to leverage the performance and ecosystem advantages to be gained from using AMP.
There is still quite a bit of work to be done. These are very exciting times to be a web developer, and also a WordPress developer! We are certainly excited as we continue advancing towards our goals and unlock the even greater potential of the WordPress platform. And remember: everything we are working on is open source, including AMP! All the work described in this post is the result of a great collaboration between Automattic, XWP, Google, and the WordPress community. Want to help? Join the effort and participate with your contributions, feedback, and engagement!