# NVIDIA interview preparation — Yi Gao

**Role:** JR2020478, Senior AI Agent Test Developer, SDET, Shanghai.  
**Candidate:** AI Algorithm Engineer, Ztalk, Hangzhou.  
**Planning date:** Thursday evening, October 22, 2026.  
**All times below:** Beijing / Singapore time, UTC+8.

**Confirmed Tuesday, October 27 schedule:** HackerRank at **14:00–15:35 (95 minutes)**; Microsoft Teams at **15:35–approximately 16:25**, camera on and screen-share ready. There is **no scheduled transition buffer**. Ask the recruiter before Tuesday how to handle the immediate handoff; unless told otherwise, keep both appointments and do not assume a grace period or shorten the test yourself.

**Priority:** regain reliable Python problem-solving speed, then translate genuine agent-evaluation experience into testing-engineering language. Do not pretend three days of study equals production Kubernetes ownership or five years of classic QA automation. All coding drills and the mock are **without AI, autocomplete assistants, editorials, or outside solution help while the timer runs**. Read explanations only during review.

## 1. PREDICTED TEST

### What the evidence supports—and what it does not

- **Official NVIDIA guidance:** [How We Hire](https://www.nvidia.com/en-us/about-nvidia/careers/how-we-hire/) says technical candidates may receive a coding exercise, usually using HackerRank, and that unapproved outside tools such as ChatGPT during interviews result in disqualification. It does **not** publish this requisition's question count or topics.
- **Weak but relevant historical signal:** a [QA/SDET intern interview account](https://www.geeksforgeeks.org/interview-experiences/nvidia-interview-experience-for-qa-sdet-intern-on-campus/) describes a November 2021 HackerRank round with two coding problems plus OS, computer fundamentals, and reasoning, followed by Teams questions on projects and Python/C++. This is one old, self-reported internship account, **not a reliable template for a senior Shanghai AI-agent role**. It supports preparing for mixed coding/fundamentals, not memorizing its questions.
- **Strongest role-specific evidence:** the supplied JD emphasizes Python, AI-assisted testing, scalable frameworks, regression/flakiness, cloud-native reliability, and bug lifecycle. The recruiter explicitly says the interview will discuss the test solutions and relevant experience. That makes explainable code and rigorous testing reasoning more valuable than studying obscure algorithms.

**Working forecast:** prepare for **two substantial coding tasks, with a possible third shorter task or a fundamentals/MCQ section**. Expect easy-to-medium array/string/hash-map work before advanced algorithms. Practical Python may appear inside a normal coding problem rather than as a separate section. Dedicated test-writing, API work, and debugging are plausible, but may instead appear in the video interview. These are preparation priorities, not measured probabilities or knowledge of the actual test.

| Rank / likelihood | Type and role-specific reasoning | Patterns and concrete examples to rehearse |
|---|---|---|
| **1 — High** | **DSA in Python.** NVIDIA's coding format and the JD's framework-building requirements both favor clear implementations, complexity analysis, and edge cases. | **First:** frequency maps/sets: Two Sum, Two Strings, Ransom Note, Sparse Arrays. **Next:** arrays/indexing: Left Rotation; stack validation: Balanced Brackets; sort-and-scan: Merge Intervals. **Then:** sliding window: Longest Substring Without Repeating Characters; binary-search boundaries: Binary Search. **Backup only:** BFS/DFS connected components: Number of Islands. |
| **2 — Medium–high** | **Practical Python/string/data processing.** Direct match to test-result aggregation, defect triage, and regression analysis. Could be the theme of a DSA question. | Parse JSON lines; count failures by case; deduplicate while preserving order; sort with tie-breakers; group records; handle malformed/missing fields according to a contract. Examples: Merge the Tools!, the local **P1 Log Summary** exercise, and joining baseline/current evaluation results by case ID. Know `dict`, `set`, `Counter`, `defaultdict`, `deque`, `sorted(key=...)`, `json.loads`, and exception handling. |
| **3 — Medium** | **MCQ/short fundamentals.** Supported by the historical SDET account, but uncertain for this senior test. JD explicitly calls for Linux, Python, containers, CI/CD. | Python aliasing/mutable defaults, generators, shallow copies, exception flow, average hash lookup versus list scan; process/thread differences and race conditions; shell exit codes/pipes; HTTP methods/statuses; unit/integration/system tests; CI gates; container versus VM; Pod versus Deployment versus Service. Use **P4 Fundamentals Recall**. Do not spend hours on generic aptitude or hardware trivia. |
| **4 — Medium–low in the online test; high interview relevance** | **Write tests / debug a buggy or flaky scenario.** This is central to SDET work, though a timed HackerRank screen may test it indirectly through hidden cases. | Equivalence classes, boundary values, empty/duplicate inputs, deterministic fixtures, resource cleanup, global-state leakage, race conditions, timeout versus sleep, and controlled dependencies. Examples: test an evidence-completeness function (**P2**); fix order-dependent duplicate detection (**P3**); explain why passing a retry does not establish correctness. |
| **5 — Low–medium online; medium–high interview relevance** | **API/REST testing.** Relevant to MCP services and cloud-native reliability, but not confirmed as a separate assessment. | Status/schema/semantic assertions; pagination; auth isolation; timeouts; bounded retries/backoff; 429/5xx; idempotency; malformed JSON; partial failure. Use **P5 Paged Results API** with a stub, not an unreliable public API. Distinguish REST examples from MCP's own protocol contract. |
| **6 — Low** | **SQL.** Useful for analyzing test telemetry, but absent from the stated must-haves. Cover basics cheaply rather than displacing Python reps. | `SELECT`, filtering, `GROUP BY`, `HAVING`, `COUNT(*)` versus `COUNT(column)`, `LEFT JOIN`, NULL, and join fan-out. Examples: Combine Two Tables; Duplicate Emails; per-build failure rate. Window functions only if the basics are already automatic. |

**Do not prioritize:** hard dynamic programming, advanced graph algorithms, CUDA kernels, deep GPU architecture, C++ language revision, or Kubernetes administration. There is no supplied evidence these outrank Python/testing fundamentals for this requisition. If time runs short, drop the backup graph drill and additional SQL—not mock review or the Zeval story.

## 2. PRACTICE MAP

### Verified resource directory

Every external link in this document was checked live on October 22, 2026 with `curl -L` and returned **HTTP 200**, including after redirects where applicable. Returned page titles/content were checked to distinguish real pages from error/challenge pages. This verifies reachability from the preparation machine at that time, **not** login, submission functionality, or availability from the test network. Confirm access again Monday with VPN off.

**Cost/access:** the selected HackerRank and LeetCode problems are free practice targets; plan on a free account to submit and retain progress. LeetCode China may require its own regional login. Documentation and the two evidence articles require no account to read. Some platform editorials or other content may be paid; none is required here. A GitHub account is needed only to actually run GitHub Actions, which this plan does not require.

| ID | Verified resource / exact destination | What to use; effort cap |
|---|---|---|
| H0 | [HackerRank Interview Preparation Kit](https://www.hackerrank.com/interview/interview-preparation-kit) | Use Arrays, Dictionaries and Hashmaps, Sorting, and Stacks and Queues as a topic index. Do not complete the entire kit. |
| H1 | [HackerRank 1 Week Preparation Kit](https://www.hackerrank.com/interview/preparation-kits/one-week-preparation-kit/) | Redirects to Day 1. Optional **Plus Minus** and **Mini-Max Sum** for Monday warm-up; 10 minutes each. Do not consume its own mock tests in addition to the planned mock. |
| H2 | [HackerRank Python track](https://www.hackerrank.com/domains/python) | Strings, Collections, and Errors and Exceptions. Rehearse **collections.Counter()**, **DefaultDict Tutorial**, **Exceptions**, and **Merge the Tools!**; choose gaps, not the full track. |
| H3 | [HackerRank Algorithms / problem-solving track](https://www.hackerrank.com/domains/algorithms) | Implementation, Strings, Sorting, Search. Backup exercise selection only; the specific problems below take priority. |
| H4 | [HackerRank SQL track](https://www.hackerrank.com/domains/sql) | Basic Select, Aggregation, Basic Join. **Revising the Select Query I** is an optional 10-minute syntax warm-up. |
| H5 | [Two Strings](https://www.hackerrank.com/challenges/two-strings/problem) | Set intersection; 15 minutes plus 5 minutes of edge cases. The question is about any shared substring, not finding the longest one. |
| H6 | [Arrays: Left Rotation](https://www.hackerrank.com/challenges/ctci-array-left-rotation/problem) | Indexing/modulo or slicing; 20 minutes. Explain allocation costs and what the stated input constraints permit. |
| H7 | [Balanced Brackets](https://www.hackerrank.com/challenges/balanced-brackets/problem) | Stack and prefix invariant. **Reserve unseen for Sunday's mock.** |
| H8 | [Sparse Arrays](https://www.hackerrank.com/challenges/sparse-arrays/problem) | Frequency map with repeated queries. **Reserve unseen for Sunday's mock.** |
| H9 | [Hash Tables: Ransom Note](https://www.hackerrank.com/challenges/ctci-ransom-note/problem) | Counts rather than membership; repeated words matter. 20 minutes plus 5 minutes review. |
| H10 | [Merge the Tools!](https://www.hackerrank.com/challenges/merge-the-tools/problem) | Fixed-size chunks and stable deduplication; 25 minutes. A set alone loses required order. |
| L1 | [LeetCode 1 — Two Sum](https://leetcode.cn/problems/two-sum/) | One-pass map, distinct indices, duplicate values; 20 minutes. |
| L2 | [LeetCode 3 — Longest Substring Without Repeating Characters](https://leetcode.cn/problems/longest-substring-without-repeating-characters/) | Sliding window; 30 minutes. Check `abba`, `dvdf`, and all-identical characters. |
| L3 | [LeetCode 56 — Merge Intervals](https://leetcode.cn/problems/merge-intervals/) | Sort then merge overlapping/touching closed intervals. **Reserve unseen for Sunday's mock.** |
| L4 | [LeetCode 704 — Binary Search](https://leetcode.cn/problems/binary-search/) | Maintain a clear inclusive or half-open interval invariant; 20 minutes. Test singleton, absent target, first/last element. |
| L5 | [LeetCode 200 — Number of Islands](https://leetcode.cn/problems/number-of-islands/) | Optional 20-minute BFS/DFS outline after core work; connected components, visited marking, recursion-depth risk. Not required for readiness. |
| L6 | [LeetCode 175 — Combine Two Tables](https://leetcode.cn/problems/combine-two-tables/) | `LEFT JOIN`, including a person with no address; 15 minutes. |
| L7 | [LeetCode 182 — Duplicate Emails](https://leetcode.cn/problems/duplicate-emails/) | `GROUP BY ... HAVING COUNT(*) > 1`; 15 minutes. |
| D1 | [pytest parametrization](https://docs.pytest.org/en/stable/how-to/parametrize.html) | Read the first function-parametrization example, then build P2. Learn fixture isolation/teardown with the local instructions below; no full framework course. |
| D2 | [pytest: flaky tests](https://docs.pytest.org/en/stable/explanation/flaky.html) | Causes, uncontrolled state, overly strict assertions, parallelism; then reproduce P3. |
| D3 | [GitHub Actions: building and testing Python](https://docs.github.com/en/actions/tutorials/build-and-test-code/python) | Understand checkout, Python setup, dependencies, test command, artifacts, and job status. Draft only; no remote publication required. |
| D4 | [Docker: what is a container?](https://docs.docker.com/get-started/docker-concepts/the-basics/what-is-a-container/) | Image versus running container, isolation, ports, volumes, reproducibility. Build/run one local test image if Docker is available. |
| D5 | [Kubernetes Basics](https://kubernetes.io/docs/tutorials/kubernetes-basics/) | Read the deploy, expose, scale, and update summaries. Learn the object model and failure signals; do not complete a cluster-administration course. |

**Coverage map:** DSA → H0/H3/H5–H9/L1–L5; practical Python → H2/H10/P1; test design/debugging → D1/D2/P2/P3; API testing → P5; MCQ/fundamentals → P4/D3–D5/H2; SQL → H4/L6/L7. The local exercises below are deliberately self-contained; they need no external service or URL.

**Links rejected:** the global LeetCode problem pages for Two Sum, Longest Substring Without Repeating Characters, Merge Intervals, Binary Search, Number of Islands, Combine Two Tables, and Duplicate Emails returned HTTP 403 bot challenges, including their `/description/` variants. Their verified China pages above replace them. An initially attempted generic GeeksforGeeks NVIDIA SDET interview article returned 404; the specific historical QA/SDET intern article in Section 1 replaces it. Failed URLs are intentionally not reproduced.

### Local exercises: precise contracts, not vague study topics

Use a disposable local `prep-lab` directory, synthetic data, and no employer code, credentials, merchant conversations, or customer identifiers. These are practice artifacts to create during preparation, not additional deliverables accompanying this plan.

**P1 — Log Summary: practical Python (30 minutes).** Implement `summarize(lines) -> (failure_counts, skipped_count)`. Each line must decode to a JSON object containing a nonempty string `case_id` and `status` equal to `pass` or `fail`; ignore extra fields. Skip and count malformed JSON, non-object JSON, missing fields, or invalid field values. Each valid `fail` record counts once, including repeated case IDs. Return `(case_id, count)` pairs ordered by descending count, then ascending case ID. Do not deduplicate attempts silently.

Use these input lines:

```text
{"case_id":"B","status":"fail"}
{"case_id":"A","status":"pass"}
{"case_id":"B","status":"fail"}
{"case_id":"A","status":"fail"}
{"case_id":"C","status":"fail"}
not-json
{"case_id":"D"}
[]
```

Expected result: `([("B", 2), ("A", 1), ("C", 1)], 3)`. Also check empty input and all-pass input. Spend 5 minutes stating the contract, 18 implementing, 7 testing/explaining. Explain linear parsing/counting plus sorting distinct failed case IDs. Follow-up verbally: when comparing baseline/current runs, distinguish added/removed cases from regressions and join by stable identity, not list position.

**P2 — pytest/framework bridge (75 minutes).** Implement `evidence_complete(required, consulted)` using lists of evidence IDs. Contract: true iff every distinct required ID was consulted; order and duplicates do not matter; no requirements means true. These are contract tests for a synthetic metric, **not a claim about Zeval's implementation**.

- First 15 minutes: D1; understand test discovery (`test_*.py`), ordinary `assert`, parametrization, fixtures, setup/teardown, and test independence.
- Next 35 minutes: create `metrics.py` and `tests/test_metrics.py`; use `@pytest.mark.parametrize` for empty requirements, exact match, missing evidence, extra evidence, reordered IDs, and duplicates. In particular, required `["a", "b"]`, consulted `["a", "a"]` must be false—a count-only implementation is wrong. Required `["a", "a"]`, consulted `["a"]` must be true. Use `tmp_path` in one snapshot round-trip test with Python's `json` module. If a dependency needs replacement, understand `monkeypatch`; do not mock the metric under test.
- Next 10 minutes: run `python -m pytest -q`; deliberately substitute the wrong count-only rule, observe a failing test, restore the correct rule, rerun. If pytest is unavailable, create a virtual environment and install it during preparation, not on test day.
- Final 15 minutes: sketch the framework: versioned case loader → system adapter → deterministic assertions / separately calibrated judge → per-case result → aggregate report and failure artifacts. Put fixture sharing in `conftest.py` only when needed. Separate unit tests (no network), integration/contract tests (controlled dependencies), and nightly/live evals (slower, less deterministic). Explain JUnit XML, marks, configurable timeouts, cleanup, and why scoring failures must not be swallowed.

**P3 — A real order-dependent failure (75 minutes).** Start with this intentionally defective helper:

```python
def first_seen(case_id, seen=set()):
    fresh = case_id not in seen
    seen.add(case_id)
    return fresh
```

Intended contract: callers may pass a set to share a collection within one run; calls without a set must not share state. Two independently collected tests each asserting `first_seen("same-case") is True` pass alone but fail when run together. Two calls with the same explicitly supplied set should return true then false.

- 15 minutes: D2 and the distinction between a reproducible bug, order-dependent flake, environmental failure, and legitimate stochastic variation.
- 25 minutes: reproduce each test alone and together with pytest; reverse their order; fix the default to `None` with a fresh set inside the function. Check the explicitly shared-set behavior remains correct. Do not “fix” it by clearing state in the tests or accepting retries.
- 15 minutes: repeat the suite 20 times in fresh processes; explain why this alone would not expose state leakage *between* individual isolated runs. The together-in-one-process test is the discriminator.
- 20 minutes: map other causes to mitigations: fixed sleeps → deadline-bounded polling of observable state; wall clock → injected clock; external network → stub plus separate integration suite; random data → logged seed; parallel shared files → unique temporary directories; judge/model changes → pinned versions and controlled repeated measurements. Quarantine needs an owner, ticket, expiry, and visibility; retries are diagnostic or explicitly part of a product contract, not a greenwashing mechanism.

**P4 — Fundamentals Recall: 12 prompts (20 minutes, answer aloud before reading the key).**

1. Why does appending to one of two aliased lists affect both?
2. Why is a mutable function default dangerous? What differs from an explicit shared set?
3. When does a generator help, and what changes on a second iteration?
4. Why can a set solve Two Strings but not Ransom Note?
5. What is the difference between a process and a thread? Does Python's GIL prevent application-level races?
6. What do a nonzero shell exit status, a pipeline, and `pipefail` imply for CI?
7. Which layer should test a pure scorer versus a real model endpoint?
8. What do HTTP 401, 403, 429, and 503 mean? Should every failure be retried?
9. What is an idempotent operation? Why can blind retries of POST create duplicates?
10. How are an image, container, Pod, Deployment, and Service different?
11. Why does a readiness failure differ from a liveness failure?
12. Why can `COUNT(column)` differ from `COUNT(*)`, and how can a join inflate counts?

**Short answer key:** same object reference; defaults evaluated once versus caller-owned sharing; lazy one-pass consumption; membership versus multiplicity; address-space sharing and synchronization still matter; nonzero indicates failure and an earlier failed pipeline command can otherwise be hidden; unit versus integration; unauthenticated/forbidden/rate-limited/unavailable with bounded contract-aware retry; repeating has the same intended effect, non-idempotent writes need deduplication/idempotency support; image template/container process/Pod scheduling unit/Deployment replica controller/Service stable network access; readiness controls serving eligibility, liveness can restart a container; NULL values are omitted by `COUNT(column)` and one-to-many joins multiply rows. These are preparation prompts, not claimed NVIDIA questions.

**P5 — Paged Results API (30 minutes).** Implement `collect_failures(fetch_page)`. Inject a stub callable accepting `cursor`, initially `None`, and returning `(http_status, body)`. A successful body has `items` (objects with `case_id` and `status`) and `next_cursor` (string or `None`). Collect distinct failing IDs in sorted order. Follow cursors until `None`. On 503, retry the same cursor once; a second 503 or any other non-200 raises an exception. A repeated non-null next cursor is an error rather than an infinite loop. Invalid body shape/status values also raise rather than silently reporting success. Production backoff is discussed, not slept through in this lab.

Stub scenario: first page contains `B/fail`, `A/pass`, next cursor `p2`; page `p2` first returns 503, then `A/fail`, `B/fail`, next cursor `None`. Expected output: `["A", "B"]`. Test empty results, persistent 503, 401, a cursor loop, and malformed body. Use 5 minutes for the contract, 15 for implementation, 10 for tests. In an interview, extend the test matrix to missing/expired auth, tenant isolation, pagination duplication, schema compatibility, timeout, rate limit, and cleanup. Do not point this exercise at production or an external API.

## 3. THE 3-DAY PLAN

**Budget:** Friday 6 focused hours; Saturday 6; Sunday 6 hours 40 minutes; Monday 2 hours. Gaps in the tables are meals/breaks, not hidden study time. Stop at the block boundary. Carry at most two unresolved errors forward; do not let one problem consume the day. Every timed attempt ends with a brief correctness invariant, complexity statement, and at least three edge cases. On non-mock drills, spend the last 5–10 minutes reviewing rather than looking up a solution mid-attempt.

### Friday, October 23 — reliable Python + translate Zeval into testing engineering

| Time / duration | Focus | Exact work and completion target |
|---|---|---|
| **09:00–10:30 / 90 min** | Coding: maps, counts, arrays | H5 Two Strings 20 min; L1 Two Sum 25 min; H9 Ransom Note 25 min; H6 Left Rotation 20 min. Use platform stubs, not a preferred local template. Check duplicate counts, repeated values, and rotation boundaries. Capture only mistakes in a short error log. |
| **10:45–12:00 / 75 min** | Coding: Python fluency | H2: Counter/DefaultDict/Exceptions, 30 min total; H10 Merge the Tools!, 25 min; 20 min writing tiny input/output functions from memory (`split`, `map`, `enumerate`, dictionary updates, sorted tie-breaks, JSON exceptions). Contrast a HackerRank stdin driver with a supplied function stub. No new algorithm topics. |
| **13:00–14:15 / 75 min** | Interview/QA bridge: pytest | Complete P2 using D1. Produce a passing suite and one observed failure from the deliberate wrong implementation. Explain fixture isolation, parametrization, runner versus scorer, and test levels in terms of Zeval. |
| **14:30–15:30 / 60 min** | Coding: practical automation | P1 Log Summary 30 min; P5 Paged Results API 30 min. Use local synthetic data and a stub only. If unfinished, preserve a correct smaller implementation and name the missing contract; do not pretend it is complete. |
| **15:45–16:45 / 60 min** | Interview: resume deep-dive | Use the story guide below: 10 min opening pitch; 25 min Zeval architecture and one real case; 15 min meta-judge calibration and limitations; 10 min record/replay an answer to “Why SDET rather than an algorithm role?” Say what was implemented, what is proposed, and what evidence exists. |

**Friday output:** Python error log; small pytest/API lab; a truthful 90-second opening; one 5-minute Zeval walkthrough. No need to polish slides or build a new product.

### Saturday, October 24 — algorithm coverage + reliability/cloud vocabulary

| Time / duration | Focus | Exact work and completion target |
|---|---|---|
| **09:00–10:30 / 90 min** | Coding: window/search/SQL | L2 Longest Substring 35 min; L4 Binary Search 25 min; L6 Combine Two Tables 15 min; L7 Duplicate Emails 15 min. Explain the `abba` window trap, search interval invariant, and unmatched join rows. Do **not** open H7/H8/L3. |
| **10:45–12:00 / 75 min** | Interview/QA bridge: flaky tests | Complete P3 using D2. Distinguish order dependence from model nondeterminism. Produce one bug report: title, environment/version, minimal reproduction, expected/actual result, evidence, severity versus priority, suspected cause, fix, verification, regression coverage. |
| **13:00–14:00 / 60 min** | Interview/QA bridge: CI + containers | D3 15 min; D4 10 min; 35 min mini-exercise below. Explain what would block a pull request, what runs nightly, and what artifacts make a failure actionable. This is a new lab, not historical Ztalk CI experience. |
| **14:15–15:30 / 75 min** | Interview/QA bridge: Kubernetes + faults | D5 and vocabulary 20 min; local manifest exercise 25 min; fault-injection test matrix 30 min. Learn to describe a deployment and diagnose symptoms—not administer a cluster. Use the concrete instructions below. |
| **15:45–16:45 / 60 min** | Interview: services, performance, failure analysis | ztalk-mcp 20 min; Azure voice harness 15 min; Axera/Bosch 15 min; gap answers and two interviewer questions 10 min. Select real episodes and verify which outcomes/metrics you can honestly defend. |

**CI/container mini-exercise (35 minutes, inside the 13:00 block).** Draft a workflow with a pull-request trigger and a job containing checkout → setup Python → install test dependencies → `python -m pytest -q --junitxml=results.xml` → upload the report even on failure. The pytest failure must keep the job red; do not add `continue-on-error`. Separate a fast deterministic merge gate from slower live-model/nightly evaluations. Record commit, case-data version, configuration/model version, logs, and per-case results for reproducibility. Never commit secrets; distinguish cache from diagnostic artifacts.

Then create a minimal Dockerfile for the synthetic lab: Python base image, work directory, copy test dependencies, install them, copy lab files, and default command `python -m pytest -q`. Build and run it locally if Docker is already installed; confirm its exit status reflects test success/failure. For reproducibility, understand pinned dependencies and immutable image digests rather than assuming a moving tag is fixed. No registry push or deployment is needed. Cap Docker setup troubleshooting at 10 minutes: if unavailable, run the exact test command in a clean virtual environment and explain the Dockerfile line by line. Report this honestly as a **container design walkthrough**, not a successful container run. Know that containers share the host kernel (Docker Desktop on macOS supplies a Linux VM), published ports differ from exposed metadata, and persistent data needs explicit storage.

**Kubernetes mini-exercise (25 minutes, inside the 14:15 block).** Write a local YAML manifest containing a Deployment for a hypothetical `eval-api` image with two replicas, matching selector/Pod labels, an HTTP readiness probe on `/ready`, and CPU/memory requests and limits; add a Service whose selector matches those Pods. Use an installed YAML parser to load the document and assert the selectors match and replicas equals two; this is **structural validation only**, not Kubernetes schema validation or a live deployment. If no parser is available, use a small JSON manifest (valid Kubernetes input) and Python's `json` module for the same checks. Do not spend the afternoon installing a cluster. If `kubectl` and a local disposable cluster already exist, inspect a harmless local example; never target a shared cluster.

Learn exactly these terms: Pod; Deployment/ReplicaSet; Service; namespace; ConfigMap versus Secret (base64 is not encryption); Job for batch eval runs; requests versus limits; readiness versus liveness versus startup probes; rolling update/rollback; `Pending`, `CrashLoopBackOff`, and `OOMKilled`. Be able to say what `kubectl get pods`, `describe pod`, `logs`, and `rollout status` would help inspect. Readiness failure removes traffic eligibility; liveness is not a substitute for dependency health and can cause restart storms. Admission policies, operators, Helm, cluster networking internals, and production operations are out of scope.

**Fault-injection mini-exercise (30 minutes, same block).** Extend the P5 stub for a bounded timeout and intermittent 503. Write a five-row matrix: tool timeout; 429/rate limit; malformed payload; one replica restart; memory pressure. For each, state fault injection method (stub or hypothetical local container action), expected bounded degradation, observed signal (latency/error/retry count), and recovery criterion. Execute the two stub cases; treat replica restart and memory pressure as proposed tests unless actually exercised locally. Explain no duplicate side effects, bounded queues/retries, and how readiness affects routing. Distinguish functional correctness, load capacity, stress limits, soak stability, and recovery testing.

### Sunday, October 25 — dress rehearsal, immediate debrief, targeted repair

| Time / duration | Focus | Exact work and completion target |
|---|---|---|
| **09:00–10:00 / 60 min** | Coding: repair, not expansion | Re-solve Friday/Saturday's two weakest **already attempted** problems, 25 min each; 10 min compare error patterns. If none remain, re-solve L2 and P1 from blank. L5 may replace the last 20 min only if the core patterns are secure. Keep H7/H8/L3 unseen. |
| **10:15–11:15 / 60 min** | Interview: full story coverage | Zeval/meta-judge 20 min; MCP reliability 15 min; Axera/Azure 15 min; honest Kubernetes/QA gap answers 10 min. Use the question bank below. Practice follow-up questions, not memorized speeches. |
| **11:30–12:15 / 45 min** | Fundamentals + setup | P4 closed-book recall 20 min; 10 min review misses using D3–D5/H2; 15 min confirm logins, Python selection, Chrome/VPN-off access, and Teams microphone/camera/screen share. Load only the mock problem statements at 14:00. Lunch and rest until then. |
| **14:00–15:35 / 95 min** | **The one full timed coding mock** | Exact set: **H8 Sparse Arrays + H7 Balanced Brackets + L3 Merge Intervals**, in that order. Follow the minute-by-minute rules below. |
| **15:35–16:25 / 50 min** | Interview rehearsal with no transition gap | 5 min introduction; 20 min explain mock solutions; 15 min Zeval/meta-judge/MCP questions; 5 min gaps; 5 min questions for interviewer. Speak aloud to a person or record yourself. Do not inspect editorials first. |
| **16:40–18:10 / 90 min** | Same-day mock review | 10 min classify failures; up to 50 min re-solve failed/weak questions **without a per-question timer**; 20 min test counterexamples and explain corrected invariants; 10 min produce Monday's repair list. If all passed, repair the weakest explanation and test adversarial inputs instead of adding a second mock. |

#### Exact 95-minute mock protocol

This is a **three-task preparation stress test**, not a prediction of the actual question count. Use HackerRank for H8/H7 and LeetCode China for L3, with one uninterrupted external timer. This is a deliberate cross-platform approximation, not an official NVIDIA/HackerRank test. Use the published function signatures and constraints. Do not read solutions, discussions, tags, or hints beforehand. If you already know a solution, still implement from blank and label the resulting score as familiarity-assisted rather than claiming a blind baseline.

| Elapsed time | Action |
|---|---|
| **0–5 min** | Read all three statements and constraints; note return formats and rough approaches. |
| **5–25 min** | H8 Sparse Arrays: implement, run samples/custom cases, submit. |
| **25–50 min** | H7 Balanced Brackets: implement, test prefixes/mismatches, submit. |
| **50–85 min** | L3 Merge Intervals: implement, test nested/touching/disjoint intervals, submit. |
| **85–95 min** | Revisit highest-value failure; check signatures/output; submit current best versions. Hard stop at 95. |

During the debrief, explain intended complexity: Sparse Arrays linear counting plus query lookups (with string hashing costs acknowledged); Balanced Brackets linear time and up to linear stack space; Merge Intervals sorting-dominated time and result/storage costs. Do not claim constant memory for a Python solution that creates slices, a sorted copy, or an output list.

**Review method:** save each failure as **symptom → smallest counterexample → wrong assumption → correct invariant → regression case**. Classify reading/contract, algorithm, Python API, boundary, complexity, or time-management errors. Try the untimed re-solve first. If still blocked after a genuine attempt, read a minimal explanation, close it, then rebuild from blank; mark that attempt as assisted. For every corrected solution, run an input that would reject the original wrong approach—not merely another sample. Record actual minutes and accepted/failed submissions; do not infer a company pass threshold from this mock.

### Monday, October 26 — light taper, 2 hours only

| Time / duration | Focus | Exact work and completion target |
|---|---|---|
| **09:30–10:00 / 30 min** | Coding confidence | Re-solve one Sunday repair item from blank, 20 min; verbally explain its invariant and edge cases, 10 min. If no repair item exists, use H1 Plus Minus and Mini-Max Sum, 10 min each, then 10 min review. No new hard problem. |
| **10:15–10:45 / 30 min** | Interview confidence | Opening pitch 5 min; Zeval/meta-judge 10 min; one MCP/Axera story 10 min; honest gap statement 5 min. Use the final resume as the source of truth. |
| **14:00–14:30 / 30 min** | Environment / schedule | Chrome and platform access with VPN off; Teams camera/microphone/speaker check; rehearse share/unshare of one harmless window; check power/network and invitation timezone. Resolve the 15:35 handoff with recruiter if not yet clarified. Do not start the real assessment or consume its attempt. |
| **16:00–16:30 / 30 min** | Final recall / pack | Review error log and P4 for 15 min; review test-day checklist and prepare a clear desk for 15 min. Stop preparation afterward; normal dinner and a full night's sleep. |

### Interview story guide: real experience, testing vocabulary

**90-second positioning:** “I am an AI algorithm engineer who has moved toward evaluating and improving the reliability of agent systems. At Ztalk I created Zeval around curated case snapshots, explicit deterministic metrics, and a calibrated analysis meta-agent. That work exposed the need for repeatable evidence access, which led to a shared stateless MCP service. Earlier computer-vision work at Axera and Bosch trained me to investigate failure modes and dataset coverage. My strongest fit is AI-agent evaluation, failure analysis, and test tooling; I am building the conventional pytest/CI/container vocabulary around that experience, and I would not claim production Kubernetes ownership.” Adapt wording to your own voice.

**Zeval in SDET terms:** curated case snapshots → regression fixtures; explicit verdict/evidence/remediation metrics → test oracles; judge calibration → oracle validation; case-level analysis → defect triage; versioned artifacts and reproducible execution → framework design. These are mappings, **not proof that Zeval already has every classic QA feature**. Explain which are implemented, which have analogues, and which are improvements you would make.

**Preserve the exact calibration story:** the collecting Codex agent helped curate the dataset and supplied per-case judgments. The Evaluator Analysis Meta-Agent was calibrated against those judgments so evaluation could continue after that collecting agent's session ended. Do **not** call those judgments independent human ground truth, claim formal inter-rater reliability measurements you did not run, or imply calibration makes the judge infallible. Explain the risk of shared blind spots, rubric overfitting, leakage, and model drift. Propose human adjudication and a held-out case set as improvements if they are not already implemented.

**ztalk-mcp in SDET terms:** a reusable evidence/tool interface can enable contract testing, isolated clients, repeatable fixtures, and centralized observability. Be ready to distinguish stateless protocol handling from persistence in databases, registries, or downstream services. Your resume states MCP 2026-07-28 stateless specification plus a Git-based agent-plugin registry; describe the design you actually built rather than inventing specification details. Explain tool schemas, request context/auth boundaries, version compatibility, timeouts, errors, and registry revision pinning where those really exist. If a mechanism is missing, say how you would test/add it.

For each story, prepare **context → failure/risk → your decision and implementation → observed result → limitation/next test**. Use real numbers only if you can explain their source, denominator, baseline, and measurement window. A qualitative result is better than a fabricated percentage.

| Likely interview question | Background story to trigger; what a strong answer must contain |
|---|---|
| “Design a test framework for an AI agent.” | **Zeval.** Case snapshots, adapters, deterministic assertions, semantic judge, result schema, artifacts, test levels, versioning, and separation of test-data failures from agent failures. Sketch a representative case flowing through the system. |
| “How did you validate your evaluator?” | **Meta-judge calibration.** Collecting agent's per-case judgments, rubric, mismatch analysis, persistence beyond the session, and limitations. Propose held-out/human review if not done. Agreement with another agent is not the same as correctness. |
| “What do the three metrics actually measure?” | **Zeval metrics.** Verdict correctness, evidence-consultation completeness, remediation-route agreement. Give one concrete, anonymized example of each, its expected reference, denominator, and a case where the metrics disagree. Do not silently substitute a single overall accuracy score. |
| “A nightly eval drops by 8 points. Is it a regression?” | **MyQA/Zeval.** First verify comparable cases/configurations/model/tool/data versions; pair results by case; inspect subgroup deltas, repeat controlled runs, separate harness/infrastructure issues from product behavior. The 8 points are hypothetical, not a claimed project event. |
| “How do you handle flaky LLM tests?” | **Eval/regression thinking plus P3.** Identify source of variation, control fixtures/configuration, retain raw traces, repeated measurement where justified, stable deterministic gates plus separate semantic monitoring. Temperature zero alone does not guarantee reproducibility. |
| “How would you use AI to generate tests or optimize coverage?” | **Collecting agent / AutoResearch loops.** Generate candidates from uncovered behaviors and historical failures, validate expected results, deduplicate, preserve a fixed holdout, and measure useful defect discovery versus review cost. Do not let the generator become its own unchecked oracle. |
| “Why make MCP stateless? What can still leak?” | **ztalk-mcp.** Actual request context, isolation, multiple clients, external state, schema errors, auth, retries, timeouts, and registry compatibility. A proposed cross-client isolation test is more persuasive than “stateless means no bugs.” |
| “A tool call times out after causing a side effect. Retry?” | **ztalk-mcp / P5.** Unknown outcome, idempotency/deduplication or outcome lookup, bounded retries, deadline propagation, auditability. Do not assume every tool is a read or safe to repeat. |
| “Design a performance and reliability test.” | **Azure voice-agent harness.** Actual workload, concurrency, warm-up, latency distribution/tail, time to first useful response where relevant, throughput, errors, instrumentation, and bottleneck isolation. Distinguish measured facts from a proposed load/soak/fault plan. |
| “Tell me about a difficult defect and its lifecycle.” | **Axera failure analysis.** A real detection/annotation/ISP failure, minimal reproducible evidence, stratification by conditions, root-cause investigation, fix owner, verification, and regression cases. Explain severity versus scheduling priority. |
| “How would you improve test-data coverage?” | **Axera plus Bosch.** Failure taxonomy, rare conditions, representative slices, annotation quality, Blender/CAD synthetic data, and domain-gap checks against real samples. Coverage is not just more cases or higher line coverage. |
| “How would you put this into CI and Kubernetes?” | **Zeval plus Saturday lab.** Fast deterministic PR gate, heavier integration/nightly runs, artifacts and failure status, containerized runner, Job versus service Deployment, probes/resources. Explicitly separate proposed architecture from hands-on production experience. |
| “You are an algorithm engineer; where is your QA experience?” | **Whole resume.** Evaluation oracles, regression cases, failure analysis, automation, and performance harnesses are genuine. Acknowledge the classic-framework/operations gap directly; explain the concrete bridge without claiming the JD's five years of conventional QA ownership. |
| “Explain your research or a technical trade-off deeply.” | **TU Berlin / ICARM or Bosch.** Choose one method you can derive and one limitation you observed. Keep this a backup story; do not displace the role's evaluation/tooling focus with an unrelated model lecture. |

**Questions to ask NVIDIA (choose two):** “What agent failures are most costly today, and how are ground truth and release gates defined?” “How much of this role is framework development versus live-system reliability testing?” “What test infrastructure exists already, and what would success in the first 90 days look like?”

## 4. TEST-DAY CHECKLIST — TUESDAY, OCTOBER 27

### Before the test

| Time / duration | What to do / where |
|---|---|
| **09:30–09:50 / 20 min** | Review the existing Python error log and explain one solved function aloud. No new problems or full mock. |
| **12:00–12:30 / 30 min** | Familiar light lunch and water; avoid experimenting with caffeine or food. Rest afterward. |
| **13:00–13:20 / 20 min** | At the test machine: power connected; stable internet; Chrome ready; **VPN off**; close AI chats, coding agents, assistant extensions, editor copilots, unrelated tabs, notifications, and background jobs that may interrupt. Do not change managed software or disable security protections. |
| **13:20–13:35 / 15 min** | Using the invitations, check assessment access, account identity, permitted Python version, camera/permissions if requested, and instructions. Prepare Teams signed in with the correct meeting ready, but do not join prematurely if that conflicts with assessment rules. Keep the recruiter's approved contact channel available for genuine technical trouble. |
| **13:35–13:50 / 15 min** | Read allowed-resources/proctoring rules without starting the timed attempt early. Use only explicitly permitted materials/tools; assume no AI or outside assistance. Check that a notebook, second display, external editor, or documentation is allowed before using it. Clear the desk accordingly. |
| **13:50–14:00 / 10 min** | Bathroom/water, sit down, breathe. Do not open practice problems. Start at the instructed time. |

### HackerRank tactics: 14:00–15:35

- **Minutes 0–5:** scan every question, points, section locks, constraints, and submission rules. Choose Python. Identify supplied function signatures versus stdin/stdout tasks. Estimate the easiest points first; do not assume you can return to a locked section.
- **If three coding tasks:** use the mock's 5-minute scan + 20/25/35-minute task budgets + 10-minute final pass. Reorder by actual difficulty/value, not screen position.
- **If two coding tasks:** 5-minute scan + 35 minutes each + 20 minutes testing/repair. If a short MCQ section is present, allocate 10 of those final 20 minutes to it, unless section locks require an earlier order. Rebudget from actual point weights; no fixed plan overrides the interface.
- **For each problem:** restate the contract, give yourself one simple example and one hostile edge case, select the simplest algorithm meeting constraints, then code. Check empty/minimum input when allowed, duplicates, boundary indices, large inputs, and required ordering. Debug output must not pollute stdout.
- **When stuck:** after 7–10 minutes without a concrete new step, write a simpler correct approach or move on. If a brute-force solution is all you can finish, submit it only knowing which constraints it violates; it may earn subset credit if the scoring supports that. Do not hard-code examples or assume partial credit exists.
- **Submit incremental working versions** if the platform permits; check what counts as the final saved/submitted answer. Passing samples does not establish hidden-test correctness. Investigate an off-by-one or multiplicity bug before replacing a mostly correct algorithm.
- **Use Python intentionally:** avoid `list.pop(0)` for queues, quadratic concatenation, deep recursive DFS on large inputs, accidental shared state, and sorting away required input order. Prefer standard-library tools you understand; do not rely on unapproved packages.
- **Last 10 minutes:** no risky rewrite. Check return types, output formatting, function names, edge cases, and that your best version is actually submitted. Keep a mental one-sentence explanation of each approach for Teams; do not export, screenshot, or copy assessment material unless expressly permitted.
- **Technical trouble:** use the assessment's official support or recruiter channel as allowed; describe the symptom and time. Do not use AI to diagnose the assessment or bypass proctoring/network restrictions. Do not assume a restart or extension is authorized.

### Immediate Teams handoff: 15:35

- Use the recruiter-agreed transition arrangement. Without a changed schedule, finish/confirm submission at 15:35 and join immediately; there is no planned post-test recovery window. If a platform issue causes delay, notify the recruiter through the agreed channel rather than silently missing the interview.
- Camera on; verify correct microphone, speaker/headset, and camera; neutral background and good lighting. Close private work/customer windows and notification previews. Keep a harmless window ready for sharing.
- Ask what to share; choose the requested window or screen. Check text is readable, share/unshare controls work, and no private data, AI overlay, chat notifications, or preparation notes are visible. Do not show the assessment itself unless permitted/requested. Do not record the actual interview without consent.
- Have the resume available only if interview rules allow. No hidden live assistance, chat agents, transcription assistants that answer questions, or generated interview responses.

### Discussing the test solutions immediately afterward

For each problem, use this **2–3-minute structure**:

1. **Contract and example (20–30 seconds):** what had to be returned; important constraints and a discriminating edge case.
2. **Approach and invariant (45–60 seconds):** chosen data structure, why each step is correct, and what stays true during the loop.
3. **Trade-offs (20–30 seconds):** time/space complexity, including Python allocations; contrast one plausible alternative.
4. **Testing and result (20–30 seconds):** samples plus adversarial tests; say exactly what passed or remained uncertain. Do not claim hidden cases you could not see.
5. **Improvement (20–30 seconds):** name the specific missing case, optimization, or clarity improvement. If unfinished, explain the bottleneck and next step without excuses or invented success.

Example phrasing: “I used counts rather than a set because duplicate requirements matter. The invariant is that the map tracks remaining demand after each item. My implementation passed the visible cases; I would additionally test repeated values and an absent required item. The trade-off is extra map storage for avoiding repeated scans.” Use the actual test problem's semantics, not this wording if it does not apply.

**Final standard:** demonstrate a developer who can build test tooling, reason about correctness and uncertainty, investigate failures, and explain personal contributions honestly. Three days should make those abilities visible—not manufacture an operations history you do not have.