# DevFilter Starter Screening Kit: React / Node.js Screening Questions

Use these to assess practical depth for startup candidates working across React, Next.js, Node.js, APIs, and production delivery. Pick 6 to 8 questions for an async screen or 10 to 12 for a live technical screen.

## How to Use This Pack

- Ask for concrete examples from production work, not textbook definitions.
- Press for tradeoffs, constraints, and results.
- A strong candidate should connect frontend decisions to API design, performance, testing, and operational impact.

## Questions

### 1. Tell me about a React feature you shipped that became slow at scale. What caused it, and how did you fix it?

**Strong signal:** Identifies a specific bottleneck such as unnecessary re-renders, oversized bundles, poor list rendering, expensive effects, or bad data-fetching patterns, then explains measurement and remediation.

### 2. When would you keep state local to a component versus moving it into context, a store, or the URL?

**Strong signal:** Distinguishes UI-local state from shared application state and discusses reusability, debugging, performance, and user experience implications.

### 3. What problems have you seen from incorrect `useEffect` usage, and how do you avoid them?

**Strong signal:** Mentions stale closures, duplicated requests, race conditions, dependency mistakes, cleanup failures, or effects being used for pure derivation.

### 4. How would you decide between server rendering, static generation, and client-side rendering for a new page in a React or Next.js app?

**Strong signal:** Frames the decision around freshness requirements, SEO, latency, caching, personalization, and operational complexity.

### 5. Describe an API you designed or significantly improved in Node.js. What made the design good or bad?

**Strong signal:** Talks about resource modeling, validation, pagination, idempotency, versioning, error semantics, and how clients actually consumed the API.

### 6. How do you structure validation in a Node.js service so bad input fails early without turning controllers into giant if-statements?

**Strong signal:** Uses a schema or contract layer, keeps validation close to boundaries, and separates parsing, business rules, and persistence concerns.

### 7. What does good error handling look like in a production Node.js API?

**Strong signal:** Covers typed or categorized errors, user-safe messages, logging, traceability, status codes, retries, and avoiding swallowed failures.

### 8. Tell me about a debugging session where the frontend and backend teams blamed each other. How did you isolate the real issue?

**Strong signal:** Uses logs, network traces, reproducible requests, feature flags, or request IDs to narrow the fault instead of guessing.

### 9. How do you approach authentication and authorization in a startup app with both internal admin users and external customers?

**Strong signal:** Separates identity from permissions, discusses session or token strategy, role checks, least privilege, and secure defaults.

### 10. What would you look for in a pull request from a mid-level React engineer before approving it?

**Strong signal:** Focuses on behavior, maintainability, state boundaries, accessibility, test coverage, and failure cases rather than surface-level style issues.

### 11. Describe a time you reduced bundle size or improved frontend performance. What changed, and how did you verify the result?

**Strong signal:** Mentions code splitting, tree shaking, dependency removal, image optimization, SSR changes, or caching, and cites measurable outcomes.

### 12. How do you keep a Node.js service reliable when it depends on third-party APIs?

**Strong signal:** Discusses timeouts, retries, circuit breakers, idempotency, queueing, fallback behavior, and observability around external failures.

### 13. What makes tests valuable in a React and Node codebase, and where do you usually see teams over-test or under-test?

**Strong signal:** Balances unit, integration, and end-to-end coverage, and talks about confidence per maintenance cost instead of blindly maximizing counts.

### 14. If a product manager asks for a feature in two days, how do you cut scope without creating a mess the team has to rewrite next sprint?

**Strong signal:** Can define the smallest shippable slice, preserve clean interfaces, and document deferred work without over-engineering.

### 15. Tell me about a migration you handled, such as JavaScript to TypeScript, REST to GraphQL, pages router to app router, or CSS system cleanup.

**Strong signal:** Explains sequencing, rollout risk, developer ergonomics, and how they avoided blocking feature work during the migration.

### 16. How do you review a candidate claim like "built a scalable microservices platform" on a resume? What follow-up questions do you ask?

**Strong signal:** Pushes for concrete responsibility, traffic or scale numbers, tradeoffs, failure modes, and what they personally owned.

### 17. What accessibility issues do React teams commonly miss, and how do you catch them before release?

**Strong signal:** Mentions semantics, keyboard navigation, focus management, labels, color contrast, and a mix of automated and manual checks.

### 18. Suppose a dashboard page is making six API requests on load and feels sluggish. What would you examine first?

**Strong signal:** Looks at request criticality, sequencing, caching, batching, waterfall behavior, render blocking, and whether the UI really needs all data immediately.

### 19. What operational metrics would you watch for a Node.js application after launching a new hiring workflow feature?

**Strong signal:** Includes latency, error rates, queue depth, third-party failure rates, conversion, and business metrics tied to the feature outcome.

### 20. In an early-stage startup, what separates a strong full-stack engineer from someone who can only complete narrowly defined tickets?

**Strong signal:** Describes ownership, judgment, communication, product sense, and ability to move between ambiguity, implementation, and operations.