kompanion.sh

kompanion.sh joins the question, lab, evaluation, and review in one observable interview session. I designed and built the product and its platform architecture around a simple contract: assess the infrastructure state a candidate produces, rather than a prescribed sequence of commands.

The problem at the seams

When the question, lab, scoring, and review live in separate tools, interviewers do setup work and candidates operate through abstractions that do not resemble a real system. The assessment loses context as it moves between those tools.

The product keeps that context together while giving each actor a distinct responsibility.

One assessment session

  1. InterviewerAssign

    Challenge + private session

  2. CandidateRepair

    Terminal + scoped environment

  3. EvaluatorValidate

    State + acceptance criteria

  4. InterviewerReview

    Outcome + preserved evidence

The actor changes at each handoff; the session keeps the work connected to its evidence.
View the original product overview
Product overview showing challenge selection, private assignment, terminal repair, validation, and interviewer review.
Original product overview. Open the image at full size for interface detail; the steps above provide the readable workflow.

One session, explicit boundaries

Each assessment is a short-lived session. A browser terminal connects through a session gateway to a scoped runtime. Provisioning creates the challenge resources; evaluation reads the resulting state; teardown removes the session.

Candidate path · least-trusted input

  1. Browser terminal

  2. Session gateway

  3. Scoped runtime

Session control

Identity · lifetime · routing

Provision → runtimeEvaluate ← runtime stateTeardown → resources
Conceptual boundary model. Candidate commands enter the scoped runtime. Provisioning, state evaluation, and cleanup belong to separate control responsibilities. This shows the described model, not a verified deployment topology.

Candidate input stays in the least-trusted boundary. Identity, lifetime, and routing remain session-control responsibilities. Provisioning and evaluation use narrower control-plane privileges and do not depend on a candidate following an expected command path.

Evaluate the state

Different valid repairs should be able to reach the same accepted outcome. Kubernetes challenges inspect readiness, reachability, or configuration; Terraform challenges inspect managed state and resource attributes.

The scoring contract is the resulting infrastructure state, not the command history.

The trade-off is explicit lifecycle ownership. Isolated sessions need provisioning, bounded retries, evaluation, and cleanup. State-based grading moves work from comparing commands to defining observable acceptance criteria.

Follow one repair

The recorded public verification on 22 July 2026 followed challenge selection, private assignment, terminal work, state validation, and interviewer evidence. It described a Kubernetes workload moving from CrashLoopBackOff to Running, with acceptance criteria reported as met.

BeforeCrashLoopBackOff
Inspect + repair
AfterRunning + accepted
Reported public run · 22 July 2026. The precise patch is not included in this record, and Pod phase alone is not the grading contract. This is an illustration of the authored verification record, not a new test or reliability benchmark.
Terminal excerpt from the public product page, with Running and CrashLoopBackOff workloads visible side by side.
A terminal detail from the public product page. It illustrates the interface, rather than verifying the reported repair. Open the image to inspect the original.

Design for the paths that fail

The happy path ends with evidence. The operational model also needs an answer for each interrupted transition:

  • Partial provisioning: bound retries and remove partially created resources.
  • Dropped terminal: preserve or deliberately end the session.
  • Boundary crossing: deny access outside the session scope.
  • Partial evaluation: retry or report an inconclusive result.
  • Failed teardown: detect leaked resources and escalate cleanup.

Shared, long-lived labs were a poor fit for clean state and fault containment. Keystroke-diff grading would reject alternative valid repairs. Human-only review would make the outcome slower and less repeatable. Scoped sessions and state checks fit the behavior being assessed.

What shipped

The public workflow connects assignment, repair, validation, and review. The next useful evidence would concern the quality of those boundaries under failure, rather than another screenshot of the happy path.