25+ Claude Code Interview Questions 2025: MCP, Agents, Hooks & SDK

By 2026, an estimated 70% of developers will use AI coding assistants daily—but there's a fundamental difference between autocomplete tools and agentic systems. While GitHub Copilot suggests code snippets, Claude Code autonomously executes multi-step tasks: searching codebases, modifying files, running tests, and creating commits. Understanding this paradigm shift is becoming essential interview knowledge for senior developers.

Table of Contents

1. Agentic Coding Fundamentals Questions
2. MCP Server Questions
3. Slash Commands Questions
4. Agents and Subagents Questions
5. Hooks and Lifecycle Questions
6. Security and Permissions Questions
7. Claude Agent SDK Questions
8. Git Workflow Questions
9. Plugins and Skills Questions
10. Practical Scenario Questions
11. Quick Reference

Agentic Coding Fundamentals Questions

These questions test your understanding of what makes Claude Code different from traditional AI coding tools.

What is Claude Code and how does it differ from GitHub Copilot?

Claude Code is an agentic coding assistant that autonomously executes multi-step tasks through terminal commands and file operations. The distinction runs deeper than just features—it's a different interaction model entirely.

GitHub Copilot, Tabnine, and Amazon CodeWhisperer operate as "smart autocomplete." They predict what you're about to type and suggest code snippets based on context. You remain the primary actor, writing code line-by-line with AI assistance.

Claude Code, by contrast, is an agentic system. You describe what you want to accomplish—"add rate limiting to all API endpoints" or "debug why the integration tests are failing"—and it independently plans and executes the necessary steps. It can grep through your entire codebase, read multiple files simultaneously, modify code across different files, execute terminal commands, run tests, and even create pull requests.

# GitHub Copilot Workflow
1. You: Open authentication.js
2. Copilot: Suggests function completion
3. You: Accept suggestion, type next line
4. Copilot: Suggests next line
5. You: Manually save, run tests, commit
6. (Repeat for each file)
 
# Claude Code Workflow
1. You: "Add JWT authentication to replace session-based auth"
2. Claude: Searches codebase for auth files
3. Claude: Reads relevant files, analyzes architecture
4. Claude: Modifies authentication.js, middleware.js, config.js
5. Claude: Runs tests, reports results
6. Claude: Creates commit with descriptive message
7. (All automated in one task)

This architectural difference means Claude Code excels at higher-level tasks—refactoring, debugging complex issues, implementing features across multiple files—while traditional extensions excel at reducing typing overhead during active code composition.

What is CLAUDE.md and how should it be structured?

CLAUDE.md is a project instructions file placed at your repository root that provides Claude Code with essential context about your project—build commands, architecture decisions, development workflows, and coding conventions. It persists knowledge across sessions, so you don't need to re-explain your setup every time.

Think of CLAUDE.md as onboarding documentation specifically written for an AI team member who will work autonomously on your codebase. The critical insight: Claude Code's system message explicitly states that instructions in CLAUDE.md "OVERRIDE any default behavior and you MUST follow them exactly as written."

## Project Overview
Multi-tenant SaaS platform using Clean Architecture.
Backend: Node.js/Express with TypeScript. Database: PostgreSQL with Prisma.
Frontend: React with Vite.
 
## Development Commands
 
### Local Development
npm run dev  # Starts both frontend and backend
 
### Testing
npm test                    # Run all tests
npm test -- auth.test.ts    # Specific test file
 
### Build
npm run build  # Production build with type checking
 
## Architecture Decisions
- Use named exports, never default exports
- All API endpoints follow REST conventions
- Business logic lives in /src/domain, never in controllers
- Tests go in __tests__ directories adjacent to source files
 
## Code Conventions
- Prefer composition over inheritance
- Use early returns to reduce nesting
- No console.log in production code—use the logger

CLAUDE.md is checked into version control, so sensitive information goes in environment variables or .env files (which CLAUDE.md can reference by name without exposing values).

MCP Server Questions

The Model Context Protocol is where Claude Code becomes genuinely extensible. These questions test understanding of external tool integration.

What is MCP and what transport types does Claude Code support?

MCP (Model Context Protocol) is an open protocol that enables Claude to securely connect to external data sources and tools. Claude Code supports three transport types: stdio for local processes (most common), HTTP with Server-Sent Events for remote servers, and WebSocket for real-time bidirectional communication.

MCP servers act as bridges between Claude and external resources. When you configure an MCP server, you're essentially giving Claude permission to interact with specific tools, databases, or services through a standardized interface.

Stdio (standard input/output) is for local processes running on your machine—communication happens via stdin/stdout streams. Think of local file system servers or database clients that run alongside your terminal.

HTTP/SSE (HTTP with Server-Sent Events) is for remote servers accessible via HTTP. The server-sent events enable server-to-client streaming for real-time updates from cloud-based data sources or remote APIs.

WebSocket maintains persistent bidirectional connections for real-time communication. Use this for streaming services or collaboration tools where both client and server need to send messages at any time.

{
  "mcpServers": {
    "filesystem": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-filesystem", "/path/to/allowed/directory"],
      "transport": "stdio"
    }
  }
}

How do you configure authenticated MCP servers securely?

Configure authenticated MCP servers using environment variable substitution with ${VARIABLE_NAME} syntax. Never hardcode credentials in configuration files. Use the env object for passing environment variables to local processes, and the headers object for HTTP authentication headers.

For a GitHub MCP server that needs a personal access token:

{
  "mcpServers": {
    "github": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-github"],
      "transport": "stdio",
      "env": {
        "GITHUB_TOKEN": "${GITHUB_PERSONAL_ACCESS_TOKEN}"
      }
    }
  }
}

For HTTP-based servers requiring Bearer token authentication:

{
  "mcpServers": {
    "api-server": {
      "url": "https://api.example.com/mcp",
      "transport": "http",
      "headers": {
        "Authorization": "Bearer ${API_TOKEN}",
        "X-API-Key": "${API_KEY}"
      }
    }
  }
}

The ${VARIABLE_NAME} syntax tells Claude Code to read the value from your environment variables at runtime, keeping the actual tokens out of files that might be committed or shared.

Slash Commands Questions

Custom slash commands enable personalized workflow automation. These questions test your ability to create reusable, maintainable automation.

How do you create custom slash commands in Claude Code?

Custom slash commands are Markdown files stored in .claude/commands/ (project-level) or ~/.claude/commands/ (personal). The filename becomes the command name—commit.md becomes /commit. Files can include YAML frontmatter for metadata like description, allowed-tools, and argument-hint, plus the prompt template that gets expanded when invoked.

---
description: Stage changes and create a commit with conventional format
allowed-tools: Bash(git add:*), Bash(git status:*), Bash(git commit:*), Bash(git diff:*)
argument-hint: [type] [message]
---
 
Current repository status:
!`git status --short`
 
Recent commits for style reference:
!`git log -5 --oneline`
 
Staged changes:
!`git diff --staged`
 
Create a commit following these rules:
1. Type must be one of: feat, fix, docs, style, refactor, test, chore
2. Message should be imperative ("Add feature" not "Added feature")
3. Keep the subject line under 72 characters
4. Include the Co-Authored-By line for Claude
 
Commit type: $1
Message guidance: $2

The frontmatter restricts which tools the command can use—only specific git operations, nothing else. The !`command` syntax executes bash commands and injects their output into the prompt, giving Claude context about the current repository state.

What is the difference between @file and !command syntax?

These two syntaxes serve different purposes. @file includes the contents of a file directly in the prompt—@src/config.js would inject the JavaScript source code. !`command` executes a shell command and includes its output—!`git status` would run git status and inject the result.

Use @file for static context (configuration files, source code you want reviewed). Use !`command` for dynamic context (current git state, test output, system information).

Agents and Subagents Questions

Understanding the agent system is essential for productive Claude Code usage. These questions test knowledge of task delegation.

What is the difference between commands and agents?

Commands are user-initiated shortcuts that inject prompts into your main conversation thread. Agents (subagents) are autonomous, specialized AI instances that operate in isolated context windows to handle complex multi-step tasks independently.

Think of commands as macros or keyboard shortcuts—they expand into actions in your current context. Agents are more like specialized team members you assign work to. When you delegate to an agent, it works in parallel without cluttering your main conversation with intermediate steps.

The isolation is key. Each subagent has its own context window, which means all the files it reads and searches it performs don't consume space in your main conversation. For complex tasks like "research all the authentication libraries we're using and write a security audit," an agent can consume 100K tokens of context exploring the codebase while your main session stays focused.

What is the Explore subagent and when does it activate?

The Explore subagent is a built-in, Haiku 4.5-powered agent specialized for fast, read-only codebase exploration. It automatically triggers when Claude needs to search or understand code without making changes, keeping exploration results out of your main context.

If you ask "how does our authentication middleware work?" or "find all the places we use the deprecated API," Claude delegates to the Explore subagent rather than handling it directly. The Explore agent has access to read-only tools: ls, git status, git log, find, cat, head, tail. It cannot modify files, run builds, or execute tests.

This design serves two purposes. First, it keeps your main conversation clean—the Explore agent might read 50 files to answer your question, but only the summary comes back to your main thread. Second, it's faster because Haiku is optimized for quick turnaround on search-and-discovery tasks.

How do background agents enable parallel work?

Background agents run asynchronously in separate context windows, allowing you to continue working while long-running operations complete. Use them for research, code reviews, test runs, or any task that would otherwise block your workflow.

Imagine you're implementing a feature that requires understanding a third-party API's authentication flow:

1. Spawn a research agent to explore the API documentation
2. Continue writing your implementation with best-guess assumptions
3. When the research agent completes, it notifies your main session
4. Adjust your implementation based on findings

The keyboard shortcut Ctrl+B runs any suggested command in the background. For programmatic execution, use run_in_background: true. Check running tasks with /tasks.

Hooks and Lifecycle Questions

Hooks are Claude Code's extension points for injecting custom behavior. Security-conscious organizations care deeply about this system.

What lifecycle events are available in Claude Code hooks?

Claude Code provides lifecycle events including SessionStart (when a session begins), Stop (when it ends), SubagentStop (when a subagent completes), and PreToolUse/PostToolUse (before and after tool execution). Hooks execute shell commands in response to these events.

Here's a practical example that blocks commits containing potential secrets—exactly the kind of safety mechanism enterprises want:

{
  "hooks": {
    "PreToolUse": [
      {
        "matcher": "Write|Edit",
        "hooks": [
          {
            "type": "command",
            "command": ".claude/hooks/prevent-secrets.sh"
          }
        ]
      }
    ]
  }
}

The hook script scans for patterns like AWS keys, GitHub tokens, or private key headers:

#!/bin/bash
FILE_CONTENT="$2"
 
# Secret patterns
if echo "$FILE_CONTENT" | grep -qE 'AKIA[0-9A-Z]{16}|ghp_[0-9a-zA-Z]{36}|-----BEGIN.*PRIVATE KEY-----'; then
    echo "ERROR: Potential secret detected"
    exit 1
fi
 
exit 0

A non-zero exit code blocks the operation. This prevents Claude from accidentally writing secrets to files that might be committed.

How does CLAUDE_ENV_FILE enable dynamic configuration?

CLAUDE_ENV_FILE is an environment variable pointing to a temporary file where hooks can export environment variables for the current session. Hooks write KEY=value pairs to this file, and Claude Code loads them automatically.

A common use case is session initialization that detects project type and configures appropriate variables:

#!/bin/bash
# .claude/hooks/session-start.sh
 
if [ -z "$CLAUDE_ENV_FILE" ]; then
    exit 0
fi
 
# Detect project type
if [ -f "package.json" ]; then
    echo "NODE_PROJECT=true" >> "$CLAUDE_ENV_FILE"
    echo "PACKAGE_MANAGER=$(command -v yarn >/dev/null && echo 'yarn' || echo 'npm')" >> "$CLAUDE_ENV_FILE"
fi
 
if [ -f "pyproject.toml" ]; then
    echo "PYTHON_PROJECT=true" >> "$CLAUDE_ENV_FILE"
fi

This lets Claude automatically know which package manager to use, what test framework is available, and other project-specific context—without repeating it in every session.

Security and Permissions Questions

Security questions are increasingly common as companies deploy AI tools with real system access. These questions test awareness of implications.

How should you apply the principle of least privilege in plugin development?

Grant plugins only the minimum permissions necessary. Explicitly list each required tool in allowedTools rather than using wildcards. Restrict file access to specific directories with allowedPaths. Avoid patterns like mcp__* that grant access to all MCP server tools.

{
  "mcpServers": {
    "my-plugin": {
      "command": "node",
      "args": ["./plugin.js"],
      "allowedTools": [
        "Read",
        "Grep",
        "mcp__github__get-issue"
      ],
      "allowedPaths": [
        "/home/user/projects/my-repo"
      ]
    }
  }
}

Compare this to the dangerous alternative: "allowedTools": ["*"]. The wildcard grants access to every tool including Write, Edit, Bash—far more than a code analysis plugin needs. If the plugin is compromised or behaves unexpectedly, the blast radius is enormous.

How do you prevent path traversal attacks in Claude Code plugins?

Settings files should have chmod 600 permissions (owner read/write only) because they often contain credentials. Prevent path traversal by validating paths against an allowlist, rejecting .. patterns, and always resolving to absolute canonical paths before access.

const path = require('path');
 
const ALLOWED_PATHS = [
  '/home/user/projects/my-repo',
  '/home/user/documents/safe-data'
];
 
function isPathAllowed(requestedPath) {
  const resolvedPath = path.resolve(requestedPath);
 
  return ALLOWED_PATHS.some(allowedPath => {
    const resolvedAllowed = path.resolve(allowedPath);
    return resolvedPath.startsWith(resolvedAllowed + path.sep) ||
           resolvedPath === resolvedAllowed;
  });
}

The key is resolving paths before checking them. An attacker might request /home/user/projects/my-repo/../../../etc/passwd, which looks like it starts with an allowed path until you resolve it.

Claude Agent SDK Questions

For developers building AI-powered applications, these questions test whether you can move from using Claude Code to building with it.

What are the two official Claude Agent SDKs?

The two official SDKs are the Python SDK (claude-agent-sdk, installed via pip, requires Python 3.10+) and the TypeScript SDK (@anthropic-ai/claude-agent-sdk, installed via npm, requires Node.js 18+). Both provide the same tools, agent loop, and context management that power Claude Code.

Python:

from claude_agent_sdk import ClaudeSDKClient
 
client = ClaudeSDKClient(api_key=os.getenv('ANTHROPIC_API_KEY'))
response = client.run("Analyze this codebase and suggest improvements")

TypeScript:

import { ClaudeAgent } from '@anthropic-ai/claude-agent-sdk';
 
const agent = new ClaudeAgent({
  apiKey: process.env.ANTHROPIC_API_KEY
});
 
const result = await agent.run("Analyze this codebase and suggest improvements");

How should API keys be stored securely for the SDK?

Store API keys in .env files loaded via environment variables. Never hardcode keys. Never commit .env files. Include .env.example in version control showing required variable names without values.

# .env (NEVER COMMITTED)
ANTHROPIC_API_KEY=sk-ant-api03-xxx
 
# .env.example (COMMITTED)
ANTHROPIC_API_KEY=your-api-key-here

# .gitignore
.env
.env.local
*.local.json

Loading in Python:

from dotenv import load_dotenv
import os
 
load_dotenv()
api_key = os.getenv('ANTHROPIC_API_KEY')
 
if not api_key:
    raise ValueError("ANTHROPIC_API_KEY environment variable not set")

Git Workflow Questions

Claude Code's git integration is one of its most practical features for daily development. These questions test understanding of automated workflows.

How does Claude Code automate commit and PR creation?

Claude Code automates git workflows by running git status and git diff in parallel to analyze changes, learning commit style from git log, staging relevant files, generating contextual commit messages, and using gh CLI to create pull requests with comprehensive summaries based on all commits in the branch.

When you ask Claude to create a commit, it first examines your repository's recent history:

git log -20 --pretty=format:'%s'

From this, it extracts patterns: Do you use conventional commits (feat:, fix:)? Imperative mood or past tense? Capitalization after prefixes? It then drafts messages that match your existing style.

Every Claude-generated commit includes attribution:

feat(auth): add email validation to login flow

🤖 Generated with Claude Code

Co-Authored-By: Claude <noreply@anthropic.com>

Plugins and Skills Questions

The plugin and skills architecture is where Claude Code becomes genuinely extensible. These questions test understanding of the extension model.

What is the Skills system and how does it differ from slash commands?

Skills are specialized capabilities packaged as directories containing a SKILL.md file with instructions and optional supporting files. Unlike slash commands (user-invoked), Skills are model-invoked—Claude decides when to activate them based on matching task descriptions to skill descriptions.

At session start, Claude loads only skill names and descriptions (~30-50 tokens each) into its context. When a user's request matches a skill's description, Claude invokes the Skill tool, which loads the full instructions. This keeps context usage efficient while providing deep specialization when needed.

A skill structure:

my-skill/
├── SKILL.md          # Required: Core instructions with YAML frontmatter
├── scripts/          # Optional: Helper scripts
├── references/       # Optional: Detailed documentation
└── assets/           # Optional: Templates, data files

What is CLAUDE_PLUGIN_ROOT and why is it important?

CLAUDE_PLUGIN_ROOT is an environment variable containing the absolute path to a plugin's installation directory. It enables plugin-relative path resolution across different installations and platforms.

Claude Code copies plugins to a cache directory rather than running them in-place. Without CLAUDE_PLUGIN_ROOT, plugins couldn't reliably reference their own files:

{
  "hooks": {
    "PostToolUse": [
      {
        "matcher": "Write|Edit",
        "hooks": [
          {
            "type": "command",
            "command": "$CLAUDE_PLUGIN_ROOT/scripts/format-code.sh"
          }
        ]
      }
    ]
  }
}

Practical Scenario Questions

These questions test ability to apply knowledge to realistic situations.

How would you create a test-build-release workflow?

Create a custom slash command with explicit sequencing and validation between steps:

---
description: Execute complete release workflow
allowed-tools: Bash(npm:*), Bash(git:*), Bash(gh:*)
argument-hint: [major|minor|patch]
---
 
# Release Workflow
 
Execute these steps in strict sequence. Stop immediately if any step fails.
 
## Pre-flight Checks
1. Verify we're on main branch
2. Verify working directory is clean
3. Verify we're up to date with remote
 
## Test Suite
1. Execute `npm test`
2. If ANY tests fail, STOP and report
 
## Build
1. Run `npm run build`
2. Verify build artifacts exist
 
## Version and Release
1. Run `npm version $1`
2. Push with tags
3. Create GitHub release with `gh release create`
 
If any step fails, report the error and DO NOT continue.

The key design principles: explicit ordering, validation checkpoints, fail-fast behavior, and clear tool scoping.

How would you debug a failing MCP server connection?

Follow a systematic approach:

1. Verify configuration files are valid JSON and point to the right locations
2. Check environment variables are actually set and exported
3. Test the server independently with debug flags enabled
4. Enable verbose logging in the MCP configuration:

{
  "mcpServers": {
    "my-server": {
      "command": "node",
      "args": ["dist/index.js", "--debug"],
      "env": {
        "DEBUG": "*",
        "LOG_LEVEL": "debug"
      }
    }
  }
}

5. Inspect stderr output where MCP servers log errors
6. For HTTP servers, test the endpoint directly with curl

Common failure modes: missing environment variables, timeout issues (increase MCP_TIMEOUT), stdout contamination (MCP servers must use stderr for logging), and authentication failures.

How would you implement standardized code reviews with Claude Code?

Create a two-tier solution. First, create a custom /code-review command that codifies your team's review checklist:

---
description: Review code with team standards
allowed-tools: Bash(git:*), Read, Grep
---
 
# Team Code Review Checklist
 
## Architecture
- [ ] Follows layered architecture
- [ ] Proper separation of concerns
 
## Code Quality
- [ ] Functions are single-purpose
- [ ] No magic numbers
 
## Security
- [ ] No hardcoded secrets
- [ ] Input validation present
 
Provide: required changes (blocking) and suggestions (non-blocking)

Second, create a specialized subagent for automated PR reviews that can run via GitHub Actions:

name: Automated Code Review
on:
  pull_request:
    types: [opened, synchronize]
 
jobs:
  review:
    runs-on: ubuntu-latest
    steps:
      - uses: anthropics/claude-code-action@v1
        with:
          mode: 'review'
          anthropic-api-key: ${{ secrets.ANTHROPIC_API_KEY }}

Quick Reference

Related Articles

• System Design Interview Guide - Scalability, reliability, and distributed systems
• TypeScript Type vs Interface - When to use type aliases vs interfaces