Interviews

Suppose your school wants to build a small AI system that reduces food waste in the canteen — something that predicts how much rice, dal, and sabzi to cook each day so less ends up in the bin. Before anyone writes a single line of code, there is a problem: the canteen's records only show how much food was thrown away, not why. A sensor on the dustbin can weigh the waste. A camera can count plates. Neither can tell you that Class 8 students skip the sabzi because it's too spicy, or that Class 6 students take large portions because the line moves fast and they don't want to go back for seconds. That kind of information — reasons, opinions, experiences — usually has to come from asking people directly. In the language of data collection, that is called an interview, and it is one of the most important — and most misunderstood — ways of gathering data for a technology or AI project.

What an interview actually is, in data-collection terms

In everyday language, "interview" often means a job interview or a celebrity being questioned on TV. In computer science and AI, the word has a narrower, more technical meaning: an interview is a planned, one-on-one (or small-group) conversation between an interviewer and a respondent, conducted specifically to collect information that will be recorded and analyzed. The key word is planned. A chat with a friend at lunch is not an interview, even if you learn something useful from it, because nobody prepared questions, recorded answers consistently, or intended to analyze the conversation afterward. The moment you decide in advance what you want to find out, write down a set of questions, and record the answers so they can be compared across many people, a conversation becomes a data-collection method.

This matters for AI projects specifically because of something called the AI Project Cycle, the standard sequence used to build any AI solution: Problem Scoping → Data Acquisition → Data Exploration → Modelling → Evaluation. Interviews belong mainly to the second stage, Data Acquisition, but they often start even earlier, during Problem Scoping, when you use a "4Ws" canvas — Who is affected, What is the problem, Where does it occur, Why does it matter — to understand the people involved. You cannot fill in "Who" and "Why" convincingly just by staring at a spreadsheet. You have to talk to the people the problem actually affects: canteen staff, students standing in line, the person who empties the dustbin.

Three shapes an interview can take

Not all interviews are conducted the same way. Depending on how tightly the questions are controlled, interviews fall into three types, and the difference is not just style — it changes what kind of data you end up with and how easily a computer can later use it.

• Structured interview: Every respondent is asked the exact same questions, in the exact same order, usually with fixed answer choices. Example: "On a scale of 1 to 5, how much did you enjoy today's lunch?" This is fast to conduct and easy to turn into numbers, because every answer is already in a comparable format. The cost is flexibility — if a student wants to explain why they gave a 2, a strictly structured interview has no room for that.
• Unstructured interview: The interviewer starts with a general topic but no fixed question list, and lets the conversation flow naturally, asking follow-up questions based on what the respondent says. Example: "Tell me about your experience with school food this term." This produces rich, detailed information and can surface things you never thought to ask about — but because every conversation goes differently, the answers are hard to line up and compare across many respondents.
• Semi-structured interview: A middle path, and the one used most often in real research and product design. The interviewer prepares a core list of questions to make sure every respondent covers the same ground, but is free to ask spontaneous follow-up questions when an answer is interesting or unclear. Example: "What did you think of lunch today?" followed by "You said it was too spicy — is that true most days, or just today?"

The choice between these three is a trade-off, not a matter of one being "correct." A structured interview trades depth for consistency; an unstructured interview trades consistency for depth. Semi-structured interviews try to get a bit of both, which is why they dominate real-world data collection — from UX researchers at Indian companies like Zomato and Swiggy interviewing users before redesigning an app screen, to a Grade 8 student figuring out canteen food waste.

Interview or survey? They are not the same tool

A very common mix-up is treating "interview" and "survey" (or "questionnaire") as interchangeable, since both involve asking people questions. They are related but distinct data-acquisition methods, and an AI project usually has to pick the right one for the right stage:

• Format: An interview is spoken and interactive; a survey is usually written, and the respondent fills it in without the researcher present.
• Follow-up questions: An interviewer can hear an interesting answer and immediately dig deeper ("why do you say that?"). A survey form cannot react — the questions are fixed the moment it is printed or published.
• Scale: Because each interview takes real time (often 10–30 minutes per person), you can realistically only interview a small number of people — say, 15 to 30. A survey, especially an online form, can be sent to hundreds or thousands of people at almost no extra cost per response.
• Depth vs. breadth: Interviews give you depth — detailed, personal, sometimes unexpected information from a few people. Surveys give you breadth — simpler information from many people, which is more useful for confirming a pattern with numbers.

In practice, the two are often used together in a specific order: a handful of semi-structured interviews first, to figure out what questions are even worth asking, followed by a large-scale survey to check whether the small sample's opinions hold true across everyone. If the canteen-waste team interviews 20 students and hears "portion size" mentioned repeatedly, that becomes a specific, well-worded question in a survey sent to all 800 students — rather than the team guessing at survey questions from scratch.

Designing questions that don't quietly ruin your data

A badly worded question can make an entire interview's data useless, even if every respondent answers honestly. Three mistakes come up again and again:

• Leading questions push the respondent toward a particular answer. "Don't you think the sabzi is too spicy?" invites agreement rather than an honest opinion, because it signals what the interviewer expects to hear. The fix is a neutral phrasing: "What do you think of the sabzi?"
• Double-barreled questions ask two things at once and force a single answer to cover both. "Do you think the food is tasty and the queue is fast?" is unanswerable if a student thinks the food is great but the queue is slow — they cannot give one honest answer. The fix is to split it into two separate questions.
• Closed vs. open-ended, used at the wrong moment. A closed question ("Do you like the food: yes or no?") is quick to analyze but throws away detail. An open question ("What would you change about the food?") captures detail but is slower to process. Neither is wrong — the mistake is using only closed questions when you actually need reasons, or only open questions when you just need a quick yes/no count.

You cannot interview everyone: sampling

A school might have 800 students, but interviewing all 800 one-on-one, at even 10 minutes each, would take over 133 hours of conversation alone — before any analysis. This is precisely why interviews are almost always conducted on a sample — a smaller group chosen to represent the larger population (the full group you actually care about, here, all 800 students). The core idea, and a genuinely important one in data science, is that a well-chosen sample can reveal patterns that hold reasonably well for the whole population, without needing to ask everyone.

"Well-chosen" is the operative phrase. If the canteen-waste team only interviews 20 students from Class 8, Section A, they will miss whatever is different about Class 6 students, or students who bring tiffins instead of eating in the canteen. A better sample deliberately spreads across grades, sections, and eating habits — say, 4 students from each of five grade levels. This does not guarantee a perfect picture, but it is far more trustworthy than a sample chosen purely by convenience (like interviewing only your own friends, which is called a convenience sample and is a common — and easy to avoid — source of bias).

Turning what people said into something a computer can use

Here is the part that connects interviews to actual AI/data work, and it is where most beginners get stuck: an AI model does not understand sentences like "the portions are just too big for me, I always end up throwing half of it away." It needs structured, comparable data — usually numbers or categories. The step that bridges spoken answers and machine-usable data is called coding (in the data-collection sense — not the same "coding" as writing a Python program, though the two meet in a moment). Coding means reading through every response and assigning it to one of a small number of categories, or tags, that you either decided in advance or discovered while reading the answers.

Say the canteen team interviews 20 students and asks, open-endedly, "why do you sometimes leave food on your plate?" After reading all 20 answers, they notice the reasons cluster into four recurring tags: portion (portion too large), taste (didn't like the taste), not_hungry (wasn't hungry / ate a snack earlier), and other (everything else). Tallying the 20 responses gives: 8 tagged portion, 5 tagged taste, 4 tagged not_hungry, and 3 tagged other. Once every answer has a tag, the qualitative interview data has become a simple frequency count — and a frequency count is exactly the kind of structured input an AI model, a spreadsheet, or a bar chart can work with.

Here is that tallying step written as a short Python program, which is genuinely how a data scientist would start turning a folder of interview notes into usable numbers:

responses = [
    "portion", "portion", "portion", "portion",
    "portion", "portion", "portion", "portion",
    "taste", "taste", "taste", "taste", "taste",
    "not_hungry", "not_hungry", "not_hungry", "not_hungry",
    "other", "other", "other"
]

counts = {}
for r in responses:
    counts[r] = counts.get(r, 0) + 1

total = len(responses)
for tag, n in counts.items():
    percent = round(n / total * 100)
    print(tag, ":", n, "students ->", percent, "%")

Tracing this by hand confirms the arithmetic before trusting the output: counts.get(r, 0) + 1 simply increments a running total each time a tag appears in the list, so after the loop, counts holds {"portion": 8, "taste": 5, "not_hungry": 4, "other": 3} — matching the 20-item list exactly (8 + 5 + 4 + 3 = 20). For percentages: 8 ÷ 20 = 0.40 → 40%, 5 ÷ 20 = 0.25 → 25%, 4 ÷ 20 = 0.20 → 20%, and 3 ÷ 20 = 0.15 → 15%. Adding those four percentages — 40 + 25 + 20 + 15 — gives exactly 100%, which is a useful sanity check: if your percentages from a coded interview dataset don't sum to 100%, either a response was left untagged or a tag was counted twice. The printed output, in the order the tags first appear in the list, reads:

portion : 8 students -> 40 %
taste : 5 students -> 25 %
not_hungry : 4 students -> 20 %
other : 3 students -> 15 %

Only now — after planning, conducting, recording, and coding the interviews — does the information become the kind of input a Data Exploration step or a Modelling step in the AI Project Cycle can actually use, for instance to decide that reducing default portion sizes (addressing the 40%) would cut more waste than changing the recipe (addressing the 25%).

The full pipeline, and where structured interviews sit on it

The diagram below shows the five-step journey from a planned conversation to model-ready data, along with how the three interview styles trade consistency for depth.

A misconception worth correcting: "It's just talking, so it doesn't need a plan"

Because an interview looks like an ordinary conversation, many students assume it needs no preparation — you just walk up and start asking things as they occur to you. This is one of the most common reasons student AI/data projects produce unreliable results. Without a written interview guide, an interviewer unconsciously asks different students slightly different questions, in different orders, sometimes with a different tone — and each of those small variations can change the answer. Ask one student "What's wrong with the canteen food?" (which primes them to complain) and another "What do you think of the canteen food overall?" (which is neutral), and you will get systematically different answers that have nothing to do with what the students actually believe — only with how the question was phrased. A real interview, even a very informal-sounding one, is built on a written guide prepared beforehand: a fixed core of neutral questions, decided before the first conversation, so that differences in the answers reflect real differences in opinion rather than accidental differences in how the question was asked. This is also why an interviewer must watch out for two kinds of bias at once: interviewer bias (the interviewer's tone or wording nudges the answer) and social desirability bias (the respondent gives the answer they think will please the interviewer rather than their honest opinion — for instance, telling a teacher conducting the interview that they "love" the vegetables).

A second misconception: "More questions always means better data"

It is tempting to think that a 30-question interview must produce more useful data than a 6-question one. In practice, long interviews suffer from respondent fatigue — after the first several minutes, people start giving shorter, less thoughtful answers just to finish, which quietly lowers the quality of exactly the data collected later in the interview. A well-designed interview guide favors a small number of carefully chosen, non-overlapping questions — enough to cover the 4Ws (who, what, where, why) of the problem — over a long list that exhausts the respondent's attention. Quality of questions, not quantity, is what makes interview data trustworthy.

Worked example: fixing a flawed interview guide

Suppose a first draft of the canteen interview guide contains this single question: "Don't you agree that the food is too oily and the queue takes forever?" Read carefully, this one line contains three separate problems covered above: it is a leading question (starts with "don't you agree," nudging the respondent toward "yes"), it is double-barreled (bundles "oily food" and "slow queue" into one answer), and it is entirely closed with no room for a reason. A corrected version splits it into two neutral, semi-structured questions: "What do you think of the food's taste and texture — is there anything you'd change?" and, separately, "How do you find the time it takes to get through the lunch line?" Each now measures one thing, invites a reason rather than just agreement, and can be followed up with "why?" — turning one broken question into two usable ones.

Practice: check your understanding

• A researcher interviews 25 shopkeepers about why they don't accept UPI payments, asking each the identical fixed list of questions in the identical order, with no follow-ups. Which type of interview is this, and name one thing this approach sacrifices compared to a semi-structured interview?
• Rewrite this flawed interview question so it is neutral and not double-barreled: "Isn't the new app confusing and slow to load?"
• A team interviews 40 auto-rickshaw drivers (out of roughly 2,000 in a city) about barriers to using a navigation app, and all 40 happen to be drivers the researcher already knew personally. What is this sampling mistake called, and why might it distort the results?
• After coding 50 interview responses about why people stopped using a bus app, a student gets these tag counts: slow_app: 18, no_signal: 14, confusing_ui: 10, other: 8. Calculate the percentage for each tag, and check that your four percentages sum to 100%.
• Explain, in your own words, why an AI model cannot directly use a sentence like "the app kept crashing when I tried to book a ticket," and name the specific step in the pipeline that solves this.

Answer notes: (1) this is a structured interview; it sacrifices the ability to probe unexpected reasons with follow-up questions. (2) A fixed version splits it into two, e.g. "How do you find the new app's layout?" and "How do you find its loading speed?" — both dropping the leading "isn't." (3) This is a convenience sample; because all 40 drivers already knew the researcher, their answers may not represent drivers who are less familiar or less comfortable with the researcher, skewing the results. (4) 18/50 = 36%, 14/50 = 28%, 10/50 = 20%, 8/50 = 16%; these sum to 36 + 28 + 20 + 16 = 100%. (5) A model needs structured, comparable input such as numbers or categories, not free-form sentences; the coding/tagging step converts each response into a category so responses can be counted and compared.

Think About It

Think about this: How would you explain interviews to a friend who has never seen a computer? What real-world analogy would you use? Imagine you had to build a system using these concepts — what would be your first step? Try this: before moving on, write down three things you learned and one question you still have.

Key Takeaways — Summary and Recap

Let us recap what we covered: the core ideas behind interviews, how they connect to real-world applications, and why they matter for your journey in computer science. Remember these key points as you move forward. For competitive exam preparation (CBSE, JEE, BITSAT), focus on understanding the WHY behind each concept, not just the WHAT.