Founders

How to Blind-Code Interview Notes Before You Read Them

Antonio Evans8 min read

A split desk scene: on the left, a printed interview transcript with names, company details and emotionally charged phrases blacked out with marker; on the right.
Key points

Key points

  1. 1Blind-coding means stripping identifying and hypothesis-confirming details from a transcript, fixing a codebook in advance, then letting a model tag themes.
  2. 2Confirmation bias is a documented failure mode in interview research, so the order in which you read and code a transcript changes what you conclude.
  3. 3Published comparisons of model-generated codes with human codes show a large share of model tags are duplicated or thin on context, so sampling and checking is not optional.
  4. 4A stratified human audit with a pre-committed agreement threshold turns the model into a first coder you can correct instead of an authority you defer to.

What blind-coding is trying to fix

The danger in interview analysis is rarely that the data is thin. It is that the reader has already decided what the data means before opening the file. Confirmation bias, the habit of seeking only information that confirms existing beliefs, is one of the standard bias categories in customer discovery work, alongside selection bias and response bias, and it distorts conclusions before anyone writes a summary (Innovation Within).

Practitioners are blunt about the scale of the problem. One discovery guide argues that the goal of customer discovery is not to validate your idea at all, because confusing validation with understanding produces research that confirms what you already believed rather than challenging it (Skimle). Another notes that founders routinely listen only for what fits their hypothesis, and that asking about solutions rather than problems produces false validation (Startups.com lexicon).

Blind-coding interrupts that loop by changing the order of operations. Instead of reading a transcript, forming an impression, then hunting for support, you:

  1. Remove the details that tell you whose interview it is and what business question is at stake.
  2. Fix a codebook before the model sees anything, so categories cannot drift toward the hypothesis.
  3. Let a model apply the codebook first.
  4. Audit a sample of its tags against the redacted source before you read anything in full.

The output you want is not a finished analysis. It is a set of tagged excerpts with a measurable error rate, which you then correct by hand.

Why the model is the first coder, not the analyst

Qualitative coding is the act of attaching labels to extracts so patterns can be derived later, and it exists to make analysis systematic and reviewable by someone else (Grad Coach). That reviewability is what makes a two-pass process work: if the model's tags are written down in a fixed format, a second person can check them.

The evidence for caution is concrete. A study of semi-structured patient interviews (n = 34) compared two open-source models against human inductive coding and found that roughly 45% of model-generated codes carried meaningful context, while 22% to 39% were duplicative (International Journal of Qualitative Methods). A model can tag fast, but between one in five and two in five of its tags may be noise. Any process that skips the audit trusts a tool whose published error profile does not support that trust.

There is a second reason to treat the model as a coder rather than an analyst. Coding is a systematic pass through the data, and the interpretation of themes comes after it, drawn from the research aims and questions (Grad Coach). If you let the model jump straight to themes, you lose the layer that makes the work auditable.

Fix the codebook before anything else

A codebook is your defense against drift. Write it down and freeze it before the model sees a single quote. The practical form is a short list of codes, each with a definition, one or two inclusion criteria, and a boundary case.

A numeric starting point that scales to most small studies: 8 to 12 codes, each with a one-sentence definition of at most 25 words. If a code needs more than 25 words, it is probably two codes.

DecisionRecommended settingWhy
Codebook size8 to 12 codesFewer codes collapse distinct themes, more codes push duplicate-tag rates up
Coding modeDeductive, fixed codes onlyThe same study found deductive prompting produced higher and more nuanced output than inductive prompting (IJQM)
Chunk sizeOne speaker turn or one paragraphSmaller chunks keep the cited excerpt auditable
Output formatCode, exact quote, character offsetAn offset lets you jump straight to the source during the audit
New-code handlingModel may flag "unclear" but must not invent codesInvented categories break comparability across interviews

The last row is the one people skip. If the model can invent codes, it will quietly expand your framework, and your cross-interview comparison stops being comparable.

A minimal tagging instruction:

You are a coding assistant. Use ONLY the codes listed below.
For each passage that matches a code, return JSON:
{"code": "<code id>", "quote": "<exact substring>", "start": <int>, "end": <int>}
If a passage fits no code, skip it. Do not summarize. Do not invent codes.
If a passage seems important but fits nothing, tag it "unclear".
CODES:
C1 ... (definition)
C2 ... (definition)

Returning character offsets rather than paraphrases is the single biggest quality improvement in this workflow. Paraphrased quotes cannot be verified, and unverifiable tags are what make model coding feel unreliable.

Pass one: redact, then tag

Redaction runs in two layers, and both matter.

Layer one is identity. Names, company names, product names, job titles that identify a single person, locations and dates. Replace each with a stable placeholder ([PERSON_A], [VENDOR_B]) so pronoun references still make sense.

Layer two is the hypothesis tell. This is the layer people forget. Strip the phrases that reveal whether the interview supports your idea: "this is exactly the problem we solve," "unlike the incumbent," "where the current tools fail." If a participant raved about a feature or dismissed a competitor, that is a signal about your hypothesis, and leaving it in primes both the model and you.

Keep the substantive content. You are removing framing, not evidence. Before and after:

BEFORE: Priya at Acme said their current vendor is a disaster and she'd switch to us tomorrow.

AFTER: [PERSON_A] at [ORG_B] said their current vendor [VENDOR_C] fails often, and that they would evaluate an alternative.

What changed: identity is gone, the enthusiasm markers ("disaster," "switch to us tomorrow") are gone, and the behavioral claim (fails often, would evaluate) survives.

Redaction order affects what survives

Do the identity pass first, then the hypothesis pass, reading each sentence aloud. If a sentence would make a reader nod, it is a candidate for redaction. This is uncomfortable, because it removes exactly the material you want to see. That is the point.

Run the model per transcript with the frozen codebook, collect the JSON output into one table with a transcript ID column, and do not read the tagged excerpts yet. Interviews rarely go as planned, and the temptation to re-run a transcript because the tags look wrong is strong. Resist it until the audit.

If your volume is high, this is where one interface for every model type saves handling a separate provider per stage. Transcription, tagging and any embedding-based deduplication are usually three vendors in an ad hoc pipeline; Quanta Inference exposes text, image, audio and embedding models behind one OpenAI-compatible key, priced in US dollars.

Pass two: audit a stratified sample

Random sampling alone is not enough. A model's errors cluster, so a purely random draw can miss a whole failure mode. Stratify by three things: transcript length (short, medium, long), participant segment, and code frequency.

A defensible plan for 20 transcripts and 10 codes:

StratumUnitsSamplePurpose
Transcript20 interviews6 (2 short, 2 medium, 2 long)Catch per-interview failures
Code10 codes2 tags per codeCatch codes the model confuses
Rare tagscodes with fewer than 3 tagsevery tagRare codes are where hallucination hides
Total tags checkedroughly 400 to 60060 to 80Enough to compute a usable error rate

The audit is mechanical. Open the redacted source at the character offset, compare the highlighted text to the tag, and record one of four verdicts: correct, wrong code, quote does not support tag, or tag missed an obvious instance. Count them. The disagreement rate is your headline number, and you write it down before you adjust anything, because post hoc adjustment erases the record.

A worked example. You check 64 tags and find 7 wrong codes, 5 quotes that do not support their tag, and 2 missed instances. That is 12 disagreements out of 64, an 18.75% tag-level error rate. If your threshold was 10%, you do not proceed to full analysis; you revise the codebook and rerun pass one on the sample.

The decision rule

Pre-commit to a threshold before you audit. A practical rule:

  • Under 10% disagreement: proceed, and report the rate in your methods.
  • 10% to 20%: revise definitions for the two codes with the most errors, re-tag the sample, recheck.
  • Over 20%: the codebook is the problem, not the model. Rewrite it, or split the offending codes, and restart pass one.

Two revisions fix most audits. First, when a code is confused with its neighbor, add a boundary sentence to each definition ("C3 is about the frequency of the problem; C4 is about its cost"). Second, when quotes fail to support their tag, require the exact substring rather than a description, and reject any output where the quote is not found at the stated offset.

There is a discipline cost to skipping this. The same study that measured duplicate tags noted that reliability in qualitative work is normally handled through inter-rater agreement, where coders work independently and reconcile discrepancies (IJQM). Your audit is that reconciliation step in miniature, with the model as one coder and your redacted source as the arbiter.

Reading the full set with the frame already set

Only now do you read everything. Two habits keep the frame from collapsing.

Read the audit log first. Skim the disagreements you recorded so you know which codes the model is weak on, and slow down there.

Code the outliers by hand. Any transcript where the model produced far fewer tags than the sample average gets read without the model's output open, then compared. Divergence between your hand read and the model's tags is the most informative material in the dataset.

When you write up findings, report the audit rate, the number of tags checked, and the codebook version. That is what separates a defensible analysis from an impression with citations attached, and it gives a reviewer a way to challenge you, which is the whole purpose of making coding visible in the first place (Delve).

One more check worth the hour: hand a redacted transcript and the codebook to a colleague with no stake in the hypothesis, and compare their tags to the model's on a single interview. If the colleague and the model disagree more than your audit rate suggested, your definitions are still too loose.

Where this method breaks

Blind-coding is not free, and three failure modes show up repeatedly.

Redaction that removes the finding. Enthusiastic quotes are evidence. Strip them and you may strip the strongest signal in the study. Mitigation: keep a separate unredacted key file that reconnects placeholders to originals for the final read, and keep the behavioral claim even when you remove the framing.

A codebook that encodes the hypothesis. If your codes are "willingness to pay," "pain severity" and "switching intent," you have built a confirmation machine. Mitigation: include at least one code that could embarrass the hypothesis, for example "workaround that already works" or "reason current process is adequate." Discovery guidance recommends exactly this instinct: ask at least one question that could destroy your current business idea (Studio Zao).

Audit theater. Checking five tags, finding them fine, and declaring victory. Mitigation: fix the sample size and the threshold in writing before you look.

There is also an upstream problem. If the interview sample itself is skewed, no amount of blind coding repairs it. Practitioners describe selection bias as the error of drawing respondents from a group that does not represent the audience you care about, and warn that it skews results before analysis begins (Innovation Within).

A note on tooling and privacy

Redacted transcripts are still participant data. Transcripts of patient interviews raise privacy concerns specifically when analysis runs through hosted chat tools, which is one reason the published study above used open-source models (IJQM). Before pasting anything into a hosted endpoint, know your consent language and your data handling terms.

If your team needs a custom pipeline, a redaction tool with an audit log, or an internal dashboard that holds tagged excerpts next to their source offsets, that is a build rather than a research decision. Describe the site, app, document or plan you need and a specialist picks it up and builds it with you at Quanta.

FAQ

FAQ

How many transcripts do I need before blind-coding is worth the setup?

The setup cost (codebook, redaction pass, audit template) is roughly a day. It pays off from about 8 to 10 transcripts, where manual coding starts to drag. Below that, hand-coding everything is faster and gives you a better feel for the data.

Can I use the model's tags as the final analysis?

No. Published comparison work found that a large share of model-generated codes were duplicative or lacked sufficient context, so the tags are a first pass to be corrected (IJQM). The final analysis is yours, built on the audit log and the full read.

Should the model see the research question?

Give it the codebook, not the hypothesis. If the model knows what you hope to find, it will find it, and your redaction work is wasted. The code definitions are enough context to tag accurately.

What if the model's tags disagree with mine on transcripts I already read?

Treat your own read as the second coder and log the disagreement. If your read contradicts the model on a code the audit also flagged, the code definition is the likely culprit. Revise it and re-tag rather than deferring to either coder.

Is deductive coding with fixed codes always better than letting themes emerge?

For this method, yes, because a moving target cannot be audited. Inductive coding has real value when the subject is genuinely unexplored. A hybrid approach, fixed a priori codes plus deliberate additions after the audit, is the common compromise in practice (Grad Coach).

Sources

Sources

  1. Avoiding Bias in Customer Discovery Interviews, Blog
  2. How to do customer discovery: a practical guide ...
  3. Customer Discovery
  4. How To Code Qualitative Data For Analysis (4 Steps + Examples)
  5. Large Language Models in Qualitative Analysis
  6. Essential Guide to Coding Qualitative Data - Delve Tool
  7. 10 Tips To Conduct Customer Discovery Interviews | Insights
About the author

About the author

Antonio Evans
Antonio Evans

Antonio Evans is the founder of Quanta Intelligence and a fractional CTO who builds HIPAA-ready AI systems for health and life-science companies. Before that he was technical co-founder of FriendsEAT for twenty years, CEO of Socialdraft, and a data engineer at IBM. Antonio lives with his dog Santino in Lisbon, Portugal.

All articles