We’ve gotten a positive impression of your relevant skillset and experience, and are keen to move to the next phase of the interview process. This is our technical challenge, which we expect will take approximately four hours. It is highly relevant to the day-to-day work you would be doing on the Platform Engineering team. We understand this is a meaningful time commitment, and have done our best to make sure it is not wasted:
- At the end of the challenge, you are likely to have a viable portfolio project to show off independent of Hyperbolic.
- Acing this takehome and demo means your code screening is done. After a successful system design interview (e.g. using Excalidraw), Engineering will ask Management to schedule a final interview.
We would like you to develop and deploy an open-source golang project to a kubernetes cluster.
The golang container itself should live in a kubernetes cluster and demonstrates the following programmatic capabilities
- [ ] takes basic input from an http frontend
- UI is not important - we would just like to be able to test your deployment live on our end. A simple html input field with a button or two is fine!
- [ ] creates Kubernetes resources (e.g. pods, services) dynamically from user input
- for example: the user enters a bash command, and clicks ‘enter’ - then your golang controller creates a kubernetes job that runs that command and displays the output.
- [ ] deletes Kubernetes resources dynamically
- [ ] reads from in-cluster resources to display basic information on the frontend.
- example: “deployment has 2/2 replicas ready”
- [ ] The deployment should be managed by ArgoCD such that a ‘git push’ to the repo is automatically (or semi-automatically) deployed to the cluster.
It may be too much to hope for in a job interview, but we do aspire to leave room for ‘fun’ in this coding challenge. To that end, the rest of the challenge is up to you. Here are a couple examples of potentially ‘fun’ projects to get the juices flowing:
user pastes their ssh pubkey into the frontend, and the backend creates a configmap, deployment, and service to allow the user to ssh into ther ‘cloud instance.’ The frontend then shows the status of the instance, how to ssh in, and a button to terminate it.
user sees a list of AI models that can be deployed to the cluster. When ‘deploy’ is clicked, a kubernetes deployment and service is created. A new link appears in the frontend such that the user can enter into a chat with the newly deployed LLM.
- tip: the LLM doesn’t need to be very good
user pastes some text, and specifies a desired path for the text to be posted to. The golang backend dynamically updates an Ingress to add the new path. When the user goes to that path, the text they pasted is shown.
user clicks ‘new server’ and the golang controller creates a playable minecraft server and shows the user how to connect. The user can create multiple servers and connect to any of them. They can also delete any server when they are done.
- (open-source minecraft: https://github.com/minetest/minetest)
we will share an ssh private key and rainforest-id. You can then ssh into the server like so:
ssh -i <path-to-ssh-private-key.pem> ubuntu@<rainforest-id>.challenge.dev-hyperbolic.xyz
we recommend microk8s for ease-of-use, since you can quickly spin up a new kubernetes cluster and install argocd like so:
sudo snap install microk8s --classic sudo microk8s enable community sudo microk8s enable argocd microk8s.kubectl get all --all-namespaces
you can also print the microk8s kubeconfig like so:
microk8s config
that being said, if you have a preferred distro other than microk8s, feel free to use it. And if your project requires a multi-node cluster, you are welcome to skip our ssh box as well. We just provide it for convenience and to make sure you aren’t forced to spend any money on cloud hosting to deploy your product.
Note that the kubeconfig printed by `microk8s config` will point to the local address. If you would like to access the cluster via public internet, you have two options:
A) edit the csr.conf.template file on the remote server
# edit the csr.conf file in microk8s to add the the desired IP or DNS route
vi /var/snap/microk8s/current/certs/csr.conf.template
microk8s stop
microk8s start
(note that you will also have to edit the kubeconfig file printed by `microk8s config` according to the DNS route or public IP you’d like to access the cluster at)
- https://github.com/hyperboliclabs/hyper-dos
- https://pkg.go.dev/k8s.io/client-go/dynamic
- https://mholt.github.io/json-to-go/
- https://argo-cd.readthedocs.io/en/stable/operator-manual/applicationset/
- https://gitlab.com/squire-exchange/public/cluster-dos
- https://tailscale.com/kb/1236/kubernetes-operator
We are excited to see what you’ve built! Here is what we’d like you to submit when you feel ready to share (ideally within 72 hours of receiving this email, or 5 days at the latest)
- a repo with your code
- a 5-10m demo video walking us through the following:
- what it is (from the ‘user’ perspective)
- how it works (from the dev perspective)
- how to deploy it (from the ops perspective)