EXPERIMENT 09PROTOTYPE

Interview Harness

A practice system that separates improvement from scoring noise

Can a daily interview-practice loop show whether an answer is actually improving, rather than merely receiving a different score?
People preparing for high-stakes interviews who need structured feedback on spoken answers over time.Try the application

THE PROBLEM

What is actually going wrong

Interview practice usually produces a vague feeling: an answer either felt better or it did not. That is not enough to tell whether a habit is improving, whether the question changed, or whether the feedback changed.

Automated scoring adds another problem. If the scoring instrument drifts, its changing number can look exactly like progress or decline.

WHAT I DID ABOUT IT

I built

A local interview-practice harness that records a spoken answer, keeps a verbatim transcript for delivery signals and a cleaned transcript for content review, then scores both against a fixed metric registry.

The review dashboard keeps the recording, transcript, metric evidence and human overrides together. A trends view compares repeated attempts, while a golden-set drift check reruns a scorer against labelled attempts before its results are trusted.

TRY IT YOURSELF

Demo

Interview Harness attempt review dashboard showing a spoken-answer transcript and scored metrics.
Each attempt keeps the recording, two transcript views and the evidence behind every score together.
Interview Harness trends dashboard showing metric priorities and a score trend chart.
Trend review makes a changing score visible alongside the metric and its direction of improvement.

Demo in progress

The harness runs locally because it stores microphone recordings and interview material. The screenshots show the review and trend views from a real local run.

Want to see it sooner? Ask me.

BEFORE AND AFTER

What changed

Before

An isolated practice session
  1. 01Choose a question
  2. 02Practise an answer
  3. 03Rely on memory or general feedback
  4. 04Try again later without a comparable record

After

One recorded feedback loop
  1. 01Record one spoken answer
  2. 02Review delivery and content separately
  3. 03Inspect scored evidence and override where needed
  4. 04Compare the metric over repeated attempts
  5. 05Check whether the scoring instrument is stable

PRACTICE RECORD

Memory of an answerAudio, transcripts and evidence

FEEDBACK

General impressionNamed metrics and overrides

PROGRESS SIGNAL

One-off scoreTrends with drift checks

ARCHITECTURE

How does it work?

  1. 01

    Question and recording

    A selected interview question creates an attempt with the original audio kept as the reviewable source.

  2. 02

    Dual transcript

    DETERMINISTIC

    The system retains a verbatim transcript for delivery signals and creates a rule-based cleaned version for content scoring.

  3. 03

    Metric registry

    DETERMINISTIC

    One registry defines every metric, its target, direction and weight so planning and review cannot silently disagree.

  4. 04

    Scoring and review

    Independent scorers produce evidence-backed metrics, while the dashboard supports human review and overrides.

  5. 05

    Trends and drift checks

    Repeated attempts form a trend. Re-running scorers against labelled examples detects when the instrument itself has shifted.

The important boundary is between a changing answer and a changing judge. The harness treats both as things that need evidence.

ENGINEERING

Engineering notes

NOT PUBLISHED

No engineering article has been published for this experiment yet.

BUSINESS IMPACT

What could this mean for a real business?

  • POTENTIAL

    A consistent record of attempts and evidence could make interview practice more deliberate than relying on memory alone.

  • POTENTIAL

    Separating delivery from content scoring could make it easier to identify what an answer needs to improve.

Observed means measured in a real engagement. Estimated is reasoned from the work but not measured. Potential is what the approach makes possible. Nothing here is dressed up as more than it is.

WHAT FAILED

What didn't work

Wiring scoring components from documentation without first proving they worked against the installed packages.

Several imports and scorer assumptions typechecked but failed when the modules actually loaded. A scoring system that has never run is not a measuring instrument.

WHAT CHANGED

The project added import smoke tests and a coverage gate that rejects a scorer emitting an unregistered metric or a registered metric with no producer.

CODE

See the implementation

SELECTED IMPLEMENTATION

The implementation is a private local tool. Its architecture, verification gates and selected dashboard evidence are documented here.

SHARE AND ENJOY

Share and enjoy

Tell me what's going on. I'll come back within a business day, and if I'm not the right person for it I'll say so.

What are you after?

Pick as many as apply.

50 people
1200+

First step is a free half-hour call. No pitch deck, no obligation. Prefer plain email? Reach me directly at [email protected].