Overview

We’re the learning ecosystem that powers the platforms of some of the largest organizations in the world with AI. The purpose of this test is to make sure that you are comfortable with the underlying open source technologies that power us. It’s what we’ll talk about in our interviews.

Take your time with it, there’s no deadline. Just make sure that you are able to deeply understand these technologies in order to effectively deploy and extend the platform.

Below is a representative sample of the tools you’d need to use to effectively build. There are other tools that we use such as Apache Kafka that are not here, but if you have the skills below then you’ll be able to build on it as well.

DevOps

See our base open source containers at https://gallery.ecr.aws/ibleducation

It’s important that you have an excellent understanding of Docker (and Docker Compose), which underpins our infrastructure. We also use Traefik.

As far as systems are concerned, we deploy platforms for hundreds of thousands and millions of learners at once. It’s important that we understand how to deploy and scale infrastructure. A good overview / checklist is available at

https://github.com/donnemartin/system-design-primer

Our operating system of choice is Ubuntu, and an excellent understanding of the command line is essential. We also generally deploy on AWS, primarily using the following services: EC2, EKS, RDS, EFS, Route 53.

APIs and Protocols

Understanding REST APIs –how to architect them in a clean manner and deploy them securely via OAuth2 for server-to-server communication – is important as it defines the basis of our backend.

In terms of single sign-on, our protocol of choice is OAuth2 / OpenID Connect. Though you’ll never write the protocol in any programming language you use, it’s necessary to understand it.

WordPress

There’s an important piece of our architecture that is built on a core of WordPress (which powers over 30% of the Internet). It has an excellent no-code platform (Gutenberg), robust user management and multitenancy layer, and massive open source community.

Understanding how to develop a plugin, theme and Gutenberg component is key. Here’s the test:

Stand up two instances of WordPress

using either the default WordPress Docker image or

ours at https://gallery.ecr.aws/ibleducation/ibl-web-ce (our image is built using the

Bedrock

version of WordPress for added security).

Create a WordPress theme that includes the header (in Desktop and Mobile) of

f

ibleducation.com

. Install this on both WordPress environments.

Create a plugin that exposes an API that is secured behind an OAuth2 layer. It should take a single parameter (let’s call it “greeting”) and store it in its database. The plugin should also display the greeting on the WordPress Admin screen. Install this on both WordPress environments.

Create a Gutenberg block that, when installed on one WordPress environment, calls the API of the other WordPress environment with a custom greeting.

Open edX

Another platform that IBL is built on is Open edX. Here’s the test:

Stand up an instance of Open edX

using either the Dockerized Tutor release or

our https://gallery.ecr.aws/ibleducation/ibl-edx-ce (architected using Tutor).

Develop an extension that exposes a REST API endpoint and saves a greeting from the user (secure this endpoint with OAuth2 in the same way that Open edX secures its other API endpoints). This endpoint should do the following things with the user-submitted greeting:

Log it (it should be visible in the platform’s LMS logs).

Save it in the database (the greeting should be visible from the Django Admin).

If the greeting is “hello”, then the view of this API endpoint should call the original greeting endpoint again with “goodbye” as the parameter. This is to make sure that you can write an Open edX view that can make an OAuth2-secured API call with a client ID, a client secret and an access token.

Of course, if your code calls this endpoint with “hello” again then it’ll be recursive and things will crash.