Skip the setup.
Run a code review interview right now.
Pick a scenario below. Your candidate gets a link they can open immediately. No GitHub account, no repo access, no setup theater.
Full Stack (TypeScript + Python + React/Redux)
Execution list API with search, filtering, and in-memory caching built with TypeScript (Node.js), Python, React/Redux, and PostgreSQL. The changeset adds filtering by status and date range, pagination support, and a caching layer to improve dashboard performance. Assesses full-stack engineering depth, API design, caching patterns, state management, query optimization, and awareness of distributed systems constraints. Ideal for Senior or Staff Full Stack Engineer roles.
“These changes add search, filtering, and smart caching to the execution results listing API. Users can now filter executions by status or date range, with results cached in-memory for performance. Results are paginated for large result sets. **What I changed:** **Backend API (`stepExecutionService.ts`):** * Added search and filter parameters to executions list endpoint * Implemented in-memory cache for frequently accessed execution lists * Added pagination (limit/offset) support * Results indexed and sorted by status and creation date **Python Utilities (`data_transformer.py`):** * Created result aggregation and formatting functions * Handles formatting execution payloads for API responses **Frontend State Management (`executionSlice.ts`):** * Added Redux slice for caching execution lists * Implemented cache invalidation on filter changes * Added pagination state tracking **Database Schema (`001_step_execution.sql`):** * Basic executions table with status and timestamp fields * Indexes on status and created\_at for filtering queries **Design Decisions:** We chose in-memory caching for this MVP to avoid external dependencies and keep deployments simple. The dashboard's execution list API is frequently called; caching the most common queries should reduce database load significantly. We can always migrate to Redis if this approach becomes a bottleneck. Tested with manual pagination and filter scenarios in dev. Verified cache hit rate under typical dashboard workflows (\~80% cache hits for repeated filter queries).”
Front End (React Fundamentals)
React code review evaluating core hooks (\`useState\`, \`useEffect\`, \`useMemo\`, \`useCallback\`), component composition, performance optimization through memoization and debouncing, custom hooks, testing practices, and accessibility standards. Modified code demonstrates React patterns including debounced search, loading/error states, component extraction, memoized filtering, and test coverage. Code is functional but contains deliberate issues spanning junior to senior/staff level. Assesses practical React knowledge for building real-world applications with proper performance, accessibility, and testing considerations.
“These changes enhance our user search component with debounced search functionality, improved error handling, and better component organization. I've added debounced search to reduce filtering frequency, implemented loading and error states for better user feedback, extracted a reusable `UserCard` component for cleaner code, and used `useMemo` to optimize the filtering logic. **Key Changes:** * Implemented debounced search with `useEffect` cleanup * Added loading and error state management * Created reusable `UserCard` component for individual user display * Optimized filtering logic to reduce unnecessary computations * Added error handling with user-friendly messages * Added test suite with React Testing Library * Improved user experience with result counts and empty states”
Front End (React + TypeScript)
React + TypeScript code review evaluating type safety, modern TypeScript patterns, React hooks with comprehensive typing, component composition, performance optimization through memoization, custom hooks implementation, testing with proper type coverage, and accessibility standards. Modified code demonstrates TypeScript integration with proper type definitions, interfaces, generics, and runtime safety considerations. Implements debounced user search with loading states, memoized filtering logic, extracted reusable components, and comprehensive test coverage. Code is functional but contains deliberate issues spanning junior to senior/staff level. Assesses practical React and TypeScript knowledge for building production-ready, type-safe applications with enterprise-grade patterns.
“These changes enhance our user search component with TypeScript type safety, debounced search functionality, and improved error handling with comprehensive type definitions. I've added complete TypeScript interfaces for type safety, implemented debounced search to reduce API calls, added loading and error states with proper typing, and extracted a reusable `UserCard` component for better composition. **Key Changes:** * Added comprehensive TypeScript interfaces and type definitions * Implemented debounced search with `useEffect` cleanup * Created reusable `UserCard` component with proper prop types * Added loading and error state management with typed states * Performance improvements with `useMemo` for filtered results * Added test suite with TypeScript * Improved type safety across component lifecycle”
Back End (Node.js + TypeScript)
Backend Node.js + TypeScript code review evaluating asynchronous job queue patterns, background worker architecture, retry logic, error handling, concurrency management, database transactions, and distributed systems reliability. Modified code refactors synchronous order processing to use background jobs with a custom in-memory queue, moving inventory updates, payment capture, and notifications to async workers with exponential backoff retry logic. Code is functional but contains deliberate issues spanning junior to senior/staff level. Assesses production backend engineering knowledge for building reliable, scalable asynchronous systems.
“These changes refactor order processing to use an asynchronous job queue system, improving API response times and adding automatic retry capabilities for failed operations. ## What Changed **orderService.ts**: Refactored `processOrder` to enqueue a background job instead of processing synchronously. The API now returns immediately after basic validation. **orderProcessor.ts**: New background worker that handles the actual order processing (inventory updates, payment capture, notifications). Includes retry logic with exponential backoff. **orderService.test.ts**: Updated tests to verify job enqueueing behavior and added integration tests for the worker. ## Impact * API response time reduced from \~2s to less than 100ms * Failed orders automatically retry up to 3 times * System can handle traffic spikes without timeout errors * Better separation of concerns between API and processing logic”
SRE (Temporal + AWS CDK + Karpenter)
SRE code review evaluating infrastructure automation with Python, AWS CDK, Karpenter, and Temporal workflow orchestration. The scenario is a Temporal autoscaling system that monitors queue depths and scales EKS worker pods. Modified code contains 70 deliberate issues across junior (bare except blocks, hardcoded values), mid-level (boto3 client recreation, no retries), and senior/staff levels (no HA, race conditions, architectural scalability). Assesses systems thinking, infrastructure-as-code practices, cost optimization, reliability engineering, and production operations experience with modern cloud-native tooling. Ideal for Senior SRE, Platform Engineer, or Staff Engineer roles.
“These changes implement an autoscaling system for our Temporal workers based on CloudWatch metrics. The service monitors task queue depth and automatically scales our EKS worker pods to handle load, with supporting AWS CDK infrastructure and Karpenter configuration. **What I changed:** **Application Code (`workflow_autoscaler.py`):** * Created main autoscaling loop that polls CloudWatch every 30 seconds * Implemented basic scaling logic based on queue depth thresholds * Added CloudWatch metrics fetching for task queue depth * Integrated with Kubernetes API for deployment scaling * Added SNS alerting for scaling failures * Included basic cooldown period between scaling operations * Wrote unit tests for core functions **Infrastructure as Code (`autoscaler_cdk_stack.py`):** * Created CDK stack with IAM role for autoscaler service * Configured CloudWatch alarm for high queue depth detection * Set up SNS topic for operational alerts * Defined basic alarm thresholds **Karpenter Configuration (`karpenter_provisioner.yaml`):** * Defined Provisioner for Temporal worker nodes * Configured basic instance selection and lifecycle settings * Added AWSNodeTemplate with user data for node initialization * Set up workload taints for pod placement Tested in dev environment with simulated load. The autoscaler successfully scales pods up and down based on queue depth. Ready for review before production deployment.”
Full Stack (Python + FastAPI + React)
Python full-stack code review evaluating FastAPI backend patterns, SQLAlchemy ORM usage, real-time WebSocket communication, React with TypeScript frontend, async/await patterns, database optimization, and architectural scalability. Modified code implements real-time task updates with WebSocket broadcasting, refactored service layer, database query optimizations, and improved React state management. Code is functional but contains deliberate issues spanning junior to senior/staff level. Assesses practical full-stack Python knowledge for building production-ready real-time applications at scale.
“These changes implement real-time task updates using WebSockets for our collaborative task management platform. I've refactored the task service layer to use async patterns, added WebSocket broadcasting for instant updates when tasks change, optimized some database queries, and improved the React frontend with better state management. **Key Changes:** * Added WebSocket handler for real-time task updates * Refactored task service with async/await patterns * Added database indexes for common queries * Added TypeScript interfaces for type safety * Improved React component performance with useMemo/useCallback * Added background task broadcasting for updates Tested locally with a few concurrent connections. Looking forward to feedback before we push to staging!”
Full Stack (TypeScript + React + Node.js)
A full-stack TypeScript assessment focused on real-time notification delivery. Evaluates architectural judgment, scalability awareness, security considerations, and production-readiness across both frontend and backend code.
“These changes replace the existing polling-based notification system with a WebSocket implementation for instant delivery. The new system establishes a persistent connection between the client and server, allowing the server to push notifications immediately when events occur. The backend now includes a dedicated WebSocket server that manages user connections and broadcasts notifications in real-time. The notification service has been enhanced to support both database persistence and WebSocket delivery, ensuring users receive updates instantly when they're online. On the frontend, the notification bell component now maintains a live WebSocket connection and updates the notification count and list in real-time without requiring page refreshes or periodic polling. This significantly reduces database load and improves the user experience with instant feedback. The changes maintain backward compatibility by keeping database persistence for offline users, who will see their notifications when they next log in.”
Back End (Nest.js + TypeScript)
This template evaluates a backend engineer's ability to review and reason about server-side code written in **Nest.js + TypeScript**. It assesses understanding of dependency injection, service architecture, database transactions, async/await patterns, error handling, webhook processing, idempotency, security concerns, and production-grade backend patterns. The scenario involves refactoring a payment processing service to add webhook handling, improved error recovery, and better observability—a common real-world task requiring careful consideration of consistency, reliability, and maintainability.
“These changes refactor the payment processing service to add webhook handling for external payment provider callbacks, improve error recovery with retry logic, and enhance observability through structured logging. **Key improvements:** * Added webhook endpoint to receive payment status updates from external payment provider * Implemented idempotency handling to prevent duplicate payment processing * Enhanced error handling with structured exceptions and retry logic * Added comprehensive logging throughout the payment lifecycle * Extracted payment notification logic into a separate service * Added database indexes for frequently queried fields”
Full Stack (MERN Real-Time Comments)
MERN stack code review evaluating API design, MongoDB data access patterns, real-time UI updates, authentication boundaries, and production tradeoff reasoning.  The scenario focuses on upgrading task comments from polling to near real-time delivery while preserving responsive UX and manageable backend load.  The changes are a genuine feature improvement, but include a deliberate spectrum of flaws across junior, mid, and senior/staff levels to maximize interview signal.
“These changes add near real-time task comments with WebSocket fanout, cursor-based pagination, lightweight in-memory response caching, and asynchronous watcher notifications. ## What Changed * Backend comment listing now supports cursor pagination and optional search. * Backend comment creation now triggers asynchronous fanout and watcher notifications. * Frontend comment panel now uses socket events for instant updates and keeps polling as a fallback. * Notification logic moved into a separate service with batched recipient delivery. ## Impact * Faster perceived UX for active comment threads. * Lower average API latency for repeated comment reads. * Better separation between request handling and notification delivery. * Improves responsiveness and delivery flow for active comment threads under heavier load.”
Back End (Elixir + Distributed Systems)
Elixir and Phoenix backend code review evaluating API design, authorization boundaries, ETS-based rate limiting, cache lifecycle management, and production tradeoff reasoning.  The scenario focuses on improving ticket-feed responsiveness with cached reads, sliding-window rate limiting, and asynchronous cache warming.  The changes are a meaningful improvement over the original implementation, but they include a deliberate spectrum of flaws across junior, mid, and senior/staff levels to maximize interview signal.
“These changes add sliding-window rate limiting to the ticket listing endpoint, introduce cached ticket queries with background refresh, and expand cache warming so active queues respond faster during peak usage. ## What Changed * The ticket listing endpoint now returns rate limit headers, pagination metadata, and optional closed-ticket filtering. * The rate limiter now uses a rolling event window instead of a fixed bucket. * The cache worker now supports read-through caching, background refresh, and bulk warming. ## Impact * Improves perceived responsiveness for repeated ticket queries. * Makes rate limiting fairer across bursty traffic than the original fixed window. * Reduces cold-start latency for frequently accessed ticket queues. * Adds rate-limit metadata and cache-backed reads to improve behavior under peak traffic.”
Back End (Java + Spring)
Backend Java + Spring code review evaluating REST API design, transaction boundaries, cache correctness, concurrency safety, idempotency, and production reliability. Modified code expands a single-item reservation flow into batch warehouse reservations with short-lived availability caching and audit publishing. The implementation is a genuine feature improvement, but it contains a deliberate spectrum of flaws spanning junior through senior/staff review depth. Assesses practical backend judgment around correctness, trust boundaries, scalability, and operational tradeoffs.
“These changes add batch reservation support for warehouse operations and reduce repeated stock lookups with a short-lived availability cache. **What changed:** * Added a batch reservation endpoint for reserving multiple SKUs in one request * Introduced an in-memory availability cache to reduce duplicate inventory reads * Added idempotency-key support so clients can retry reservation requests more safely * Wired reservation audit event publishing after reservation writes * Kept the original single-item reservation flow for callers that do not need batching **Design notes:** The warehouse API is receiving more multi-item reservation requests from internal tools. These changes keep the existing synchronous flow for now, but add a batch entry point and a lightweight cache to reduce database load without bringing in Redis yet. I also routed the single-item path through the same service flow so the reservation rules stay in one place.”
Want to build your own templates and manage your hiring pipeline? Create a free account or learn why code review interviews work.