Tech interview English glossary

A behavioural example built around giving or receiving feedback on a teammate’s change. It is a common prompt because it shows collaboration, technical judgement, and how diplomatically you can phrase criticism in English.

A behavioural prompt asking you to describe a professional disagreement — typically with a colleague, manager, or stakeholder. Interviewers are assessing how you handled the disagreement and what you did to resolve it, not whether you were right.

A four-part structure for answering behavioural interview questions: Situation (the context), Task (what you were responsible for), Action (what you personally did), and Result (the measurable outcome). It keeps an answer to a predictable shape, which matters most when you are speaking English under pressure.

A prepared set of work examples, written out in advance and mapped to the competencies or leadership principles a company screens for. Building one means you recall and reuse strong stories rather than inventing them live in a second language.

The single career theme that connects your roles into one coherent story, rather than a list of unrelated jobs. Interviewers use it to understand why this role is the logical next step for you.

An Amazon interviewer from outside the hiring team whose job is to protect the company-wide hiring standard. They have veto power over the decision, and they are typically the most rigorous interviewer in the loop.

One of the behavioural standards Amazon uses to score candidates. Every behavioural question in an Amazon loop maps to at least one principle, and interviewers write up your answer against that specific principle rather than a general impression.

Driving an outcome to completion without having full authority over the people or systems involved. In an interview answer, ownership is demonstrated by what you did when something outside your remit was going wrong.

Expanding a single event into many deliveries — for example, turning one post into an entry in every follower’s feed. Fan-out on write does this work when the event is created; fan-out on read defers it until someone requests their feed.

The property that performing the same operation more than once has the same effect as performing it once. It is what makes a request safe to retry after a timeout without creating duplicate charges, messages, or records.

The ranked home timeline of posts a user sees from accounts they follow. It is a standard system design prompt because it forces you to discuss fan-out, ranking, and caching, and to state the trade-off between write cost and read latency.

The online, offline, or last-seen status of a user in a real-time system. Explaining presence well means addressing how status is updated, how quickly it expires, and why exact accuracy is usually traded away for lower cost.

What you give up by choosing one option over another — latency for consistency, cost for redundancy, simplicity for scale. Naming the trade-off out loud is the single clearest signal of senior thinking in a system design round.

A long-lived, two-way connection between client and server, kept open so either side can send data at any time. It is the usual answer for chat and live presence features, where polling would be too slow or too expensive.

A question you ask before answering, to confirm what is actually being asked and surface any ambiguity. Repeating the prompt back in your own words is not stalling; it signals that you think before acting, and it protects you against mishearing the question.

A question asking you to calculate a large real-world quantity — market size, revenue, or user count — from first principles rather than recalled facts. Interviewers score the structure and clarity of your reasoning, not the accuracy of the final number.

A structured comparison of the current state against the desired state, used to identify what is missing and what work would close the difference. It is a standard framing device for requirements and discovery questions.

The uncontrolled growth of a project’s requirements after work has started, usually without matching adjustments to timeline or resourcing. Naming it accurately in English is useful because it frames a delivery problem as a process failure rather than personal blame.

Anyone affected by a change or needed to approve it — engineering, legal, sales, support, or an external customer. Interviewers listen for whether you identified the right stakeholders and how you handled their competing priorities.