DEV Community: Roshan singh

# 🚀 Important React Interview Questions Every Developer Must Know

Roshan singh — Fri, 08 May 2026 06:28:56 +0000

If you're preparing for:

React interviews
frontend roles
full stack interviews

these are the most important React concepts you should know.

This guide covers:

core React fundamentals
hooks
rendering
state management
optimization concepts

in a beginner-friendly way.

✅ 1. What is Virtual DOM?

The Virtual DOM is a lightweight JavaScript copy of the real DOM.

Instead of directly updating the browser DOM:

React creates a new Virtual DOM
compares it with the old one
updates only changed parts in the real DOM

This process is called:

⚡ Reconciliation / Diffing

✅ Why is Virtual DOM Fast?

Because:

comparing JavaScript objects is fast
real DOM operations are expensive

React minimizes direct DOM manipulation.

✅ 2. What is useState?

useState is a React Hook used for managing component state.

```jsx id="jlwmn"
const [count, setCount] = useState(0);




* `count` → current state
* `setCount` → updates state

When state changes:

# React re-renders the component

---

# ✅ 3. What is useEffect?

`useEffect` handles:

* API calls
* timers
* subscriptions
* event listeners
* side effects



```jsx id="jlwmm"
useEffect(() => {
  fetchData();
}, []);

✅ Important Point

useEffect runs:

AFTER component render

✅ Dependency Array

Dependency	Behavior
No array	Runs every render
`[]`	Runs once
`[count]`	Runs when count changes

✅ 4. Props vs State

Props	State
Passed from parent	Managed inside component
Read-only	Mutable
Used for communication	Used for dynamic data

✅ 5. What is Redux Toolkit?

Redux Toolkit is used for:

Global State Management

It helps avoid:

prop drilling
deeply nested state passing

✅ Main Concepts

Store
Slice
Reducer
Dispatch

✅ 6. What is RTK Query?

RTK Query simplifies API integration in Redux Toolkit.

It automatically handles:

caching
loading state
errors
refetching

```jsx id="jlwml"
const { data } = useGetUsersQuery();




---

# ✅ 7. Component Lifecycle

React components have 3 lifecycle phases:

1. Mounting
2. Updating
3. Unmounting

Handled using `useEffect`.

---

## ✅ Mount Example



```jsx id="jlwmk"
useEffect(() => {}, []);

✅ Cleanup Example

```jsx id="jlwmj"
useEffect(() => {
return () => {
console.log("cleanup");
};
}, []);




---

# ✅ 8. Controlled vs Uncontrolled Components

---

## ✅ Controlled Component

React controls input state.



```jsx id="jlwmi"
<input value={name} onChange={handleChange} />

✅ Uncontrolled Component

DOM controls input using refs.

```jsx id="jlwmh"




---

# ✅ 9. What is useRef?

`useRef` stores mutable values without causing re-renders.

Commonly used for:

* DOM access
* focusing inputs
* timers
* previous values



```jsx id="jlwmg"
const inputRef = useRef();

✅ 10. API Integration in React

Usually done using:

fetch
axios

Inside useEffect.

```jsx id="jlwmf"
useEffect(() => {
axios.get("/api/users");
}, []);




---

# ✅ fetch vs axios

| fetch               | axios                  |
| ------------------- | ---------------------- |
| Built into browser  | External library       |
| Manual JSON parsing | Automatic JSON parsing |
| More boilerplate    | Cleaner syntax         |

---

# ✅ 11. What is Lifting State Up?

Lifting state up means:

# Moving shared state to the nearest common parent component.

Used when sibling components need same data.

---

# ✅ Example



```jsx id="jlwme"
<ChildA count={count} />
<ChildB setCount={setCount} />

✅ 12. What is Context API?

Context API helps avoid:

Prop Drilling

It allows components to access shared data directly.

✅ Example

```jsx id="jlwmd"
const user = useContext(UserContext);




---

# ✅ 13. What is React.memo?

`React.memo` prevents unnecessary component re-renders.

It uses:

# Shallow Prop Comparison



```jsx id="jlwmc"
export default React.memo(Child);

✅ 14. What is useMemo?

useMemo memoizes expensive calculations or values.

```jsx id="jlwmb"
const value = useMemo(() => calculate(), [dep]);




Recalculates only when dependencies change.

---

# ✅ 15. What is useCallback?

`useCallback` memoizes function references.



```jsx id="jlwma"
const handleClick = useCallback(() => {}, []);

Helps prevent unnecessary child re-renders.

🔥 Most Important React Optimization Concept

React.memo alone is often NOT enough.

Because:

functions
arrays
objects

create new references every render.

So:

useCallback preserves function reference
useMemo preserves value reference

This helps:

✅ React.memo work effectively

📊 Difference Between React.memo, useMemo, useCallback

Feature	React.memo	useMemo	useCallback
Used For	Component	Value	Function
Prevents	Re-render	Recalculation	Function recreation

🎯 Final Interview Tips

For React interviews:

focus on concepts
understand rendering
know how hooks work internally
explain WHY optimizations are needed

Most interviewers care more about:

understanding

than memorizing syntax.

🏁 Final Thoughts

React becomes much easier once you understand:

rendering
component lifecycle
state management
memoization
re-renders

Master these concepts properly and you’ll already know most of the important React interview topics.

React.memo vs useMemo vs useCallback — Complete Guide

Roshan singh — Fri, 08 May 2026 06:25:26 +0000

If you're learning React, you've probably heard these terms everywhere:

React.memo
useMemo
useCallback

At first, they look confusing.

But all three solve one major problem:

⚡ Unnecessary Re-renders & Performance Issues

This guide explains:

what each one does
why they exist
how they are connected
when to use them
interview explanations

🤔 Why Do These Exist?

In React, components re-render very frequently.

A component re-renders when:

state changes
props change
parent component re-renders

Most of the time this is fine.

But in large applications:

expensive calculations
recreated functions
unnecessary child renders

can slow down the application.

That’s why React provides:

React.memo
useMemo
useCallback

for optimization.

🧠 First Understand One Important Thing

In React:

function App() {
  console.log("Rendered");

  return <h1>Hello</h1>;
}

Whenever React re-renders:

the ENTIRE component function runs again
variables get recreated
functions get recreated

This is the root reason why memoization exists.

1️⃣ React.memo

✅ What is React.memo?

React.memo prevents unnecessary component re-renders.

❌ Problem Without React.memo

function Child() {
  console.log("Child rendered");

  return <h1>Child Component</h1>;
}

function Parent() {
  const [count, setCount] = useState(0);

  return (
    <>
      <button onClick={() => setCount(count + 1)}>
        Increment
      </button>

      <Child />
    </>
  );
}

🔍 What Happens Here?

When button is clicked:

Parent re-renders
Child ALSO re-renders

Even though:

Child props didn't change
Child state didn't change

❌ This is an unnecessary re-render.

✅ Solution Using React.memo

const Child = React.memo(() => {
  console.log("Child rendered");

  return <h1>Child Component</h1>;
});

Now React remembers the previous render.

If props are unchanged:

✅ Child render is skipped

⚙️ How React.memo Works Internally

React performs:

👉 Shallow Comparison

It compares:

old props
new props

If props are same:
✅ React skips rendering.

📌 Important Point

React.memo works best with:

strings
numbers
booleans

But NOT always with:

functions
arrays
objects

Because they create new references every render.

That’s where useCallback and useMemo help.

2️⃣ useCallback

✅ What is useCallback?

useCallback memoizes functions.

It prevents function recreation on every render.

❌ Problem Without useCallback

function Parent() {
  const [count, setCount] = useState(0);

  const handleClick = () => {
    console.log("Clicked");
  };

  return <Child onClick={handleClick} />;
}

Looks normal, right?

But here's the hidden issue:

🚨 A NEW function gets created on every render

🤯 Why?

Because in JavaScript:

const a = () => {};
const b = () => {};

console.log(a === b);

Output:

false

Because:

both functions have different memory references

🚨 Why This Causes Re-renders

Suppose Child uses:

const Child = React.memo(({ onClick }) => {
  console.log("Child rendered");

  return <button onClick={onClick}>Click</button>;
});

Even with React.memo,
Child STILL re-renders because:

oldFunction !== newFunction

React thinks:

❌ Prop changed

✅ Solution Using useCallback

const handleClick = useCallback(() => {
  console.log("Clicked");
}, []);

Now React stores:

✅ SAME function reference

between renders.

So:

Child gets same prop
React.memo works properly
unnecessary render avoided

🧠 Behind The Scenes

❌ Without useCallback

Render 1 → new function
Render 2 → new function
Render 3 → new function

✅ With useCallback

Render 1 → create function
Render 2 → reuse same function
Render 3 → reuse same function

3️⃣ useMemo

✅ What is useMemo?

useMemo memoizes values or expensive calculations.

❌ Problem Without useMemo

const filteredUsers = users.filter(user => user.active);

This runs:

🚨 On EVERY render

Even when unrelated state changes.

🤯 Example

Suppose:

theme changes
modal opens
input typing happens

Still:

users.filter()

runs again.

For large data:
❌ performance issue.

✅ Solution Using useMemo

const filteredUsers = useMemo(() => {
  return users.filter(user => user.active);
}, [users]);

Now calculation runs ONLY when:

users

changes.

⚙️ How useMemo Works Internally

React stores:

previous dependencies
previous calculated value

If dependencies don't change:

✅ Cached value is returned

No recalculation happens.

🔥 MOST IMPORTANT — How All Three Are Connected

This is where most beginners get confused.

❌ React.memo Alone Is NOT Enough

Suppose:

<Child
  onClick={handleClick}
  data={filteredUsers}
/>

Even with React.memo,
Child may STILL re-render because:

handleClick creates new function
filteredUsers creates new array/object

React sees:

oldProp !== newProp

because references changed.

✅ That’s Why We Need:

👉 useCallback

to preserve function reference

AND

👉 useMemo

to preserve value/object/array reference

So that:

✅ React.memo can ACTUALLY skip rendering

🧩 Simple Mental Model

✅ React.memo

“Skip component render if props are same.”

✅ useCallback

“Keep same function reference.”

✅ useMemo

“Keep same calculated value/reference.”

📊 Final Difference Between All Three

Feature	React.memo	useMemo	useCallback
Used For	Component	Value	Function
Prevents	Re-render	Recalculation	Function recreation
Returns	Memoized component	Memoized value	Memoized function
Common Use	Child optimization	Expensive calculations	Stable callbacks

🚫 When NOT To Use Them

Do NOT overuse memoization.

These hooks also have overhead.

Use them only when:

unnecessary renders are causing issues
calculations are expensive
components are large/heavy

🎯 Interview Summary

✅ React.memo

Prevents unnecessary component re-renders using shallow prop comparison.

✅ useMemo

Memoizes calculated values and recalculates only when dependencies change.

✅ useCallback

Memoizes function references to prevent unnecessary function recreation and child re-renders.

🏁 Final Thoughts

Most developers memorize:

syntax
definitions

But the REAL understanding is:

React.memo depends on stable references.
useMemo and useCallback help maintain those stable references.

Once this connection clicks, React rendering behavior becomes much easier to understand.

Scaling Redis in Distributed Systems: From Local Cache Problems to Redis Cluster

Roshan singh — Wed, 06 May 2026 12:04:05 +0000

**When building scalable backend systems, one common question arises:

“If we scale our application using multiple instances, how should caching work?”

This becomes especially important when using Redis in distributed architectures.

Let’s understand the problem step by step and then move toward advanced scaling concepts like sharding and replication.**

🚨 The Problem with Local Redis per Instance

Suppose we scale our backend application:

Load Balancer
     ↓
 ┌───────────┐
 │ Instance1 │
 └───────────┘
       │
   Local Redis 1

 ┌───────────┐
 │ Instance2 │
 └───────────┘
       │
   Local Redis 2

At first glance, this looks fine.

But here’s the issue.

Imagine:

User data gets updated through Instance 2
Local Redis 2 gets updated
Local Redis 1 still contains old cached data

Now:

Requests routed to Instance 1 return stale data
Requests routed to Instance 2 return fresh data

This creates:

Cache inconsistency
Synchronization complexity
Stale reads

❌ Why Syncing Local Redis is Difficult

To keep multiple local Redis caches synchronized, we need:

Pub/Sub systems
Event broadcasting
Cache invalidation messaging
Distributed coordination

This becomes very complex at scale.

That’s why production systems usually avoid separate Redis instances per application server.

✅ The Correct Approach: Centralized Redis

Instead of separate caches, all backend instances use a shared Redis layer.

                        ┌─────────────────┐
Client → Load Balancer  → App Instances
                        └─────────────────┘
                              ↓
                     Shared Redis Cluster
                              ↓
                         PostgreSQL

Now:

All instances read/write from the same Redis
Any update becomes immediately visible everywhere
No synchronization problem

Example:

await db.updateUser(id, data);
await redis.del(`user:${id}`);

Once the cache is invalidated:

Any instance fetching the data gets the latest value

This architecture is simple, scalable, and production-friendly.

🤔 But What Happens When Redis Itself Needs Scaling?

A single Redis server has limitations:

Limited memory
Limited CPU
Single point of failure

For very large systems, we need:

Horizontal scaling
Fault tolerance
High availability

This is where Redis Cluster comes in.

🔥 Redis Cluster

A Redis Cluster distributes data across multiple Redis nodes.

It uses two important concepts:

Sharding
Replication

1️⃣ Sharding — Scaling Redis Horizontally

What is Sharding?

Sharding means:

Splitting data across multiple Redis nodes.

Instead of storing all data in one Redis server:

Redis Node 1
→ All users
→ All movies
→ All bookings

Redis distributes keys across multiple nodes.

Example:

user:101    → Node 1
movie:201   → Node 2
booking:301 → Node 3

Important:
Redis does NOT shard by entity type.

It shards based on:

Hash calculation of keys

Internally:

HASH(key) % 16384 = slot

Each node owns a range of hash slots.

Example:

Node 1 → Slots 0–5000
Node 2 → Slots 5001–10000
Node 3 → Slots 10001–16383

✅ Why Sharding is Important

Sharding helps with:

Memory scaling
Traffic distribution
Better performance
Horizontal scalability

Without sharding:

One Redis server becomes overloaded

2️⃣ Replication — High Availability & Failover

What is Replication?

Replication means:

Creating copies of Redis data on replica nodes.

Example:

Master 1 → Replica 1
Master 2 → Replica 2
Master 3 → Replica 3

If:

Master 2 crashes

Redis automatically promotes:

Replica 2 → New Master

This process is called:

Automatic failover

✅ Why Replication is Needed

Sharding distributes data,
but it does NOT protect against node failure.

Without replication:

If a node crashes,
Data on that shard becomes unavailable

Replication provides:

High availability
Fault tolerance
Backup copies
Reduced downtime

⚔️ Sharding vs Replication

Feature	Sharding	Replication
Purpose	Scalability	High Availability
Data	Split	Copied
Increases Memory Capacity	✅ Yes	❌ No
Handles Node Failure	❌ No	✅ Yes
Improves Performance	✅ Yes	Partial

🏗️ Final Production Architecture

Production systems usually combine both:

                Redis Cluster

Master 1 → Replica 1
Master 2 → Replica 2
Master 3 → Replica 3

Here:

Masters handle sharded data
Replicas provide failover protection

🎯 Final Thoughts

When scaling distributed systems:

Avoid local Redis per instance
Use centralized Redis
Scale Redis using sharding
Ensure reliability using replication

This architecture helps achieve:

Low latency
High scalability
High availability
Fault tolerance

Which is exactly what modern distributed systems require.

# How to Build a Complete CI/CD Pipeline with GitHub Actions and Docker Hub

Roshan singh — Wed, 25 Mar 2026 07:16:44 +0000

## Introduction

In this tutorial, I'll show you how to set up a complete CI/CD pipeline that automatically builds Docker images, pushes them to Docker Hub, and deploys your application to a production server - all triggered by a simple git push!

## What You'll Learn

Setting up GitHub Actions for automated builds
Building and pushing Docker images to Docker Hub
Deploying containerized applications to a remote server
Version tagging with Git commit SHAs
Zero-downtime deployments with Docker Compose

## Prerequisites

Before we start, make sure you have:

A GitHub repository with your application code
A Docker Hub account
A remote server (VPS/Cloud VM) with Docker and Docker Compose installed
SSH access to your server
Basic understanding of Docker and Docker Compose

## Architecture Overview

Our CI/CD pipeline consists of two main jobs:

Build & Push: Build Docker images and push them to Docker Hub
Deploy: Pull the new images on the server and restart containers

Git Push → GitHub Actions → Build Images → Docker Hub → Deploy to Server → Live!

## Step 1: Project Structure

Here's what your project structure should look like:

your-project/
├── .github/
│   └── workflows/
│       └── deploy.yml          # CI/CD workflow
├── backend/
│   ├── Dockerfile              # Backend Docker image
│   └── ... (your backend code)
├── frontend/
│   ├── Dockerfile              # Frontend Docker image
│   └── ... (your frontend code)
├── docker-compose.prod.yml     # Production deployment config
└── nginx.conf                  # Nginx configuration

## Step 2: Create Dockerfiles

### Backend Dockerfile Example

# backend/Dockerfile
FROM node:18-alpine

WORKDIR /app

COPY package*.json ./
RUN npm ci --only=production

COPY . .

EXPOSE 5000

CMD ["node", "server.js"]

*### Frontend Dockerfile Example
*

# frontend/Dockerfile
FROM node:18-alpine as build

WORKDIR /app

COPY package*.json ./
RUN npm ci

COPY . .
RUN npm run build

FROM nginx:alpine
COPY --from=build /app/dist /usr/share/nginx/html
COPY nginx.conf /etc/nginx/conf.d/default.conf

EXPOSE 80

CMD ["nginx", "-g", "daemon off;"]

yaml

## Step 3: Create Docker Compose Production File

# docker-compose.prod.yml
version: '3.8'

services:
  backend:
    image: yourdockerhub/crm-backend:${CRM_BACKEND_TAG:-latest}
    container_name: crm-backend
    restart: unless-stopped
    environment:
      - NODE_ENV=production
      - DATABASE_URL=${DATABASE_URL}
    ports:
      - "5000:5000"
    networks:
      - app-network

  frontend:
    image: yourdockerhub/crm-frontend:${CRM_FRONTEND_TAG:-latest}
    container_name: crm-frontend
    restart: unless-stopped
    ports:
      - "3000:80"
    depends_on:
      - backend
    networks:
      - app-network

  nginx:
    image: nginx:alpine
    container_name: nginx-proxy
    restart: unless-stopped
    ports:
      - "80:80"
      - "443:443"
    volumes:
      - ./nginx.conf:/etc/nginx/nginx.conf:ro
    depends_on:
      - frontend
      - backend
    networks:
      - app-network

networks:
  app-network:
    driver: bridge

## Step 4: Create GitHub Actions Workflow

Create .github/workflows/deploy.yml:

name: Build and Deploy to Production

on:
  push:
    branches: [main]

jobs:
  build-and-push:
    name: Build and push Docker images
    runs-on: ubuntu-latest

    steps:
      - name: Checkout repository
        uses: actions/checkout@v4

      - name: Log in to Docker Hub
        uses: docker/login-action@v3
        with:
          username: ${{ secrets.DOCKERHUB_USERNAME }}
          password: ${{ secrets.DOCKERHUB_TOKEN }}

      - name: Generate image tags
        id: tag
        run: |
          echo "full=${GITHUB_SHA}" >> "$GITHUB_OUTPUT"
          echo "short=${GITHUB_SHA:0:7}" >> "$GITHUB_OUTPUT"

      - name: Build and push backend image
        uses: docker/build-push-action@v5
        with:
          context: ./backend
          file: ./backend/Dockerfile
          push: true
          tags: |
            yourdockerhub/crm-backend:latest
            yourdockerhub/crm-backend:${{ steps.tag.outputs.full }}
            yourdockerhub/crm-backend:${{ steps.tag.outputs.short }}

      - name: Build and push frontend image
        uses: docker/build-push-action@v5
        with:
          context: ./frontend
          file: ./frontend/Dockerfile
          push: true
          tags: |
            yourdockerhub/crm-frontend:latest
            yourdockerhub/crm-frontend:${{ steps.tag.outputs.full }}
            yourdockerhub/crm-frontend:${{ steps.tag.outputs.short }}

  deploy:
    name: Deploy to production server
    runs-on: ubuntu-latest
    needs: build-and-push

    steps:
      - name: Checkout repository
        uses: actions/checkout@v4

      - name: Copy configuration files to server
        uses: appleboy/scp-action@v0.1.7
        with:
          host: ${{ secrets.SSH_HOST }}
          username: ${{ secrets.SSH_USER }}
          key: ${{ secrets.SSH_KEY }}
          source: "docker-compose.prod.yml,nginx.conf"
          target: "~/crm-app"

      - name: Deploy application
        uses: appleboy/ssh-action@v1.0.0
        with:
          host: ${{ secrets.SSH_HOST }}
          username: ${{ secrets.SSH_USER }}
          key: ${{ secrets.SSH_KEY }}
          script: |
            cd ~/crm-app
            TAG="${{ github.sha }}"

            # Clean up old images
            sudo docker image prune -a -f

            # Pull new images
            sudo docker compose -f docker-compose.prod.yml pull backend frontend

            # Recreate containers with new images
            sudo CRM_BACKEND_TAG="$TAG" CRM_FRONTEND_TAG="$TAG" \
              docker compose -f docker-compose.prod.yml up -d \
              --force-recreate --no-deps backend frontend

            # Restart nginx
            sudo docker compose -f docker-compose.prod.yml restart nginx

            # Final cleanup
            sudo docker image prune -a -f

## Step 5: Configure GitHub Secrets

Go to your GitHub repository → Settings → Secrets and variables → Actions

Add the following secrets:

DOCKERHUB_USERNAME: Your Docker Hub username
DOCKERHUB_TOKEN: Docker Hub access token
SSH_HOST: Your server IP address or domain
SSH_USER: SSH username
SSH_KEY: Your private SSH key

## Conclusion

You now have a fully automated CI/CD pipeline! Every push to main will automatically build, test, and deploy your application.

Tags: #docker #cicd #githubactions #devops #automation

Questions? Drop them in the comments below! 👇