Appendix N - Glossary

How to use this glossary

This is a working vocabulary, not a complete computer science dictionary. Look up a term when an answer risks becoming vague, then name the decision, constraint, failure mode, or evidence that the term helps you express. Using the word is not a substitute for explaining its consequence.

Interview process terms

Bar raiser: An interviewer or decision participant who focuses on hiring consistency across teams. Treat them as someone looking for transferable senior evidence, not only team fit.

Behavioral round: A round that evaluates past behavior: ownership, conflict, ambiguity, influence, failure, learning, and judgment. Strong answers include stakes, personal action, alternatives, result, and reflection.

Calibration: The mapping between a company’s level expectations and the evidence produced in interviews. A candidate calibrates by studying job scope, round mix, and seniority signals.

Debrief: The post-loop meeting where interviewers compare evidence. Good interview answers leave clear evidence that survives debrief without the candidate present.

Follow-up probe: A question that tests depth, ownership, or adaptability after an initial answer. Senior candidates expect probes and use them to show reasoning, not defensiveness.

Loop: The full sequence of interviews for a role. A loop usually samples coding, design, project depth, behavioral, and team-specific judgment.

Signal: Observable evidence relevant to a hiring decision. Examples include framing, correctness, decomposition, production awareness, influence, and reflection.

Take-home: An asynchronous assessment. It tests not only implementation but also requirements interpretation, scope control, README quality, tests, trade-offs, and polish.

Coding and algorithms

Amortized complexity: Average cost over a sequence of operations. Use it when an operation is sometimes expensive but the total cost is bounded, such as dynamic array resizing or union-find operations.

Backtracking: A search technique that builds partial solutions and abandons branches that cannot lead to valid answers. Explain state, choices, constraints, and undo behavior.

Boundary case: An input near the edge of the allowed range or behavior, such as empty input, one element, duplicate values, extreme values, or invalid transitions.

Correctness argument: A reason the algorithm returns the right result for all valid inputs. It may use invariants, induction, exchange arguments, contradiction, or case analysis.

Dynamic programming: A method for solving problems with overlapping subproblems and reusable state. A strong DP answer names state, transition, base case, order, and answer extraction.

Greedy algorithm: An algorithm that makes locally optimal choices. It needs proof: exchange argument, monotonic property, cut property, or another reason local choices remain globally safe.

Invariant: A condition that stays true before and after each relevant operation. In coding interviews, invariants help explain loops, data structures, and correctness.

Sliding window: A technique for maintaining a contiguous range while moving one or both boundaries. It works when the condition can be updated as the window changes.

Topological order: A linear ordering of nodes where dependencies appear before dependents. Use it for DAG scheduling, build systems, course prerequisites, and dependency resolution.

Two pointers: A technique using two indices or references to scan, compare, partition, or converge. It is strongest when sorted order, monotonicity, or paired movement constrains the search.

Practical coding and code review

Cohesion: How tightly a module’s responsibilities belong together. Low cohesion makes code harder to test, reason about, and change.

Coupling: The degree to which one component depends on another. Senior answers distinguish necessary coupling from accidental coupling.

Idempotency: The property that repeating an operation has the same intended effect as performing it once. In practical coding, idempotency protects retries, imports, migrations, and external calls.

Refactoring: Changing code structure without changing observable behavior. Good refactoring has tests, small steps, and a clear reason.

Regression test: A test that protects against a previously observed failure. Mention it after fixing a bug or edge case.

Seam: A boundary where behavior can be isolated, replaced, or tested. Useful seams include interfaces, adapters, pure functions, and dependency injection points.

Technical debt: A design or implementation compromise that increases future change cost. Not all debt is bad; unmanaged or invisible debt is the problem.

System design

Availability: The ability of a system to serve requests successfully over time. Define the user-visible operation and failure boundary before claiming availability.

Backpressure: A mechanism that slows or rejects incoming work when downstream capacity is exceeded. It prevents overload from becoming uncontrolled failure.

Cache invalidation: The process of keeping cached data correct enough after source data changes. Strong answers name TTLs, write-through/write-around choices, event invalidation, and stale-read impact.

Consistency: The rules governing what reads may observe after writes. In interviews, specify which facts require strong consistency and which can tolerate staleness.

Durability: The expectation that committed data survives defined failures. Durability depends on storage, replication, acknowledgments, backups, and restore tests.

Fan-out: Sending one event or request to many recipients or downstream operations. Fan-out changes latency, cost, failure handling, and ordering.

Hot partition: A shard or partition receiving disproportionate load. It can break systems whose average traffic looks safe.

Latency: Time taken to complete an operation. Senior design answers distinguish median, tail latency, user-visible latency, and background lag.

Partitioning: Splitting data or workload across multiple units. Good partitioning requires a key, routing strategy, rebalance plan, and hotspot mitigation.

Rate limiting: Controlling how much traffic a user, tenant, client, or system can send. It protects availability, cost, fairness, and abuse resistance.

Replication: Maintaining copies of data across nodes or regions. Replication improves read scale or availability but introduces lag, consistency, failover, and conflict concerns.

SLO: Service-level objective. A target for measured service behavior, such as successful writes, p95 latency, freshness, or restore time.

Source of truth: The authoritative place for a fact. Derived copies should know their source, freshness, rebuild path, and deletion behavior.

Databases and data

Index: An auxiliary data structure that speeds particular reads at the cost of storage and write work. Name the query it serves, key order, selectivity, and the writes that must maintain it.

Isolation: The rules governing how concurrent transactions may observe one another’s work. Choose an isolation level from the anomalies the application must prevent, not from the label alone.

Schema migration: A controlled change to stored data or its structure. Safe migrations account for old and new application versions, backfill load, rollback limits, and verification.

Transaction: A group of operations given a defined atomicity and isolation boundary. State what must succeed together, where that boundary ends, and how external side effects are reconciled.

Write-ahead log: A durable record written before the corresponding data-page changes. It supports recovery and replication, but retention, replay, corruption, and lag still need explicit handling.

Networking and security

Authentication: Establishing the identity of a user, service, or device. It answers who is making the request; it does not decide what that identity may do.

Authorization: Deciding whether an authenticated identity may perform an action on a resource. Strong designs name the policy, enforcement point, tenant boundary, and denial behavior.

Least privilege: Granting only the access needed for a defined purpose and duration. Apply it to people, services, credentials, data, and administrative paths.

Load balancer: A component that distributes traffic among backends. Its routing policy, health checks, connection behavior, and failure mode affect both capacity and availability.

Retry: Reattempting an operation after failure or uncertainty. Retries need a budget, backoff, jitter, and an idempotency strategy or they can amplify overload and duplicate effects.

Threat model: A structured account of assets, trust boundaries, plausible attackers, abuse paths, and required controls. It keeps “secure” tied to a system and a set of risks.

Timeout: A limit on how long a caller waits for an operation. Set it from the end-to-end latency budget and pair it with cancellation, retry policy, and a clear treatment of uncertain outcomes.

Production engineering

Alert fatigue: Reduced response quality caused by noisy, low-value alerts. Good alerting pages humans for actionable, user-impacting problems.

Blast radius: The scope of harm caused by a failure or change. Reduce it with isolation, staged rollout, flags, limits, and rollback.

Canary rollout: Releasing a change to a small subset before broader rollout. It works only when health signals and rollback criteria are defined.

Circuit breaker: A mechanism that stops calls to a failing dependency for a period of time. It protects callers and gives dependencies time to recover.

Dead-letter queue: A queue for messages that failed processing after allowed attempts. It needs ownership, triage, replay safety, and age limits.

Error budget: The acceptable amount of unreliability remaining under an SLO. It helps balance feature delivery and reliability work.

Observability: The ability to understand system behavior from emitted signals. Logs, metrics, traces, events, dashboards, and sampled checks should answer operational questions.

Rollback: Returning to a previous known-good version or state. A rollback plan must account for schema, data, external side effects, and compatibility.

Runbook: A documented response procedure for an operational condition. Good runbooks include symptoms, checks, actions, escalation, and recovery verification.

Toil: Repetitive manual work that scales with system usage and does not create lasting value. Senior engineers reduce toil through automation, simplification, or ownership change.

Delivery, product, and leadership

Alignment: Shared understanding of goal, constraints, decision owner, and next step. Alignment is not agreement; it is enough clarity to move responsibly.

Decision record: A concise document explaining context, decision, alternatives, consequences, and revisit triggers. It helps future readers understand why a choice was reasonable then.

Escalation: Raising a decision, risk, or conflict to the right owner when local resolution is insufficient. Healthy escalation is timely, factual, and option-bearing.

Influence without authority: Creating motion through evidence, framing, trust, and coordination rather than formal control.

Non-goal: Something intentionally out of scope. Good non-goals protect focus and make trade-offs explicit.

Ownership: Responsible stewardship of an outcome, including ambiguity, trade-offs, communication, follow-through, and learning. It is broader than completing assigned tasks.

Stakeholder: A person or group affected by a decision or needed to make it work. Senior answers name stakeholders when decisions cross product, operations, security, support, legal, or customer boundaries.

Trade-off: A choice where alternatives have real costs. Do not use the word unless the alternatives and consequences are named.

Field reference

When using a term in an answer, convert it into evidence:

Related links

• Senior Competency Matrix
• System Design Formula Sheet
• Architecture Component Catalogue
• Mistake Log and Practice Tracker