## Scenario You've been invited to a DoorDash onsite round labeled the **"AI Code Craft Challenge."** Per the prep kit: - You will receive **starter code** — an existing, small but unfamiliar codebase. - You are **allowed and encouraged** to use an **AI coding assistant** in your own local IDE. - The goal is to complete a **practical engineering task** while demonstrating how you use AI to **build, test, debug, and iterate** under time pressure. You want to know how to prepare for this format, what to have set up beforehand, and what kind of task to expect. ### Constraints & Assumptions - **Time-boxed:** a single onsite block (commonly 60–90 minutes including setup and discussion). - You must ship a **correct, maintainable** change and be able to **explain your tradeoffs**. - AI assistance is permitted, but you are still expected to demonstrate independent **engineering judgment and verification** — the AI is a tool, not the author of record. - You may be restricted on what code you can paste into external tools; assume some policy boundary may apply. ### Clarifying Questions to Ask These are questions a candidate should raise up front, with the recruiter or interviewer, before the session: 1. **Language/stack:** Is the starter code in a specific language/framework, or can I pick? Will I know it in advance so I can pre-configure my environment? 2. **Which AI tools are allowed:** Any specific assistant required or banned? Are there restrictions on pasting the provided code into a third-party tool? 3. **Environment:** Do I bring my own machine and IDE, or is it a provided/remote environment? Will dependencies and a test runner already be set up? 4. **Evaluation focus:** Is correctness the main bar, or are code quality, tests, and communication weighted heavily too? 5. **Scope of the task:** Roughly how large is the change expected to be — one function, one feature, a bug fix? 6. **Internet/docs access:** Can I look things up and read external documentation during the session? --- ### Part 1 — Preparation priorities What should you prioritize when preparing for an AI-assisted, starter-code-based coding interview? Identify the underlying skills being tested and how to train them, given that the AI removes much of the raw typing burden. ```hint Reframe what's being measured The AI can write code, so the interview is no longer testing recall of syntax. Ask: what's left to evaluate? Think **comprehending unfamiliar code fast, a tight build/test/debug loop, verification discipline, and supervising the AI** (catching hallucinations and API mismatches). ``` ```hint Drill the unfamiliar-codebase skill The hardest time sink is orienting in code you didn't write. Practice a repeatable orientation routine: find where **inputs enter**, where **core logic** lives, where **outputs** are produced, and how **tests** are organized. ``` #### What This Part Should Cover - Recognition that the bar shifts from "can you write code" to **engineering judgment, verification, and AI supervision**. - A concrete plan to get fast at reading/navigating an unfamiliar repo (entry points, layering, conventions). - Emphasis on a fast feedback loop (small diffs, frequent test runs) and on testing/verification discipline. - Awareness of communication: stating assumptions, tradeoffs, and what was verified. --- ### Part 2 — Tools and workflow to have ready Which tools and workflows (IDE setup, testing, debugging, linters/formatters, AI assistants) are most useful to have configured and rehearsed before interview day? ```hint Optimize for feedback speed The single biggest lever is how fast you can run **one test case**, not the whole suite. Memorize the targeted-run incantations for your stack (`pytest -k`, `npm test <pattern>`, `mvn -Dtest=…`) and have a debugger ready. ``` ```hint Make the AI a workflow, not a crutch Pick **one** assistant you're fluent with and rehearse three concrete uses: summarize unfamiliar code, scaffold tests in the repo's existing conventions, and propose a patch you then review. Decide your "trust but verify" checklist in advance. ``` #### What This Part Should Cover - A working local environment + debugger fluency (breakpoints, variable inspection, step-through) for the likely stack. - Fast code navigation (go-to-definition, find-references, ripgrep/IDE search) and targeted test execution. - Formatter/linter and a clean Git workflow (small commits, easy revert) so changes stay reviewable. - A rehearsed, tool-agnostic AI workflow with explicit verification (asking the AI what changes, why, edge cases, and how to verify) — plus awareness of policy limits on pasting code. --- ### Part 3 — Likely task types and per-type preparation In practice, do these tasks tend to be closer to **feature implementation**, **debugging**, **refactoring**, or **improving test coverage** — and how should you prepare for each? Note that a single task often blends several of these. ```hint Map each task type to a prep drill For each of the four, name the telltale prompt ("add an endpoint" = feature; "this test fails" = debug; "clean this up while adding X" = refactor; "your fix should include tests" = coverage) and the matching drill. Tie all four back to a common spine: **reproduce/understand → small change → verify with tests**. ``` #### What This Part Should Cover - Acknowledgement that tasks usually **blend** types, with feature implementation and debugging most common. - For **feature implementation:** follow existing repo patterns, write 1–3 tests, avoid introducing new architecture. - For **debugging:** reproduce reliably first, narrow via logs/bisection, fix with a regression test. - For **refactoring:** behavior-preserving small steps with tests green at each step; resist "boiling the ocean." - For **test coverage:** test public interfaces over internals; use parameterized/table-driven tests and clear boundaries (mocks/fixtures). --- ### What a Strong Answer Covers Across all three parts, a strong answer treats the AI as an accelerant under human supervision rather than as the thing being evaluated — and ties preparation, tooling, and task types back to one disciplined loop. - **Correct reframing:** the assistant removes typing, so the evaluation centers on judgment, verification, and the ability to catch AI mistakes. - **A repeatable working loop** that spans all parts: clarify requirements → run a baseline → plan small steps → use AI intentionally → verify continuously → summarize. - **Verification as the through-line:** never shipping AI output unread; using tests to reproduce bugs and prevent regressions. - **Pragmatism under time pressure:** small diffs, following repo conventions, and avoiding over-engineering / over-refactoring. - **Communication:** narrating assumptions, tradeoffs (quick fix vs. robust fix), and what was validated. ### Follow-up Questions 1. The AI suggests a patch that uses an API or function signature that doesn't exist in this codebase (a hallucination). Walk through exactly how you'd catch and recover from this without losing much time. 2. You're 15 minutes from the end and your change passes the happy path but you haven't covered edge cases. How do you decide what to prioritize, and what do you say to the interviewer? 3. The starter code has no existing tests and no test harness configured. How does that change your approach to verifying a feature or fix? 4. How would your process differ if pasting the provided code into your AI assistant were explicitly disallowed by interview policy?