Interview StacksMaster every tech stack

Behavioral & Scenario-Based

Behavioral and scenario-based questions on debugging, migrations, architecture, and code review.

Open as page

Your React application is experiencing slow rendering. Walk through your debugging process.

Answer:

  1. Identify the Problem:

    • Use React DevTools Profiler to measure component render times
    • Check for unnecessary re-renders using React DevTools highlight updates
    • Monitor bundle size and initial load time
    • Use browser DevTools Performance tab to identify bottlenecks

  2. Common Causes & Solutions:

    • Unnecessary Re-renders: Use React.memo(), useMemo(), useCallback() to prevent unnecessary renders
    • Large Lists: Implement virtualization with libraries like react-window or react-virtualized
    • Heavy Computations: Move expensive calculations to useMemo() or Web Workers
    • Large Bundle Size: Implement code splitting with React.lazy() and Suspense
    • Memory Leaks: Check for uncleaned event listeners, timers, or subscriptions

  3. Debugging Tools:

    • React DevTools Profiler
    • Chrome DevTools Performance tab
    • Bundle analyzers (webpack-bundle-analyzer)
    • Lighthouse for performance audits

  4. Example Debugging Process:

    // Before: Component re-renders on every parent update
const ExpensiveComponent = ({ data, filter }) => {
  const processedData = data.filter(item => item.category === filter)
    .map(item => expensiveTransformation(item));
  return <div>{processedData.map(item => <Item key={item.id} data={item} />)}</div>;
};

// After: Optimized with memoization
const ExpensiveComponent = React.memo(({ data, filter }) => {
  const processedData = useMemo(() => 
    data.filter(item => item.category === filter)
      .map(item => expensiveTransformation(item)), 
    [data, filter]
  );
  
  const renderItem = useCallback((item) => <Item key={item.id} data={item} />, []);
  
  return <div>{processedData.map(renderItem)}</div>;
});
Open as page

How would you approach migrating a large JavaScript codebase to TypeScript?

Answer:

  1. Planning Phase:

    • Assessment: Audit the codebase to identify complexity, dependencies, and potential challenges
    • Strategy: Choose between gradual migration (file-by-file) vs. big-bang approach
    • Timeline: Create a realistic timeline with milestones and rollback plans
    • Team Training: Ensure team is familiar with TypeScript concepts and best practices

  2. Setup & Configuration:

    // tsconfig.json - Start with loose settings, gradually tighten
{
  "compilerOptions": {
    "allowJs": true,
    "checkJs": false,
    "noImplicitAny": false,
    "strict": false,
    "skipLibCheck": true
  },
  "include": ["src/**/*"],
  "exclude": ["node_modules", "dist"]
}

  3. Migration Strategy:

    • Phase 1: Rename .js files to .ts (allowJs: true)
    • Phase 2: Add basic type annotations for function parameters and returns
    • Phase 3: Create interfaces for complex objects and API responses
    • Phase 4: Add generic types and advanced TypeScript features
    • Phase 5: Enable strict mode gradually

  4. Practical Steps:

    // Before: JavaScript
function processUserData(userData) {
  return userData.map(user => ({
    id: user.id,
    name: user.firstName + ' ' + user.lastName,
    email: user.email.toLowerCase()
  }));
}

// After: TypeScript
interface User {
  id: number;
  firstName: string;
  lastName: string;
  email: string;
}

interface ProcessedUser {
  id: number;
  name: string;
  email: string;
}

function processUserData(userData: User[]): ProcessedUser[] {
  return userData.map(user => ({
    id: user.id,
    name: `${user.firstName} ${user.lastName}`,
    email: user.email.toLowerCase()
  }));
}

  5. Challenges & Solutions:

    • Third-party Libraries: Use @types/ packages or create custom .d.ts files
    • Dynamic Properties: Use index signatures or Record<string, any>
    • Complex Legacy Code: Start with any type and gradually add proper types
    • Build Process: Update build tools (Webpack, Babel) to handle TypeScript

  6. Best Practices:

    • Start with utility functions and data models
    • Use // @ts-ignore sparingly and with comments explaining why
    • Create shared type definitions for common interfaces
    • Set up ESLint rules for TypeScript
    • Use gradual strict mode enabling
Open as page

You're building a dashboard with real-time updates, complex filtering, and must support 1000+ concurrent users. Describe your architecture.

Answer:

Frontend Architecture:

  1. Framework & State Management:

    • React with TypeScript for type safety
    • Redux Toolkit + RTK Query for state management and caching
    • React Query for server state synchronization
    • Zustand for lightweight local state

  2. Real-time Updates:

    // WebSocket connection with reconnection logic
const useWebSocket = (url) => {
  const [socket, setSocket] = useState(null);
  const [connectionStatus, setConnectionStatus] = useState('disconnected');
  
  useEffect(() => {
    const ws = new WebSocket(url);
    
    ws.onopen = () => setConnectionStatus('connected');
    ws.onclose = () => {
      setConnectionStatus('disconnected');
      // Auto-reconnect with exponential backoff
      setTimeout(() => setSocket(new WebSocket(url)), 1000);
    };
    
    setSocket(ws);
    return () => ws.close();
  }, [url]);
  
  return { socket, connectionStatus };
};

  3. Performance Optimizations:

    • Virtual scrolling for large datasets (react-window)
    • Debounced search and filtering
    • Memoized components with React.memo
    • Code splitting with React.lazy
    • Service Worker for offline capabilities

Backend Architecture:

  1. API Design:

    • RESTful APIs with GraphQL for complex queries
    • WebSocket server for real-time updates
    • Rate limiting and authentication middleware
    • API versioning strategy

  2. Database Strategy:

    -- Optimized queries with proper indexing
CREATE INDEX idx_dashboard_data_timestamp ON dashboard_data(timestamp);
CREATE INDEX idx_dashboard_data_user_id ON dashboard_data(user_id);
CREATE INDEX idx_dashboard_data_category ON dashboard_data(category);

  3. Caching Layer:

    • Redis for session management and real-time data
    • CDN for static assets
    • Application-level caching with TTL
    • Database query result caching

Scalability Considerations:

  1. Load Balancing:

    • Horizontal scaling with multiple server instances
    • Load balancer with sticky sessions for WebSocket connections
    • Database read replicas for query distribution

  2. Microservices Architecture:

    ┌─────────────────┐    ┌─────────────────┐    ┌─────────────────┐
│   Auth Service  │    │  Data Service   │    │  Real-time      │
│                 │    │                 │    │  Service        │
└─────────────────┘    └─────────────────┘    └─────────────────┘
        │                       │                       │
        └───────────────────────┼───────────────────────┘
                                │
                 ┌─────────────────┐
                 │   API Gateway   │
                 │   (Rate Limit,  │
                 │   Auth, Routing)│
                 └─────────────────┘

  3. Monitoring & Observability:

    • Application Performance Monitoring (APM)
    • Real-time metrics with Prometheus + Grafana
    • Error tracking with Sentry
    • Log aggregation with ELK stack

Security & Performance:

  1. Authentication:

    • JWT tokens with refresh mechanism
    • Role-based access control (RBAC)
    • API key management for external integrations

  2. Data Flow:

    // Optimized data fetching with caching
const useDashboardData = (filters) => {
  return useQuery({
    queryKey: ['dashboard', filters],
    queryFn: () => fetchDashboardData(filters),
    staleTime: 30000, // 30 seconds
    cacheTime: 300000, // 5 minutes
    refetchOnWindowFocus: false,
  });
};

  3. Real-time Data Pipeline:

    • WebSocket connections with connection pooling
    • Message queuing (Redis Pub/Sub or RabbitMQ)
    • Data streaming with Apache Kafka for high-volume updates
    • Client-side data synchronization with conflict resolution
Open as page

What do you look for during code reviews? How do you balance perfectionism with pragmatism?

Answer:

Code Review Checklist:

  1. Functionality & Logic:

    • Does the code solve the intended problem?
    • Are edge cases handled appropriately?
    • Is error handling comprehensive?
    • Are there any potential security vulnerabilities?

  2. Code Quality:

    • Readability: Clear variable names, proper comments, logical structure
    • Maintainability: Modular design, single responsibility principle
    • Performance: Efficient algorithms, proper use of React optimization techniques
    • Type Safety: Proper TypeScript usage, avoiding any types

  3. React-Specific Considerations:

    // Good: Proper dependency array
useEffect(() => {
  fetchData(userId);
}, [userId]);

// Bad: Missing dependency
useEffect(() => {
  fetchData(userId);
}, []); // userId changes won't trigger refetch

// Good: Memoized expensive calculation
const expensiveValue = useMemo(() => {
  return heavyCalculation(data);
}, [data]);

// Bad: Recalculated on every render
const expensiveValue = heavyCalculation(data);

  4. Testing & Documentation:

    • Are there appropriate unit tests?
    • Is the code self-documenting?
    • Are complex business logic explained?

Balancing Perfectionism vs. Pragmatism:

  1. Must-Fix Issues (Non-negotiable):

    • Security vulnerabilities
    • Performance bottlenecks
    • Breaking changes without proper migration
    • Accessibility violations
    • Type safety issues that could cause runtime errors

  2. Should-Fix Issues (Important but flexible):

    • Code style inconsistencies
    • Missing error handling
    • Inefficient algorithms
    • Poor naming conventions

  3. Nice-to-Have Issues (Pragmatic approach):

    • Minor style preferences
    • Over-engineering for simple problems
    • Perfect test coverage vs. adequate coverage
    • Micro-optimizations with minimal impact

Example Review Process:

// Before Review: Multiple issues
const UserList = ({ users, onUserClick }) => {
  const [filteredUsers, setFilteredUsers] = useState([]);
  
  useEffect(() => {
    const filtered = users.filter(user => user.active);
    setFilteredUsers(filtered);
  }, [users]); // Missing dependency on filter logic
  
  return (
    <div>
      {filteredUsers.map(user => (
        <div key={user.id} onClick={() => onUserClick(user)}>
          {user.name}
        </div>
      ))}
    </div>
  );
};

// After Review: Improved version
interface User {
  id: string;
  name: string;
  active: boolean;
}

interface UserListProps {
  users: User[];
  onUserClick: (user: User) => void;
  showActiveOnly?: boolean;
}

const UserList: React.FC<UserListProps> = ({ 
  users, 
  onUserClick, 
  showActiveOnly = false 
}) => {
  const filteredUsers = useMemo(() => {
    return showActiveOnly 
      ? users.filter(user => user.active)
      : users;
  }, [users, showActiveOnly]);

  const handleUserClick = useCallback((user: User) => {
    onUserClick(user);
  }, [onUserClick]);

  if (filteredUsers.length === 0) {
    return <div>No users found</div>;
  }

  return (
    <div role="list">
      {filteredUsers.map(user => (
        <div 
          key={user.id} 
          onClick={() => handleUserClick(user)}
          role="listitem"
          tabIndex={0}
          onKeyDown={(e) => e.key === 'Enter' && handleUserClick(user)}
        >
          {user.name}
        </div>
      ))}
    </div>
  );
};

Review Communication:

  • Constructive Feedback: Focus on the code, not the person
  • Explain the "Why": Don't just say "this is wrong," explain the reasoning
  • Suggest Alternatives: Provide concrete examples of better approaches
  • Acknowledge Good Practices: Recognize when code follows best practices

Pragmatic Decision Framework:

  1. Impact Assessment: How critical is this issue?
  2. Effort vs. Benefit: Is the fix worth the time investment?
  3. Timeline Constraints: Does the deadline allow for perfection?
  4. Technical Debt: Will this create future maintenance issues?
  5. Team Standards: What are the established coding standards?
Open as page

How do you identify and prioritize technical debt? Give an example of when you advocated for refactoring.

Answer:

Identifying Technical Debt:

  1. Code Smells:

    • Duplicated Code: Same logic repeated across multiple files
    • Long Methods: Functions exceeding 20-30 lines
    • Large Classes/Components: Components with too many responsibilities
    • Deep Nesting: Complex conditional logic or deeply nested components
    • Magic Numbers/Strings: Hardcoded values without constants
    • Dead Code: Unused imports, functions, or components

  2. Performance Indicators:

    • Slow build times
    • Large bundle sizes
    • Memory leaks
    • Slow test execution
    • Frequent production bugs

  3. Maintenance Pain Points:

    • Difficult to add new features
    • High bug rate in specific areas
    • Developer onboarding challenges
    • Frequent merge conflicts

Prioritization Framework:

  1. Impact vs. Effort Matrix:

    High Impact, Low Effort    |  High Impact, High Effort
(Quick Wins)              |  (Strategic Projects)
--------------------------|--------------------------
Low Impact, Low Effort    |  Low Impact, High Effort
(Nice to Have)           |  (Avoid)

  2. Risk Assessment:

    • High Risk: Security vulnerabilities, performance bottlenecks
    • Medium Risk: Code maintainability, developer productivity
    • Low Risk: Code style, minor optimizations

  3. Business Value:

    • Customer-facing impact
    • Developer productivity gains
    • Future feature development speed
    • Maintenance cost reduction

Example: Advocating for Refactoring

Situation: A React application had a 2000-line UserDashboard component that was becoming increasingly difficult to maintain.

Problems Identified:

// Before: Monolithic component with multiple responsibilities
const UserDashboard = () => {
  // 2000+ lines of code handling:
  // - User data fetching
  // - Chart rendering
  // - Form validation
  // - Real-time updates
  // - Export functionality
  // - Multiple state management patterns
  
  const [users, setUsers] = useState([]);
  const [charts, setCharts] = useState({});
  const [filters, setFilters] = useState({});
  const [exportData, setExportData] = useState(null);
  // ... 50+ more state variables
  
  // Mixed concerns: API calls, UI logic, business logic
  const fetchUsers = async () => { /* 100+ lines */ };
  const renderChart = () => { /* 200+ lines */ };
  const validateForm = () => { /* 150+ lines */ };
  const handleExport = () => { /* 100+ lines */ };
  
  return (
    <div>
      {/* 500+ lines of JSX */}
    </div>
  );
};

Advocacy Approach:

  1. Data Collection:

    • Measured bug rate: 3x higher in this component
    • Developer time: 2x longer to add new features
    • Code review time: 4x longer than average
    • Test coverage: Only 30% due to complexity

  2. Business Case:

    • Cost: 2 weeks of refactoring effort
    • Benefit: 50% reduction in bug rate, 40% faster feature development
    • ROI: Break-even in 3 months, significant long-term savings

  3. Proposed Solution:

// After: Modular architecture
const UserDashboard = () => {
  return (
    <DashboardLayout>
      <UserDataProvider>
        <UserFilters />
        <UserCharts />
        <UserTable />
        <ExportPanel />
      </UserDataProvider>
    </DashboardLayout>
  );
};

// Separated concerns into focused components
const UserDataProvider = ({ children }) => {
  const { users, loading, error } = useUsers();
  const { filters, updateFilters } = useFilters();
  const { exportData, handleExport } = useExport();
  
  return (
    <UserDataContext.Provider value={{
      users, loading, error, filters, updateFilters, exportData, handleExport
    }}>
      {children}
    </UserDataContext.Provider>
  );
};

const UserCharts = () => {
  const { users, filters } = useUserData();
  const chartData = useMemo(() => 
    processChartData(users, filters), [users, filters]
  );
  
  return (
    <div className="charts-container">
      <RevenueChart data={chartData.revenue} />
      <UserGrowthChart data={chartData.growth} />
      <ActivityChart data={chartData.activity} />
    </div>
  );
};
  1. Implementation Strategy:
    • Phase 1: Extract data fetching logic into custom hooks
    • Phase 2: Break down UI into smaller components
    • Phase 3: Implement proper state management
    • Phase 4: Add comprehensive testing
    • Phase 5: Performance optimization

Results:

  • Code Reduction: 2000 lines → 5 focused components (~200 lines each)
  • Bug Rate: Reduced by 60%
  • Feature Development: 40% faster
  • Test Coverage: Increased to 85%
  • Developer Satisfaction: Significantly improved

Key Lessons:

  1. Quantify the Problem: Use metrics to support your case
  2. Propose Incremental Solutions: Break large refactoring into phases
  3. Demonstrate Business Value: Show ROI and long-term benefits
  4. Get Stakeholder Buy-in: Involve team leads and product managers
  5. Plan for Maintenance: Ensure ongoing commitment to prevent regression