interviewDeck

Your one-stop platform to prepare, practice and ace your interviews.

Loading your questions…

interviewDeck

All Questions

Filters & tools

AI-Assisted Dev Interview Questions and Answers

30 hand-picked AI-Assisted Dev interview questions with detailed answers. Open the interactive version above to search, filter by difficulty, run code, bookmark questions and track your progress.

What is AI-assisted software engineering, and where does it help across the SDLC?

Using LLM-based tools (GitHub Copilot, Cursor, ChatGPT/Claude) to accelerate everyday dev work: scaffolding and boilerplate, inline code completion, generating unit tests, writing docs, explaining or refactoring unfamiliar code, drafting debugging hypotheses, and assisting code review.

It augments the developer — you remain responsible for design, correctness, security, and maintainability. It helps most on well-understood, repetitive, or boilerplate tasks and on onboarding to a new codebase; least on novel architecture and domain-critical business logic.

Helps: boilerplate, tests, docs, refactors, explaining code, debug hints
You own: architecture, correctness, security, review

How does an AI coding assistant (Copilot / Cursor) actually work under the hood?

It assembles a prompt from context — your current file, cursor position, open tabs, and (for repo-aware tools) snippets retrieved from your codebase via embeddings/RAG — and sends it to a code-tuned LLM that predicts the completion.

Copilot gives inline completions plus a chat panel. Cursor is an AI-first editor that indexes your whole repo for codebase-aware chat and multi-file/agentic edits. The output is a probabilistic suggestion, not verified-correct code — it doesn't compile or test it for you.

your file + cursor + open tabs + retrieved repo snippets (RAG)
        -> code LLM -> predicted completion (unverified)

GitHub Copilot vs Cursor vs chat assistants (ChatGPT/Claude) — how do they differ?

  • GitHub Copilot — inline autocomplete + chat embedded in your existing IDE; lightweight, stays in your flow.
  • Cursor — an AI-first editor with deep codebase indexing, multi-file and agentic edits, and repo-aware chat.
  • Chat assistants (ChatGPT / Claude) — general reasoning, explanations, and design discussion; not wired into your repo.

Rule of thumb: inline completion for flow, Cursor for repo-wide changes, a chat assistant for design/learning.

Copilot : inline completions + chat (your IDE)
Cursor  : AI editor, repo index, multi-file/agentic edits
ChatGPT/Claude : general reasoning, not repo-integrated

What are the benefits of AI-assisted coding, and where does it help most?

Faster boilerplate and scaffolding, unit-test generation, documentation, regex/SQL, translating between languages or frameworks, explaining unfamiliar code, and quick debugging hypotheses. It removes the blank-page problem and cuts context-switching to look things up.

The biggest wins are on repetitive, well-specified tasks and when onboarding to a new codebase — freeing your time for design and the genuinely hard problems.

What are the risks and limitations of AI-generated code?

  • Hallucinated APIs — plausible calls to methods/libraries that don't exist.
  • Subtly wrong logic that looks correct and passes a happy-path glance.
  • Security vulnerabilities — injection, weak crypto, missing validation.
  • Outdated patterns from stale training data.
  • License / IP contamination from memorised code.
  • Over-reliance that erodes your own understanding.

It has no true grasp of your domain or architecture and can't guarantee correctness — treat every suggestion as a draft to verify.

How do you ensure the quality and security of AI-generated code?

Never merge it blindly. Treat it like a junior developer's PR:

  • Review every line and make sure you understand it.
  • Test — run and extend unit/integration tests; don't trust AI-written tests that only assert the happy path.
  • Static analysis / SAST + linters and dependency/secret scanning.
  • Verify APIs exist and are used correctly; check for secrets, PII, and license issues.
  • Keep a human accountable in code review.

AI accelerates writing the code, not the responsibility for its correctness.

How do you write effective prompts for code generation?

Give the model what it needs to match your intent and conventions:

  • Context — language, framework + version, and the surrounding code/types.
  • A precise goal and constraints (performance, style, libraries allowed).
  • Examples of the desired output/style and the edge cases and error handling to cover.
  • Ask for tests alongside the code.

Iterate: feed back the compiler error or wrong output to refine. Small, well-scoped asks beat a vague "build me X".

// Weak:  'write a user service'
// Strong: 'Spring Boot 3 @Service for User CRUD over UserRepository,
//          constructor injection, throw NotFoundException on miss,
//          return DTOs, and include JUnit 5 tests for not-found.'

How do you use AI assistants for debugging, and what are the pitfalls?

Paste the error, stack trace, and the relevant code and ask for likely causes and fixes; ask it to explain unfamiliar code or suggest where to add logging. It's great at pattern-matching common errors quickly.

Pitfalls: it can invent a plausible-sounding cause, "fix" a symptom rather than the root cause, or hallucinate an API. Always verify its hypothesis against the actual code, reproduce the bug, and never apply a fix you don't understand.

How do you use AI for documentation and test generation effectively?

It's excellent for drafting docstrings, READMEs, and API docs, and for generating unit-test skeletons plus edge cases from a function signature — removing the blank-page problem.

But curate the output: docs can drift from what the code actually does, and generated tests may just assert that the code runs rather than that it's correct. Make tests assert meaningful behaviour, add the cases the AI missed, and re-read docs against the real implementation.

When should you NOT rely on an AI coding assistant?

  • Novel or complex architecture and domain-critical business logic.
  • Security-sensitive code (crypto, authentication) without expert review.
  • Anything where you can't verify correctness.
  • When it would send proprietary code or secrets to a non-approved service.
  • While learning fundamentals — over-reliance stunts skill.
  • Blindly accepting large multi-file edits you haven't read.

How do you integrate a pre-built AI service/API (OpenAI, Bedrock, Azure OpenAI) into an enterprise app?

Call it server-side via the SDK/REST — never expose API keys to the browser. Then treat it like any external dependency:

  • Secrets in a vault / env, not in code.
  • Resilience: timeouts, retries with backoff, rate-limit handling, and a fallback path.
  • UX: stream responses (SSE) for perceived speed.
  • Cost control: token budgeting, caching, and right-sizing the model.
  • Safety: validate/guardrail inputs and outputs; log and monitor usage.
// server-side
const res = await client.chat.completions.create({ model, messages });
// keys in vault, retry w/ backoff on 429, stream to client via SSE,
// cache + token budget for cost, validate output before use

How would you implement a RAG-based feature in an enterprise app?

Ground the LLM in your own data so answers are current and cite sources instead of hallucinating:

  1. Ingest your documents and chunk them.
  2. Embed the chunks and store vectors in a vector DB (pgvector, Pinecone, OpenSearch).
  3. At query time, embed the question, retrieve the top-k relevant chunks, and inject them into the prompt.
  4. The LLM answers grounded in that context; return citations.

Add access control on the corpus, and re-ranking/eval to improve quality. RAG keeps answers fresh without fine-tuning.

query -> embed -> vector search (top-k chunks)
      -> prompt = system + retrieved context + question
      -> LLM answer (+ citations)

What data-privacy and security concerns apply when using AI tools at work?

Prompts and code you paste may leave your network and be logged or used for training. So:

  • Never paste secrets, credentials, PII, or proprietary code into public/consumer tiers.
  • Use enterprise / zero-retention offerings or self-hosted models; respect data-residency and compliance.
  • Scan AI output for accidentally injected secrets.
  • Follow your org's approved-tool policy.

And when your app feeds untrusted content to an LLM, defend against prompt injection.

How do you measure the impact of AI-assisted development, and what are the caveats?

Track delivery outcomes — cycle time, PR throughput, DORA metrics (lead time, deploy frequency, change-fail rate) — plus suggestion acceptance rate and developer-experience surveys.

Caveats: lines written or suggestions accepted is a vanity metric — more code isn't better. Watch quality signals (defect/escape rate, review load, rework) so raw speed doesn't quietly trade off maintainability. Measure outcomes, not keystrokes.

What are project context files (CLAUDE.md / AGENTS.md / .cursorrules) and what belongs in them?

A file at the repo root that the assistant loads automatically on every session, so you stop re-explaining the same things.

Belongs in it: how to build/test/lint (exact commands), the architecture in a few lines, conventions the code does not make obvious ("we never use barrel files", "errors go through AppError"), directories that are generated and must not be hand-edited, and workflow rules ("stage, don't commit").

Does not belong: anything derivable from the code, giant API dumps, or aspirational rules the codebase itself violates — those cost tokens on every request and teach the model the wrong thing.

Keep it short and factual. A 60-line file that is true beats a 600-line one that is half stale, and it should be reviewed in PRs like any other code.

# CLAUDE.md

## Commands
- Build: `npm run build`
- Test a single file: `npm test -- path/to/file.spec.ts`

## Conventions
- State via NgRx signals store; no new BehaviorSubjects.
- `shared-data/` is generated — edit `content/` and run `build-manifest.mjs`.

## Workflow
- Stage changes with `git add`; never commit or push.

How is an agentic coding tool different from autocomplete, and how do you work with one?

Autocomplete predicts the next few lines in the file you are in. An agentic tool (Claude Code, Cursor agent mode, Copilot Workspace) runs a loop: read the repo, plan, edit multiple files, run tests and linters, read the failures, and iterate.

The skill shifts from writing code to specifying and verifying it:

  • Give it a feedback signal. An agent with a runnable test suite self-corrects; without one it produces plausible code and stops.
  • Ask for a plan first on anything non-trivial, and correct the plan — it's far cheaper than correcting 400 lines of diff.
  • Scope tightly. One coherent task per run. "Refactor the app" produces sprawl no one can review.
  • Review the diff, not the transcript. The explanation is always convincing; the diff is the truth.

What are hallucinated packages and APIs, and why are they a security problem?

Models confidently invent library names, functions and config options that don't exist — or that existed in an older major version. Most of the time you get an import error and move on.

The security angle is slopsquatting: hallucinated package names are repeatable, so an attacker can publish a real package under a name models commonly invent. A developer installs it because the assistant suggested it, and now untrusted code runs in their build.

Defences: verify a package exists and is maintained before installing (downloads, repo, last publish); prefer dependencies already in your lockfile; pin versions and use a lockfile; and lean on a private registry/allowlist in an enterprise. For APIs, check the actual docs for your installed version rather than trusting the signature.

How do you use AI for code review without making review worse?

What it does well: the mechanical pass — null handling, missed error paths, obvious injection and secret leakage, inconsistent naming, missing tests for a new branch, and summarising a large diff so a human reviewer starts oriented.

What it does badly: judging whether the change is the right change. It has no product context, no history of why the weird workaround exists, and no stake in the architecture.

How to keep it useful:

  • Post findings as suggestions, not blocking checks — an AI gate that fires on noise gets ignored within a week.
  • Tune for precision over recall; a reviewer who learns to skip the bot has lost all its value.
  • Give it the diff plus the surrounding files — reviewing a diff in isolation produces confident nonsense.
  • Keep human sign-off. The bot is a first pass, not an approver.

How do you use AI on legacy code and large migrations?

This is where assistants pay off most — the work is mechanical, well-specified and tedious.

Understanding first: have it explain a module, map call sites, and produce a dependency sketch before touching anything.

The safe migration loop:

  1. Characterisation tests first — pin down existing behaviour, bugs included, before changing code. Without this you cannot tell a refactor from a rewrite.
  2. Migrate one slice, review it closely, and turn the accepted result into the reference example.
  3. Repeat with that example in the prompt — consistency across hundreds of files comes from the exemplar, not from the instructions.
  4. Verify mechanically — tests, type checks, and ideally a behavioural diff between old and new.

Where it goes wrong: plausible-but-different semantics (null vs undefined, timezone handling, integer division), and silent drops of a rarely-hit branch.

How does MCP change an AI coding assistant's usefulness at work?

MCP (Model Context Protocol) is a standard way to expose tools and data to an assistant, so one integration works across clients instead of being rebuilt per vendor.

Practically it moves the assistant from "knows my files" to "knows my system": issue tracker, CI, logs and traces, database schema, design files, internal docs.

That changes the questions you can ask — "why did this build fail", "what changed in the schema since the last release", "summarise the errors this endpoint threw today" — because the answer needs live systems, not the repo.

Watch the security side: an MCP server runs with real credentials. Scope tokens to read-only where possible, prefer per-user auth over a shared service account, and remember that any tool returning external content (a ticket, a web page) is an injection vector into an agent that also holds write tools.

Why does TDD work particularly well with AI assistants?

Because tests are an unambiguous, machine-checkable spec — exactly what the model is missing when it guesses.

The loop: you (or the assistant, reviewed by you) write failing tests that encode the requirement; the assistant implements until they pass; you review the diff. The model now has a hard success criterion instead of "looks right", and it can iterate without you in the loop for every step.

The discipline that makes it safe:

  • You own the tests. If the model writes both tests and implementation, it can satisfy its own misunderstanding perfectly.
  • Confirm the test fails first, for the right reason. A test that passes against an empty implementation proves nothing.
  • Re-read any test change in the final diff — a weakened assertion is the most common way "all tests pass" becomes a lie.

How do assistants handle a codebase far larger than the context window?

They don't load the repo — they retrieve slices of it:

  • Embedding index — files chunked and embedded, semantically searched per request (Cursor's model).
  • Agentic search — the model uses grep/glob/read tools to navigate like a developer would, following imports and symbols (Claude Code's model). Slower per step, but it sees real current code rather than a possibly-stale index.
  • Structural signals — symbol/LSP data, call graphs, git history and recently-opened files to rank what's relevant.

What follows for you: clear module boundaries, descriptive names and a sane directory layout are now machine-readable documentation. A codebase where behaviour is spread across ten indirection layers is as hard for the assistant as for a new hire — and it will confidently edit the wrong copy if a stale duplicate exists.

What are the IP and licensing concerns with AI-generated code?

Three distinct questions, often conflated:

  1. Can it reproduce licensed code? Rarely, but memorised snippets from training data do surface. Vendors offer duplicate-detection filters and code-referencing features; enterprise tiers usually add IP indemnification.
  2. Who owns the output? Contractually the vendor generally assigns it to you — but purely machine-generated work may not be copyrightable in some jurisdictions, which matters if your product's value is the code itself.
  3. Does your input leak? Check the training clause. Consumer tiers may train on your data; enterprise tiers typically don't and offer zero retention.

What teams actually do: enable duplicate filtering, use enterprise tiers with indemnification for proprietary work, keep an internal policy on which tools may see which repos, and run normal licence scanning in CI regardless of who wrote the code.

How would you roll out AI coding tools across a team?

  1. Pick a scope, not a slogan. Start with a clear allowed/forbidden list: which repos, which data classes, which tools. Ambiguity produces shadow usage on personal accounts, which is the actual risk.
  2. Enterprise tier from day one — SSO, audit logs, no-training guarantees, admin controls.
  3. Pilot with a few volunteers across different areas (frontend, backend, QA), for 4–6 weeks, with a baseline captured beforehand.
  4. Codify what works — repo context files, prompt patterns and review norms shared as team conventions, not tribal knowledge.
  5. Keep the quality gates unchanged. Same review, same tests, same CI. If AI-assisted PRs need weaker gates, the tool isn't ready.
  6. Measure honestly — cycle time, change-failure rate, review load — and be willing to report a null result.

Which prompting patterns actually work for code?

  • Anchor on an existing file. "Write this the way user.service.ts does it" transfers conventions no instruction list can.
  • Constrain the shape up front — signature, file placement, allowed dependencies, whether tests are expected.
  • Ask for a plan before a large diff, and correct the plan.
  • Give it the real error — full stack trace, versions, and the code path — instead of describing the symptom.
  • Ask for the diff, not the whole file, on edits to large files: easier to review, less collateral rewriting.
  • Say what not to do. "Don't change the public API", "don't add dependencies", "don't touch the tests" prevent most unwanted scope.
  • Restart rather than argue. After two failed corrections the context is polluted; a fresh session with a better first prompt beats a third correction.

Where does AI belong in CI/CD, and where is it dangerous?

Reasonable: PR summaries and changelogs, review comments as suggestions, triaging flaky-test failures, drafting a fix branch for a Dependabot bump, clustering and summarising production errors.

Dangerous:

  • Auto-merging AI-authored changes — no human ever reads it.
  • Non-deterministic gates — a model deciding pass/fail makes CI flaky and unauditable.
  • Untrusted input reaching a privileged job. A PR from a fork whose description or diff contains instructions, processed by a job holding write tokens, is prompt injection with your deploy credentials.

Rules that keep it safe: AI jobs run with least privilege and never on secrets-bearing triggers for untrusted PRs; output is advisory; every AI-authored change goes through a normal, human-approved PR.

How do you manage the cost of AI development tools?

Two different bills: per-seat subscriptions (predictable) and token/usage-based agentic tools (very much not).

Usage costs concentrate in a handful of behaviours: repeatedly re-reading a large repo, long agent loops on vague tasks, and frontier models used for trivial edits.

Controls that work:

  • Per-user and per-team budgets with alerts, not just a monthly invoice review.
  • Model routing — cheap model for autocomplete and small edits, expensive model for hard reasoning.
  • Prompt caching for stable repo context, which is often the single biggest saving.
  • Scoping tasks — a well-specified task costs a fraction of an exploratory one.

For ROI, compare against the fully-loaded cost of engineering time, and be honest that the gains show up in cycle time and toil reduction, not in headcount.

Does heavy AI use erode engineering skill, and how do you guard against it?

It can, and the mechanism is specific: accepting working code you could not have written removes the struggle that builds the mental model. The visible symptom is an engineer who ships steadily but cannot debug their own feature when it breaks at 2am.

Habits that keep the skill:

  • Never merge code you can't explain line by line. That single rule covers most of the risk.
  • Predict before you read — decide how you'd solve it, then compare. The diff between your approach and the model's is the learning.
  • Turn off assistance deliberately when learning something new, and use it in "explain" mode rather than "write" mode.
  • Own debugging. Reading a stack trace and forming a hypothesis is the skill that doesn't transfer if you always delegate it.

The counter-point is real too: used as a tutor — explaining unfamiliar code, comparing approaches, generating practice problems — it accelerates learning considerably.

How should you talk about AI tool usage in an interview?

Assume the interviewer wants to hear judgement, not either extreme. "I don't use AI" reads as out of touch in 2026; "AI writes everything" reads as unaccountable.

What lands well:

  • A concrete example: what you delegated, what you kept, and why.
  • A failure you caught — a subtly wrong migration, a hallucinated API, a test that was weakened rather than fixed. This is the strongest signal you actually review output.
  • Awareness of the boundaries: data policy, licensing, and not pasting proprietary code into consumer tools.

For live coding: ask what's allowed before you start. Many companies now permit AI and evaluate how well you direct and verify it; using it silently when it was disallowed is a hard fail, and asking never costs you anything.

AI shifts work from writing to reviewing. What problems does that create?

Generation got ~10× cheaper; review did not. That asymmetry produces real failure modes:

  • Review becomes the bottleneck — bigger PRs, arriving faster, at unchanged human reading speed.
  • Automation bias — fluent, well-formatted, confident code gets a lighter review than the same code from a junior. The polish is not evidence.
  • No author intent. Normally you can ask "why did you do it this way?" With generated code, often nobody knows — the reasoning was never held by a person.
  • Volume-driven rubber-stamping — the classic outcome when throughput rises and review capacity doesn't.

Mitigations: enforce small PRs regardless of how fast they were produced; require the author to explain the change in their own words; strengthen mechanical checks (types, tests, lint, static analysis) so humans spend attention on design and correctness rather than style.