Active listening: five mistakes in a tech job interview

You know the subject, start answering and realise halfway through that the interviewer asked something slightly different. You keep going because stopping your own explanation feels even worse. A few minutes later, the conversation contains plenty of SQL, some Excel and very little of the answer the other person actually needed. That can make an interview harder even when you prepared reasonably well.

I also treat a data analyst interview as a small sample of working together. Can you establish what someone needs? Can you explain your decisions? When a task becomes difficult, can you distinguish missing knowledge from missing information? I would practise those behaviours alongside technical skills. They become useful again when someone asks you to build a report with an unclear definition of success.

The five mistakes below are my way of organising communication problems. They do not provide a reliable diagnosis of every rejected application. Role requirements, technical ability, other candidates and the quality of the recruitment process can all affect the outcome. What I can work on is making the skills I already have easier for another person to understand and assess.

1. You talk about the subject while missing the question

For me, active listening starts with recognising the kind of answer a question requires. A question about choosing a tool calls for a decision and its reasoning. A question about a function calls for an explanation of its behaviour. A question about your project calls for your contribution. All three can concern the same report while requiring quite different responses.

Consider a practice scenario. The interviewer asks why you prepared a report in Excel. You describe pivot tables, charts and conditional formatting. Those details may be accurate, but they still leave the choice unexplained. I would start with the constraints: who used the file, how often they updated it and which tools they already had available. Features become relevant when they explain how the choice met those needs.

A possible answer is: “I chose Excel because the recipient needed to filter a small dataset independently and already worked with those files. I would revisit the decision if refresh frequency or the number of users increased.” This is a synthetic example, rather than a story about one of my clients. It demonstrates a decision, a reason and a limit without requiring a tour of every feature.

When a question is broad, I check the scope. “Would you like the business reason or the data preparation steps?” can prevent several minutes of talking past each other. There is no need to ask a clarifying question after every sentence. I use one when different interpretations would produce materially different answers. Then I follow the clarification instead of returning to the speech I had already prepared.

A practical way to check your listening

When practising with someone, ask them to write down a question and one sentence describing what the answer should address. Respond without seeing their sentence. Afterwards, compare the answer with that intended focus. This makes the exercise more concrete than asking whether you sounded professional. You can see whether the conversation reached the actual decision, problem or explanation your listener was looking for.

It also helps to notice words that trigger your autopilot. You hear “Python” and immediately list libraries, although the question concerned agreeing requirements. You hear “conflict” and begin describing a former manager, although the interviewer asked about your response. Catching that reflex gives you a chance to return to the question before the answer becomes a catalogue of unrelated expertise.

2. The context takes over your answer

A long answer can be appropriate. Some technical questions require several assumptions and a careful explanation. The problem appears when the listener cannot tell which part is background, which part describes your decision and which part explains the result. After hearing how every folder was organised, they may still have no idea what you were responsible for or why your approach made sense.

I try to give the main answer first, an example second and extra context afterwards. If someone asks about the hardest part of a project, I name that difficulty before explaining how the team reached it. This gives the listener a clear point of reference. They can then ask for the details they need instead of remembering every department name in the hope that it becomes relevant later.

For a question about a specific past event, the STAR method described by the National Careers Service provides a useful structure: situation, task, action and result. I use it to check that the important pieces are present. I do not need to announce those labels or deliver a memorised script. My actions and the reasons behind them deserve most of the attention.

In a synthetic reporting example, one sentence can establish that two teams counted orders differently. My task would be to identify the source of the discrepancy. The action would involve comparing definitions and checking boundary cases. The result could be an agreed definition, even if the report still needed changes. There is no need to invent a time saving that nobody measured to make the example useful.

Knowing when to stop

Once the decision and example are clear, I can stop talking. A short pause gives the interviewer room to continue. I avoid treating silence as proof that my answer was too short. If useful, I can offer to explain the data checks in more detail. The other person gets a choice, and I avoid adding unrelated material merely to fill the space between questions.

I would not impose one time limit on every answer. A definition and a project discussion need different amounts of explanation. During practice, I look for passages I could remove without losing the point. Those are usually good candidates for shortening. When a technical detail changes the interpretation or the result, I keep it and explain why it matters to the decision.

3. You adapt your language by judging the listener

A conversation with HR, a future manager and a technical specialist may need different levels of detail. Their job titles alone do not tell me what each person understands. Assuming someone will struggle can produce a patronising explanation of things they never asked about. I prefer to establish the useful level of the conversation instead of assigning the other person a level of competence.

Rather than announcing that a subject is complicated and needs simplifying, I can suggest starting with its effect on the report and then explaining the technical mechanism. That offers a sequence the listener can accept or change. For a data analyst, a useful explanation should also help someone make a decision. A long list of tools rarely tells them whether the figures can be trusted or when a correction will be available.

Here is another practice scenario. Two teams report different customer totals. With the person responsible for sales, I explain that one report includes customers without an active order. With the person maintaining the report, I also explain where the definition is recorded and how to compare the two versions. The underlying problem stays the same. The details change according to the next action each person needs to take.

I also avoid correcting vocabulary simply to demonstrate expertise. If someone calls a report a spreadsheet, I can still discuss their requirements accurately. When a distinction affects the task, I introduce it calmly. Showing that I know a more specialised word does not answer a question about delivery, data quality or scope. Respect becomes visible in how I collaborate when people bring different kinds of knowledge.

4. You describe the task without showing your contribution

“I was told to do it” can accurately explain how a task started. The next question is what you did after receiving it. Did you check the input? Notice an ambiguity? Ask who would use the output? Someone applying for an early career role does not need to have designed the entire architecture. They can still describe their actual responsibility and the limits of their independence.

I separate team decisions from my own work. “The team chose the tool. I prepared the input and compared the result with the previous report” gives the interviewer a clear place to ask a follow-up question. A broad statement such as “we delivered a dashboard” leaves them wondering whether you built it, tested it or attended the presentation after somebody else had finished it.

That distinction also protects against claiming another person’s results. If several people worked on the project, say so. If a manager proposed the approach, explain how you implemented your part and which decisions remained yours. When you lack a measured numerical result, identify an observable outcome: a definition was agreed, a limitation documented or a discrepancy resolved. A modest, accurate account is easier to discuss in depth.

Engagement does not have to look theatrical. It can mean noticing a problem, checking it and giving the finding to the person who could decide what to do. Nobody needs a childhood dream of organising exports. What matters in your answer is whether you thought about the quality of your work and recognised when a decision needed another person’s knowledge or authority.

5. A difficult task makes you stop or start guessing

An unfamiliar task can trigger two unhelpful reactions. One is an immediate “I don’t know” followed by silence. The other is a confident stream of guesses. I prefer to name the precise limit of my knowledge. “I do not remember that function’s syntax, but I understand the expected output” opens a more useful discussion than treating the whole task as either solved or impossible.

Next, I propose a first step. I might clarify the required level of detail, sketch a tiny input dataset or identify the documentation I would consult. If reference materials are not allowed during the interview, I respect that rule and make my assumptions explicit. I avoid presenting unverified syntax as a finished solution. Reasoning about a problem and knowing how to implement it are separate things the interviewer may need to assess.

Imagine a synthetic task in which a report’s total increases after two tables are joined. My first hypothesis would concern repeated keys and the number of rows before and after the join. I could explain how I would investigate that before knowing the exact implementation in the team’s tool. The answer shows a relevant hypothesis, a way to check it and the boundary of what I currently know.

Persistence has limits as well. Once reasonable approaches are exhausted, I can ask for a hint or suggest moving on. Repeating the same attempt adds little information. An honestly identified skills gap may mean the role needs more preparation. Clear communication helps an interviewer assess your thinking; it cannot replace the knowledge required for independent work or guarantee a positive hiring decision.

What an interview can assess

OPM describes structured interviews as a way to assess job-related competencies through questions about past behaviour or hypothetical situations. I find that a useful reference point: questions should relate to the role. I do not assume every company uses the same process, criteria or standard of evaluation. A single interview gives me only a partial view of the organisation’s decisions.

That is why I avoid reading hidden intentions into every gesture. An interviewer may take notes because they need notes. They may ask for a shorter answer because time is running out. If I do not understand a request, I can check its meaning instead of building a story about failure. Afterwards, I separate what was actually said from my interpretation of the exchange.

Preparation also includes ordinary practical work. The National Careers Service recommends reading the role description, researching the organisation and preparing examples. I then check which examples demonstrate the requirements of this particular job. A story that shows independence may answer a teamwork question poorly. I choose the example for the question instead of forcing my favourite project into every response.

Return to the question after drifting away

Sometimes I notice the problem halfway through my answer. I can stop the detour and say: “I started with implementation details, but you asked about the reason for the choice. The main constraint was the tool available to the recipient.” That brings the conversation back to its purpose without requiring a lengthy explanation of the mistake itself. It also shows that I can recognise when my answer has drifted away from another person’s need.

When the interviewer interrupts, I listen to the new question instead of insisting on my prepared ending. They may be identifying the missing detail. If I am describing a report and they ask who checked its accuracy, the next useful step is explaining responsibility for checking. Returning to chart design would move away from the part of the work they want to assess.

I take the same approach to correcting an imprecise claim. If I described a project as independent but someone approved my decisions, I clarify the boundary: “I prepared the file myself; my manager approved the metric definition.” It is easier to make that distinction immediately than build later answers on a misleading shortcut. The interviewer can then assess the actual degree of responsibility involved.

Afterwards, I choose one such moment to examine. I record the question, my response and the missing element. I avoid turning it into a theory about my character or a certain explanation for rejection. Instead, I prepare a clearer version for the next opportunity. When asking somebody for help, that specific exchange gives them more useful material than a general request to judge whether I am good at interviews.

Practise one conversation and three corrections

Choose a project you can describe honestly. It may come from employment, study or volunteering, provided you name that context. Ask another person to pose three questions: why you chose the approach, what you owned and how you responded to a problem. Leave room for follow-up questions. Those often reveal where an answer depends on assumptions the listener cannot yet see.

Afterwards, make a brief note against each question. Did you answer it directly? Was your individual contribution clear? Did you separate the result from your assumptions? If you record yourself for private practice, use fictional or anonymised details. Confidential information from an employer is unnecessary for improving communication. You can preserve the mechanism of the problem while removing customer names and sensitive figures.

On the next attempt, change one thing, such as starting with the decision rather than the department’s history. Check whether your partner finds the answer easier to follow. Changing everything at once makes it difficult to identify what helped. The purpose is to gain control over your explanation while keeping room for a real conversation. A memorised speech can make that harder.

For help with the content of your answers, continue with nine interview questions. If you are still planning the move into a new role, start with four elements of a career change. In your next interview, choose one habit to apply deliberately: listen to the whole question, address its central point and give the other person room to take the conversation forward.