Start with a reproducible example
A good way to learn interview coding is to practice on a short excerpt where the evidence is visible. The sample below is synthetic demonstration material. It describes a fictional early-career employee talking about remote work, apprenticeship, focus time, and growth. It is not a real participant transcript and should not be treated as research data.
Interviewer: Thanks for joining. To start, can you describe what a typical remote workday looks like for you?
Participant A: I usually start around 8:30, but the first hour is not really work in the focused sense. I check messages from the team in London, scan the project board, and try to figure out what actually needs my attention. When we were all in the office, I could ask someone next to me, "Is this urgent?" Now I have to infer that from Slack threads, calendar invites, and whether someone used an exclamation point. It sounds silly, but that affects how I prioritize.
Interviewer: What has improved for you?
Participant A: The quiet has improved my writing. I do research summaries for product managers, and I need uninterrupted blocks to make sense of interview notes. At home I can protect those blocks better. I also save commute time, which means I can exercise before work or cook dinner instead of buying something on the way home. That makes the week feel less compressed.
Interviewer: What has become harder?
Participant A: Learning by watching people is harder. I joined this company remotely, so I did not see how senior researchers talk through a messy finding or push back on a stakeholder. Training documents tell you the process, but they do not show the judgment. Sometimes I worry that I am only learning the visible steps, not the craft behind them.
Interviewer: How do team meetings affect that?
Participant A: Meetings help when they are designed for discussion. They do not help when they are just status updates. The best meetings are the ones where someone shares their screen, shows a rough draft, and says, "Here is where I am stuck." That gives me permission to admit uncertainty too. But those meetings are rare because everyone is trying to protect focus time.
Interviewer: If you could change one thing about the remote setup, what would it be?
Participant A: I would create more deliberate apprenticeship moments. Not more meetings exactly, but small sessions where a junior person can observe how an experienced person thinks through evidence. Remote work gives me autonomy, which I value, but it also means growth has to be designed. Otherwise you can be productive and still feel like you are developing in isolation.
Step 1: open coding by hand
Open coding means reading the transcript closely and assigning provisional labels to meaningful passages. At this stage, you are not trying to build the final theory. You are trying to notice what is happening in the participant's own account. The first paragraph might receive codes such as "signal interpretation," "remote prioritization," and "loss of informal urgency cues." The writing paragraph might receive "protected focus," "commute time recovery," and "less compressed week." These labels are small, imperfect handles for returning to the evidence.
A good beginner habit is to code slightly more than you think you need, then write a short note explaining why. For example, "signal interpretation" is stronger than a generic code like "communication" because it captures the participant's active work of inferring urgency from Slack threads, calendar invites, and punctuation. That code points to a pattern you might compare across other interviews. Do other participants also describe reading digital traces as social signals? If so, the code may become analytically useful.
Step 2: turn repeated observations into a codebook
A codebook is a set of working rules that helps you apply codes consistently. For the sample excerpt, the code "Invisible apprenticeship" could be defined as: participant describes missing tacit learning from observing how experienced colleagues reason through messy work. Include passages about judgment, craft, pushback, and learning by watching. Exclude general complaints about training documents unless the passage links them to tacit learning.
The downloadable codebook linked below includes example fields for code name, definition, inclusion rule, exclusion rule, quote, and memo prompt. Those columns keep you honest. If you cannot write an inclusion rule, the code may be too vague. If two codes have the same example quote and no clear boundary, you may need to merge them. If a code has a strong definition but no good quote, it may be an idea you brought to the data rather than an interpretation grounded in the transcript.
Step 3: write memos while the evidence is fresh
Memos are where coding becomes analysis. A memo is not a polished finding. It is a record of what you are noticing, what you are unsure about, and what you want to test in later transcripts. After coding the sample, a memo might say: "Remote work is described as both autonomy and stalled apprenticeship. The participant values focus time but worries that professional judgment is learned through observation. Future interviews should check whether this tension appears among people who joined before the remote shift."
Notice the difference between a memo and a summary. A summary says what the participant said. A memo begins to ask what that account might mean for the research question. Memos also preserve your analytic trail. If you later build a theme about "productive isolation," you can show how that theme developed from coded excerpts and unresolved questions rather than appearing suddenly in the final report.
Where QDA software helps
Qualitative data analysis software usually supports this workflow by giving you a stable place to import transcripts, highlight passages, attach codes, manage code definitions, write memos, and export coded excerpts. A typical workflow is to import a transcript, read line by line, select a passage, apply a code from a coding panel, and update the codebook as definitions become clearer. Larger projects also benefit from filters, matrices, and retrieval views that show every passage assigned to a code.
Software is useful because it lowers the mechanical burden of staying organized. It does not remove the interpretive burden. You still decide whether a passage belongs under "protected focus" or "productive isolation." You still decide whether a code is too broad, whether a quote supports a claim, and whether a theme is credible across the dataset. The tool should make those decisions easier to inspect, not hide them behind a cleaner interface.
How AI assistance should be bounded
AI can help with first-pass suggestions, candidate summaries, similar-passage grouping, and codebook hygiene. It may notice that "training documents tell you the process, but they do not show the judgment" is related to a code about tacit learning. It may propose that "productive and developing in isolation" supports a theme about growth costs. Those suggestions are useful only when they remain auditable.
In a rigorous workflow, AI output should stay in a suggested state until a researcher reviews it against the transcript. A reviewer may accept the suggested code, edit the wording, reject the suggestion, or write a memo explaining why the passage is ambiguous. That is the methodological reason OpenVerbatim separates suggested and confirmed evidence. Machine assistance can accelerate preparation, but final analytic material must be traceable to source passages and human review.
Download the practice files
Use the synthetic transcript and codebook to practice the workflow yourself. Start by coding the transcript on paper or in a plain text editor, then compare your labels with the example codebook. After that, import the transcript into your preferred QDA tool or try the browser sandbox to see how a review queue changes the rhythm of coding.
Download the sample interview transcript and the sample codebook CSV. For adjacent methods, read how to do thematic analysis, browse qualitative coding examples, compare AI qualitative data analysis, and review the open source qualitative research software guide. If you are evaluating commercial migration, the NVivo alternative page and traditional QDA workflow comparison explain the larger operating model.