AI Coding Interview Questions for Software Engineers

THE QUESTIONS

Real questions, senior answers

1. 01

   Walk me through your AI-assisted development workflow.

   Before AI: refinement, planning, two weeks of implementation, tests at the end, code review, deploy. With AI the implementation phase shrinks and planning grows. I plan with a coding agent — mostly Claude Code, lately Kimi — ask for two or three versions of the design, and question the trade-offs on performance and state. Once the plan is solid, implementation is fast.

   workflowClaude-Codeplanning
2. 02

   How does AI coding change the other phases of the development lifecycle?

   Testing and review get bigger. AI-written tests are often false positives: 100% coverage, all green, application still broken — agents over-optimize locally against whatever context they have, so covering a component does not mean the tests make logical sense.

   Pull requests get bigger too, so review grows. I run CodeRabbit on the PR, feed its comments back to Claude Code, and make the agent evaluate which suggestions are worth implementing before I review myself.

   testingcode-reviewCodeRabbit
3. 03

   Besides Claude Code, what are your favorite AI coding tools?

   Claude Code is the market leader — flaky (I have hit memory leaks), but connected to Opus it gives the best performance. I also use OpenCode and Kimi: the model is weaker but the interface is more stable. Watch Kimi though — it can commit to master without telling you, so lock your master branch before adopting it.

   These are all TUIs, and text-in, text-out is a poor way to understand a codebase. I use agents for planning and implementation; for review I move to an IDE — Cursor or Zed — because I need to see the code to refactor.

   Claude-CodeKimiZedtooling
4. 04

   Do you use AI-powered tools for code reviews?

   Yes — CodeRabbit on every pull request. It nitpicks and it is not 100% accurate, but it catches edge cases the coding agent missed, and it has an MCP so the findings feed straight back to the agent.

   My review order: tests first, then static analysis — code duplication, cyclomatic complexity, and whether the PR regresses the overall quality metric — then dynamic checks: end-to-end tests, then unit tests. You still review manually, because if you tell a model to reduce complexity it may hit the metric and break the function.

   CodeRabbitstatic-analysiscyclomatic-complexity
5. 05

   What structures and processes do you use to get stable, consistent output from AI coding?

   My mindset shifted from reviewing components to reviewing how we build components — the factory of code matters more than the code. In the frontend I check state first, then component structure, then the blast radius of the change; anything touching global state gets full attention. Then a performance pass against Core Web Vitals to catch re-render and caching mistakes.

   In the backend, program against APIs. I hand-review the REST endpoints, modularization, and the database schema — models write bloated schemas and bad migrations, and a bloated ORM declaration becomes slow SQL. Then I make the model produce sequence diagrams per endpoint. With API schema on one side and database on the other, any model mistake is sandwiched in between and stays localized.

   stateRESTdatabase-schemasequence-diagrams
6. 06

   What are the most dangerous AI code smells?

   Missing modularization is number one: 15 components in one file, functions declared inside functions. Number two is over-generalization — tell a model to "write cleaner code" and it abstracts too early. Classic case: a five-field form turned into an array plus a map, which breaks JSX caching, messes with React fiber, and is harder to debug than just writing the markup.

   Also: code duplication in the backend instead of shared utilities, false-positive and empty tests written to fill coverage, and architecture drift — like hardcoding a pixel value where the codebase uses a Tailwind design token. The token is a one-line global change; the hardcoded value is a codebase-wide hunt.

   code-smellsover-abstractionTailwindtesting
7. 07

   Do you have a mental checklist for reviewing AI-written code?

   Frontend: check global state changes first, then component structure, then architectural drift — for example, does the code follow the codebase's CSS convention, or did the model invent a third strategy? Then review the tests before the logic.

   Backend: manually check any change to the REST API or the database schema. Then skim the rest for code style, not line by line: real immutability versus mutated local variables, too much abstraction, duplicated logic. Tools measure duplication and complexity; you decide whether to add rules or fix by hand.

   code-reviewstateRESTimmutability
8. 08

   How do you choose what to delegate to AI, what to verify, and what to build yourself?

   Decide by blast radius. I own the core data structures myself: frontend state, the database schema, and the REST API shape — a mistake there can break the whole application and every client on the API. Note the API and the database should not have the same shape; their constraints are different, and if they match, something is wrong.

   I delegate the declarative code in between — given the API and the schema, models fill that gap well. I build by hand anything I do not understand deeply (a recent SVG graph was impossible to get right with AI) and delegate things I understand but do not remember the syntax for, like writing a Dockerfile.

   delegationblast-radiusdatabase-schema
9. 09

   A junior dev on your team pushes huge AI-written pull requests. How do you handle it?

   I skim the PR. More than five code smells and I stop reviewing — otherwise I am QAing their code and they are just a proxy to Claude Code. I take it private: 30 minutes, have them explain the code. If they did no thinking, they cannot explain it, and there is a social cost to that — but it stays recoverable because it is not public.

   Then fix the system: shared linter and formatter settings so diffs stay small, and a team culture where a big pull request is a sign of poor engineering. Speed is not scarce anymore; quality is.

   pull-requestsmentoringteam-culture
10. 10

    Would you enforce a fixed lines-of-code limit per pull request?

    No silver bullet — not all lines are equal. A thousand backend lines are much harder to review than a thousand lines of JSX that mostly open and close tags. Infrastructure changes I always call out regardless of size.

    What matters is sampling. AI mistakes propagate: if the same CSS mistake is in three files, it is everywhere, unlike a human reviewer's one-off. If 25% of the sample is bad, the rest is a projection — I stop there.

    pull-requestscode-review
11. 11

    Is AI coding different on a greenfield project versus a brownfield legacy codebase?

    Very. Greenfield has no real users, so you can move fast, even vibe-code the first proof of concept — rough architecture in the prompt, let the model write. Quality starts mattering when users arrive and bounce.

    Brownfield means the consequence of a production bug is expensive — insurance, banking, healthcare, payments, customer data. Code is cheap, but coding the wrong thing is expensive, and verification costs less than a production bug. There you review, refactor, and test yourself; the real productivity gain is maybe 10-15%. Use AI read-only to explain the legacy codebase — going slower makes you faster.

    greenfieldlegacyrisk
12. 12

    You run out of tokens in the middle of a critical feature. What do you do?

    Happened to me. First, check how far the code changes got. Then switch to a second coding agent on a different model so you do not depend on one company — I went from Claude Code to Kimi and it held up. Always keep two agents; they are unstable and you want no vendor lock-in.

    No agent at all? Use the time to onboard yourself on the changes made so far, review the plan, and bring it home by hand.

    coding-agentsvendor-lock-inKimi
13. 13

    What do you do while Claude Code is coding?

    I review another open pull request, review tests, or read the documentation of a new library we added — the wait is upskilling time, not staring time. Sometimes I spin up one parallel agent to explore the database.

    I do not run ten agents. That is a Silicon Valley flex: with that many you are just shipping whatever the agent produces, unsupervised — might as well hand the agent to the product manager. One or two agents max, or code quality drifts hard.

    coding-agentsparallel-agentsproductivity