Explain AI coding assistant usage strategy

# Strategy for Responsible AI Assistant Use During a Live Coding Interview ## Principles I follow - AI as a copilot, not an autopilot: I keep ownership of problem-solving, design, and verification. - Transparency: I narrate when I’m using the tool, what I’m asking, and how I’m validating results. - Privacy and safety: Never share secrets or proprietary inputs. Redact and sanitize. - Time discipline: Strict limits on tool interaction; quick fallback to manual coding. - Test and verify: Favor small, verifiable steps with fast feedback. ## Time-boxed flow (typical 45–60 minutes) 1. 0–3 min: Restate requirements, constraints, and expected complexity aloud. Propose an approach and identify edge cases. 2. 3–6 min: Write minimal types/signatures and a couple of quick tests or example I/O (even if informal) to lock the target behavior. 3. 6–10 min: Use AI once for scaffolding only (function/class skeleton, I/O parsing, test harness boilerplate). Hard limit: ≤3 minutes per call. 4. 10–25 min: Implement core logic myself. Optionally ask AI for a small helper (e.g., parsing corner cases) if it doesn’t touch the algorithmic heart. 5. 25–35 min: Verify: run tests, add edge cases, analyze complexity, compare against constraints. If failing, request focused hints (not full rewrites). 6. 35–45 min: Refactor for clarity and correctness with types, names, and comments; re-run tests. If time allows, discuss trade-offs and alternatives. If AI suggestions mislead me twice or exceed 20% of total time, I stop using it for the core task and proceed manually. ## How I prompt for scaffolding (without outsourcing thinking) - Goal: get boilerplate, not the algorithm. - Example prompt (spoken and pasted): - "I’m implementing [problem summary] in Python 3.11. Please generate minimal scaffolding: function signature, docstring with parameters/returns, and a tiny test harness/main that reads from stdin and prints results. Do NOT implement the core algorithm; leave TODOs. Follow PEP8, include type hints, and avoid external libraries." - Guardrails in prompts: - Specify language/runtime and style (e.g., TypeScript strict mode, Python 3.11, PEP8). - Ask for TODO markers for core logic. - Ask for small, deterministic tests I can run quickly. - Request no network calls, no file I/O unless required. ## Verifying correctness and quality - Tests first (lightweight): - Write 2–3 concrete examples and edge cases, then run them after each change. - If the environment allows, use a small unit test function; otherwise, a main() with assertions/print checks. - Complexity check: - State expected time/space complexity and confirm the code meets it (e.g., two pointers → O(n), heap → O(n log n)). - API sanity: - For any library calls, quickly confirm signatures against standard library docs or built-in help. - Adversarial/edge tests: - Empty inputs, large inputs, duplicates, negative values, Unicode/locale, off-by-one boundaries. - Ask AI for review, not rewrite: - "Review this function for edge cases and complexity. Don’t rewrite; list potential pitfalls and micro-optimizations." I selectively apply suggestions. ## Refactoring safely - Steps: 1. Pass tests first; then refactor with small, revertible changes. 2. Improve names, extract small pure functions, add type hints and docstrings. 3. Re-run tests after each refactor chunk. - AI-assisted refactor prompt: - "Suggest clearer naming and a function decomposition for readability; do not change behavior. Provide a diff-like plan, not code dump." ## Preventing secret or data leakage - Never paste: - Credentials, tokens, URLs with tokens, internal endpoints, or proprietary code/data. - Sanitize inputs: - Redact identifiers, replace with placeholders (e.g., <API_KEY>), and use synthetic sample data. - Error logs: - Before sharing stack traces, remove file paths, usernames, or internal details. - Minimize context: - Share only the smallest code fragment needed for the assistant to help; avoid full project dumps. - If the platform provides a privacy policy toggle or local mode, I’ll confirm settings before use. ## Attribution and licensing - If I copy a recognizable algorithmic snippet or code pattern from public docs, I’ll: - Mention the source verbally and in a brief comment (e.g., "// adapted from Python docs: heapq usage"). - Check license compatibility if any third-party snippet is involved (usually avoid third-party code in interviews). - For AI-generated scaffolding, I note verbally that I used an assistant for boilerplate and that I own and reviewed the final solution. ## Maintaining understanding and ownership - I explain the approach before coding and narrate trade-offs as I go. - I can re-derive the core algorithm on a whiteboard if needed. - I add concise comments and invariants, and I’m ready to walk through the code with sample inputs. - If AI proposes non-obvious logic, I restate it in my own words and, if necessary, rewrite it from scratch to ensure I can defend it. ## Fallbacks and guardrails - Stop conditions: If the assistant hallucinates APIs or contradicts docs twice, I stop using it for that part. - Defensive checks: - Prefer standard library over obscure packages. - Add asserts for invariants in tricky sections. - Keep functions small and pure where possible to ease reasoning. - Contingency plan: - If time is short, I deliver a correct, clear baseline solution first; optimizations later if time remains. ## Example micro-playbook (what you’d see/hear) - "I’ll write the function signature and two tests. Now I’ll ask the assistant for a minimal test harness and docstring—no core logic." - "I’ll implement the main algorithm myself. Complexity should be O(n log n) due to the heap; let’s validate on these inputs." - "Assistant suggests an alternative using a deque. I’ll verify correctness and complexity vs. constraints, then choose." - "Tests pass; I’ll refactor names and add types. Assistant, please list readability improvements only—I’ll apply them selectively." - "No secrets or proprietary info were shared; sample data is synthetic." This approach demonstrates judgment, preserves privacy, maintains ownership of the solution, and keeps progress visible and test-driven under time constraints.