How to Interview Engineers Who Use Cursor, Claude Code, or Codex

Key takeaways

• Allow AI in the interview and score the candidate's judgment, not their typing speed.
• A live repo exercise gives better hiring signal than a no-AI take-home.
• Strong candidates verify generated code, reject weak output, and explain tradeoffs clearly.
• The best interview format tests implementation, debugging, code review, and communication in the same session.
• Stack-specific tasks matter, but the evaluation standard is the same across roles: understand the system, protect quality, and communicate decisions.

Interview engineers who use Cursor, Claude Code, or Codex by allowing the tool and testing how they reason with it. Use a short live session in a real repo that shows how they frame the task, steer the tool, verify output, debug failures, and explain tradeoffs.

If your team writes production code with AI assistance, the interview should reflect that reality. Developer surveys and industry reporting from GitLab, CodeSignal, and Stack Overflow all support the same practical takeaway: AI coding tools are now part of normal engineering workflows.

For a software team that is hiring, stop treating AI use as a trick question. Assume the candidate will use tools, then design the interview to reveal whether they still think like an engineer when the tool is in the loop.

Use a live repo-based interview

Use a live, repo-based session instead of a no-AI take-home. That format matches real work and gives cleaner signal on judgment.

A good session includes:

• Repo and task framing. Give the candidate a small starter repo, a short README, acceptance criteria, and a few constraints. Ask them to restate the task and explain their plan.
• A scoped implementation task with AI allowed. Let them use Cursor, Claude Code, Codex, docs, and search. Ask them to keep the screen shared and explain why they accept, edit, or reject suggestions.
• A debugging segment. Provide a failing test, broken request flow, rendering bug, or useful logs. Look for isolation of the issue instead of random trial and error.
• A short diff review. Give them a pull request with intentional problems. Ask what they would block, what they would comment on, and what they would merge.
• A tradeoff discussion. Ask what they would ship now, what they would defer, what they would test next, and what risks remain.
• Candidate questions. Leave space for them to ask about the codebase, the team, and delivery expectations.

This works because it mirrors the actual job. Engineers join an existing codebase, use tools, inspect output, debug under pressure, and communicate tradeoffs to other engineers.

Stop using no-AI take-homes as the main filter

A no-AI take-home is weak signal if the actual job allows AI. It tests behavior in an artificial environment instead of the workflow your team uses.

That usually creates two problems:

• Strong candidates treat the task as theater. The job includes tools, docs, and iteration. A blank-screen exercise often selects for interview performance more than production judgment.
• The interview rewards output volume. If you allow AI without changing the format, you mostly learn who can generate a lot of code fast. You learn less about whether they can evaluate it.

The better question is not whether the candidate can write code with no assistance. The better question is whether they can use AI without dropping the quality bar.

Score judgment instead of typing speed

Score judgment, not raw output. A shared rubric is enough if every interviewer uses the same definitions.

Use these categories:

• Problem framing
  • Finds constraints early.
  • Clarifies ambiguity.
  • Breaks the task into sensible steps.
• AI tool use
  • Writes clear prompts.
  • Uses the tool for draft work where it helps.
  • Verifies suggestions before keeping them.
• Debugging
  • Reproduces the issue.
  • Forms hypotheses.
  • Uses logs, tests, traces, and smaller checks instead of guessing.
• Code review judgment
  • Catches correctness issues first.
  • Notices security, maintainability, and performance risks.
  • Separates blockers from style opinions.
• Communication and tradeoffs
  • Explains what is known, what is assumed, and what remains risky.
  • Knows when a simple fix is enough and when design changes are needed.

A strong candidate does not need perfect output. They need to show that they can verify generated code, recover when the first attempt fails, and keep the system understandable for the next engineer.

Watch for dependence without understanding

The main red flag is not AI use. The main red flag is accepting AI output without an internal model of what the code does.

Watch for these patterns:

• They prompt well but inspect poorly. They get plausible code quickly but cannot explain why it works.
• They do not narrow the problem. They keep asking the tool to solve the whole task instead of isolating the failing part.
• They never challenge wrong output. Hallucinated APIs, stale framework patterns, broken tests, or bad package choices do not trigger skepticism.
• They optimize for code quantity. They add files, abstractions, or libraries before proving the simple path.
• They ignore operational edges. Validation, auth checks, logging, rate limits, and error handling do not register as risks.
• They treat every review comment the same. They cannot separate a blocker from cleanup.

Disqualifying behavior is usually obvious:

• Copying generated code into the repo without reading it.
• Exposing secrets or tokens in client code.
• Disabling tests to make the build look green.
• Speaking with certainty when the requirements are clearly ambiguous.
• Using AI to answer basic why questions about code they just wrote.

The best candidates use AI aggressively for draft work and slow down at boundaries such as interfaces, data flow, side effects, security checks, and tests.

Match the exercise to the stack

Keep the structure consistent and change the task to match the role. A frontend candidate should not spend the session buried in backend plumbing, and a backend candidate should not be judged on visual polish.

React interviews should test state, effects, and UI judgment

Use a small component tree with a real bug and a small feature request. Good tasks include an editable list, a search box with debouncing, or a form with optimistic updates.

Look for:

• Clear state ownership.
• Sensible component boundaries.
• Correct handling of async UI states.
• Testable logic.
• Awareness of rendering costs when it matters.

React red flags:

• useEffect used as a catch-all for logic that belongs elsewhere.
• Derived state stored when it can be computed.
• Unstable keys.
• Form state that drifts into inconsistency.
• Generated code that works once but is hard to reason about.

Next.js interviews should test server and client boundaries

Use a small app router repo with data fetching, a form submission path, and a caching decision. Ask the candidate to add a feature or fix a bug without leaking secrets or bloating the client bundle.

Look for:

• Correct use of server and client components.
• Awareness of caching and revalidation behavior.
• Good handling of route handlers, server actions, or API boundaries.
• A simple mental model of where code runs.

Next.js red flags:

• Putting secret values in client code.
• Fetching the same data on both server and client without a reason.
• Marking large trees as client components by default.
• Confusion about cache invalidation.
• Accepting generated boilerplate that does not match the current app router model.

Node interviews should test API design and failure handling

Use a small Express, Fastify, or Nest-style service with a basic endpoint and an integration edge. Ask for input validation, logging, or safe handling around duplicate or partial failure.

Look for:

• Clear request validation.
• Safe async error handling.
• Reasonable logging and response shape.
• Awareness of retries, duplicate requests, and partial failure.

Node red flags:

• Blocking work in the request path without noticing.
• Missing validation.
• Promise handling that hides failures.
• No distinction between client errors and server errors.
• Blind trust in generated middleware or libraries.

Python interviews should test clarity, data flow, and tests

Use a small service, script, or worker task. Ask the candidate to transform data, fix a failing test, or add a small endpoint.

Look for:

• Readable control flow.
• Solid test updates.
• Care with exceptions and edge cases.
• Typing where it improves understanding.

Python red flags:

• Swallowing exceptions.
• Hidden mutable state.
• Weak test coverage on the changed path.
• Large generated helper functions with unclear responsibility.
• Overuse of abstraction for a small task.

.NET interviews should test async, data access, and framework discipline

Use a small ASP.NET Core API with an EF Core query, a service layer path, and a failing test or bug.

Look for:

• Correct async patterns.
• Reasonable dependency injection usage.
• Awareness of query shape and overfetching.
• Comfortable handling of nullability and validation.

.NET red flags:

• Sync over async in request code.
• Ignoring cancellation or timeouts where they matter.
• Query issues left unnoticed.
• Pushing business logic into controllers.
• Accepting generated patterns that fight the existing project structure.

Replace the take-home round first

Start by swapping the take-home round for a live repo session. You do not need to redesign the full hiring loop at once.

Build these artifacts first:

• A starter repo for each role family.
• An interviewer guide.
• A shared scorecard.
• A seeded bug.
• A short diff review exercise.

This gives your team a more consistent interview and a better way to separate code generation from engineering judgment.

Boltout is a software agency.

If you want a second set of eyes, Boltout can scope a single role or review an interview workflow on a short call.

Sources

• https://www.boltout.co
• https://about.gitlab.com/developer-survey/
• https://codesignal.com/blog/
• https://stackoverflow.blog/
• https://cursor.com/pricing
• https://openai.com/api/pricing/