AI Interview Questions and Answers

AI is the broad goal of making machines perform tasks that normally need human intelligence. Machine learning is one way to get there: instead of writing every rule by hand, the system learns patterns from data.

Deep learning is a subset of machine learning that uses neural networks with many layers. It powers modern image recognition, speech and large language models.

Supervised learning trains on labelled examples, such as emails marked spam or not spam, and learns to predict the label for new inputs.

Unsupervised learning finds structure in unlabelled data, for example clustering customers into segments.

Reinforcement learning trains an agent by trial and error: it takes actions in an environment and learns from rewards and penalties.

Overfitting happens when a model memorises the training data, including its noise, so it scores well in training but poorly on new data.

You prevent it with more or better data, regularisation (such as L2 or dropout), simpler models, early stopping, and by always checking performance on a separate validation set.

Bias is error from overly simple assumptions, which leads to underfitting. Variance is error from being too sensitive to the training data, which leads to overfitting.

Making a model more complex usually lowers bias but raises variance. The goal is the balance that gives the lowest error on unseen data.

Accuracy is misleading when classes are imbalanced. If 1% of transactions are fraud, a model that always says 'not fraud' is 99% accurate and useless.

Use precision when false positives are costly, such as flagging legitimate payments. Use recall when false negatives are costly, such as missing a disease. F1 is the harmonic mean of the two and is useful when you need a balance.

The training set fits the model. The validation set is used to tune choices such as hyperparameters and prompts. The test set is kept untouched until the end to give an honest estimate of real-world performance.

If you tune on the test set, its score stops being a fair measure because you have indirectly fitted to it.

An LLM is a transformer trained on huge amounts of text to predict the next token. At generation time it repeatedly predicts a probability distribution over the next token, picks one, appends it and repeats.

Settings such as temperature control how the next token is chosen: low temperature picks the most likely tokens, higher temperature allows more variety.

Tokens are the chunks of text a model reads and writes, often parts of words. The context window is the maximum number of tokens the model can handle in one request, counting both the input and the output.

They matter for cost (APIs bill per token), latency, and design: long documents may not fit, so you need retrieval, summarisation or chunking.

Self-attention lets every token look at every other token in the sequence and decide how much each one matters for its own meaning. For example, in 'the trophy didn't fit in the suitcase because it was too big', attention helps link 'it' to 'trophy'.

Because attention is computed in parallel rather than word by word, transformers train efficiently on very large datasets.

Clear, specific instructions with context about the goal and audience; a defined output format; few-shot examples when the pattern is hard to describe; delimiters such as XML tags to separate instructions from data; and asking the model to reason step by step on complex problems.

For production, I keep prompts in version control and test changes against a fixed set of example inputs rather than judging from a single try.

A hallucination is when the model states something false or unsupported with confidence.

To reduce them: ground the model in source documents (RAG), tell it to answer only from the provided context and to say when it doesn't know, ask for citations, lower the temperature for factual tasks, and add automated checks or human review for high-stakes output.

Start with prompting because it is cheapest and fastest to change. Add RAG when the model needs knowledge it lacks, especially private or frequently changing information.

Fine-tune when you need consistent behaviour that prompting can't reliably achieve, such as a strict output style, a specialised classification task at scale, or a smaller, cheaper model that matches a larger one on a narrow task.

RAG retrieves relevant pieces of your own documents and adds them to the prompt so the model answers from that context.

It lets the model use private or up-to-date knowledge without retraining, and makes answers easier to verify because you can cite the sources.

Ingestion: load documents, clean them, split them into chunks, create embeddings and store them in a vector database with metadata.

Query time: embed the user's question, retrieve the most similar chunks (often with hybrid keyword and vector search plus a reranker), build a prompt with those chunks and generate the answer, ideally with citations.

Chunks that are too small lose the context needed to answer; chunks that are too large dilute relevance and waste the context window. A few hundred tokens with a small overlap is a common starting point.

The right answer comes from testing: build a set of real questions, try different chunk sizes and splitting strategies (by headings or paragraphs instead of fixed length), and measure retrieval quality.

Hybrid search combines keyword search such as BM25, which is good at exact terms like product codes and names, with vector search, which is good at meaning. Results are merged, for example with reciprocal rank fusion.

A reranker is a slower but more accurate model that re-scores the top candidates against the query, so the best chunks reach the prompt.

Evaluate retrieval and generation separately. For retrieval, measure whether the right chunks appear in the top results (recall@k, MRR). For generation, check faithfulness (is the answer supported by the retrieved context?), relevance and correctness.

Use a test set of real questions with expected answers or sources, and combine automated LLM-as-judge scoring with human spot checks.

First look at what was retrieved for the failing questions. If the right information was never retrieved, fix ingestion and retrieval: parsing, chunking, embeddings, filters or search settings.

If the right chunks were retrieved but the answer is still wrong, fix the generation step: the prompt, the order and amount of context, or the model choice.

A chatbot answers in one turn. An agent works toward a goal over several steps: the model decides which tool to call, the application runs it, the result goes back to the model, and the loop continues until the task is done.

Agents can search, read files, call APIs or write code, which makes them more capable but also harder to control and test.

You describe each tool to the model with a name, a description and a JSON schema for its parameters. When the model wants to use one, it returns a structured tool call with arguments.

Your application validates the arguments, runs the function and sends the result back to the model. The model never executes anything itself, which is where you add permission checks and logging.

When the steps are known in advance. A fixed workflow, such as extract then summarise then classify, is cheaper, faster, easier to test and more predictable than letting a model decide each step.

Use an agent when the path genuinely depends on what the model discovers along the way, such as open-ended research or multi-step troubleshooting.

Short-term memory is the conversation and tool results in the current context window. Long-term memory is information saved to an external store, such as a database or vector index, and retrieved when relevant.

Long runs also need context management, such as summarising or dropping old tool output, so the context window doesn't fill up.

Give tools the least privilege they need, validate every tool argument, require human approval for irreversible or high-impact actions such as payments or sending email, and set limits on steps, time and cost.

Treat content from web pages, emails and documents as untrusted data to defend against prompt injection, and trace every step so failures can be investigated.

Common choices are LangChain for building blocks, LangGraph for stateful agent workflows modelled as graphs, and provider SDKs that support tool calling directly. The Model Context Protocol (MCP) is an open standard for connecting AI applications to tools and data sources.

Be ready to explain why you picked one: for example, LangGraph when you need explicit control over loops, branching and human-in-the-loop checkpoints.

Build an evaluation set of realistic inputs with expected outputs or grading criteria. Score outputs with code-based checks where possible (format, exact match), an LLM-as-judge with a clear rubric for open-ended answers, and regular human review.

Run the evaluation on every prompt or model change so you catch regressions before users do.

Use the smallest model that meets the quality bar, route easy requests to cheaper models, shorten prompts, use prompt caching for repeated context, cache full responses where appropriate, and stream output so users see text sooner.

Batch non-urgent work, and measure token usage per feature so you know where the money goes.

Prompt injection is when untrusted text, such as a web page, email or user input, contains instructions that try to override your application's instructions.

Defences include clearly separating instructions from data, never giving the model more permissions than the task needs, requiring confirmation for sensitive actions, filtering inputs and outputs, and monitoring for unusual behaviour. No single defence is complete, so layer them.

Latency, error rates, token usage and cost; quality signals such as user feedback, thumbs up or down, and sampled human review; and safety signals such as refusals and flagged content.

Tracing tools such as LangSmith or Langfuse record each step and tool call, which makes it possible to debug individual bad answers.

Check training and evaluation data for gaps in who and what is represented, test outputs across different user groups, and measure whether error rates differ between them.

Keep humans in the loop for decisions that affect people's lives, document known limitations, and give users a way to report problems.

Use a clear structure: the problem and who it was for, your approach and why you chose it, the technical challenges, how you measured success, and what you would do differently.

Give numbers where you can, for example 'retrieval recall went from 60% to 85% after switching to heading-based chunking and adding a reranker'.

Name specific habits: following model release notes and documentation from major providers, reading a few trusted newsletters or papers, and, most importantly, building small experiments with new techniques.

Interviewers want to hear that you test new ideas yourself rather than only reading headlines.

Pick a real example and use the STAR format: situation, task, action, result. Focus on how you diagnosed the issue, for example by looking at traces or building a small evaluation set, and what you changed.

End with what you learned and how you now prevent similar problems.

Start from the business outcome, use a simple analogy (RAG is like giving the model an open-book exam with the right pages bookmarked), avoid jargon, and be honest about limitations and risks.

Offer to show a short demo, because seeing the system work is often clearer than any explanation.