LLM Foundations · 60 to 90 minutes
Correct common LLM assumptions
Explain why a context window is not a word count, why a model does not remember earlier chats on its own, and why temperature zero does not make an answer true.
1.5 h
Overview
Explain an LLM-powered feature the way a technical screen expects: tokens, generation, context limits, training versus inference, and hallucinations, each with a concrete example.
Study time: 60 to 90 minutes
Interview format: Conceptual technical screen
By the end you can
- Explain how a model generates text one token at a time
- Explain why token counts differ from word counts and between tokenizers
- Budget a request's context, including the output reserve
- Distinguish pretraining, inference, in-context learning, and fine-tuning
- Explain why low temperature does not make an answer correct, and how to verify one
Prerequisites
Helpful background: Basic software development knowledge is enough.
What a language model does
A language model assigns probabilities to sequences of tokens. A typical autoregressive text model generates a response by predicting a next token, appending it to the sequence, and repeating. The prompt and previously generated output influence each step. This mechanism can support summarization, translation, classification, extraction, and code generation.
A plausible continuation can still contain an incorrect statement. Fluency and factual accuracy need separate assessment. An application should verify outputs according to the consequences of an error.
Tokens and tokenization
A tokenizer maps text into token IDs. A token may represent a word, a word fragment, punctuation, or another text unit. Token boundaries depend on the tokenizer. The same sentence may have different token counts across models. Code, identifiers, non-English text, and unusual strings can have very different token densities.
For example, customerAccountId may be split into several pieces. Counting characters or whitespace-separated words cannot establish its exact token count. Use the tokenizer associated with the selected model, or the provider's supported counting mechanism. Special message delimiters and tool definitions may also contribute to request size.
Tokens matter because they affect request limits, generation length, latency, and often billing. A model with a larger context allowance still has finite limits.
Context windows and conversation history
The context window is the amount of tokenized information a model can process for a request under its documented accounting rules. Inputs can include instructions, user messages, prior turns, retrieved text, and tool results. Output also consumes capacity in many model interfaces. Separate output limits may apply.
A simplified teaching model uses input tokens + reserved output tokens <= context capacity. Actual APIs may account for reasoning tokens and other content differently. Always check the model's rules before implementing this calculation.
Conversation history usually reaches the model because the application or service supplies it. A model call does not inherently remember every earlier conversation. Trimming or summarizing history changes what information is available for the answer.
Training, inference, and adaptation
| Term | Meaning | Example |
|---|---|---|
| Pretraining | Learning model parameters from a large training corpus | Learning patterns in language and code |
| Post-training | Additional training that shapes task behavior or preferences | Improving instruction following |
| Inference | Using learned parameters to produce outputs | Answering a user request |
| In-context learning | Adapting behavior from examples inside the request | Following two examples of a desired answer style |
| Fine-tuning | Updating parameters using additional training data | Adapting a model to a consistent task |
Providing a document in a prompt does not ordinarily update the model's weights. Provider data retention and training policies are separate service-level questions.
Transformer intuition
Many contemporary LLMs use transformer architectures. Attention lets a representation incorporate information from other tokens according to learned relationships. Positional information helps distinguish order. In causal generation, a token can attend to earlier positions without reading future generated tokens.
At this difficulty, explain the purpose of attention and ordering. Deriving attention equations or implementing a transformer belongs in deeper model study.
Instructions and messages
Chat systems commonly expose message roles to distinguish application instructions, user requests, and model responses. Exact roles and precedence are interface-specific. A chat template translates structured messages into the model's expected representation.
A request might instruct the assistant to summarize a supplied paragraph in three bullets. The paragraph is task data. Clear separation helps communicate intent, but instructions alone do not provide a reliable security boundary.
Hallucinations and uncertainty
A hallucination is generated content that is fabricated, unsupported, or inconsistent with relevant evidence. A model might invent a book title, a citation, or a configuration option. Missing information, ambiguous requests, and misleading context can contribute.
Useful responses include supplying relevant evidence, checking citations against that evidence, validating fields, and allowing the application to report insufficient information. Asking the model whether it is certain cannot independently verify an answer. A confident tone is not a calibrated probability of correctness.
Generation settings
An output limit bounds generation. Sampling settings influence which token is chosen from a distribution. Lower temperature generally concentrates sampling toward more probable choices when sampling is enabled. Higher temperature can increase variation. Neither setting establishes factual truth. Supported parameters and their interactions vary by model.
A short output can result from a limit, a stop condition, or a deliberately concise response. Inspect termination information before deciding which explanation applies.
Worked example: a context budget
Predict the outcome
Worked example: a context budget
A fictional model has an 8,000-token context capacity. Use the simplified rule input tokens + reserved output tokens <= capacity. For each request, work out the total and whether it fits before you reveal the answers.
| Request | Parts (tokens) | Total | Fits? |
|---|---|---|---|
| Original document | 500 instructions, 1,500 history, 4,000 document, 200 question, 1,000 output reserve | ? | ? |
| Document grows | Same, but the document is 5,500 | ? | ? |
Completion checklist
- Explain generation without implying that every statement is retrieved from a database.
- Distinguish tokens, context, output limits, and persistent application state.
- Work the context budget without looking at the answer.
- Explain one invented-citation failure and the check that would catch it.
- Answer the canonical question in two minutes.
Sources
- Hugging Face text generation guide Generation terminology and settings.
- Anthropic: effective context engineering for AI agents Selecting and summarizing what goes into the context.
The examples, budget figures, questions, and rubric are original synthetic teaching material. Study times and readiness thresholds are editorial estimates. Token accounting differs between providers, so check the selected model's documentation before relying on any formula here.
Related on CodeSnatch
Lessons, problems, and articles that build the skills this question uses.
Community article
Counts tokens in prose and code with a real tokenizer and shows why each chat turn resends its history.
System Design
Explains stateless servers that keep no memory between requests, a useful model for how each LLM call gets its context.
AI Engineering
Shows how supplied documents become evidence for an answer, the usual remedy for confident but unsupported text.
AI Engineering
Builds on the training and inference terms here to decide when prompting, retrieval, or fine-tuning fits a failure.
Practice problem
Practice treating model output as untrusted text and checking each field before the application relies on it.
Practice the interview question
Answer it in your own words before you look at the reference answer.
