Senior Software Engineer interview questions

In a ReAct-style agent loop, the canonical cycle is: (1) Reason — the model produces a Thought about what to do next; (2) Act — the model emits a tool call/action based on that thought; (3) Observe — the environment executes the action and returns an observation; then the loop repeats with the new observation appended to the context until a final answer is produced. Skipping or reordering these steps breaks the grounding that makes ReAct reliable.

Since December 2020, S3 provides strong read-after-write consistency automatically for all GET, PUT, LIST, and tag/ACL/metadata operations, in every Region, at no extra cost. A read issued after a successful write always sees the latest data. The old eventual-consistency model (and the read-your-own-write workarounds people built around it) is gone — but a lot of legacy advice and interview prep still teaches it, which is the trap here. Versioning and AZ scope are unrelated to this guarantee.

PostgreSQL's query planner chooses between a sequential scan and an index scan based on cost estimates derived from statistics (pg_statistic). When a predicate matches a large fraction of rows (e.g., a low-selectivity condition like status = 'active' on a table where 95% of rows are active), the planner correctly decides that reading the entire heap sequentially is cheaper than random index lookups plus heap fetches. The planner uses the page-level cost model: random I/O has a higher cost constant (random_page_cost) than sequential I/O (seq_page_cost). An index is only beneficial when selectivity is high (few rows returned). Options about outdated statistics (ANALYZE not run) and fillfactor are distractors — the described behavior is correct planner behavior, not a bug.

Webhook reliability requires the consumer to respond quickly (within the provider's timeout window, often 5–30 s) with a 2xx status to acknowledge receipt, then process asynchronously. If the consumer does heavy work synchronously and times out, the provider may retry, causing duplicate deliveries. Idempotency keys/event IDs let consumers deduplicate retries. Signature verification (HMAC) guards against spoofed payloads but does not help with duplicate delivery. Storing the raw payload before processing is the correct 'accept-then-process' pattern. Option C describes returning a 200 immediately and queuing the work — the correct pattern — while the others describe anti-patterns or incomplete solutions.

Python's typing.get_type_hints() resolves forward references and applies __future__ annotations. When from __future__ import annotations is active, ALL annotations are stored as strings (PEP 563 postponed evaluation). get_type_hints() then resolves them at call time using the provided (or inferred) global namespace. Here the forward reference 'Node' is resolved by get_type_hints() to the actual Node class, so hints['next'] returns typing.Optional[Node]. Printing that gives typing.Optional[__main__.Node] (or the equivalent module path). The __annotations__ dict, by contrast, would still hold the raw string.

In a multi-region active-active architecture, the core challenge with eventual consistency is handling concurrent writes to the same record from different regions. Vector clocks (or similar mechanisms like CRDTs) track causality across nodes so that conflicts can be detected and resolved rather than silently overwriting data. Last-Write-Wins (LWW) based solely on wall-clock time is unsafe because clocks can skew, making it possible to overwrite a newer write with an older one. Two-phase commit provides strong consistency but introduces cross-region coordination latency and is an availability risk — the opposite of what active-active targets. Read repair is a read-path technique and does not prevent write conflicts. Vector clocks remain the standard causality-tracking answer for active-active replication conflict detection.

Agent memory architectures are typically decomposed into four distinct tiers that serve different temporal and functional purposes. In-context (working) memory is the active prompt window — cheap to read but bounded by context length. External/episodic memory (e.g., a vector store of past episodes) allows retrieval across unlimited history but requires an explicit lookup step. Semantic/knowledge memory stores structured facts the agent can query. Procedural memory encodes learned skills or tool-use policies, often baked into weights or fine-tuned adapters — NOT the in-context window, which is stateless across sessions. The statement that in-context memory persists across independent agent sessions is false: a fresh invocation starts with an empty context unless explicitly reconstructed from an external store.

Strongly consistent reads are supported only on base tables and local secondary indexes, because an LSI shares the partition's storage with the table. Reads default to eventually consistent; you opt into strong consistency per-request with ConsistentRead: true. Global secondary indexes (c) maintain their own asynchronously-updated copy of the data, so they are eventually consistent only — passing ConsistentRead: true to a GSI query is an error. DynamoDB Streams (d) deliver change records eventually, not as consistent point reads. The GSI limitation is the classic gotcha: people design a read path through a GSI and then discover they can't get a strong read there.

A relation is in BCNF if for every non-trivial functional dependency X → Y, X is a superkey. The given relation R(A, B, C, D) has FDs: AB → C, C → B, and AB → D. Check each: AB → C: AB is a superkey? AB → C and AB → D means AB determines all attributes (AB → ABCD), so yes, AB is a superkey. AB → D: same reasoning, valid. C → B: Is C a superkey? C+ = {C, B} ≠ {A,B,C,D}, so C is NOT a superkey. Therefore C → B violates BCNF. This relation is in 3NF (because B is a prime attribute — it's part of the candidate key AB), but NOT in BCNF. The relation is NOT in 4NF either because it first fails BCNF, and 4NF requires BCNF. The correct answer is 3NF but not BCNF.

Breaking changes are those that can cause existing well-written clients to behave incorrectly without modification. (a) Renaming full_name to name breaks clients that read full_name. (c) Removing internal_score breaks clients that depend on it. (d) Changing id's type from integer to string breaks clients that store or compare it as a number. (e) Returning 200 instead of 404 for a missing resource breaks clients that branch on HTTP status codes to detect absence. Adding a new optional field (b) is generally considered a non-breaking, additive change under most REST versioning contracts.

pytest.mark.skipif skips the test when its condition evaluates to True. The requirement here is to skip when CI is falsy — meaning absent or set to an empty string (e.g., CI=). not os.getenv("CI") is True in both of those cases, making Option B correct. Option A (is None) only returns True when the variable is entirely absent; if CI is exported as an empty string, os.getenv("CI") returns "" (not None), so is None is False and the test would run despite CI being empty — missing the falsy case. Option D inverts the logic and skips when CI is present. Option C unconditionally skips, ignoring the environment variable entirely.

In a horizontally scaled stateless service behind a load balancer, session affinity (sticky sessions) pins a user's requests to a single instance. This re-introduces a single point of failure per user and prevents full horizontal elasticity. The correct alternative is to externalise session state into a shared distributed store (e.g., Redis) so any instance can serve any request. Rate-limiting at the LB, distributing static assets via CDN, and database read replicas are all orthogonal scalability improvements that do not conflict with statelessness.

LLM-as-a-judge is a popular evaluation technique, but it has well-documented systematic biases. Studies (e.g., from Zheng et al. 2023 on MT-Bench) show that GPT-4 and similar judges exhibit (1) position bias — preferring the first answer shown, (2) verbosity bias — favouring longer answers regardless of correctness, and (3) self-enhancement bias — rating outputs from models of the same family higher. Calibration drift and sycophancy are real but are properties of the target model, not the judge. The key insight for senior engineers is that using a single LLM judge without positional swapping, length normalization, or multi-judge consensus will silently skew evaluation results.

True. Standard queues guarantee at-least-once delivery: because SQS stores messages redundantly across servers, a server being briefly unavailable during a delete can cause the same message to be received again. So consumers must be idempotent. If you need duplicates suppressed and strict ordering, you use a FIFO queue, which provides exactly-once processing and ordered delivery (at lower throughput). Assuming a standard queue delivers exactly once is a frequent source of double-charged payments and duplicated side effects in production.

ACID's Isolation property is the one that governs how concurrent transactions see each other's in-progress changes. The four standard isolation levels (READ UNCOMMITTED, READ COMMITTED, REPEATABLE READ, SERIALIZABLE) are all refinements of the Isolation guarantee. Atomicity ensures all-or-nothing completion; Consistency ensures data remains valid after a transaction; Durability ensures committed changes survive crashes. None of the other three properties concern themselves with concurrency anomalies like dirty reads, non-repeatable reads, or phantoms — those are isolation concerns.