How to Code an Interview Transcript: A Step-by-Step Guide with Examples

What is a qualitative code?

Johnny Saldaña's Coding Manual for Qualitative Researchers is the book most supervisors point to, and its definition is the one you will see quoted in methods chapters. A code is most often a word or short phrase that assigns a summative, salient, essence-capturing or evocative attribute to a portion of data. Put more simply, a code is a label that says what a piece of your transcript is about, or what it means.

Saldaña compares a code to the title of a book: it represents the content without reproducing it. Miles and Huberman described codes as tags for assigning units of meaning to the information you have collected, and made the practical point that their main job is retrieval. Once a passage is coded, you can pull up every other passage with the same code and compare them side by side. That is the whole reason for coding. It turns twenty pages of talk per participant into something you can sort.

A code is not yet a finding. Codes are the building blocks. Themes and categories are what you build from them, and confusing the two is one of the most common reasons examiners send analysis chapters back. Our guide to the difference between a code and a theme covers that step in detail.

Three decisions to make before you start

Where your codes come from. Inductive coding builds codes from the data. Deductive coding starts from a list drawn from theory or your research questions. Many studies mix the two: a short starting list, with new codes added whenever the data says something the list doesn't cover. If you are unsure which you are doing, read our guide on inductive vs deductive coding.

Which analysis method the codes feed. Coding looks slightly different depending on where it is heading. Braun and Clarke's reflexive thematic analysis treats coding as an interpretive, evolving process and doesn't require a fixed codebook or a second coder (Braun & Clarke, 2021). Qualitative content analysis and team-based studies usually want a written codebook with tight definitions. Grounded theory leans on line-by-line initial coding. Knowing your method now saves recoding later. If you haven't chosen yet, our overview of thematic analysis frameworks compares the options.

Whether you are a lumper or a splitter. Saldaña borrows these terms from the anthropologist H. Russell Bernard. A lumper gives a whole paragraph one broad code. A splitter breaks the same paragraph into several small codes. Neither is wrong, but you should pick a level deliberately and stay roughly consistent, or your codes will be impossible to compare.

The coding process, step by step

The running example for the rest of this guide is an illustrative study of 14 early-career nurses and how they manage the boundary between work and home. Here is a short excerpt from participant 7:

“In my first year I was on call every other weekend, so I just stopped making plans. My friends stopped asking after a while, which, fair enough. And honestly? I felt guilty saying no to extra shifts, because you know the ward is short and it's your colleagues who pay for it. Now I block my days off in the rota the minute it opens. That was my manager's idea, actually.” (P07)

1. Read the transcript without coding

Read the whole transcript through once, ideally while listening to the recording, before you mark anything. You want the shape of the whole account in your head. P07's excerpt only makes sense once you know that later in the interview she describes feeling more settled in her second year. Jot first impressions in a memo, not on the transcript.

2. Decide your approach and unit of coding

Settle the three decisions above and write them down. They go straight into your methods section later.

3. Code the first transcript closely

Work through the transcript and attach a code to every passage that relates to your research question. Skip small talk and interviewer housekeeping. The first time you use a code, write a one-line definition next to it in a running list. A first pass on the P07 excerpt might look like this:

4. Write memos as you go

Saldaña treats analytic memos as part of coding, not an extra. Every time you create a code, doubt a code, or notice a link, write a few lines. For P07 a memo might say: “Guilt is tied to colleagues, not the organisation. Check if others separate the two.” That single note could become a theme.

5. Build a draft codebook after two or three transcripts

By the third transcript your code list will have duplicates (GUILT and FEELING BAD ABOUT REFUSING) and codes that are too vague to apply consistently. Merge, rename and define them. This is the moment to turn the running list into a codebook, covered in detail below.

6. Code the rest and recode the early transcripts

Apply the codebook to the remaining transcripts, adding new codes when the data won't fit. Then go back and recode the first two or three with the final version. MacQueen and colleagues put it well: recoding is not a step back, it is a sign the analysis is moving forward.

7. Organise codes into parent codes, categories or themes

This is Saldaña's second cycle. You group related codes and ask what the groups are about. What happens here depends on your method: themes in thematic analysis, categories in content analysis, a core category in grounded theory. For a full worked example of that move in a dissertation, see thematic analysis for a dissertation.

Should I code line by line or paragraph by paragraph?

Line-by-line coding comes from grounded theory, where Kathy Charmaz recommends it for initial coding because it forces you to look at what each line actually says instead of skimming for what you expected. It is slow, and it produces a lot of codes, but it is the best cure for coding on autopilot.

Paragraph coding is faster but risky. Participants rarely keep to one idea per paragraph. P07's excerpt is a single paragraph and contains at least five separate ideas, so one paragraph-level code would lose most of them.

The approach that works for most projects sits between the two. DeCuir-Gunby, Marshall and McCulloch (2011) coded by what they called the “level of meaning”: a segment gets its own code when it can stand on its own and still make sense outside the wider interview. Sometimes that is half a sentence, sometimes three sentences. Our recommendation is to code the first two transcripts line by line to learn your data, then switch to meaning-level segments for the rest.

How long should a code be?

Short. Saldaña's definition says a word or short phrase, and in practice most good codes are one to five words. The test is simple: could someone who has never seen the quote understand the code on its own, in a list of fifty others?

• SHIFTS is too short. Shifts what? It tells you the topic but not what was said about it.
• FEELS GUILTY SAYING NO TO EXTRA SHIFTS BECAUSE COLLEAGUES SUFFER is too long. That is a summary, and it will only ever fit this one quote.
• GUILT ABOUT REFUSING SHIFTS works. It is specific and reusable.

Put the nuance in the definition, not the name. A tidy code name with a careful definition is easier to apply consistently than a long name that tries to do both jobs.

Descriptive, interpretive, process, emotion and in vivo codes

Saldaña profiles more than thirty coding methods. You don't need most of them. The five below cover nearly every interview project, and the easiest way to understand them is to code the same sentence each way. The sentence is P07's: “I was on call every other weekend, so I just stopped making plans.”

The descriptive and interpretive distinction goes back to Miles and Huberman. A descriptive code needs almost no inference: the passage is about weekend on-call, full stop. An interpretive code needs you to read between the lines, and so it needs more evidence before you apply it. Descriptive codes are a safe place to start. Interpretive codes are where analysis starts to say something.

Process codes use gerunds on purpose. Saldaña points out that “-ing” words capture things that emerge, change or happen in sequence, which descriptive nouns hide. WITHDRAWING implies a before and after that SOCIAL LIFE doesn't. Emotion codes label feelings, whether the participant names them or you infer them. When the participant names the feeling (“I felt guilty”), Saldaña suggests coding it in vivo.

You can and usually should mix types. Miles, Huberman and Saldaña's worked example of coding a participant's smoking withdrawal symptoms mixes emotion, process, descriptive and in vivo codes in one list.

Should codes use participants' exact words?

Sometimes, and for a reason. In vivo codes keep the participant's language in the analysis, which matters when a phrase carries meaning your own words would flatten. If “saying no” turns up in interview after interview, always with the same weight, that repetition is worth keeping visible. Miles, Huberman and Saldaña note that phrases participants use repeatedly are good leads, and that in vivo codes suit studies that aim to honour participants' voice. Put them in quotation marks so you can tell them apart from your own codes.

MacQueen et al. (1998) found a related benefit in team projects. Codes built from professional jargon encouraged coders to read their own assumptions into the text. Codes built from participants' own terms kept the respondent's voice separate from the analyst's.

The drawback is comparison. If one nurse says “stopped making plans,” another says “my social life died,” and a third says “I just went to bed on my days off,” three in vivo codes hide the fact that they describe the same thing. Use in vivo codes for vivid or recurring phrases, and a researcher-worded code to connect passages that mean the same thing in different words.

Can one extract receive more than one code?

Yes. Saldaña calls it simultaneous coding: two or more codes applied to the same passage, or overlapping passages, because the passage genuinely means more than one thing. “I felt guilty saying no to extra shifts” is about an emotion and about refusing work, so it reasonably takes both GUILT and “SAYING NO”. Social life does not come in neat, separate pieces, and your coding doesn't have to pretend it does.

DeCuir-Gunby et al. (2011) noticed that some codes almost always travel together. In their study, teachers who described their beliefs about learning nearly always gave examples of classroom practice in the same breath. Pairs like that are worth a memo, because they may point to a relationship you want to report.

The warning comes from Miles, Huberman and Saldaña: use it sparingly. If most passages end up with three or four codes, the codes probably overlap, and the fix is tighter definitions, not more codes.

How many codes should I create?

There is no right number, and anyone who gives you one without knowing your data is guessing. What is predictable is the shape. Codes multiply quickly over the first few transcripts, level off, then shrink as you merge duplicates and drop codes that only ever appear once and don't bear on your question. If your list is still growing fast at transcript ten, your codes are probably too specific.

One number is worth knowing. MacQueen et al. (1998) found that coders can reasonably handle 30 to 40 codes at a time. Beyond that, consistency drops, and they recommend splitting the codebook into domains and applying one set at a time. For a solo student, the practical equivalent is a two-level structure: a handful of parent codes you can hold in your head, each with its own children.

Rather than aiming for a number, check two things. Can you apply every code without hesitating over which one fits? And does every code bear on your research question? A code that passes both is earning its place.

How to organise parent and child codes

A parent code is a broader label. Its child codes (also called sub-codes) are kinds or aspects of it. Saldaña's example from a study of children's play has the category Oppression through physical force, the code FIGHTING, and beneath it SCRATCHING, PUSHING and PUNCHING. In the nurse study, the structure might look like this:

EMOTIONAL COST OF WORK
├── GUILT
├── EXHAUSTION
└── RESENTMENT
PROTECTING PERSONAL TIME
├── BLOCKING DAYS OFF
├── "SAYING NO"
└── MANAGER SUPPORT
WORK CROWDING OUT LIFE
├── WITHDRAWING FROM SOCIAL LIFE
└── FRIENDSHIPS FADING

A few rules keep a hierarchy useful:

• Every child must be a genuine kind or part of its parent. If you can't say “X is a type of Y,” it belongs somewhere else.
• Keep it to two or three levels. Deeper trees are hard to apply and harder to report.
• Decide whether you code at the child level only (the parent is then just a folder) or allow coding at the parent when a passage is too general for any child. Write that rule in your codebook.
• Build the hierarchy after a few transcripts, not before. Parents that come from the data fit better than ones you guessed in advance.

In NVivo and MAXQDA this is simply dragging codes under other codes. Our guides to coding in NVivo and coding in MAXQDA show where the options are. A parent code is not automatically a theme. A theme says something about the data. A parent code is a filing decision. Sometimes they end up the same, often they don't. Once your structure settles, you can turn it into a figure with our thematic map generator.

How to create a codebook (and what goes in it)

A codebook is the list of your codes with definitions and examples, written so that you, a second coder, or an examiner could apply them the same way. DeCuir-Gunby et al. (2011) describe it as a set of codes, definitions and examples used as a guide to analysing interview data. It also puts your assumptions on the page, which MacQueen and colleagues saw as one of its main benefits.

What to include

MacQueen et al. (1998), working on large CDC projects, settled on six parts for every code:

1. the code name
2. a brief definition
3. a full definition
4. when to use it (inclusion criteria)
5. when not to use it (exclusion criteria)
6. an example quote

DeCuir-Gunby et al. used a lighter version with three parts: the name, a full definition that folds in the inclusion and exclusion rules, and an example. For a solo dissertation, three parts is usually enough. If anyone else will code your data, use all six. Here is one entry from the nurse study in the full format:

The “don't use when” line does the most work. Most coding inconsistency happens at the border between two similar codes, and the exclusion rule is where you settle that border in advance.

How to build it

• Start from the running list you kept while coding the first two or three transcripts, plus any codes drawn from theory.
• Merge duplicates and write the full definitions. MacQueen et al. advise never assuming anything is obvious; say exactly what each code does and doesn't capture.
• Test it. Code a fresh transcript using only the codebook. Every time you hesitate between two codes, fix the definitions.
• If you work with others, have two people code the same transcript independently and compare. In reflexive thematic analysis this step isn't required, so check what your method expects.
• Keep one person in charge of edits, and keep the codebook as a current reference, not a history. Log changes separately if you need an audit trail.

Expect it to take time. DeCuir-Gunby and colleagues reported 36 hours of team discussion to create their codebook and another 24 to train research assistants to use it. A solo student will spend far less, but it is still a real task, not an afternoon.

Common coding mistakes

• Coding the interview question instead of the answer. A code like Q4 WORK-LIFE BALANCE sorts the data by your questions. That is fine as a first index, but it isn't analysis.
• Codes that summarise instead of label. If a code only fits one quote, it is a paraphrase.
• Never recoding the first transcripts. Your early coding used a codebook that no longer exists.
• Only coding what you expected. Participants will talk about things your questions didn't ask. Some of your best findings live there.
• No memos. Six weeks later you won't remember why DRIFTING and WITHDRAWING are different codes.
• Treating code counts as findings. A code applied forty times is not necessarily more important than one applied four times. In reflexive thematic analysis, frequency isn't evidence of importance at all.

Your own position shapes what you notice when coding. A short positionality statement written before you start makes that visible to you and to your examiner.

Getting the first pass done faster

None of the judgement in this guide can be handed off. Deciding that GUILT and RESENTMENT are different codes, or that “saying no” deserves an in vivo code, is your analysis. What eats the weeks is the mechanical part: reading twenty transcripts line by line to produce a first list of codes, copying each quote into a spreadsheet, and hunting for every passage that should share a label.

If you want a head start, thematicanalysis.ai will do that first pass on your interview transcripts. Each code comes with a definition and the verbatim quote it came from, and the codes are grouped into themes you can edit and rename, moving codes between themes or removing the ones that don't hold up. Think of it as a colleague's first attempt that you then check line by line against the transcript, not as the finished analysis. Whether AI belongs in coding at all is debated, and our guide to AI qualitative coding sets out both sides. If your supervisor asks how you used it, our guide to reporting AI-assisted analysis has wording for the methods section.

Paste one transcript below and compare its codes with your own. The first three are free, and you'll know in a few minutes whether it helps.

Frequently asked questions

Coding open-ended survey answers instead of interviews? The same principles apply, with a few differences covered in our guide to analysing open-ended survey responses.