1. Predicted test composition

1.1 What is known (verified on HackerRank's candidate docs, 2026-10-22)

• Scoring is per test case, with partial credit. Each hidden test case passed earns its own points (Evaluation method, Hidden test cases).
• Python 3 = 3.14.2, with a 10 s time limit and 512 MB memory. requests, python-dateutil and pyyaml are available. PyPy3 is only 3.6, so avoid it unless pure-loop code times out (Execution environment).
• Possible question types: Coding, Multiple Choice, Database (SQL), DevOps (Linux VM), Code Review (inline comments on a diff), Subjective, QA projects (Selenium/Cypress/Playwright), and others (Question types).
• Malpractice includes exiting full-screen, switching tabs, copying code from online sources, and outside help. Plagiarism detection catches renamed or reformatted copies (Test integrity).
• MCQs may use negative marking. The instructions page will say so (MCQ).
• Built-in AI Assistant: HackerRank has one, but only the hiring company can enable it. If it's on, the onboarding says so and a panel appears. If there's no panel, it's off (AI Assistant). Plan for no AI.
• Submission at time-out: after you edit a submitted answer, your last submitted version is what counts unless you re-run and re-submit (Modifying submissions, Time-out evaluation).
• The editor is Monaco (the VS Code engine). Its IntelliSense autocomplete is part of the platform and is fine to use (Answer coding questions).

1.2 Reasoning

• The interview discusses your solutions, 0 minutes after the test. So the test is mainly auto-scored coding. MCQs give an interviewer little to discuss. Expect at least 2 coding questions.
• 95 minutes is consistent with either 3 coding questions of increasing difficulty, or 2 coding questions plus an MCQ/short-answer block.
• The JD stresses Python/Linux/shell, test automation, flaky/regression analysis and log-heavy cloud systems. So at least one question is likely a "realistic" data-processing task (logs, test results, events with timestamps) rather than pure puzzle DSA.
• SDET online assessments at large tech companies usually reuse standard library-style DSA (LeetCode Easy–Medium). They sometimes add testing-theory MCQs or a "find the bug / write tests" item.
• QA web-UI projects (Selenium etc.) are unlikely. The role is AI agents and cloud-native systems, not browser UI.

The likelihoods below are my estimates, not leaked content. Prepare in proportion to them.

1.3 Most likely configurations

1.4 Question types ranked by likelihood, with patterns and examples

Difficulty to expect: LeetCode Easy–Medium, sometimes a Medium-Hard with a naive solution that earns partial credit. Python TLE traps are common: O(n²) on n = 10⁵, list.pop(0), deep recursion.

NVIDIA JR2020478 — Senior AI Agent Test Developer (SDET), Shanghai

3-day prep plan for Yi Gao (written Thu 2026-10-22, Beijing time)

The test ends at 15:35, and the interview starts at 15:35. You have no buffer. Plan to finish the test by 15:28, and set up Teams before 14:00 (§4).

The five things that matter most

1. Coding speed in plain Python, with no AI and no docs. HackerRank flags tab-switching and leaving full-screen as malpractice, so you can't look up datetime formats mid-test. Appendix A has to be in your fingers.
2. Partial credit. Scoring is per hidden test case. Submit a working brute force early on every question, then optimize.
3. Explaining your own code 0 minutes later. Write readable code, and keep paper notes on approach, complexity and failures for each question (§4.5).
4. Present Zeval / ztalk-mcp as test infrastructure for non-deterministic AI systems. That is what the JD is asking for (§3.8).
5. Be honest about the gaps and show you've started closing them. Over the weekend you'll build zeval-lite: a pytest suite → GitHub Actions YAML → Docker image → Kubernetes Job on OrbStack. Afterwards you can say "I did this" rather than "I'd learn it" (Appendix C, T5).

Time split across Fri–Mon: ~17 h coding-test prep / ~11 h interview prep (≈ 60/40). The test gates you, and the interview starts by discussing the test, so coding gets the larger share.

1. Predicted test composition

1.1 What is known (verified on HackerRank's candidate docs, 2026-10-22)

• Scoring is per test case, with partial credit. Each hidden test case passed earns its own points (Evaluation method, Hidden test cases).
• Python 3 = 3.14.2, with a 10 s time limit and 512 MB memory. requests, python-dateutil and pyyaml are available. PyPy3 is only 3.6, so avoid it unless pure-loop code times out (Execution environment).
• Possible question types: Coding, Multiple Choice, Database (SQL), DevOps (Linux VM), Code Review (inline comments on a diff), Subjective, QA projects (Selenium/Cypress/Playwright), and others (Question types).
• Malpractice includes exiting full-screen, switching tabs, copying code from online sources, and outside help. Plagiarism detection catches renamed or reformatted copies (Test integrity).
• MCQs may use negative marking. The instructions page will say so (MCQ).
• Built-in AI Assistant: HackerRank has one, but only the hiring company can enable it. If it's on, the onboarding says so and a panel appears. If there's no panel, it's off (AI Assistant). Plan for no AI.
• Submission at time-out: after you edit a submitted answer, your last submitted version is what counts unless you re-run and re-submit (Modifying submissions, Time-out evaluation).
• The editor is Monaco (the VS Code engine). Its IntelliSense autocomplete is part of the platform and is fine to use (Answer coding questions).

1.2 Reasoning

• The interview discusses your solutions, 0 minutes after the test. So the test is mainly auto-scored coding. MCQs give an interviewer little to discuss. Expect at least 2 coding questions.
• 95 minutes is consistent with either 3 coding questions of increasing difficulty, or 2 coding questions plus an MCQ/short-answer block.
• The JD stresses Python/Linux/shell, test automation, flaky/regression analysis and log-heavy cloud systems. So at least one question is likely a "realistic" data-processing task (logs, test results, events with timestamps) rather than pure puzzle DSA.
• SDET online assessments at large tech companies usually reuse standard library-style DSA (LeetCode Easy–Medium). They sometimes add testing-theory MCQs or a "find the bug / write tests" item.
• QA web-UI projects (Selenium etc.) are unlikely. The role is AI agents and cloud-native systems, not browser UI.

The likelihoods below are my estimates, not leaked content. Prepare in proportion to them.

1.3 Most likely configurations

1.4 Question types ranked by likelihood, with patterns and examples

Difficulty to expect: LeetCode Easy–Medium, sometimes a Medium-Hard with a naive solution that earns partial credit. Python TLE traps are common: O(n²) on n = 10⁵, list.pop(0), deep recursion.

2. Practice map (all URLs curl-verified 2026-10-22; method in Appendix D)

LeetCode note: leetcode.com pages answer curl with a Cloudflare bot check (403), so each LeetCode problem was verified twice. First via LeetCode's own GraphQL API (exists, isPaidOnly=false). Second, the same slug on the CN mirror (200, real title). If leetcode.com is slow with VPN off, swap leetcode.com → leetcode.cn in any problem URL below; every slug was checked there too. Premium problems I excluded: Meeting Rooms II, Logger Rate Limiter, Design Hit Counter, Design Log Storage System, Analyze User Website Visit Pattern, Encode and Decode Strings.

2.1 Type 1 — Algorithmic DSA

Where:

• HackerRank Interview Preparation Kit. It uses the same editor and hidden-test scoring as the real test, so do most DSA reps here. Sections: Dictionaries & Hashmaps · Sorting · String Manipulation · Greedy · Search · Stacks & Queues · Graphs · Arrays · Dynamic Programming
• Real-test-UI rehearsal: Problem Solving (Intermediate) certification or Problem Solving (Basic). Each is 1 h 30 min with 2 questions, unseen problems, in the proctored test UI. Used on Sunday.
• LeetCode lists for extra reps (free): Top Interview 150 · LeetCode 75 · Top 100 Liked · Grind 75 · NeetCode practice. CN mirrors: 面试经典 150 · LeetCode 75 (CN) · 热题 100

Problems by pattern (★ = in the 3-day plan; ◆ = reserved for the mock, so don't open it early):

2.2 Type 2 — Python practical / data processing

Where: the HackerRank Python domain. Target the subdomains Collections, Date and Time, Regex and Parsing, Errors and Exceptions, Built-Ins, and Debugging. Python docs to memorize from before Tuesday: collections · datetime · re · itertools · heapq · bisect · functools · Time complexity of builtins

2.3 Type 3 — Testing-flavored items

2.4 Type 4 — MCQ

Appendix B (16 questions, part of the mock) plus the Appendix A2/A3 cheat sheets. Depth sources are in §3.10 (G1–G8).

2.5 Type 5 — REST API consumption

• Live mock endpoints (HackerRank's real test fixtures): football_matches · articles · iot_devices · transactions. The tasks and answer keys are in Appendix C, T4.
• Library docs: urllib.request · requests
• REST API (Intermediate) certification: 1 h 30 min, 2 questions, and you get one attempt only. Don't spend it as practice before Tuesday.

2.6 Type 6 — SQL (low priority)

• HackerRank SQL domain: The Report · Top Competitors · Challenges · Contest Leaderboard · SQL Project Planning · Placements · Symmetric Pairs · Occupations · Binary Tree Nodes · Weather Observation Station 20 (median)
• LeetCode SQL 50 (CN: 高频 SQL 50). Specific problems: 176 · 178 · 180 · 184 · 185 · 197 · 550
• Cheap rehearsal: SQL (Basic) certification (30 min, 2 questions)

2.7 Type 7 — Linux shell

HackerRank Linux Shell domain: ★Cut #1 · ★Sort Command #5 · ★'Uniq' Command #2 · ★'Grep' - A · ★'Awk' - 1 · ★'Sed' command #3 · 'Grep' #1 · 'Awk' - 2 · Paste - 1 · 'Tr' Command #1 · Compute the Average · Tail #2. One-liners are in Appendix A3.

3. The 3-day plan

3.0 Rules for all four days

• No AI autocomplete while practicing. Turn off Copilot, Codex, Claude, Cursor Tab, etc. in your editor until Tuesday evening, because you need the muscle memory back.
• Time caps: Easy 10–12 min, Medium 20–25 min. When you hit the cap, read the HackerRank Discussions tab or a hint. Then close it and re-implement from a blank editor, and log it in errors.md.
• Every problem follows one ritual: constraints → target complexity → 3 edge cases written down → code → run → submit. You will use exactly this ritual on Tuesday.
• errors.md has one line per lost point: problem | label (K/I/B/E/T/F/M/R, see §3.5) | rule I'll apply next time.
• Hard stop 21:30 each night. Sleep is worth more than a 10th problem.
• If Friday is a working day: do D1-1 before work and D1-2 + D1-3 in the evening (≈ 4.5 h). Move D1-4 (S1–S3) to Sunday 19:00–20:30 in place of D3-6. Do D1-5 (pytest + Lab step 1) in Saturday's D2-7 slot, and move D2-7 (MCQ/Linux) to Monday 09:30–10:30 in place of the re-solves. From Set B keep only Balanced Brackets and LC 739 (do them Saturday 08:30 with the warm-up).

3.1 Tonight, Thu Oct 22 (30–45 min)

• In Chrome, log in or create your HackerRank account (use your application email). Solve Sales by Match to get a feel for the editor: Run vs Submit, custom input, debug output.
• Set up a local env. pytest isn't installed for your system python3 (3.14.7), so: python3 -m venv ~/nvprep/.venv && source ~/nvprep/.venv/bin/activate && pip install pytest pytest-xdist pytest-randomly pytest-rerunfailures pytest-timeout pytest-cov hypothesis requests
• Disable AI completion in your editor.
• Create ~/nvprep/errors.md and ~/nvprep/stories.md.
• In stories.md, fill in the [fill] numbers for S1–S10 (§3.8) from memory or your notes: case counts, agreement rates, latencies, regressions caught. Never use confidential Ztalk data in anything you show.

3.2 Day 1 — Fri Oct 23: re-warm the hands, start the bridge

Set A (20-min cap each): Ransom Note (10 min) → Sherlock and Anagrams → Count Triplets → Frequency Queries (watch I/O speed) → LC 3 → LC 438 → LC 347 → LC 560 → LC 56. Stretch: LC 15, Sherlock and the Valid String.

Set P: Word Order → Company Logo (tie-break!) → Time Conversion (12AM/12PM) → LC 937 → LC 811 → LC 636 → LC 1604 → T1 flaky detector (Appendix C, 30 min). Stretch: LC 1169.

Set B: Balanced Brackets (10 min) → LC 155 → LC 739 → LC 394 → Jesse and Cookies → LC 215 → Find the Running Median. Stretch: LC 150.

3.3 Day 2 — Sat Oct 24: the mock, then breadth

Set C: LC 200 (iterative BFS) → LC 994 → LC 207 → Components in a graph (union-find) → LC 743 → LC 278 → LC 875 → LC 435. Stretch: Castle on the Grid, LC 721.

3.4 THE MOCK — Sat Oct 24, 09:00–10:35 (exactly 95 min)

Conditions:

• Chrome full-screen, phone in another room, no AI, no docs, no other tabs.
• Paper and pen. A visible timer.
• Open the three problem links at 08:58. Don't read them before then.

Triage rule: at minute 15 of any question with no working approach, write the brute force, submit it for partial credit, and move on. Come back if time remains.

Score sheet (write it down immediately):

Q   | tests passed | minutes | first-submit at | time split read/plan/code/debug | labels
MCQ | __/16 (guessed: __) |
Q1  | __/__ | ...
Q2  | __/__ | ...
Q3  | __/__ | ...

Benchmarks:

• Q1 full plus Q2 or Q3 full ≈ on track.
• All three full and ≥ 12/16 MCQ ≈ strong. Shift Sunday time toward interview prep.
• Under 1.5 problems ≈ move Sunday's D3-3 lab to a conceptual pass, and give that time to DSA re-solves.

3.5 Same-day review method (Sat 10:50–12:20, 90 min)

This is Zeval applied to yourself: score → failure taxonomy → targeted re-run.

1. Score (10 min). Fill in the score sheet honestly: minutes per phase, and when the first green submit happened.
2. Label every lost point (20 min) with exactly one tag:
   • K didn't know the pattern
   • I knew it, implementation too slow
   • B bug
   • E missed edge case
   • T TLE / complexity
   • F I/O or format mismatch
   • M triage / time management
   • R misread the statement
3. Cold re-solve (35 min). Close everything and re-solve your worst problem from blank at ⅔ of the original time. Only then read the Discussions tab for the optimal approach, and implement it if it differs.
4. Explain cards (15 min). For Q1–Q3, write 5 lines each: problem in one line · key insight · complexity · edge cases + how you'd test it · what you'd change. Say each card aloud in 60 s. This is exactly Tuesday's first interview segment.
5. Rules and routing (10 min).
   • Write one rule per label in errors.md. Example: "T → compute the operation count from constraints before typing."
   • Reorder Set C so your worst label/pattern comes first.
   • MCQs: read the explanation for every wrong and every guessed answer.

3.6 Day 3 — Sun Oct 25: close the gaps, rehearse the interview

3.7 Mon Oct 26 — taper

Optional, send by Friday: a one-line note to the recruiter confirming the interview starts right at 15:35, back-to-back with the test. If they offer 15:40, take it.

3.8 Interview prep: resume deep-dive

Positioning (30 seconds; memorize the shape, not the words):

"I build verification for AI systems. At Ztalk I created Zeval, the evaluation and regression system for our customer-service LLM agent MyQA, which runs on Taobao, JD and Douyin. Zeval is a curated suite of case snapshots that makes agent runs reproducible. Deterministic metrics are the primary oracle, and an LLM evaluator calibrated against reference judgments covers what metrics can't capture. It grew into ztalk-mcp, a shared stateless MCP service. Before that I did failure analysis for automotive perception at Axera and defect-detection models at Bosch. The thread is the same: make AI behavior measurable and catch regressions before users do. That's what this role does at NVIDIA scale."

90-second 'tell me about yourself': TU Berlin M.Sc. Computer Engineering (ICARM paper, dynamic object detection) → Bosch: defect detection (Mask R-CNN/U-Net), synthetic data from Blender/CAD → Axera: detection-model failure analysis, annotation workflows, ISP/image quality → Ztalk: MyQA agent, Zeval, ztalk-mcp, Azure voice-agent perf harnesses → why SDET now (S10).

Vocabulary translation (say the right-hand column to an SDET panel):

JD → evidence map (and how to state each gap):

Story cards. Each card is Hook → Problem → What I built (SDET terms) → Proof [fill] → Follow-ups. Keep the spoken version to 2 minutes.

• S1 Zeval (anchor story).
  • Problem: changes to the MyQA agent (prompts, retrieval, model versions) had no reliable regression signal. Outputs are non-deterministic, and spot checks didn't scale. [fill: release cadence, cost of a bad release]
  • Built:
    1. Case-snapshot suite collected with a Codex agent that also recorded per-case judgments, so the cases are hermetic and replayable.
    2. Three deterministic oracles (verdict, evidence completeness, route agreement).
    3. A meta-agent judge calibrated against those judgments, for analysis the metrics can't express.
  • Proof: [fill: #cases, #regressions caught, a decision Zeval changed, run time].
  • Follow-ups: How do cases get added and retired? How do you avoid overfitting the agent to the suite (held-out cases, refreshing from production)? How is the suite versioned? Is it in CI? If not: "here's the CI design" (zeval-lite).
• S2 Judge calibration.
  • Calibration set with reference labels → agreement measured [fill: % / κ] → review the confusion matrix on disagreements → fix the rubric.
  • Known LLM-judge failure modes: position bias, verbosity bias, self-preference, drift on model updates.
  • Mitigations: structured rubric output, pinned model/version/prompt, temperature 0, recalibration on any change, periodic human audit.
  • Key line: "A judge is a test oracle, and an oracle needs its own test suite."
• S3 ztalk-mcp.
  • Grew out of Zeval because agents and the evaluator needed the same tool access.
  • Stateless per the 2026-07-28 MCP spec, so any replica can serve any call. That makes it easy to scale behind a load balancer and easy to test, since there's no hidden session state.
  • The Git-based plugin registry gives versioned, reviewable tools.
  • Testing [fill: what exists]. What you'd add: schema/contract tests per tool, golden-response tests, idempotency and concurrency tests, fault injection (backend timeout, malformed payload), and compatibility tests across plugin versions.
• S4 Non-determinism vs regression.
  • Repeated runs per case; compare distributions, not single runs.
  • Thresholds with sample sizes big enough to mean something (see B15: 18/20 vs 15/20 is not significant).
  • Cases that disagree across reruns of the same version are flaky by definition, the same definition Google uses: pass and fail on the same code.
  • Freezing evidence removes external variance. [fill: an actual incident]
• S5 Azure voice-agent perf harness.
  • Workload model (concurrent sessions, call length).
  • End-to-end latency broken into stages (ASR → LLM → TTS), reported as p50/p95/p99, plus error rate.
  • The bottleneck you found and the fix [fill].
  • How you'd turn it into a CI perf gate: a baseline, a tolerance band, noise handling.
• S6 Axera failure analysis. Detection failures grouped into categories [fill: e.g. small/occluded objects, night/glare via ISP, label errors] → root cause → fix (data, annotation, ISP tuning) → verify on a regression set. That is a bug lifecycle with severity and priority. Mention the annotation-workflow changes you drove.
• S7 Bosch defect detection + synthetic data. Rare defects meant too few real samples, so you generated Blender/CAD synthetic data to cover the long tail. Same idea as AI-generated test cases: generate inputs where real coverage is thin, then validate that they help (held-out real defects) [fill: metric lift].
• S8 AutoResearch loops. An automated hypothesis → experiment → eval loop with an eval gate as the stop/accept criterion. In SDET terms: AI-driven root-cause exploration, where the safety comes from the gate. [fill: one concrete loop and its result]
• S9 The Kubernetes gap (say it straight).

  "I haven't operated Kubernetes in production; my services ran on [fill]. This weekend I containerized a pytest eval suite and ran it as a Kubernetes Job. I debugged an OOMKilled pod and an ImagePullBackOff, and watched a Deployment self-heal after I killed a pod. Concepts I'm solid on: pods, deployments, services, probes, requests/limits. In the first month I'd get hands-on with the team's cluster tooling and chaos setup."

• S10 Why SDET / why NVIDIA. "In agent engineering the bottleneck has moved from generating behavior to verifying it. I've spent [fill] years building verification for AI systems as a side responsibility. I want it to be the job, on the platform where agents and cloud-native infrastructure are being built."

Confidentiality: describe Ztalk systems at the architecture level. Don't screen-share internal code, prompts, customer data or dashboards.

3.9 Likely interview questions → the story or answer each should trigger

Your questions for them (pick 3):

• How does the team measure agent quality today, and where is it weakest?
• Which AI testing tools are built in-house versus adopted?
• How is time split between framework building and test execution?
• What does CI run on (internal K8s clusters?), and how are flaky tests handled now?
• What would make someone in this seat clearly successful at 6 months?

3.10 JD-gap crash-bridge topics (what to learn, and how deep)

G2 key content to memorize (root cause → fix):

• Async/timing waits → poll with a deadline, or wait on an event; never a fixed sleep.
• Order dependency / shared state → isolate with fixtures; run randomized order (pytest-randomly).
• Time / timezone / DST → inject a clock; freeze time.
• Randomness → seed it, or inject the RNG.
• Unordered collections → compare sets or sorted lists.
• Concurrency / races → deterministic scheduling and locks in the system under test.
• Network / external services → hermetic fakes (responses, recorded fixtures). This is what your case snapshots already do.
• Resource leaks / port collisions → per-test temp dirs and ephemeral ports.
• Infra (noisy neighbors, OOM) → resource requests; separate infra failures from test failures.
• LLM non-determinism → statistical assertions over N runs, pinned model version, temperature 0 where you can, snapshot the evidence.

4. Test-day checklist (Tue Oct 27)

4.1 Setup: dry-run Monday at 14:00, re-check Tuesday at 13:00

• Chrome: updated. Make a fresh Chrome profile with no extensions (no AI sidebars, translators, Grammarly). HackerRank supports Chrome, Firefox and Edge; Brave isn't supported (browser support).
• VPN off. Check that hackerrank.com and Teams both load quickly from your network. Prefer wired Ethernet, power plugged in, one display.
• Quit every AI app and agent: Claude, ChatGPT, Codex, Cursor, Copilot, Amp, and similar. Also quit WeChat/DingTalk/Feishu, and turn on macOS Focus / Do Not Disturb.
• Teams: app updated and signed in (or the guest link tested). Run a test call to check camera, mic and speaker.
• Screen sharing: grant System Settings → Privacy & Security → Screen & System Audio Recording → Microsoft Teams. Teams has to restart after this, so do it Monday. Practice sharing a single window. Help: Teams support.
• Local coding window for the interview: VS Code with all AI extensions disabled (or a plain editor) plus a terminal running python3. Font size ≥ 16. Have an empty scratch.py open.
• Room: light in front of you, camera at eye level, quiet, headset, water, paper + 2 pens.
• Links: star the HackerRank invitation email and the Teams invite.

4.2 Timeline

4.3 HackerRank tactics

First 3–5 minutes: open every question, read the constraints, and pick an order. Easiest and highest-value first, never the hardest first.

Time allocation:

Per-question loop:

1. Read the constraints and derive the complexity target (A4).
2. Write 3 edge cases on paper.
3. Code the clean solution.
4. Run Code. Add your own custom input (empty/min, duplicates, max-ish).
5. Submit.
6. Improve, then re-submit.

Partial credit:

• If you have no full approach at minute 12–15, ship a correct brute force. It usually passes the small hidden cases.
• Then optimize, and only re-submit if the new version passes everything the old one did.

Avoiding Python timeouts:

• Read big input with sys.stdin.readline/sys.stdin.buffer (full-program questions only).
• Use deque.popleft(), never list.pop(0).
• Build strings with ''.join, not += in a loop.
• Use iterative DFS/BFS (or sys.setrecursionlimit, which only partly protects you).
• heapq and bisect beat re-sorting.
• Precompute outside loops.

Output exactness:

• Match the expected format character for character: spacing, rounding (f"{x:.2f}"), trailing newlines.
• In function-stub questions, the template writes your return value to the output file and print() goes to a separate debug pane (code stubs, custom input). In full-program questions, remove debug prints before you submit.
• Don't rewrite the template's I/O unless you have to.

MCQs: if the instructions mention negative marking, only answer when you can eliminate at least 2 options.

Integrity:

• Stay full-screen and don't switch tabs. Both are flagged (test integrity).
• No AI unless the onboarding explicitly enables HackerRank's built-in assistant. Even then, use it at most for syntax, since you'll defend every line minutes later.
• Paper scratch work is normal.

Write for the interviewer: small helper functions, clear names, and a one-line comment with the complexity. No code golf.

Stuck or panicking: write down the brute force, its complexity, and the bottleneck. Naming the bottleneck usually points to the data structure you need.

4.4 The 15:28–15:35 switch

• Submit, then write the paper notes. Don't spend the last 7 minutes squeezing one more test case out of a question.
• If a question is unfinished, your notes say what the full solution would be. You'll offer it in the interview.

4.5 In the interview: discussing your solutions

Open proactively, after the greeting:

"Quick summary of the test: Q1 I solved fully with X in O(n log n). Q2 passes most cases. The remaining ones time out because I sort the window every day; the fix is a counting array, which gives O(n·200). Q3…"

Owning failures precisely is a strong SDET signal.

Per-question 60-second card: problem in one line → key insight → algorithm → complexity (time/space) → status → what failed and why → how I'd fix it → how I'd test it.

"How would you test this?" (EBIDPP):

• Equivalence classes (typical inputs per class)
• Boundaries (empty, 1 element, max n, min/max values, duplicates, already sorted / reverse sorted)
• Invalid input (types, malformed lines, negatives, unicode/whitespace)
• Differential testing against a brute-force oracle on random small inputs
• Property-based (Hypothesis: invariants such as "output is a permutation" or "sum is preserved")
• Performance at the maximum constraints (timed)

Then: "in CI, as parametrized pytest cases plus one Hypothesis test."

Expect a follow-up change: "inputs now stream", "make it thread-safe", "add unit tests", "the range is now 10⁹". Practice: for each mock problem, write 4 pytest tests in 5 minutes (Sunday rehearsal).

Screen-share hygiene:

• Share one window. Close everything else.
• No Ztalk internals on screen.
• Think aloud while coding, and say what you're testing before you run it.

If you blank: restate the problem, solve a tiny example by hand, name the brute force and its bottleneck. Interviewers grade the process.

Appendix A — memorize before Tuesday (no docs during the test)

A1. Standard library and templates

import sys, re, math, heapq, bisect
from collections import Counter, defaultdict, deque, OrderedDict
from itertools import groupby, accumulate, combinations, permutations, product, pairwise
from functools import lru_cache, cmp_to_key, reduce
from datetime import datetime, timedelta, timezone

data = sys.stdin.buffer.read().split()        # bulk input (full-program questions)
input = sys.stdin.readline                    # fast line input
cnt = Counter(words); cnt.most_common(3)      # ties keep insertion order -> sort yourself if a tie rule is given
ranked = sorted(cnt.items(), key=lambda kv: (-kv[1], kv[0]))   # count desc, name asc
g = defaultdict(list); g[u].append(v)
q = deque([s]); q.popleft(); q.appendleft(x)
h = []; heapq.heappush(h, (prio, idx, item)); heapq.heappop(h)  # idx = tie-breaker; max-heap: push -x
heapq.nlargest(k, xs, key=f)
i = bisect.bisect_left(a, x)                  # first i with a[i] >= x ; bisect_right: first a[i] > x
bisect.insort(win, x); win.pop(bisect.bisect_left(win, old))     # sorted sliding window
runs = [(k, len(list(grp))) for k, grp in groupby(s)]            # run-length (adjacent only)
pref = list(accumulate(a, initial=0))         # pref[j] - pref[i] = sum(a[i:j])
@lru_cache(maxsize=None)                      # memoized recursion
sorted(xs, key=cmp_to_key(lambda a, b: -1 if a + b > b + a else 1))
re.findall(r'(\w+)=(\d+)', line)              # list of tuples
m = re.match(r'^(?P<ts>\S+) (?P<lvl>[A-Z]+) (?P<svc>\w+)', line); m['lvl']
datetime.strptime('2026-10-27 14:03:22', '%Y-%m-%d %H:%M:%S')
datetime.strptime('Sun 10 May 2015 13:54:36 -0700', '%a %d %b %Y %H:%M:%S %z')
datetime.fromisoformat('2026-10-27T14:03:22Z')  # 3.11+ accepts 'Z'
(t2 - t1).total_seconds(); t + timedelta(minutes=5)
divmod(n, 60); (a + b - 1) // b               # ceil for ints; float('inf') / math.inf
f"{x:.2f}"  f"{n:05d}"  f"{s:>10}"  f"{n:,}"

# BFS on grid
def bfs(grid, sr, sc):
    R, C = len(grid), len(grid[0]); dist = [[-1] * C for _ in range(R)]
    dist[sr][sc] = 0; q = deque([(sr, sc)])
    while q:
        r, c = q.popleft()
        for dr, dc in ((1, 0), (-1, 0), (0, 1), (0, -1)):
            nr, nc = r + dr, c + dc
            if 0 <= nr < R and 0 <= nc < C and grid[nr][nc] != '#' and dist[nr][nc] < 0:
                dist[nr][nc] = dist[r][c] + 1; q.append((nr, nc))
    return dist

# Union-find
parent = list(range(n)); size = [1] * n
def find(x):
    while parent[x] != x:
        parent[x] = parent[parent[x]]; x = parent[x]
    return x
def union(a, b):
    ra, rb = find(a), find(b)
    if ra == rb: return False
    if size[ra] < size[rb]: ra, rb = rb, ra
    parent[rb] = ra; size[ra] += size[rb]; return True

# Topological sort (Kahn) -- cycle if len(order) < n
indeg = [0] * n; adj = defaultdict(list)
for a, b in edges: adj[a].append(b); indeg[b] += 1
q = deque(i for i in range(n) if indeg[i] == 0); order = []
while q:
    u = q.popleft(); order.append(u)
    for v in adj[u]:
        indeg[v] -= 1
        if indeg[v] == 0: q.append(v)

# Dijkstra
dist = {src: 0}; h = [(0, src)]
while h:
    d, u = heapq.heappop(h)
    if d > dist.get(u, math.inf): continue
    for v, w in adj[u]:
        if d + w < dist.get(v, math.inf):
            dist[v] = d + w; heapq.heappush(h, (d + w, v))

# Binary search on the answer: smallest x with ok(x) True (ok is monotone F..F T..T)
lo, hi = LO, HI
while lo < hi:
    mid = (lo + hi) // 2
    if ok(mid): hi = mid
    else: lo = mid + 1

# Variable sliding window (longest substring without repeats)
last = {}; left = best = 0
for right, ch in enumerate(s):
    if last.get(ch, -1) >= left: left = last[ch] + 1
    last[ch] = right; best = max(best, right - left + 1)

# Prefix sum + hashmap (count subarrays summing to k)
seen = Counter({0: 1}); run = ans = 0
for x in nums: run += x; ans += seen[run - k]; seen[run] += 1

# Merge intervals
out = []
for s, e in sorted(iv):
    if out and s <= out[-1][1]: out[-1][1] = max(out[-1][1], e)
    else: out.append([s, e])

# Monotonic stack (days until warmer)
res = [0] * len(T); st = []
for i, t in enumerate(T):
    while st and T[st[-1]] < t:
        j = st.pop(); res[j] = i - j
    st.append(i)

A2. Python gotchas (planted bugs and MCQ material)

• Mutable default arguments persist across calls → use None and create inside the function.
• [[0]*m]*n gives n references to one row → use [[0]*m for _ in range(n)].
• Late-binding closures: [lambda: i for i in range(3)] all return 2 → lambda i=i: i.
• // floors toward −∞: -7 // 2 == -4. % takes the sign of the divisor: -7 % 2 == 1. round(2.5) == 2 (banker's rounding). Compare floats with math.isclose.
• is vs ==: never use is for value comparison (only for None).
• Mutating a dict or set while iterating → RuntimeError. Iterate over list(d).
• Return values: list.sort() returns None; sorted() returns a new list. Both are stable, which is the trick for multi-key sorts.
• Generators are exhausted after one pass.
• finally runs even after a return.
• Bare except: also catches KeyboardInterrupt/SystemExit → catch except Exception.
• Copies: shallow (copy.copy, list[:]) vs deep (copy.deepcopy).
• Hashing: defining __eq__ without __hash__ makes instances unhashable. Use @dataclass(frozen=True) for hashable records.
• GIL: threads overlap I/O waits but not CPU work → CPU-bound work needs multiprocessing / ProcessPoolExecutor; I/O-bound work can use threads or asyncio. Docs: concurrent.futures.
• Decorators should use functools.wraps. Context managers (with) guarantee cleanup; pytest yield fixtures follow the same idea.
• pytest exit codes: 0 all passed · 1 some failed · 2 interrupted · 3 internal error · 4 usage error · 5 no tests collected.

A3. Linux one-liners

grep -c ERROR app.log; grep -E 'ERROR|FATAL' app.log; grep -v DEBUG app.log; grep -rn "timeout" src/; grep -o 'req=[0-9]*' app.log
cut -d' ' -f1 access.log | sort | uniq -c | sort -rn | head -5      # top-5 IPs (uniq needs sorted input!)
awk '{s[$3]+=$5} END {for (k in s) print k, s[k]}' metrics.txt       # group-sum col 5 by col 3
awk -F, 'NR>1 && $4 > 500 {print $1}' data.csv                       # filter CSV, skip header
sed -n '10,20p' f; sed 's/foo/bar/g' f; sed -i.bak '/^#/d' f          # print range / replace / delete comments
sort -t, -k2,2nr f; tail -f app.log; tr 'a-z' 'A-Z' < f; paste -sd, f; xargs -n1
find . -name '*.log' -mtime -1 -size +10M; du -sh *; df -h
ps aux | grep pytest; kill -15 PID  # SIGTERM (catchable)  vs  kill -9 PID  # SIGKILL (not catchable)
lsof -i :8080; ss -ltnp; curl -sS -o /dev/null -w '%{http_code}\n' "$HEALTH_URL"   # status code only
chmod 755 run.sh; chmod u+x run.sh; ln -s target link; echo $?    # last exit code
set -euo pipefail                                                  # fail fast in CI scripts
cmd > out.log 2>&1; cmd 2>/dev/null; cmd1 && cmd2 || cmd3; nohup cmd &

A4. Complexity budget (Python 3, HackerRank limit 10 s per test case; assume ~10⁷ simple ops/s)

Appendix B — MCQ set (mock Part A; don't read it before Saturday 09:00)

1. def add(x, acc=[]): acc.append(x); return acc — then add(1); print(add(2)) → (a) [2] (b) [1, 2] (c) error (d) [[1], 2]
2. g = [[0]*3]*2; g[0][0] = 1; print(g) → (a) [[1,0,0],[0,0,0]] (b) [[1,0,0],[1,0,0]] (c) error (d) [[1,1,1],[0,0,0]]
3. print(-7 // 2, -7 % 2) → (a) -3 1 (b) -4 1 (c) -3 -1 (d) -4 -1
4. fs = [lambda: i for i in range(3)]; print([f() for f in fs]) → (a) [0,1,2] (b) [2,2,2] (c) [0,0,0] (d) error
5. A runner makes 500 independent HTTP health checks in CPython. The simplest big speed-up: (a) a plain loop (b) ThreadPoolExecutor or asyncio (c) 500 processes (d) no gain is possible because of the GIL
6. Top-5 most frequent IPs (field 1) in access.log: (a) cut -d' ' -f1 access.log | uniq -c | sort -rn | head -5 (b) cut -d' ' -f1 access.log | sort | uniq -c | sort -rn | head -5 (c) sort access.log | uniq -c | head -5 (d) awk '{print $1}' access.log | sort -rn | head -5
7. A CI step runs pytest tests/ and 3 tests fail. The exit code is: (a) 0 (b) 1 (c) 3 (d) 5
8. A field accepts integers 1–100. The minimal two-sided boundary-value set: (a) 1, 50, 100 (b) 0, 1, 100, 101 (c) −1, 0, 101 (d) 1, 100
9. A test passes alone but fails intermittently when the full suite runs in random order. Most likely cause: (a) a slow CI machine (b) shared mutable state / order dependency (c) network (d) a wrong assertion
10. A @pytest.fixture(scope="module") is used by 3 tests in test_a.py and 2 in test_b.py (single process). How many times does the fixture body run? (a) 1 (b) 2 (c) 5 (d) it depends on order
11. kubectl describe pod shows Last State: Terminated, Reason: OOMKilled, and restarts keep rising. Best next step: (a) raise the readiness-probe timeout (b) compare memory use to resources.limits.memory, then raise the limit or fix the leak (c) switch the Service to LoadBalancer (d) delete the namespace
12. A container's readiness probe fails while liveness passes. Kubernetes: (a) restarts the container (b) removes the Pod from Service endpoints without restarting it (c) deletes the Deployment (d) reschedules the Pod to another node
13. Why COPY requirements.txt . + RUN pip install -r requirements.txt before COPY . .? (a) a smaller image (b) layer caching: dependencies only reinstall when requirements change (c) security (d) pip requires it
14. A typo in the company name on the home page is: (a) high severity, high priority (b) low severity, high priority (c) high severity, low priority (d) low severity, low priority
15. An agent eval case passes 18/20 runs on model v1 and 15/20 on v2. The right conclusion: (a) v2 regressed 15 points, block the release (b) not significant at this sample size (Fisher exact two-sided p ≈ 0.41), so add trials/cases before deciding (c) the case is flaky, delete it (d) v1 was flaky
16. 1,000 commits separate the last good build from the first bad one, and each test run takes 20 min. Worst-case bisection time: (a) ~20 min (b) ~3.3 h (≈ 10 runs) (c) ~1 day (d) ~333 h

Appendix C — SDET-flavored practice tasks (sample outputs checked against reference solutions)

T1. Flaky-test and regression detector (Fri, 30 min) Input: N, then N lines run_id commit test_name PASS|FAIL duration_ms. Commit order = order of first appearance. Output:

• For each test with both PASS and FAIL on the same commit: FLAKY <test> <number_of_such_commits>, sorted by count descending, then name.
• Then, for each test, the first commit where it went from all-PASS (on its previous commit) to all-FAIL: REGRESSION <test> <commit>, sorted by name.
• If both lists are empty, print NONE.

12
r1 c1 test_login PASS 120
r2 c1 test_login FAIL 3000
r3 c1 test_search PASS 80
r4 c1 test_upload PASS 200
r5 c2 test_login PASS 110
r6 c2 test_search FAIL 95
r7 c2 test_search FAIL 90
r8 c2 test_upload FAIL 5000
r9 c2 test_upload PASS 210
r10 c3 test_login FAIL 2900
r11 c3 test_login PASS 130
r12 c3 test_search FAIL 85

Expected output:

FLAKY test_login 2
FLAKY test_upload 1
REGRESSION test_search c2

Interview extension: which signals would you add (duration variance, error-message variance), and how would you make this a CI job?

T2. Log triage (stretch / Sunday evening) Input: first line N K W, then N lines ISO8601Z LEVEL service latency_ms. Lines are not guaranteed to be sorted. Output:

• Per service, sorted by name: service total errors error_rate(2dp) p95. p95 uses nearest rank: sorted latencies at index ceil(0.95·n) − 1.
• Then ALERT service ts for the first ERROR at which ≥ K of that service's ERRORs fall within the closed window [ts − W s, ts].

11 3 60
2026-10-27T14:00:00Z INFO auth 120
2026-10-27T14:00:10Z ERROR auth 900
2026-10-27T14:00:45Z INFO search 80
2026-10-27T14:00:30Z ERROR auth 950
2026-10-27T14:01:05Z ERROR auth 1000
2026-10-27T14:01:20Z ERROR search 300
2026-10-27T14:02:00Z INFO search 70
2026-10-27T14:03:00Z ERROR search 310
2026-10-27T14:03:30Z INFO search 90
2026-10-27T14:03:40Z ERROR search 330
2026-10-27T14:04:10Z INFO auth 110

Expected output:

auth 5 3 60.00 1000
search 6 3 50.00 330
ALERT auth 2026-10-27T14:01:05Z

T3. retry with backoff, plus tests (Fri D1-5 or Sat D2-6, 30 min) Spec: implement retry(fn, attempts=3, base_delay=0.1, factor=2, retry_on=(Exception,), sleep=time.sleep). It calls fn(). On an exception in retry_on, it sleeps base_delay * factor**i and retries. After the last attempt it re-raises the last exception. Other exceptions propagate immediately. attempts < 1 raises ValueError. Write pytest tests for:

• success on the first call (no sleeps)
• success on the 3rd call (sleeps [0.1, 0.2], using a recording fake sleep)
• all attempts exhausted → the original exception is raised
• a non-retryable exception is not retried
• attempts=1
• attempts=0 → ValueError

Use parametrize for the delay sequences. Then add jitter and explain how you'd test randomness: inject the RNG.

T4. REST tasks on the jsonmock fixtures (Sun D3-1). Use urllib.request + json first, then requests. Loop until page == total_pages. Answers were computed 2026-10-22; the data is live but static in practice.

• A. Total goals Barcelona scored in 2011. Query team1=Barcelona (count team1goals) and team2=Barcelona (count team2goals), all pages: endpoint. Answer: 35 (12 matches). Note that goals come back as strings.
• B. Top 3 article names by num_comments. Name = title, or else story_title; skip the article if both are null; break ties by name: endpoint. Answer: "UK votes to leave EU" (2531), "F.C.C. Repeals Net Neutrality Rules" (1397), "EU approves internet copyright law, including ‘link tax’ and ‘upload filter’" (1010).
• C. Count of RUNNING IoT devices and mean operatingParams.rotorSpeed (2 dp): endpoint. Answer: 35 devices, 3087.51.
• D. Total debit amount per userName (parse strings like "$1,670.57"), top 3: endpoint. Answer: John Oliver 97285.55 · Bob Martin 85250.00 · Helena Fernandez 65445.13.
• Then write 3 pytest tests for your fetcher without network access: monkeypatch urllib.request.urlopen, or use responses for requests. Cover pagination, an empty result, and an HTTP error.

T5. zeval-lite lab: Zeval's ideas in pytest → CI → Docker → Kubernetes. Use synthetic cases only.

Step 1, Fri D1-5 (60 min): pytest suite

zeval-lite/
  cases/*.json              # 8 synthetic case snapshots
  zeval_lite/agent.py       # fake agent: returns {"verdict", "evidence_used", "route"}
  zeval_lite/metrics.py     # verdict_correct, evidence_completeness, route_agreement
  tests/conftest.py         # session-scoped cached fake judge, report dir via tmp_path_factory
  tests/test_metrics.py     # unit tests for the metrics (parametrize + edge cases: empty evidence, extra evidence)
  tests/test_cases.py       # one parametrized test per case file
  pytest.ini

{"id": "refund-late-delivery-01",
 "input": "My order is 3 days late, I want a refund",
 "evidence": {"order_status": "shipped", "days_late": 3},
 "expected": {"verdict": "eligible", "required_evidence": ["order_status", "days_late"], "route": "refund_flow"}}

# tests/test_cases.py
import json, pathlib, pytest
from zeval_lite.agent import run_agent
from zeval_lite.metrics import verdict_correct, evidence_completeness

CASES = sorted((pathlib.Path(__file__).parent.parent / "cases").glob("*.json"))

@pytest.fixture(params=CASES, ids=lambda p: p.stem)
def case(request):
    return json.loads(request.param.read_text())

def test_verdict(case):
    out = run_agent(case)
    assert verdict_correct(out, case["expected"]), out

def test_evidence_completeness(case):
    assert evidence_completeness(run_agent(case), case["expected"]) == 1.0

@pytest.mark.judge
def test_judge_agrees(case, judge):
    assert judge(case, run_agent(case))["agree"]

# tests/conftest.py
import json, pytest

@pytest.fixture(scope="session")
def judge():
    cache = {}
    def _judge(case, out):
        key = (case["id"], json.dumps(out, sort_keys=True))
        if key not in cache:   # stub: in real life a pinned-model LLM call, cached so reruns are deterministic
            cache[key] = {"agree": out["verdict"] == case["expected"]["verdict"]}
        return cache[key]
    return _judge

# pytest.ini
[pytest]
markers =
    judge: uses the LLM judge (slow, non-deterministic) -- nightly lane only
addopts = -ra --strict-markers

Run: pytest -m "not judge" -q · pytest -n auto · pytest --lf · pytest --junitxml=reports/junit.xml · pytest --cov=zeval_lite --cov-report=term-missing

Step 2, Sat D2-6 (50 min): flakiness + CI

• Add tests/test_flaky_demo.py with three classic flaky tests:
  1. assert random.random() < 0.9
  2. test A appends to a module-level list, and test B asserts the list is empty
  3. time.sleep(0.01) waiting on a background thread
• Expose them by running for i in $(seq 20); do pytest -q tests/test_flaky_demo.py || echo "FAIL run $i"; done. pytest-randomly shuffles the order and prints a seed; reproduce with pytest --randomly-seed=<seed>. Then fix each properly: inject the RNG, isolate state with a fixture, wait on an event with a timeout.
• Write .github/workflows/tests.yml from memory, then compare it with the docs:

name: tests
on:
  pull_request:
  schedule:
    - cron: "0 18 * * *"          # nightly (UTC) -> judge lane
jobs:
  presubmit:
    runs-on: ubuntu-latest
    strategy:
      fail-fast: false
      matrix:
        python-version: ["3.12", "3.13"]
    steps:
      - uses: actions/checkout@v6
      - uses: actions/setup-python@v5
        with:
          python-version: ${{ matrix.python-version }}
          cache: pip
      - run: pip install -r requirements.txt
      - run: pytest -m "not judge" -n auto --junitxml=reports/junit.xml
      - uses: actions/upload-artifact@v4
        if: always()
        with:
          name: junit-${{ matrix.python-version }}
          path: reports/
  nightly-judge:
    if: github.event_name == 'schedule'
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v6
      - uses: actions/setup-python@v5
        with: { python-version: "3.13", cache: pip }
      - run: pip install -r requirements.txt
      - run: pytest -m judge --reruns 2 --junitxml=reports/judge.xml   # report pass-on-rerun as FLAKY, not PASS

• Write a one-page flaky policy:
  • definition
  • detection: same-SHA reruns, flip rate
  • quarantine: owner + 7-day SLA, still runs, doesn't gate
  • a rule that reruns are reported, never silently counted as green
  • LLM tests use statistical gates

Step 3, Sun D3-3 (90 min): container + Kubernetes. State of this Mac on 2026-10-22: Docker engine 29.8.2 running via OrbStack (active context), kubectl v1.33.9, no cluster context yet, kind not installed. Docker Hub pulls may need your VPN on (prep days only).

FROM python:3.13-slim
WORKDIR /app
COPY requirements.txt .
RUN pip install --no-cache-dir -r requirements.txt
COPY . .
ENTRYPOINT ["pytest", "-q", "-m", "not judge"]

docker build -t zeval-lite:dev . && docker run --rm zeval-lite:dev; echo "exit=$?"   # break a test -> exit=1
orb start k8s                       # OrbStack's built-in cluster; local images work with a non-:latest tag
kubectl config get-contexts         # expect an 'orbstack' context

# job.yaml
apiVersion: batch/v1
kind: Job
metadata: { name: zeval-lite }
spec:
  backoffLimit: 0
  template:
    spec:
      restartPolicy: Never
      containers:
        - name: tests
          image: zeval-lite:dev
          imagePullPolicy: IfNotPresent
          resources:
            requests: { cpu: "250m", memory: "128Mi" }
            limits:   { cpu: "1",    memory: "256Mi" }

kubectl apply -f job.yaml && kubectl get pods -w
kubectl logs job/zeval-lite; kubectl describe job zeval-lite; kubectl get events --sort-by=.lastTimestamp
kubectl delete job zeval-lite

Failure drills (each one becomes a sentence in story S9):

1. Add a test that allocates 300 MB with the limit at 256Mi → OOMKilled in describe.
2. Typo the image tag → ErrImagePull / ImagePullBackOff.
3. kubectl create deployment web --image=nginx --replicas=3, then kubectl expose deployment web --port=80, then kubectl delete pod <one> → the ReplicaSet recreates it. Next, add a readiness probe on a wrong path → the pod is Running but not Ready, and kubectl get endpoints web is empty.
4. Say out loud how you'd do fault injection with Chaos Mesh (PodChaos pod-kill, NetworkChaos delay) against a steady-state SLO.

Fallback if OrbStack's Kubernetes won't start: brew install kind && kind create cluster (kind quick start), then kind load docker-image zeval-lite:dev. Spend at most 15 minutes on installs before switching to the docs-only version of G5.

Appendix D — how the URLs were verified (2026-10-22)

• Every URL in this file was fetched with curl -L and a browser user agent (some sites reject plain curl).
  • HackerRank pages: HTTP 200 with the real page title. A bogus slug returns 404.
  • Certification pages: 200 plus the certificate heading. A bogus slug returns 500.
  • Candidate-support articles: 200 with the article title.
  • jsonmock endpoints: 200 with JSON data. The /api/users endpoint returned 400 and isn't used.
• LeetCode: leetcode.com HTML returns a Cloudflare bot challenge (403) to curl, so every problem and study plan was verified through LeetCode's GraphQL API. All exist, and none are paywalled. Each problem slug was also fetched on leetcode.cn (200 with a real NNN. 标题 title; bogus slugs there show an empty title).
• Excluded after checking:
  • 6 premium LeetCode problems (listed in §2).
  • toxiproxy.io, which now redirects to an unrelated betting site. The GitHub repo is linked instead.
  • Two PyPI pages that returned a bot "Client Challenge" (pytest-xdist and responses). Readthedocs/GitHub links are used instead.
  • The HackerRank Regex domain page and /dashboard, which land on the logged-in dashboard.
• NVIDIA's AI-tools policy page could not be located by curl, so no URL is given. The rule as you were told it (unapproved outside AI tools such as ChatGPT during interviews means disqualification) is the operating assumption throughout.