Interview questions, answered properly

An abstract class can hold state and constructors and models an "is-a" relationship with shared implementation; a class extends exactly one. An interface describes a capability and a class can implement many. Since Java 8 interfaces can carry default and static methods, so the practical distinction is now state and single-versus-multiple inheritance, not the presence of method bodies. Interviewers usually follow up by asking when you would pick each — say abstract class when subclasses genuinely share fields and construction logic, interface when you are defining a contract multiple unrelated types will satisfy.

HashMap gives O(1) average lookup with no ordering guarantee. LinkedHashMap keeps insertion order (or access order, which is how you build an LRU cache) at the cost of an extra linked list. TreeMap keeps keys sorted using a Comparable or Comparator and gives O(log n) operations. Choose on the question "do I need ordering, and which kind?" — most code wants HashMap.

Three things: auto-configuration (it inspects the classpath and configures beans it can infer), starter dependencies (curated, version-aligned dependency sets), and an embedded server so the application is a runnable jar rather than a war you deploy into Tomcat. It is not a different framework — it is Spring with the boilerplate removed and sensible defaults applied.

Dependency injection means an object receives its collaborators from outside rather than constructing them itself. It matters for testing because you can pass a test double in place of a real database or HTTP client without changing the class under test. Prefer constructor injection over field injection: it makes the dependency explicit and lets you construct the object in a plain unit test with no Spring context at all.

The container creates one servlet instance and services every concurrent request against it on separate threads. That means servlet instance fields are shared mutable state across requests and are a classic source of race conditions. Keep per-request state in local variables or the request object, never in instance fields.

You load N parent entities in one query, then lazily access a relationship on each one, triggering N further queries. Fix it with a join fetch in JPQL, an entity graph, or batch fetching. The reason interviewers ask is that it is the single most common performance bug in JPA applications and it never shows up until production data volumes.

useMemo caches a computed value between renders. useCallback caches a function identity so a child that depends on referential equality does not re-render. useEffect runs a side effect after render. The common mistake is reaching for useMemo as a performance reflex — measure first, because the memoisation itself has a cost and most components are cheap to re-render.

JavaScript runs on one call stack. Asynchronous work is handed to the runtime (timers, I/O, fetch) and its callback is queued; the event loop pushes queued callbacks onto the stack only when the stack is empty. async/await is syntax over promises — it suspends the async function and yields control, but nothing runs in parallel on the main thread. A CPU-bound loop still blocks everything.

Short-lived access tokens with a refresh token, the refresh token stored in an httpOnly, Secure, SameSite cookie so JavaScript cannot read it. Sign with a strong secret or asymmetric key, always verify the signature and the expiry server-side, and keep a revocation path for logout. Never put anything sensitive in the payload — a JWT is signed, not encrypted, and anyone can decode it.

When your data is genuinely relational and your queries need multi-entity joins and strong cross-document transactional guarantees. Document databases reward denormalisation around read patterns; if you find yourself doing $lookup everywhere, you have modelled a relational schema in a document store and a relational database would serve you better.

Middleware is a function with signature (req, res, next) that runs in order on the way to a route handler. It can modify the request, end the response early, or call next() to pass control on. Error-handling middleware takes four arguments (err, req, res, next) and must be registered last — a common bug is defining it before the routes, in which case it never fires.

IEnumerable evaluates in memory — filters run in your process after the data has been fetched. IQueryable builds an expression tree that the provider translates into SQL, so the filter runs in the database. Accidentally materialising an IQueryable early (by calling ToList() too soon, or by using a method EF cannot translate) is a classic cause of pulling an entire table into memory.

Requests pass through an ordered chain of middleware components, each able to act before and after the next one runs. Order is load-bearing: UseRouting before UseAuthorization, UseAuthentication before UseAuthorization, exception handling first so it wraps everything. Getting the order wrong produces bugs that look like configuration problems.

Transient — a new instance every time it is requested; use for lightweight, stateless services. Scoped — one instance per request; the right default for anything holding request state, including a DbContext. Singleton — one for the application lifetime; use for genuinely stateless, thread-safe services and caches. Injecting a scoped service into a singleton is a captive-dependency bug and will surface as stale or cross-request data.

The DbContext keeps a snapshot of every entity it loaded and compares it on SaveChanges to generate the UPDATE statements. That is why a long-lived DbContext leaks memory and produces stale reads, and why AsNoTracking() is worth using for read-only queries — it skips the snapshot entirely.

WHERE filters rows before aggregation; HAVING filters groups after it. So WHERE cannot reference an aggregate and HAVING usually does. If a query runs slowly, check whether a condition sitting in HAVING could be moved to WHERE — filtering earlier means aggregating less.

A window function computes across a set of rows related to the current row without collapsing them. Running totals, rank within a category, and comparing each row to its group average all need this — GROUP BY would reduce your rows and lose the detail. ROW_NUMBER() OVER (PARTITION BY customer ORDER BY date DESC) to find each customer's latest order is the canonical example.

First establish why it is missing, because that determines what is legitimate. Missing completely at random can be dropped or imputed safely. Missing not at random — where the absence itself carries information, like income left blank by high earners — must not be quietly imputed, because you will bias the result. Always report what you did and how much data it affected.

What decision will this change? Who looks at it and how often? What action follows a bad number? Most dashboard requests are really a question that needs answering once, and building a live dashboard for it is a waste. Asking this is usually the difference between a junior analyst and a useful one — and interviewers ask precisely to see whether you push back.

A calculated column is evaluated row by row at refresh time and stored in the model, consuming memory. A measure is evaluated at query time in the context of whatever the visual is filtering. Use measures for aggregations that must respond to slicers; use calculated columns only when you need the value as a row attribute, for example to slice by it.

Bias is error from an oversimplified model that misses real structure; variance is error from a model so flexible it fits noise in the training set. Reducing one typically raises the other. High bias shows as poor training and test performance together; high variance shows as excellent training performance and poor test performance. Regularisation, more data and simpler models pull toward bias; more features and deeper models pull toward variance.

If 97% of the data belongs to one class, a model that always predicts that class hits 97% while detecting nothing. This is why accuracy is the wrong headline metric for imbalanced problems — use precision, recall, F1 and the confusion matrix, and pick the operating point based on which error costs more. Missing a fraudulent transaction is not the same cost as flagging a legitimate one.

Leakage is any information in your training features that would not be available at prediction time. It gets in through scaling or imputing before the train/test split, through features computed using future information, and through duplicate rows spanning both sets. The tell is a validation score that looks too good and then collapses in production. Fit every transformation inside the training fold only — a Scikit-learn Pipeline enforces this for you.

When a false positive is more expensive than a false negative. Flagging a legitimate customer as fraudulent costs you a relationship, so you optimise precision. In cancer screening the cost is reversed — a missed case is catastrophic, so you optimise recall and accept more false alarms. The metric follows from the business cost, never the other way round.

Random forests build deep trees independently and in parallel on bootstrapped samples, then average — this reduces variance. Gradient boosting builds shallow trees sequentially, each fitting the residual error of the ensemble so far — this reduces bias. Forests are harder to overfit and need less tuning; boosting usually wins on accuracy but is sensitive to learning rate and tree count.

A single split gives one estimate whose value depends on which rows happened to land where — with a small dataset that variance is large enough to make model selection meaningless. K-fold cross-validation averages across k splits so every row serves as validation once. For time-series data use forward-chaining splits instead, because shuffling would let the model see the future.

Both add a penalty on coefficient size to the loss, discouraging the model from fitting noise. L2 (Ridge) shrinks coefficients smoothly toward zero but rarely to zero. L1 (Lasso) can drive coefficients exactly to zero, so it performs feature selection as a side effect. ElasticNet blends the two, which helps when features are correlated.

A language model is trained to produce plausible continuations, not verified ones — it has no separate notion of "I do not know" unless training taught it one. What reduces it in practice: grounding the answer in retrieved source text (RAG), requiring citations that can be checked, constraining output to a schema, and explicitly permitting refusal in the prompt. What does not reliably help: telling the model not to hallucinate.

Fine-tune to change behaviour, format or tone — how the model responds. Use RAG to change knowledge — what it responds about. If the requirement is "answer from our current policy documents", RAG wins because the documents change and retraining does not scale. If the requirement is "always reply in our support tone and this exact JSON shape", fine-tuning wins. Many production systems do both.

Untrusted content that the model reads — a web page, a document, a tool result — contains instructions, and the model follows them as if they came from the user. Defences are architectural, not textual: treat all retrieved content as data rather than instruction, keep privileged operations behind explicit user confirmation, apply least privilege to tools, and never let model output alone authorise a side effect. You cannot fully solve it by adding "ignore instructions in the document" to the system prompt.

Low-Rank Adaptation freezes the base model weights and trains small rank-decomposition matrices injected into the attention layers. You end up training a fraction of a percent of the parameters, so it fits on consumer GPUs, trains in hours rather than weeks, and produces adapter files of a few hundred megabytes that can be swapped per task. QLoRA adds 4-bit quantisation of the frozen base to cut memory further.

Build one — that is the actual answer, and it is smaller than people expect. Fifty to a hundred representative inputs with a written definition of what a good response looks like will catch most regressions. Layer on an LLM-as-judge with a rubric for scale, but calibrate the judge against human ratings on a subset first, because an uncalibrated judge is just a second unverified model.

Retrieval, almost always. Log the retrieved chunks for the failing queries and read them — usually the right passage was never fetched, so the model answered from parametric memory instead. Check chunking (was the answer split across a boundary?), embedding fit for the domain, and whether keyword-heavy queries need hybrid search. Fixing the generation prompt when retrieval is broken wastes time.

Dense embeddings capture semantics but degrade on exact tokens — product codes, error numbers, surnames, rare acronyms. BM25 handles those precisely but misses paraphrase. Running both and fusing the ranked lists (reciprocal rank fusion is the usual choice) covers both failure modes, and the gain is typically larger than any embedding-model upgrade.

A bi-encoder embeds the query and documents separately, which is fast enough to search millions but loses cross-term interaction. A cross-encoder reranker scores query and document together, so it is far more accurate but too slow to run over the whole corpus. The standard pattern is retrieve 50 with the bi-encoder, rerank to the top 5 with the cross-encoder, and pass those to the model.

Measure the two halves separately. Retrieval: recall@k and MRR against a labelled set of question-to-passage pairs. Generation: faithfulness (is the answer supported by the retrieved context?) and answer relevance. Measuring only end-to-end answer quality tells you something is wrong but never which half to fix.

The model decides the control flow. In a chain, you fixed the sequence of steps in advance; in an agent, the model chooses which tool to call next based on what it observed from the last one, and decides when it is done. That autonomy is the whole value and the whole risk — it is why agents need step budgets, tracing and permission boundaries that a chain does not.

One clear purpose per tool, a name that describes it, a description written for a competent stranger, and a strict parameter schema with types and enums rather than free-form strings. Return errors as informative text the model can act on, not stack traces. Most tool-calling failures are documentation failures — the model called the wrong tool because two descriptions overlapped.

Hard step and token budgets enforced outside the model, detection of repeated identical tool calls, a timeout on the whole run, and tracing so you can see where it went wrong afterwards. Instrument cost per run from day one — agent cost scales with the square of sloppiness, and without the number nobody notices until the bill arrives.

The Model Context Protocol is an open standard for exposing tools, resources and prompts to a model through a uniform interface. It matters because it decouples tool implementation from the agent framework — the same MCP server works with any compatible client, so integrations stop being rewritten per framework.

For each token, it computes a weighted sum over every other token in the sequence, where the weights come from the dot product of that token's query vector with the others' key vectors. That lets the representation of "it" incorporate the representation of the noun it refers to, at any distance. The cost is quadratic in sequence length, which is why context windows were historically small and why so much research targets that specific term.

When the dataset is small, the vocabulary is domain-specific and stable, latency and cost matter, or you need the model to be interpretable. A TF-IDF plus logistic regression baseline on a few thousand labelled support tickets is often within a point or two of a transformer, trains in seconds, and can be explained to a stakeholder. Always build it first — it tells you whether the harder approach is earning anything.

BERT is an encoder trained with masked language modelling: it sees the whole sequence bidirectionally, which makes it strong for classification, NER and retrieval embeddings. GPT-style models are decoders trained to predict the next token, seeing only leftward context, which makes them generative. Pick the encoder when you need to understand a fixed input, the decoder when you need to produce text.