4.5 KiB
GitLab Operator Interview
Overview
This document outlines the technical tasks for the interview process. The goal is to assess technical skills, communication styles, and collaboration patterns through both asynchronous work and synchronous discussion.
Timeline
Asynchronous Work
- Address the items defined in the outline of work below
- Refine items of further work in iterative fashion
- Do your best to complete everything. If not every task will be completed, please leave a comment and let us know
Synchronous Interview (60-90 minutes)
- Discussion and clarifications
- Live pairing with candidate sharing screen (ensure screen sharing via Zoom works prior to the call)
- Opportunity to clarify or further define choices
Goals of Process
We are not purely evaluating the "completed work". The goal of the interview process is to assess technical skills, communication styles, and collaboration patterns. This means that we have intentionally not set any explicit expectations of implementation patterns, but rather provide guide rails and allow each candidate to perform uniquely. We value the spectrum of knowledge and experience that we have cultivated within the team, and wish to see each candidate's contributions come naturally rather than using predefined checklists.
Prerequisites
- An editor or IDE of your preference
- Golang 1.19+ is preferred
- Helm 3.4+
- Docker available
Tasks
1. Create a Simple Go Webserver
Create a simple Go web server, in framework of choice. This needs to be a stateless container, that assumes the runtime environment meets all needs: configuration, content, and secret placement are prepared before the container's primary process is started.
Requirements:
- Take configuration from a file and from environment
- Consume a secret by some means, which is used for HTTP Basic or an API token verification (example: posting a request against a given endpoint requires authentication using this secret)
- Page / JSON content is expected to be loaded from a file system, populated by "some means" (future: from ConfigMap contents)
- (Optional, but highly recommended) Unit tests are added
2. Create a Docker Image
Create a Docker image for the Go application.
Acceptance Criteria:
- Docker image is built using multi-stage build process
- Final image is based on
debian:bullseye-slim(not golang)
3. Create a Helm Chart
Create a Helm chart capable of deploying this application, and exposing it via an Ingress provider.
Note: This chart is intended to be consumed by an end user (meaning that it is not just intended for developers of the project).
Requirements:
- ConfigMap that will provide content to the application
- Deployment for the Application
- This pulls content / configuration from ConfigMap, and token / secret from a Secret
- Service providing access to the Pods of the deployment
- Ingress provides access to the Service to provide traffic flow
Acceptance Criteria:
- Helm chart is present
- Usage of Helm chart is documented, and an entry is added to README
4. Implement CI Pipelines
Add CI implementation for the project.
Required CI Jobs:
- go build
- go unit testing
- docker build & push to registry
- helm lint
- helm template proving successful functionality
Nice to Have:
- docker hadolint
- helm specs to validate output from various configuration options
Acceptance Criteria:
- At least the required components above are implemented and passing in GitLab CI
5. Update Documentation
Provide basic documentation on the usage of the application, and runtime expectations. This will provide the basis for others to understand the requirements of designing containers / Pods to deploy this into production.
Preferably, this content is added in a form that can be rendered directly within the GitLab interface.
This document should cover:
- Runtime expectations of the application
- Arguments to the application (if any) and what the expectations of the arguments are
- Any external dependencies of the application
Acceptance Criteria:
- README is updated
Workflow Expectations
- Please make use of Issues and Merge Requests, and do not make changes directly to the primary branch 🙇
- We recommend either chaining your merge requests on each other (merge request 2 set to merge into merge request 1, etc.), or creating a single large merge request. Both approaches have their benefits and drawbacks, so we leave it to your preferences.