Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

Let the candidate mark interviewer lines they did not understand

Aperta
  • Qualcosa non va?
#391 0 commenti 0 reazioni 1 assegnatario Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

@April-ying ci sta già lavorando.

Dal 20/10/2026.

Valutazione

Questa issue non è ancora stata valutata.

Descrizione

Need

Candidates practicing an English interview as non-native speakers sometimes miss a few words of what Jim says. When the gap is large, they ask Jim to repeat. When it is only a word or two, they usually answer anyway to keep the conversation moving, and the line is forgotten by the time the report arrives. There is no way to note "I did not fully understand this" at the moment it happens, so the candidate cannot review those words afterward.

Present workaround

The report already ends with ## Conversation transcript (web/render.js), and the replay shows the transcript too. Reviewing it means rereading the whole conversation and trying to remember which lines were unclear, which rarely works for a 30 to 60 minute interview.

Desired outcome

During the interview, a small "Unclear" button next to Jim's caption marks the line currently on screen. After the interview, the report lists the marked lines in one place and also tags them inside the transcript, so the candidate can review both the wording and its context:

## Lines you marked as unclear

1. Jim: "And what would the time complexity look like if we used a monotonic stack here?"

## Conversation transcript

**Jim (marked unclear):** Great. And what would the time complexity look like if we used a monotonic stack here?

**You:** Sorry, could you repeat that?

Scope

  • Only interviewer lines can be marked; pressing the button again on the same line unmarks it.
  • Jim is not told about a mark, so the conversation is unchanged.
  • No model call is added. Marks are not sent to the report model either: they are the candidate's own study notes, and treating them as evidence could lower the Communication score and discourage candidates from using the button.
  • The "Lines you marked as unclear" section is omitted when nothing was marked.

Acceptance criteria

  • Marking a line during an interview makes it appear in the report's marked section and tagged in the transcript, in both the web report and the Markdown export.
  • Unmarking removes it from both.
  • A report with no marks looks the same as today.
  • The report prompt is unchanged whether or not lines are marked.

Approaches compared

  1. An "Unclear" button next to the interviewer caption that marks the current line (each caption already carries a turn id in web/captions.js). Small, needs no model call, and stays invisible to Jim.
  2. Detecting spoken repeat requests ("could you repeat that", "sorry?", "pardon?") and marking the preceding line automatically. This could reuse the phrase-matching approach in src/agent/turn_taking.rs, but a bare "repeat" is ambiguous in coding interviews (for example "Longest Substring Without Repeating Characters"), and the request is already visible in the transcript.

I propose 1 here and leave 2 as a possible follow-up once 1 is in.

Related

#258 proposes a "Key moments" section in the report, with moments picked by fixed rules and notes written by a model. This request differs in where the selection comes from: the candidate picks the lines during the interview, and no model call is involved. Both add a report section near the transcript, so I would place "Lines you marked as unclear" where it does not collide with "Key moments", and I am happy to follow whatever order is chosen there. Marked lines could later become one more input to the moment rules in #258, but this request does not depend on it.

#223 and #271 keep Jim's latest line readable on screen during the interview; this issue covers reviewing unclear lines after it ends.

Lingua principale
Rust
Stelle
177
Fork
100
Merge medio
1g 13h
PR unite (30g)
138

Preparare l'ambiente

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di sysprog21/codetrial

Tutte le issue di sysprog21/codetrial

Issue simili

Altre issue su Rust

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.