Originally published on the Brokee engineering blog (October 2024, as part of a monthly company update announcing new GCP and Kubernetes assessments). The brokee.io domain was later sold and now redirects elsewhere; this copy was recovered from the Internet Archive, trimmed to the technical content, and lightly edited. One list in the original (“candidates tend to fall into one of three patterns…”) was truncated in the archived snapshot — only two of the three patterns survived recovery, noted below.

We added two new GCP assessments — a shorter one for junior engineers, and a more involved one for mid-to-senior candidates — plus an easier version of our most popular Kubernetes test, aimed at both software and cloud engineers. The Kubernetes-junior version exists because a lot of clients wanted faster assessments (15–20 minutes) that still hold a high bar on hands-on skill, without the depth our full Kubernetes test requires.

Isolating candidates on GCP

Both GCP tests give candidates access to the Google Cloud console. Each candidate’s test runs in its own GCP project, so their environment is fully isolated from everyone else’s — the same isolation model we already use on AWS, just implemented with GCP’s per-project boundary instead of AWS’s per-test permission set.

Login without a Google account

Unlike AWS, GCP doesn’t support creating a standalone username/password for console access — a candidate needs an actual Google account to log in. To avoid requiring candidates to have (or create) one, we implemented Workforce Identity Federation, which lets candidates authenticate with their existing Brokee credentials and get scoped access to the GCP console for the duration of the test.

This ended up being smoother for candidates than our AWS temporary-user flow, so it’s the model we’re now working toward replicating on AWS.

As with our other tests, hiring teams get the same reporting for GCP assessments as everywhere else: command history and an AI-generated summary of candidate activity.

The new Kubernetes junior test

Our existing Kubernetes test is genuinely hard — mid-level and even senior candidates often struggle with it, since it combines core Kubernetes knowledge with understanding how external-dns and cert-manager work together to automatically provision DNS records and certificates for a running application.

Candidates tend to fall into one of a few patterns: solving it cleanly within 1–2 hours, or completing 70–80% and struggling with the remainder. (A third pattern was likely described in the original but did not survive the archive snapshot.)

Not every engineer working with Kubernetes needs deep administration knowledge — some just need to deploy applications while colleagues handle cluster administration. That gap is what the junior test targets: candidates fix configuration errors in a Kubernetes application to get it running correctly, without needing deep cluster-admin expertise. It’s meant to filter for baseline competency, not to replace the harder test.