🎙️ AI Tech Interview - Voice-Powered Interview Preparation Platform

• Overview
• Key Features
• How It Works
• Technology Stack
• Architecture
• Getting Started
• Azure Services Setup
• Project Structure
• Seniority-Based Question Generation
• Evaluation Metrics
• API Reference
• Offline Response Sync
• Testing
• Cost Estimation
• Documentation
• Roadmap
• Contributing
• License

AI Tech Interview is a fullstack application designed to help software developers prepare for technical interviews through realistic, voice-based practice sessions. The platform leverages Azure AI services to:

1. Generate tailored interview questions based on your target role and job description
2. Read questions aloud using natural-sounding neural voices
3. Record and transcribe your responses in real-time
4. Evaluate answers and provide detailed feedback with actionable improvements

Traditional interview preparation often lacks the pressure and spontaneity of real interviews. This platform bridges that gap by:

• 🎤 Voice-first interaction - Practice speaking your answers, not just writing them
• 🎯 Role-specific questions - Questions tailored to your exact target position and seniority level
• 📊 Objective feedback - AI-powered evaluation with consistent scoring criteria
• ⚡ Instant results - No waiting for feedback; get insights immediately after each session

(The voice-driven interview loop)

📸 See more visuals: Check docs/README.md for architecture diagrams, screenshots, and detailed component descriptions.

stateDiagram-v2
    [*] --> QuestionDisplayed
    QuestionDisplayed --> Recording : User Clicks "Start"

    state Recording {
        [*] --> CountingDown
        CountingDown --> Timeout : Timer reaches 0
        CountingDown --> ManualStop : User clicks "Stop"
    }

    Timeout --> Processing : Auto-save
    ManualStop --> Processing : Save

    Processing --> [*] : Transcript Ready

(State diagram of the recording process)

Key Points:

• ✅ User must press a button to start recording (gives time to think)
• ✅ Visible countdown timer shows remaining time (1-10 min based on category)
• ✅ Recording auto-stops when time runs out
• ✅ User can manually stop earlier if finished
• ✅ Whatever was spoken is saved and transcribed

• Turbopack by default - No need for --turbopack flag
• Server Actions - Seamless server-side operations without explicit API routes
• React 19 - Latest concurrent features and improved performance
• App Router - Modern file-based routing with layouts and nested routes
• Streaming - Real-time response streaming support
• TypeScript First - Excellent type safety and developer experience

(The hybrid architecture: A local Next.js app connecting to Azure AI services)

• Node.js 20.x or higher
• pnpm
• Azure subscription with:
  • Azure OpenAI Service access
  • Azure Speech Service resource
• Modern browser with microphone access (Chrome, Firefox, Edge recommended)

1. Clone the repository

git clone https://github.com/cristofima/AI-Tech-Interview.git
cd AI-Tech-Interview

2. Install dependencies

pnpm install

3. Configure environment variables

Copy the example file and update with your Azure credentials:

cp .env.local.example .env.local

Then edit .env.local with your values:

# Azure OpenAI Configuration
AZURE_OPENAI_ENDPOINT=https://your-resource.openai.azure.com/
AZURE_OPENAI_API_KEY=your-api-key
AZURE_OPENAI_DEPLOYMENT=gpt-5.4-mini
AZURE_OPENAI_MODEL=gpt-5.4-mini
AZURE_OPENAI_API_VERSION=v1

# Azure Speech Service Configuration
AZURE_SPEECH_KEY=your-speech-key
AZURE_SPEECH_REGION=eastus

💡 Terraform Users: Run terraform output -raw env_file_content > .env.local in the infra/ folder to auto-generate this file after provisioning.

Also set the PostgreSQL connection string and apply the schema:

# .env.local
DATABASE_URL=<your-postgresql-connection-string>

pnpm exec prisma generate
pnpm exec prisma db push

Use db push only for a new development database after reviewing the target. For an existing database, review the additive response-sync SQL, then apply it with pnpm exec prisma db execute --file prisma\sql\001_offline_sync_columns.sql. Do not use --accept-data-loss for this upgrade. Prisma CLI currently loads .env, not .env.local; provide DATABASE_URL through the shell environment or the existing .env configuration without committing credentials.

4. Run the development server

pnpm dev

Note: Next.js 16 uses Turbopack by default - no --turbopack flag needed!

5. Open your browser

Navigate to http://localhost:3000

1. Go to Azure Portal
2. Search for "Azure OpenAI" and click Create
3. Select your subscription and resource group
4. Choose a region (e.g., East US)
5. Provide a unique name for your resource
6. Select pricing tier (Standard S0)
7. Review and create

1. Navigate to your Azure OpenAI resource
2. Go to Model deployments → Manage Deployments
3. Click Create new deployment
4. Select model: gpt-5.4-mini, version 2026-03-17, deployment type Global Standard
5. Provide a deployment name (e.g., gpt-5.4-mini)
6. Set capacity within the available model quota for your active subscription

1. Go to Keys and Endpoint in your resource
2. Copy KEY 1 or KEY 2 → AZURE_OPENAI_API_KEY
3. Copy Endpoint → AZURE_OPENAI_ENDPOINT

1. Go to Azure Portal
2. Search for "Speech" and select Speech Services
3. Click Create
4. Select your subscription and resource group
5. Choose a region (e.g., East US)
6. Provide a unique name
7. Select pricing tier (Free F0 for development, Standard S0 for production)
8. Review and create

1. Go to Keys and Endpoint in your Speech resource
2. Copy KEY 1 → AZURE_SPEECH_KEY
3. Note the Location/Region → AZURE_SPEECH_REGION

Verify the model lifecycle and regional availability before provisioning. Global Standard can process requests outside the resource region.

The client defaults to the v1 GA API. AZURE_OPENAI_DEPLOYMENT is the deployment name; AZURE_OPENAI_MODEL is the underlying model name and defaults to gpt-5.4-mini. GPT-5 requests use max_completion_tokens and low reasoning effort, without temperature; reasoning consumes part of the completion budget. For an existing GPT-4 deployment with a custom name, set AZURE_OPENAI_MODEL explicitly to preserve its sampling parameters. A dated AZURE_OPENAI_API_VERSION still selects the legacy Azure client.

AI-Tech-Interview/
├── infra/                              # Terraform Infrastructure-as-Code
│   ├── main.tf                         # Azure resources (OpenAI, Speech)
│   ├── variables.tf                    # Input variables
│   ├── outputs.tf                      # Output values
│   ├── versions.tf                     # Terraform & provider versions
│   └── README.md                       # Infrastructure documentation
├── src/                                # Next.js source code
│   ├── app/                            # App Router (pages, layouts, API)
│   │   ├── api/                        # API Routes (sessions, responses, evaluate, speech)
│   │   ├── history/                    # Session history page
│   │   ├── interview/                  # Interview room page
│   │   ├── results/                    # Results dashboard page
│   │   ├── globals.css                 # Global styles + Tailwind theme
│   │   ├── layout.tsx                  # Root layout
│   │   └── page.tsx                    # Home page
│   ├── components/                     # React Components
│   │   ├── InterviewRoom.tsx           # Main interview logic
│   │   ├── OfflineStatusIndicator.tsx  # Sync status panel (pending / retrying / needs attention)
│   │   ├── ResponseSyncBadge.tsx       # Per-answer sync status
│   │   ├── PendingUploadsNotice.tsx    # Results-page warning for unsynced answers
│   │   ├── PermissionsCheck.tsx        # Mic/Speech permissions
│   │   ├── ScoreCard.tsx               # Result visualization
│   │   └── SessionForm.tsx             # Setup form
│   ├── generated/                      # Generated code (Prisma)
│   ├── hooks/                          # Custom Hooks
│   │   ├── useAudioRecorder.ts         # Audio recording logic
│   │   ├── useOfflineSupport.ts        # React binding for the sync controller
│   │   ├── useSpeechRecognition.ts     # Azure STT
│   │   └── useSpeechSynthesis.ts       # Azure TTS
│   ├── lib/                            # Libraries & Utilities
│   │   ├── azure-openai.ts             # OpenAI client
│   │   ├── azure-speech.ts             # Speech SDK
│   │   ├── offline-storage.ts          # IndexedDB store for recorded answers
│   │   ├── response-sync.ts            # Upload engine (claim → upload → confirm)
│   │   ├── sync-controller.ts          # Cross-tab coordination + scheduler
│   │   ├── response-submission.ts      # Server-side idempotent persistence
│   │   ├── prisma.ts                   # DB client
│   │   ├── prompts.ts                  # System prompts
│   │   └── utils.ts                    # Helpers
│   └── types/                          # TypeScript Definitions
├── prisma/                             # Schema + prisma/sql (manual schema changes)
├── tests/                              # unit (mocked) and integration (PostgreSQL) tests
├── public/                             # Static assets
├── scripts/                            # Utility scripts (diagrams, etc.)
└── docs/                               # Documentation & Images
    ├── diagrams/                       # Architecture diagrams
    └── screenshots/                    # Application screenshots

const config = {
  plugins: {
    "@tailwindcss/postcss": {},
  },
};
export default config;

@import "tailwindcss";

@theme inline {
  --color-background: var(--background);
  --color-foreground: var(--foreground);
  --font-sans: var(--font-geist-sans);
  --font-mono: var(--font-geist-mono);
}

{
  "compilerOptions": {
    "paths": {
      "@/*": ["./src/*"]
    }
  },
  "include": ["src/**/*.ts", "src/**/*.tsx"],
  "exclude": ["node_modules", "infra"]
}

import { dirname } from "path";
import { fileURLToPath } from "url";
import { FlatCompat } from "@eslint/eslintrc";

const __filename = fileURLToPath(import.meta.url);
const __dirname = dirname(__filename);

const compat = new FlatCompat({
  baseDirectory: __dirname,
});

const eslintConfig = [
  ...compat.extends("next/core-web-vitals", "next/typescript"),
];

export default eslintConfig;

When creating an interview session, users provide the following fields:

Note: Role Title and Job Description are mandatory. The Company Name is optional but can help tailor questions to the company's culture and tech stack.

Important: Both fields are mandatory. The system will not generate questions without a complete role title and job description. The seniority level (Junior, Mid, Senior) is extracted from the role title to ensure questions match the expected competency level.

Questions are generated to match the specified seniority level:

For a Senior FullStack .NET/Angular Developer role, the question distribution would be:

┌────────────────────────────────────────────────────────────┐
│                  10 INTERVIEW QUESTIONS                    │
├────────────────────────────────────────────────────────────┤
│  ████████████████████████████████████████ 70-80% Senior    │
│  ████████████                            20-30% Semi-Senior│
│                                           0% Junior        │
└────────────────────────────────────────────────────────────┘

Each question category has a recommended response time based on real interview scenarios:

Why 10 minutes max? In real interviews, System Design questions take 30-45 minutes. Since this is a practice tool where users prepare answers beforehand, 10 minutes allows for a condensed but realistic response covering: requirements clarification, high-level design, key components, and trade-offs.

How it works: When the user presses the "Start Recording" button, a visible countdown timer begins on screen. The recording automatically stops when the time limit is reached, or the user can manually stop it earlier. The system saves whatever the user managed to say within the time limit.

The AI uses this structured prompt to generate seniority-aligned questions:

const systemPrompt = `You are a technical interview expert specializing in software engineering roles.

CRITICAL RULES:
1. Questions MUST align with the seniority level specified in the role title
2. For Senior roles: 70-80% Senior-level questions, 20-30% Semi-Senior, 0% Junior
3. For Mid-level roles: 20% Senior, 60% Mid-level, 20% Junior  
4. For Junior roles: 0% Senior, 20% Mid-level, 80% Junior
5. Senior questions should test: architecture decisions, system design, leadership, mentoring
6. Never include junior-level questions for senior positions

Generate 10 interview questions based on the role and job description provided.

Output JSON format:
{
  "questions": [
    {
      "id": 1,
      "question": "...",
      "difficulty": "senior|mid|junior",
      "category": "technical|behavioral|system-design|problem-solving",
      "expectedTopics": ["topic1", "topic2"],
      "timeLimit": 240 // seconds (min: 60, max: 600)
    }
  ]
}

Time limit guidelines by category:
- technical: 60-240 seconds (1-4 min)
- system-design: 300-600 seconds (5-10 min)
- behavioral: 120-300 seconds (2-5 min)
- problem-solving: 120-360 seconds (2-6 min)`;

const evaluationPrompt = `You are an expert technical interviewer evaluating a candidate response.

CONTEXT:
- Role: {role}
- Seniority Expected: {seniority}
- Question: {question}
- Expected Topics: {expectedTopics}
- Candidate Response: {transcribedResponse}

EVALUATION CRITERIA:
Score each criterion from 0-100:

1. Relevance (25%): Does the answer directly address what was asked?
2. Technical Accuracy (25%): Are concepts, terminology, and best practices correct?
3. Clarity (20%): Is the answer clear, concise, and well-articulated?
4. Depth (15%): Does it show real-world experience and thorough understanding?
5. Structure (10%): Is there a logical flow (context → approach → outcome)?
6. Confidence (5%): Is speech fluent with minimal filler words?

SENIORITY EXPECTATIONS:
- For Senior roles: Expect architectural thinking, leadership examples, mentoring mentions
- For Mid-level roles: Expect solid technical execution and problem-solving
- For Junior roles: Expect foundational knowledge and learning attitude

Output JSON:
{
  "scores": {
    "relevance": 85,
    "technicalAccuracy": 90,
    "clarity": 75,
    "depth": 80,
    "structure": 70,
    "confidence": 85
  },
  "overallScore": 82,
  "performanceBand": "good",
  "feedback": {
    "strengths": ["Clear explanation of...", "Good use of..."],
    "improvements": ["Could elaborate more on...", "Consider mentioning..."],
    "suggestion": "To strengthen this answer, try using the STAR method..."
  }
}`;

POST /api/sessions
Content-Type: application/json

{
  "roleTitle": "Senior FullStack .NET/Angular Developer",
  "companyName": "Google",  // Optional
  "jobDescription": "We are looking for a Senior FullStack Developer..."
}

Response:

{
  "id": "sess_abc123",
  "roleTitle": "Senior FullStack .NET/Angular Developer",
  "companyName": "Google",
  "seniorityLevel": "senior",
  "createdAt": "2024-12-14T10:00:00Z",
  "status": "in-progress"
}

GET /api/sessions/{id}

Response:

{
  "success": true,
  "data": {
    "session": {
      "id": "sess_abc123",
      "roleTitle": "Senior FullStack .NET/Angular Developer",
      "status": "in-progress"
    },
    "questions": [
      {
        "id": 1,
        "question": "Describe how you would architect...",
        "difficulty": "senior",
        "category": "system-design",
        "timeLimit": 600
      }
    ]
  }
}

Note: timeLimit is in seconds. System Design questions get up to 600s (10 min) to allow for comprehensive architectural explanations, while Technical questions typically get 60-240s (1-4 min).

GET /api/speech/token

Response:

{
  "token": "eyJ0eXAiOiJKV1QiLCJhbGciOiJS...",
  "region": "eastus",
  "expiresAt": "2024-12-14T10:10:00Z"
}

POST /api/evaluate
Content-Type: application/json

{
  "sessionId": "sess_abc123",
  "responses": [
    {
      "questionId": 1,
      "transcription": "For a high-traffic e-commerce platform, I would design..."
    }
  ]
}

Response:

{
  "sessionId": "sess_abc123",
  "overallScore": 78,
  "performanceBand": "good",
  "evaluations": [
    {
      "questionId": 1,
      "scores": {
        "relevance": 85,
        "technicalAccuracy": 82,
        "clarity": 75,
        "depth": 78,
        "structure": 70,
        "confidence": 80
      },
      "overallScore": 79,
      "feedback": {
        "strengths": ["Good understanding of microservices patterns"],
        "improvements": ["Could mention specific .NET libraries"],
        "suggestion": "Consider discussing containerization with Docker/K8s"
      }
    }
  ]
}

Recordings use a write-ahead path, online or offline, so failed uploads retain a local copy for retry. Browser storage deletion, quota limits, or unavailable IndexedDB can still prevent durable storage; the direct-upload fallback is not persisted:

record → save to IndexedDB (pending) → upload → server confirms answer + audio → delete local copy
                                          │
                                          └─ failure → retry with backoff (5s · 3ⁿ, capped at 5 min)

Policies

• Idempotency – each recording gets a clientResponseId (UUID) when it is recorded. A retry after a lost acknowledgement returns duplicate and rewrites nothing.
• Ordering – each recording carries recordedAt. An older recording arriving after a newer one returns superseded and never overwrites it. Rows written by older builds (no recordedAt) are compared by completedAt.
• Replacement – a newer recording (updated) replaces the answer and audio and deletes the stale evaluation so the results page re-evaluates it.
• Audio integrity – the client sends audioSha256; the server verifies it (400 AUDIO_CHECKSUM_MISMATCH → retried) and echoes the stored checksum back. Uploads above 25 MB are rejected (413).
• Retries – network errors, 5xx, 408 and 429 retry forever with capped backoff; other 4xx (SESSION_NOT_FOUND, QUESTION_NOT_FOUND, …) mark the record rejected and wait for the user to retry or discard. After 5 failed attempts the UI flags the answer as needing attention.
• Recovery – a record claimed by a tab that closed or crashed mid-upload (expired lease, 60 s) is reclaimed by the next run. Atomic IndexedDB claims prevent simultaneous claims while a lease is valid; an expired lease can produce a repeated upload, which server idempotency handles.
• Concurrency on the server – submissions for the same question are serialised with a PostgreSQL advisory lock inside one transaction.
• Reload – the interview room merges local records for the session, so an answer saved on the device still shows as answered after a reload (the page itself still needs the network to load).

POST /api/responses/sync (multipart): questionId, sessionId, durationSeconds, transcription?, audio?, clientResponseId?, recordedAt? (unix ms), audioSha256?, audioMimeType?, recordedOffline?. Response 201 created / 200 updated | duplicate | superseded:

{
  "success": true,
  "data": {
    "outcome": "created",
    "responseId": "…",
    "syncedAt": "…",
    "audio": { "stored": true, "bytes": 48213, "sha256": "…" }
  }
}

pnpm test                                   # no services required
# Set DATABASE_URL to a dedicated test database in your shell first.
pnpm exec prisma db push
pnpm test:integration

No test talks to Azure OpenAI or Azure Speech; the integration suite creates its own session, runs, and deletes it.

Model: gpt-5.4-mini (version 2026-03-17), Global Standard.

Use the current Azure OpenAI pricing for your region, currency, and agreement. Estimate input, cached input, output, and reasoning usage; previous GPT-4o-mini estimates do not apply.

Terraform defaults to 30 capacity units. TPM/RPM conversion and quota are model- and subscription-specific; verify them before deployment rather than assuming 30K TPM or 3,000 requests/minute.

Default SKU: S0 (Standard) - Pay-as-you-go

Example Usage:

• 100 questions ≈ 50K TTS characters ≈ $0.80 (or free with F0)
• 100 responses ≈ 2 hours STT ≈ $2.00 (or free with F0)

Calculate totals from measured GPT-5.4-mini token usage plus Speech consumption and state storage. A session-count-only estimate is insufficient because reasoning and generated question counts vary.

1. Use F0 (Free) tier for Speech Service during development (500K TTS chars + 5 hours STT/month)
2. Reuse stable system prompts to benefit from model-supported prompt caching; verify the current cached-input price
3. Use dynamic quota for batch deployments to optimize capacity usage
4. Implement token counting and set usage limits per user/session
5. Cache topic extraction results for similar job descriptions
6. Monitor usage through Azure Portal > Cost Management + Billing

Comprehensive documentation is available in the docs/ directory:

• 📊 Architecture Diagrams - System architecture and interview flow visualizations
• 📸 Screenshots - UI walkthrough showing setup, interview, and results pages
• 📝 Lessons Learned - Technical challenges and solutions from building the platform
• 🏗️ Infrastructure Guide - Terraform deployment guide for Azure resources

Quick Links:

• View All Diagrams & Screenshots
• Lessons Learned - Real Technical Challenges
• Infrastructure Setup Guide

• Project architecture design
• Next.js 16 project setup with TypeScript
• Session creation with role & job description (mandatory fields)
• Azure OpenAI integration for question generation
• Seniority-aligned question logic
• Countdown timer per question (1-10 min based on category)
• Azure TTS for reading questions
• Azure STT for recording responses with auto-stop
• Basic evaluation with scoring
• Results display

• Audio waveform visualization
• Response playback feature
• Detailed feedback with charts
• Export results as PDF
• Dark/light theme support
• Pause/resume recording

• Multiple interview modes (behavioral, coding, system design)
• Practice history and progress tracking
• Custom question banks
• Real-time coaching during responses
• Multi-language support
• Team/enterprise features

Contributions are welcome! Please follow these steps:

1. Fork the repository
2. Create a feature branch (git checkout -b feature/amazing-feature)
3. Commit your changes (git commit -m 'Add amazing feature')
4. Push to the branch (git push origin feature/amazing-feature)
5. Open a Pull Request

pnpm test
pnpm typecheck
pnpm lint
pnpm build

pnpm test runs unit tests for IndexedDB storage, the response sync engine, the cross-tab sync controller, per-question status helpers, React sync components, server-side submission policy, and the sync route. IndexedDB and database writes are mocked; these tests do not access PostgreSQL or Azure. Controller tests use injected locks, channels, network events, and timers. React tests use jsdom and Testing Library with mocked network requests. Use pnpm test:watch during development.

vitest.config.mts also defines an integration project (pnpm test:integration) and a combined runner (pnpm test:all). PostgreSQL integration tests exercise audio persistence, repeated submissions, ordering, and concurrent retries. Set DATABASE_URL to a dedicated test database with the current schema before running them. The integration setup loads .env through dotenv/config, not .env.local; tests are skipped if no connection is configured. Tests create temporary sessions and remove their data afterward.

Before using this phase against an existing database, review and apply 001_offline_sync_columns.sql to the intended database. It adds five nullable columns and a unique index without dropping existing data. Applying this SQL does not create the rest of the application's schema. Regenerate the local Prisma client afterward:

pnpm exec prisma generate

The local response queue uses schema version 2, migrates existing recordings, leases uploads across tabs, and schedules retriable failures with exponential backoff. Terminal failures remain stored for explicit retry or discard.

SyncController adds startup recovery, automatic retry timers, network and visibility triggers, Web Locks coordination, and BroadcastChannel notifications. Without Web Locks, atomic IndexedDB claims still prevent simultaneous claims of the same recording. It exposes queue summaries and explicit retry/discard actions without including audio blobs in observable state. Call start() to activate coordination and stop() to remove listeners and timers.

useOfflineSupport now subscribes to the shared controller and starts coordination when mounted. InterviewRoom saves every answer locally before uploading, restores pending recordings into per-question state, and displays upload/retry status. If local storage fails, it attempts one direct upload; this fallback cannot persist or automatically retry the recording.

OfflineStatusIndicator exposes queue details, retry, and confirmed discard actions. PendingUploadsNotice warns when a results page has locally stored answers that the server has not confirmed. Reload results after uploads finish to include those answers. Automated checks cover the hook and status components with mocked browser dependencies, not a live microphone or Azure Speech session.

The sync endpoint persists audio bytes and their MIME type, size, and SHA-256 in PostgreSQL. It serializes submissions for the same question and session with a transaction-scoped advisory lock. clientResponseId identifies retries, recordedAt prevents older recordings from overwriting newer ones, and replacing an answer invalidates its old evaluation. The client deletes its local copy only after a confirmed acknowledgement with matching audio checksum (or size when Web Crypto is unavailable), or when the server reports that a newer answer supersedes it. The response retains responseId and syncedAt and adds outcome and audio confirmation metadata.

• Follow TypeScript best practices
• Use Server Components where possible
• Write meaningful commit messages
• Add tests for new features
• Update documentation as needed

This project is licensed under the MIT License - see the LICENSE file for details.

• Microsoft Azure AI Services for powerful AI capabilities
• Next.js for the amazing React framework
• Vercel for the Geist font family
• shadcn/ui for beautiful UI components
• Tailwind CSS v4 for utility-first styling