October 2026 · 6 min read

How to Code Interview Data as a Team

Team coding means two or more people apply the same codebook to the same data, then compare their choices. It slows the first pass down and speeds everything after it. A second coder catches the passages you skimmed and the codes you stretched. They also catch the definitions that only made sense in your head.

It's worth doing when a project will be read by people who weren't in the room, such as a dissertation committee or a journal's reviewers. It also works as a teaching method, because a disagreement with a classmate shows a student what a code definition actually commits them to faster than any lecture does.

Build a starter codebook

Start small. Five to eight codes is plenty for a first pass, and most of them will change. Each code needs four parts:

The "don't use when" line does most of the work. Two coders rarely disagree about the center of a code. They disagree at its edges, and the exclusion line is where you decide where the edge sits.

You can build the first draft from your research questions (deductive), from a quick read of three or four transcripts (inductive), or both. Write down which, because a reviewer will ask.

Code independently, then compare

The order matters. If coders can see each other's work while they code, the second coder anchors on the first, and you lose the disagreements you were looking for.

1. Everyone codes the same transcript alone, with the same codebook. Attach a short note to any passage you hesitated on.
2. Reveal each other's coding and read the transcript together from the top.
3. Mark every passage where coders differ. Differences come in two kinds: one person coded a passage the other skipped, or both coded it with different codes.
4. For each difference, ask whether the passage is ambiguous or the codebook is. Most of the time it's the codebook.
5. Revise the definitions, write down what changed and why, and date the codebook version.
6. Code the next transcript with the new version and repeat. Disagreements usually drop off after two or three rounds. When they stop teaching you anything, split the remaining transcripts between coders.

Keep the change log. It's the record of how your analysis developed, and it's the first thing a committee member will want to see.

What to do with disagreements

Treat each disagreement as a question about the codebook and settle it with a rule you can write down. Four outcomes cover nearly every case:

Some disagreements don't resolve, and that's fine. Record them. A passage two careful readers interpret differently is often worth a paragraph in your findings.

When agreement statistics help

Intercoder reliability statistics, such as percent agreement or Cohen's kappa, put a number on how often coders made the same call. Whether you should report one depends on your approach.

O'Connor and Joffe give a balanced account of the debate and practical steps if you do report it: Intercoder Reliability in Qualitative Research: Debates and Practical Guidelines (International Journal of Qualitative Methods, 2020). Much of their case concerns the process itself, which requires a codebook clear enough for someone else to use and a team that talks through its calls.

Try it

The free teaching kit Coding Interview Data Together walks a class through this process with four interview transcripts, a starter codebook, a session plan, and a rubric. It's licensed CC BY 4.0, so you can adapt it.

The kit runs in CollabCoder, a browser-based coding tool where group members code the same transcript and can hide each other's highlights until they're ready to compare. Classes are free for instructors and students. Research teams can use the same workflow on their own data.

By Josh Herron, PhD.