9 interview questions: how to prepare your answers

You can know the technology and still struggle when an interviewer asks you to describe a project. You start with the company, explain the department, mention several tools and suddenly run out of time. The other person still does not know what you actually contributed. I treat preparation for these questions as seriously as organising the technical side of my experience. Both help someone assess the work I can do.

I have chosen nine questions that help prepare examples about decisions, collaboration and development. They are not a guaranteed interview script or a test that determines whether you get hired. Employers may assess different competencies, and the same wording can serve different purposes across roles. I want to prepare useful material while remaining attentive to the particular question that someone actually asks during the conversation.

All sample statements below are synthetic practice material. They do not describe my clients or people I hired. Use them to examine the structure of your own answer. The scale, details and results must come from your actual experience or an accurately identified exercise. A borrowed story becomes uncomfortable quickly when another person asks how the work was done, what changed and which decisions belonged to you.

1. Why are you changing jobs?

I build this answer from three parts: what I do now, what I want to do more often and why the proposed role fits that direction. It is reasonable to say that the current responsibilities no longer match your plans. Your career does not need to form a perfect line from the first day of university. Explain today’s decision clearly enough that the interviewer understands what you seek and what you bring.

For example: “Alongside order administration, I prepared reports for the team. I want data work to become a larger part of my responsibilities, so I am looking for a reporting role. This vacancy interested me because it combines analysis with conversations with the people using the output.” The interviewer can then ask about a specific report, your independence or the questions the report was intended to answer.

Pay or a difficult workplace can also be real reasons for moving. I would describe conditions factually rather than judge a former manager’s character. If the duties differed from what was agreed, I can name the mismatch without recounting the entire conflict. A useful preparation question is whether my answer makes the conditions I want in the next role understandable, rather than merely explaining why I want to leave.

2. What was the hardest part of your previous job?

I choose a situation where I can explain both the difficulty and my response. Unclear definitions, changing priorities or unavailable data may provide useful examples. Saying that I worked under pressure leaves too much unexplained. I want to describe what the pressure involved, which decisions were mine and what I did to move the task forward. If part of the problem remained unresolved, I say that too.

For example: “Two teams wanted orders counted differently. I collected a few examples and asked the report owner to choose a definition. Until the decision was made, I documented the difference so users understood why the figures disagreed.” The outcome here concerns clarity and responsibility. There is no need to add an unmeasured productivity improvement to make the contribution worth discussing.

Prepare for follow-up questions about your limits. What could you not decide alone? Who had to approve a change? What would you approach differently next time? A story in which one candidate resolves every organisational conflict may sound impressive, but a clear account of working within real responsibilities is more useful. It gives the interviewer a realistic view of the support and independence involved in your work.

3. What are your strengths?

I start with a behaviour relevant to the role and add evidence. Instead of only calling myself accurate, I explain how I check a result. Instead of claiming good communication, I describe agreeing a requirement. One well-supported skill can communicate more than ten attractive qualities without examples. The role matters here: maintaining established reports and frequently interviewing stakeholders may require different evidence from the same person’s experience.

For example: “I am good at making a reporting request more precise. Before preparing data, I establish who needs the output, how the metric is defined and which decision it supports. In a practice project, I documented those choices so someone reviewing the report could follow the counting method.” Naming the practice context avoids implying commercial experience the candidate does not actually have.

Be ready to explain a detail. You might be asked for the definition, an exception or a change made after feedback. If you cannot supply one, another strength may be a better choice, or you may need to revisit the work before the interview. The answer should survive a calm discussion of facts. It does not need to sound like the slogan at the top of a motivational poster.

4. What are your weaknesses?

I name a real limitation and explain what I am doing about it. A disguised compliment about caring too much about quality tells the listener little. If estimating work is difficult, I explain how I break tasks down and communicate a revised date. If I am still learning a tool, I describe the level. I avoid choosing a weakness solely because it can be turned into an attractive story.

For example: “I used to accept too many tasks at once and flag deadline conflicts late. Now I check priority with the person responsible for the scope before accepting additional work. I am still improving how early I recognise that a commitment is at risk.” This leaves room for questions about a specific behaviour change and the parts that remain difficult.

A gap in a core requirement needs serious attention. If the role requires independent SQL work, lacking that skill does not disappear through a polished answer. Establish the expected level rather than hide the mismatch. The interview should help both parties assess whether the arrangement works. You can ask which onboarding support exists, without assuming the employer will provide training in every foundation the position requires.

5. Tell me about something that went wrong

A useful answer makes the mistake, its effect and the subsequent change understandable. I separate my contribution from conditions outside my control. If I made the error, I say so. If the issue involved several people, I explain my part without taking responsibility for everything. Either way, the listener needs to know what happened to the output and how the relevant people were informed.

For example: “In a practice project, I joined tables without checking repeated keys. The result contained more rows than expected. Before presenting the report, I compared the inputs and corrected the join. I then added a row-count check to the project description.” This small example identifies when the problem was caught and what changed. It does not need a fictional crisis at a large employer.

Prepare to explain how you knew the correction was sufficient. A general promise to pay more attention is difficult to assess. A concrete check gives the interviewer something to examine in your reasoning. Confidentiality matters too. You can describe an error’s mechanism without customer names, internal documents or actual sensitive figures. An interview does not require handing over a former employer’s material to make the example convincing.

6. How do you handle unclear requirements?

I begin with the decision the analysis should support. Then I check the audience, definitions, time period and acceptance criteria. A large document is unnecessary for every small task. A short note with examples may be enough. What matters is giving the recipient a chance to confirm my understanding before I spend several days building an answer to a question they did not intend to ask.

For example: “When somebody requests a report of active customers, I ask what active means and which decision the report should support. I show a few cases that could be counted differently. I record the agreement before preparing the first version.” This describes an approach without promising that every ambiguity will disappear after one conversation. Further questions can still arise when the data is examined.

The response to missing answers matters as well. I can identify which work can proceed on confirmed assumptions and which part needs a decision. If the deadline is close, I explain how the unresolved definition affects the scope. Silence should not automatically become approval for whichever interpretation I prefer. A follow-up question may concern who approves requirements and how a later change is communicated to people using the report.

7. How would you explain this to a non-technical person?

First I establish what the person needs to do after the explanation. Explaining delayed data to someone making a sales decision may require different detail from explaining it to someone scheduling team work. I avoid starting with a judgement about what they can understand. I describe the effect and add the mechanism where it helps clarify a decision, a limitation or a delivery date.

For example: “The report shows yesterday’s position because new data arrives after overnight processing. Today’s decision needs to take that date into account. If you need the current position, we should establish whether an available source provides it.” The listener learns what the output represents and what could happen next. They do not need to know every technical processing step to understand those consequences.

Afterwards, I check whether the explanation addressed the need rather than turn the conversation into a test of the listener’s knowledge. I can ask whether they need the effect on a particular measure explained. When using an analogy, I acknowledge its limits if it begins to oversimplify the issue. Clear communication sometimes requires naming a real data limitation that a neat comparison cannot adequately describe.

8. Which technologies do you like using?

I connect the preference to a task and my actual level of independence. Liking SQL for working with tables still leaves the question of which operations I can perform. I avoid making the answer a debate about one product’s superiority. When the vacancy uses a different environment, I investigate its importance to the role and accurately name any lack of experience rather than promise immediate mastery.

For example: “I am most confident preparing reports in Excel. In SQL, I practise retrieving and joining data, but I have not maintained a production database. I can describe the project and the parts I completed independently.” This helps distinguish using a tool from administering it. It also gives the interviewer a practical starting point for comparing the experience with the position’s responsibilities.

It is useful to explain a limitation of the tool you prefer. When does a file become hard to maintain? When would another team’s help be needed? You do not need to propose replacing the employer’s environment during the first interview. You can show that the choice depends on requirements, availability and how people use the output. A preference becomes something that can be discussed rather than defended as an identity.

9. Where do you see yourself in two or three years?

I do not need to predict a future job title. I prefer to explain a direction: greater independence, responsibility for a particular area or stronger collaboration with users. It helps to connect that direction with the role while leaving room for what I will learn after joining. A categorical promise to remain at the organisation for many years cannot be established from one interview conversation.

For example: “I want to lead small reporting tasks from clarifying the question through checking the result. First I need to learn the team’s data and standards. Later I would like to take responsibility for progressively more complex cases.” The employer can compare this direction with the work available. It does not require pretending that the candidate already knows the whole shape of their future career.

I would also ask how development is recognised in the role and what onboarding involves. The answer helps test whether my expectations match the actual work. If the role mainly maintains existing reports while I want exclusively new projects, discovering that difference before accepting is useful. Presenting myself clearly should still leave room to recognise a mismatch with the day-to-day responsibilities of the position.

When you lack an example from a data analyst job

You do not need to invent earlier analytical employment to discuss problem solving. A task from your current industry may involve comparing reports, clarifying a customer’s needs or improving information flow. Name the context and show the relevant skill. If the question concerns a particular tool, separate that experience from your technical level. Good collaboration in another department does not automatically demonstrate independent SQL work.

For a course project, distinguish the supplied instructions from your own decisions. Perhaps the data and question were provided, while you changed the presentation and examined cases omitted from the exercise. If everything followed the lesson, say so. A small independent variation can then give you something to explain beyond the sequence of steps. It helps the conversation assess your understanding rather than only completion of the lesson.

If no suitable example comes to mind, ask for a moment to think or check whether an example from learning would be appropriate. Avoid turning a question about an actual event into an invented account presented as fact. If a hypothetical response is accepted, clearly identify it and explain your proposed steps. That is a different kind of answer, which can be assessed without confusing intended behaviour with previous experience.

Prepare examples without memorising a performance

For questions about a past event, the STAR method offers situation, task, action and result as a structure. I record a few prompts for each example rather than a complete speech. During the interview, I choose details for the question. Being asked about a technical decision does not require starting with the entire team’s history simply because my notes begin there.

OPM describes behavioural and hypothetical questions as part of assessing job-related competencies. That does not reveal the hidden intention of every interviewer. It does suggest a useful preparation direction: look for evidence of the competencies in the vacancy. Then check whether the examples show your actions, limitations and outcomes rather than only naming projects in which you participated.

The National Careers Service recommends preparing examples and understanding role requirements. In my practice exercise, another person chooses a question and asks about a detail we have not rehearsed. If I cannot answer, I distinguish what I remember from what I cannot confirm. I also check that the answer does not assign the whole team’s achievements to me alone.

Choose two examples to begin: one about work completed well and one about a difficulty. Try using each for different questions, changing the emphasis according to the listener’s need. If answer length or clarification is the problem, return to active listening. If you are still finding a direction for your experience, work through the career transition plan.