12 Qualitative Interview Coding Problems (and How I Fix Them) — Design Review

Most qualitative interview coding problems start early in a project, long before anyone looks at the themes. By the time a supervisor writes “themes not supported” in the margin, the damage was usually done in the transcript or the codebook.

I have guided research students for 12 years, and I keep seeing the same dozen mistakes. Below I show each one with a short excerpt, and I say where I disagree with advice you will find on other sites.

What Are Qualitative Interview Coding Problems?

Qualitative interview coding is the process of labelling parts of interview transcripts with short codes, then grouping those codes into themes that answer your research question. Qualitative interview coding problems are errors in transcription, code definition or theme-building that make findings inconsistent, thinly evidenced or impossible to trace back to what participants said.

What are the common problems in qualitative coding? The common ones are inaccurate transcripts, lost context, inconsistent code definitions, over-fragmented codes, mixed code types, coding drift, topic-style themes, themes without multi-participant evidence, and no audit trail. I group them below by stage.

The 12 qualitative interview coding problems at a glance

#	Problem	What it looks like	Quick fix
1	Raw AI transcripts	Mis-heard terms change meaning	Check quotes against audio
2	Mixed transcription styles	Some files verbatim, some tidied	Pick one style, state it
3	Lost context	“Yeah, it was fine” with no question or pause	Keep speaker labels, timestamps, notes
4	No familiarisation	Coding starts on first read	Read twice, write margin notes
5	Inconsistent code definitions	“Cost barriers” and “Money problems”	Written codebook with rules
6	Over-fragmentation	Hundreds of codes, most used once	Merge, define, drop
7	Mixed code types	Description and interpretation tangled	Separate coding cycles
8	Coding drift	Interview 12 coded differently from 1	Recode a sample after a gap
9	Over-reliance on software or AI	Plausible but wrong labels	Verify every suggestion
10	Topics treated as themes	Theme called “Challenges”	Write themes as claims
11	Unsupported themes	One participant, one quote	Multi-participant evidence plus negative cases
12	No audit trail	Cannot show how data became theme	Memo trail table

Transcription Errors in Qualitative Research That Quietly Damage Your Data

These first four qualitative interview coding problems begin before you open NVivo or Excel.

What are the main challenges of transcribing interviews? Three: accuracy (accents, jargon, poor audio), consistency (one style across every file) and context (speaker labels, timestamps, pauses). Most transcription errors in qualitative research fall under one of these.

1. Trusting raw AI transcripts

Lumivero’s ATLAS.ti blog says AI transcription and structured coding shorten the gap between collecting and analysing data. That is true, but I would add a warning: a shorter gap also means transcript errors reach your codes faster. Accuracy tends to drop with accents, discipline jargon and overlapping speech.

Audio: “My supervisor never signs off on the roster.”

AI transcript: “My supervisor never science off on the roster.”

One error like this can erase a code. Check every passage you plan to quote against the audio, and listen to the rest at faster speed while reading.

2. Mixing transcription styles: which one should you pick?

Pick one style and write it in your methodology. Full verbatim (also called naturalised) keeps every pause and false start. Intelligent verbatim, closer to denaturalised, drops filler but keeps meaning.

For most thematic analysis I prefer intelligent verbatim. Use full verbatim only if hesitation or silence is part of what you are analysing.

3. Losing context: what must a transcript keep?

A transcript without context can reverse the meaning of an answer. One transcription guide points out that timestamps make a coded dataset auditable. That guide comes from a transcription tool, so it stops at the file. I would add speaker labels and the interviewer’s question to the list.

Without context: P7: “Yeah, it was fine.”

With context: I: “How did remote supervision feel?” P7: “[4-second pause] Yeah, it was fine. [laughs, looks away]”

The first version gets coded as satisfaction. The second deserves something closer to ambivalence.

4. Coding before you know the data

Braun and Clarke place familiarisation first in their thematic analysis phases, and they call the process recursive, not a checklist. It is tempting to code on first read to save time. Read each transcript twice and jot short margin notes before you create a single code.

These are your own interviews, so treat them with the care you would give any primary research data.

Where should your recordings go? Consent and data protection

Check your consent form and ethics approval before you upload a recording to any AI transcription tool. In the UK, voice recordings are personal data under UK GDPR, so your university’s ethics committee will expect a clear plan. In the US, your IRB (institutional review board) plays the same role.

Use pseudonyms such as P1, P2 and P3 from the first transcript, and remove names and places while transcribing. Ask your supervisor if AI transcription is acceptable, and record the decision in your methodology. Rules differ by university, so confirm with your ethics office.

Common Qualitative Coding Mistakes I See in Dissertations

Transcripts are clean. Here are the common qualitative coding mistakes that appear next. Discuss your codebook on WhatsApp

5. Inconsistent code definitions

GoTranscript’s NVivo guide shows how one idea ends up under names like “Access barriers” and “Barriers to access”. The same thing can easily happen as “Cost barriers”, “Money problems” and “Affordability issues” in one project. Write a one-line definition for every code:

Code: COST_BARRIER

Definition: Participant says money prevents or delays an action.

Exclude: General complaints about pay with no stated consequence.

What is a codebook? A codebook is a document listing every code in your study with a short definition, include and exclude rules, and an example quote. It lets you, and any second reader, apply codes the same way across all interviews, and it forms part of your audit trail.

That guide also advises locking the codebook after pilot coding. For inductive work I disagree. Version it instead (v1, v2, with dates) so changes stay visible.

6. Excessive coding fragmentation: how many codes is too many?

Illustrative case (composite, details changed). A master’s student sent me six interviews coded into well over a hundred labels, most used once, none defined. We merged duplicates, dropped labels with no analytical use, and ended with about thirty codes feeding five themes.

There is no magic number. If most codes appear once and cannot be grouped, you are fragmenting. Saldaña’s coding manual separates first-cycle and second-cycle coding, and I recommend the same discipline: one method per cycle.

7. Mixing descriptive and interpretive codes

P4: “I stay till nine most nights, and honestly I have stopped noticing.”

Descriptive code: LONG_HOURS

Interpretive code: EXHAUSTION_NORMALISED

Both are valid, but they sit at different levels. Do a descriptive first pass, an interpretive second pass, and label which is which.

In grounded-theory terms, the first pass is close to open coding. The second often resembles axial coding, where you relate codes to each other. An in vivo code uses the participant’s own words as the label, such as “corridor time”. Use these sparingly and define them like any other code.

8. Coding drift

Interview 1 gets careful coding. By interview 12 you are tired and coding loosely. After finishing, recode your first two transcripts without looking at your earlier codes. Compare, and record every difference in a memo.

9. Letting software or AI do the thinking

NVivo, ATLAS.ti, MAXQDA and Dedoose all store and retrieve codes well. Choose the one your university licenses and your supervisor can read. None of them fixes weak definitions.

Newer AI coding assistants read context better than old keyword matching. They still do not know your research question, and they can produce confident labels that the transcript does not support. Verify every suggestion against the data before it enters your codebook.

Inductive or deductive coding: which suits your study?

Inductive coding builds codes from the data. Deductive coding applies codes from a theory or framework chosen in advance. Many studies use a hybrid, with a few theory-based codes plus new ones from the data, and every change logged.

Qualitative Thematic Analysis Problems That Weaken Your Findings

Theme-level qualitative interview coding problems are where examiners push hardest.

10. Topic summaries mistaken for themes

“Remote work challenges” is a topic. “Remote supervision removes informal reassurance, and students absorb the cost as extra hours” is a theme. Braun and Clarke describe a theme as a pattern of shared meaning around a central idea. If your theme title could be a folder name, it is still a topic.

11. Are your themes supported by participant evidence?

Illustrative case (composite, details changed). A student’s theme read “Managers distrust remote staff”. Only one participant had said it. The other quotes were about workload.

My rule: show evidence from more than one participant, and look for at least one negative case. If a theme rests on a single voice, the issue may be depth. See understanding qualitative data saturation.

Be careful with fixed numbers. One AI-research vendor says saturation commonly arrives at 12 to 20 interviews per segment. That is a rule of thumb, not a rule. Saunders and colleagues argue saturation should be considered against the research question and analytical approach.

Students also quote Guest, Bunce and Johnson (2006) as proof that twelve interviews are enough. That study used about 60 interviews from fairly similar participants. A later systematic review found that studies converged on a relatively consistent sample size for common methods.

The type of saturation matters too. Hennink, Kaiser and Marconi’s 2017 study put code saturation near 9 interviews and meaning saturation higher, around 16 to 24. And if all your participants came through friends, say so openly (evaluating participant selection limitations).

12. No memos, no audit trail: how do you show analytical transparency?

Lincoln and Guba tie trustworthiness to dependability and confirmability, meaning a reader can follow your path from data to claim. COREQ gives a useful 32-item reporting checklist for interviews and focus groups. SRQR is a broader reporting standard for qualitative research. But ticking boxes does not make analysis transparent. A traceable trail does.

Two further habits help. Member checking, where you return findings to participants, can support credibility. Thick description, meaning enough detail about context for readers to judge if your findings apply elsewhere, supports transferability.

Transcript line	Code	Memo	Theme
P4, 00:14:32 “I stay till nine most nights…”	EXHAUSTION_NORMALISED	Seen in P2, P6. P5 disagrees.	Overwork as unspoken norm

Worked Example: From Transcript Line to Defensible Theme

This example fixes several qualitative interview coding problems at once. The excerpt is illustrative.

Interviewer: How has remote supervision changed your work?

P4: Honestly, I stay till nine most nights now. Earlier I would catch my supervisor in the corridor and sort things in two minutes. Now I wait for email and work while I wait. [pause] I have stopped noticing it, really.

Weak coding: one code, “Remote work challenges”, on the whole paragraph. The theme becomes “Challenges of remote supervision”. This is a topic label on one large chunk, with no definition and no interpretation.

Stronger coding:

• “I stay till nine most nights” → LONG_HOURS (descriptive)
• “catch my supervisor in the corridor” → LOST_INFORMAL_ACCESS (descriptive)
• “I wait for email” → WAITING_FOR_REPLY (descriptive)
• “I have stopped noticing it” → OVERWORK_NORMALISED (interpretive)

Memo: “P4 links delay to long hours. Check P2 and P6. P5 says hours unchanged: negative case.”

Theme: Remote supervision removes informal reassurance, and students absorb the cost as extra hours. Evidence from P2, P4 and P6. Negative case: P5.

How to write it up in your findings chapter: state the theme in one sentence, give two or three short quotes from different participants with their IDs, mention the negative case, and tie the theme back to your research question.

How to Code Interview Transcripts: A 6-Step Process

1. Check each transcript against its audio, at least for passages you may quote.
2. Read twice, writing short margin notes.
3. Pilot code two interviews descriptively.
4. Write codebook v1 with definitions and include and exclude rules.
5. Code the full set, memoing as you go, and merge duplicate codes.
6. Build themes and test each one with an evidence table.

How to Improve Qualitative Coding Consistency

Most interview coding problems become visible once you run a simple routine. This is how to improve qualitative coding consistency without turning your study into a statistics exercise:

• Recode a sample after a gap of a few days.
• Keep a dated codebook history.
• Ask a peer to code one transcript using your definitions.
• Write a memo whenever you merge, split or rename a code.

On intercoder reliability I take a middle position. Braun and Clarke argue that agreement statistics do not fit reflexive thematic analysis. McDonald, Schoenebeck and Forte say they make more sense when a codebook is fixed in advance.

So ask your supervisor in week one. If your design needs agreement, see understanding agreement between research coders. If it does not, do not run kappa just to look scientific.

Pre-submission checklist

Use this before you submit. It catches most qualitative interview coding problems early.

• Every quoted passage checked against the audio
• One transcription style, stated in the methodology
• Pseudonyms in place, and consent covers the tools used
• Every code has a definition, include and exclude rule, and an example
• Codebook versions are dated
• First two transcripts recoded after a gap
• Each theme has quotes from more than one participant and a negative case noted
• Memo trail runs from transcript line to theme

When Expert Review Makes Sense

If your supervisor has already written “themes not supported” in the margin, a second pair of experienced eyes can save weeks. Not sure if you need one? Read how to know if you need a dissertation expert, or see how to find a dissertation writing mentor.

A coding review works on your own material and your own interpretation. Request an analysis review on WhatsApp Here is how I approach it:

• You send your codebook, a few coded transcript pages and one excerpt-to-theme table.
• I check definitions, code levels, theme wording and whether the evidence supports each theme.
• You get written feedback listing the problems and suggested fixes, so you make the changes yourself.

Share your codebook and one excerpt-to-theme table, and I will tell you where the qualitative interview coding problems are hiding. This is feedback on your method, not someone writing your findings. If your supervisor suspects AI use, read what to do if you are accused of using AI in your dissertation.

Frequently Asked Questions

References

• Braun, V. and Clarke, V. (2006). Using thematic analysis in psychology. Qualitative Research in Psychology, 3(2), 77-101.
• Braun, V. and Clarke, V. (2019). Reflecting on reflexive thematic analysis. Qualitative Research in Sport, Exercise and Health, 11(4), 589-597.
• Guest, G., Bunce, A. and Johnson, L. (2006). How many interviews are enough? Field Methods, 18(1), 59-82.
• Hennink, M. and Kaiser, B. N. (2022). Sample sizes for saturation in qualitative research: A systematic review of empirical tests. Social Science and Medicine, 292, 114523.
• Hennink, M. M., Kaiser, B. N. and Marconi, V. C. (2017). Code saturation versus meaning saturation: How many interviews are enough? Qualitative Health Research, 27(4), 591-608.
• Lincoln, Y. S. and Guba, E. G. (1985). Naturalistic Inquiry. SAGE.
• McDonald, N., Schoenebeck, S. and Forte, A. (2019). Reliability and inter-rater reliability in qualitative research. Proceedings of the ACM on Human-Computer Interaction, 3(CSCW).
• Saldaña, J. (2021). The Coding Manual for Qualitative Researchers (4th ed.). SAGE.
• Saunders, B. et al. (2018). Saturation in qualitative research: exploring its conceptualization and operationalization. Quality and Quantity, 52, 1893-1907.
• Tong, A., Sainsbury, P. and Craig, J. (2007). Consolidated criteria for reporting qualitative research (COREQ). International Journal for Quality in Health Care, 19(6), 349-357.

Vendor sources discussed above: Lumivero (ATLAS.ti) blog, GoTranscript NVivo guide, Subanana transcription guide, Why (getwhy.io) saturation article.

About the author: Siddharth Gupta is an independent data consultant with 12 years of experience in dissertation and research guidance. He works with R, SPSS, Stata, Excel and Power BI, and holds an MBA (Finance) and a Google Data Analytics Certificate. Connect on LinkedIn.