A React developer worth hiring understands the rendering model well enough to know when to reach for React.memo and when not to — which requires understanding what triggers a re-render at all. Expect $20–45/hr for experienced offshore developers, $80–140/hr for US-based senior React work. The rest of this guide covers the portfolio signals and questions that reveal the difference between tutorial-depth and production-scale experience.
What Skills Actually Matter for React
React's Rendering Model — What Triggers Re-renders
React re-renders on every state or prop change, and by default that re-render propagates to all child components. Understanding why requires knowing how React's reconciler works: when you call setState, React schedules a re-render. During that re-render, React calls the component function again and gets a new virtual DOM tree. It then diffs the new tree against the previous one — this is reconciliation. For each component in the tree, React checks whether its props changed. If they haven't, React still calls the component function by default (unless you've used React.memo).
The performance trap: if a parent component creates a function or object literal inline — <Child onClick={() => handleClick(id)} /> — it creates a new function reference on every parent render. Even if Child is wrapped in React.memo, the prop reference changed, so React re-renders Child anyway. useCallback memoises the function reference so it's stable across renders: const handler = useCallback(() => handleClick(id), [id]). useMemo does the same for computed values. The skill is not knowing these APIs — it is knowing when the reference stability actually matters (heavy child components, long lists) versus when adding memoization is premature complexity.
Ask: "A component renders 50 times per second even when nothing visible changes. How do you diagnose it?" Expected: React DevTools Profiler to see what triggered each render, then identify whether the cause is an unstable prop reference from a parent or an unnecessary state update.
State Management Architecture
React state management is where most UI bugs originate. A skilled React developer knows when local useState is sufficient, when to lift state, when useContext is appropriate (theme, auth — state that changes rarely and is needed everywhere), and when a global store (Zustand, Redux Toolkit) is warranted (complex shared state with many updates, devtools history needed). The difference between server state (data that lives on the server, needs fetching, caching, and invalidation) and client state (UI state — open modals, selected tabs) is the lens that makes these decisions clear — and it's why TanStack Query exists as a separate tool from Redux.
Developers who put everything in Redux or useContext are not thinking about appropriate scope. Developers who put everything in useState have not thought about component communication.
Performance Understanding
React re-renders on every state change by default. Performance problems come from:
- Re-rendering components that have not changed (fix: React.memo, useMemo, useCallback when warranted)
- Large component trees with state at the top (fix: colocation, move state down)
- Slow data fetching blocking the render (fix: Suspense, loading states, TanStack Query)
The important word is "when warranted" — most developers either never use memoization (and have slow apps) or overuse it (and have complex apps that are not actually faster). The skill is knowing the difference.
TypeScript
React without TypeScript in 2026 is a significant red flag for any production application. TypeScript catches component prop type mismatches at compile time — errors that otherwise show up as runtime bugs. A React developer who refuses to use TypeScript has not experienced the pain of maintaining a large React app without it.
API Integration
Real React applications fetch data. A developer who has only built toy apps may not understand: - Loading, error, and empty states for every async operation - Optimistic updates for better perceived performance - Request cancellation when a component unmounts - Cache invalidation after mutations
Testing
A React component without tests is a component that can break silently. At minimum: unit tests with React Testing Library for complex logic, and integration tests for critical user flows.
Interview Questions That Reveal Real Ability
"Walk me through how you'd decide whether to put a piece of state in a component, in Context, or in a global store."
Good answer: local first, Context for genuinely shared UI state (theme, auth), global store only for complex shared application state with many updates. Weak answer: always use Redux.
"A component is rendering 50 times per second even when nothing visible changes. How do you debug it?"
Good answer: React DevTools Profiler to identify what triggered the renders, then check whether the problem is unstable object/function references being created on every parent render, or unnecessary state changes. Weak answer: "Add useMemo everywhere."
"How do you handle a form that has 20 fields and complex validation?"
Good answer: react-hook-form (avoids uncontrolled input re-render churn) or Formik, with Zod or Yup for schema validation. Weak answer: manage every field with useState individually.
"What happens when you call setState inside useEffect without a dependency array?"
Good answer: an infinite re-render loop — the state update triggers a re-render, which runs the effect, which updates state again. This is one of the most common React bugs. Weak answer: the developer has not seen or thought about this case.
"Show me a React component you've written that you're proud of and explain your decisions."
This question reveals real experience more than any technical quiz. Look for: thoughtful prop interface design, explicit handling of loading/error states, appropriate use of custom hooks to extract logic, and TypeScript types.
Portfolio Red Flags
No TypeScript — Acceptable for learning projects, unacceptable for anything called "production" or "client work."
State in all the wrong places — Global state for UI-only concerns (a modal open state in Redux) or local state for shared data (fetching the same API endpoint in five sibling components).
No loading or error handling — Every async operation has three states: loading, error, and success. Showing only the success state is incomplete.
Untested components — Not every component needs tests, but there should be some. Zero test files in a portfolio project is a red flag.
Giant component files — A 500-line component file is a sign the developer has not thought about separation of concerns. Logic should be in custom hooks; presentation should be in components.
Latest-framework-chasing — A portfolio with five different state management libraries, three CSS frameworks, and zero completed projects suggests a developer who never finishes anything.
Realistic Rates
| Experience | India-based | Eastern Europe | US |
|---|---|---|---|
| Mid (3–5 yrs) | $18–30/hr | $35–55/hr | $75–110/hr |
| Senior (6+ yrs) | $28–45/hr | $50–75/hr | $90–140/hr |
A React developer who also knows the backend (Node, Python/Django) typically commands 10–20% more — and is often a better hire than two specialists for early-stage products.
Full Stack React + Django: The Underrated Option
For products that need both a React frontend and a Django REST API, a single developer who handles both is frequently the best outcome. The integration points — API design, authentication flows, CORS, and error handling — are where projects fail. A developer who owns both sides eliminates the coordination overhead and makes better design decisions because they understand the full picture.
If you need a React frontend, a Django backend, or both — hire me as a React developer or as a full stack developer for the complete solution.
Frequently Asked Questions
How do I evaluate a React developer without knowing React myself? Ask to see a project they've maintained for 6+ months — not one they built in a weekend. A maintained project has evolved components, refactored logic, and realistic error handling. Ask them to walk you through a bug they fixed in production and how they found it. The specificity and honesty of the answer is accessible without React knowledge.
Should I hire a React specialist or a full-stack React + backend developer? For most early-stage products, a full-stack developer who knows React and the backend stack eliminates the coordination overhead at API boundaries — authentication flows, CORS, error response formats. A React specialist makes sense when the frontend is genuinely complex and requires dedicated focus, and when the backend is already stable enough to not need simultaneous changes.
Is React still the right choice in 2026? Yes for most production applications. The ecosystem — TanStack Query, Zustand, React Router, Next.js, shadcn/ui — is the most mature in frontend development. The talent pool is the largest. If you are choosing a framework for a new project, React's long-term stability and hiring pool make it the lowest-risk default. Vue and Svelte are legitimate for specific scenarios; React is the safe choice when you don't have a strong reason to choose otherwise.
Does a React developer need to know TypeScript? For production work in 2026: yes. TypeScript catches component prop type mismatches at compile time — errors that otherwise surface as runtime bugs. A React developer who will not use TypeScript is choosing a workflow that produces a specific class of bugs that TypeScript eliminates. See JavaScript vs TypeScript: why I now require TypeScript for the full reasoning.