DEV Community: Keyur Gohil

11 JavaScript Interview Questions Every Dev Should Know — Part 3: Objects, Prototypes & OOP

Keyur Gohil — Wed, 26 Aug 2026 06:33:06 +0000

Part 3 of the series dives into JavaScript's object model — a topic that trips people up because JS's approach (prototypal inheritance) is fundamentally different from classical OOP languages like Java or C#.

Catch up on Part 1: Fundamentals and Part 2: Functions & Closures if you missed them.

Q1. How does prototypal inheritance work in JavaScript?

Every object in JavaScript carries an internal, hidden link to another object, known as its [[Prototype]] — accessible in practice through Object.getPrototypeOf() or the older, legacy __proto__ accessor. Rather than defining behavior through rigid class hierarchies, objects share and reuse behavior by pointing to other objects that already have that behavior defined.

When you try to access a property or method on an object, the engine first checks whether the object has that property directly ("own property"). If it doesn't, the engine doesn't just give up — it walks up to the object's prototype and checks there, then that prototype's prototype, and so on, continuing this chain until either the property is found or the chain terminates at null (the end of every prototype chain). This lookup process is called the prototype chain, and it's the actual mechanism underlying everything that looks like inheritance in JavaScript, including classes.

Q2. What is the difference between `Object.create()` and a constructor function?

Object.create(proto) is the most direct way to work with prototypal inheritance: it creates and returns a brand-new, empty object whose [[Prototype]] is set to whatever object you passed in as an argument. There's no constructor function involved at all — you're explicitly wiring up the prototype relationship yourself, which makes the underlying mechanism very transparent, though it's used less often in everyday code than the class syntax.

A constructor function, called with the new keyword, is a more automated (and historically more common) way to achieve the same result, but it does several things behind the scenes at once: it creates a new object, links that object's prototype to the constructor function's .prototype property, runs the constructor's code with this bound to that new object (so you can attach instance properties), and then returns the object automatically — all without you having to manage the prototype linkage manually.

Q3. What is the difference between classical inheritance and prototypal inheritance?

Classical inheritance, found in languages like Java or C#, is built around the concept of classes — abstract blueprints, defined at compile time, that describe the shape and behavior objects of that type will have. Instances are created from these classes, and inheritance forms a fixed, hierarchical tree structure: a subclass extends a superclass, and that relationship is generally locked in at the time the code is written.

Prototypal inheritance takes a fundamentally different, more flexible approach: there are no true "classes" underneath — only objects, and those objects inherit directly from other objects through the prototype chain described earlier. Because prototypes are just regular objects, they can be modified dynamically at runtime (you can add a method to a prototype after objects have already been created from it, and every existing instance will immediately gain access to that new method through the chain), which is a level of flexibility classical class hierarchies typically don't allow.

Q4. What are ES6 classes, and are they truly a new object model?

ES6 introduced the class keyword, giving JavaScript a syntax that looks very familiar to developers coming from classical OOP languages — with constructor, extends, super, and method definitions that resemble Java or C#. This was a deliberate design choice to make JavaScript more approachable, but underneath, class is almost entirely syntactic sugar layered on top of the exact same prototype-based system that's always existed in the language.

When you define a method inside a class body, it's actually being attached to the constructor function's .prototype object, exactly as it would be if you'd manually assigned it with SomeConstructor.prototype.methodName = function() {} in pre-ES6 code. What class does add beyond pure syntax are a few genuine behavioral differences: class bodies always execute in strict mode, class declarations are hoisted but land in the Temporal Dead Zone (unlike function declarations, which are fully usable before their definition), and attempting to call a class without new throws an error rather than silently misbehaving.

Q5. What is the difference between an instance property and a prototype method?

An instance property is a property that lives directly on an individual object, typically set up inside a constructor (or class constructor) using this.propertyName = value. Because it's assigned per-instance, every single object created from that constructor gets its own independent copy of the property — mutating one instance's property has zero effect on any other instance.

A prototype method, by contrast, is defined once on the shared .prototype object of the constructor, and every instance accesses that same single copy through the prototype chain rather than each having its own duplicate. This distinction matters a lot for memory efficiency: if you have a constructor for creating a million objects and each object needs a method, defining that method on the prototype means only one copy of that function exists in memory total, whereas defining it as an instance property (e.g., this.method = function() {} inside the constructor) would create a million separate function instances, one per object.

Q6. What is the purpose of the `new` keyword?

The new keyword transforms an ordinary function call into a constructor call, and it silently performs four distinct steps on your behalf every time it's used. First, it creates a brand-new, empty plain object. Second, it sets that new object's internal [[Prototype]] link to point at the constructor function's .prototype property, wiring up the inheritance chain. Third, it executes the constructor function's code, with this inside that function bound to the newly created object, allowing the constructor body to attach properties via this.prop = value. Fourth and finally, unless the constructor function explicitly returns some other object of its own, new automatically returns the newly created and now-populated object as the result of the whole expression.

Forgetting to use new when calling a function meant to be a constructor is a classic source of bugs in older JavaScript code — without it, this inside the function falls back to the global object (or undefined in strict mode), silently corrupting global state or throwing errors instead of properly constructing a new instance. Modern class syntax protects against this by throwing a TypeError if you try to call a class without new.

Q7. What is a getter and setter in JavaScript objects?

Getters and setters are special object methods, defined using the get and set keywords, that let you attach custom logic to what looks like a plain property from the outside, but actually runs a function whenever that property is read (get) or assigned to (set). The consumer of the object never has to know they're calling a function — they just write obj.value or obj.value = 10 as if it were an ordinary data property.

const obj = {
  _value: 0,
  get value() { return this._value; },
  set value(v) { this._value = v < 0 ? 0 : v; }
};

This pattern is extremely useful for validation (rejecting or clamping invalid values before they're stored, as in the example above), computed properties (deriving a value on the fly from other internal state rather than storing it directly), and encapsulation more generally — giving you a seam to intercept reads and writes without changing the object's external API if your internal implementation needs to change later.

Q8. What is the difference between `Object.freeze()` and `Object.seal()`?

Object.freeze() is the strictest form of object locking available natively in JavaScript: once applied, you cannot add new properties, remove existing properties, or change the value of any existing property — any attempt to do so either fails silently (in non-strict mode) or throws a TypeError (in strict mode). This makes the object fully immutable at that level.

Object.seal() is a more moderate restriction: like freeze(), it prevents adding new properties and prevents deleting existing ones, but unlike freeze(), it still allows you to modify the value of any property that was already marked as writable before sealing. Both freeze() and seal() operate shallowly — they only lock the top-level object itself, and any nested objects inside it remain fully mutable unless you explicitly freeze or seal those inner objects too, recursively, yourself.

Q9. What is the difference between an object's own properties and inherited properties?

An "own" property is one that exists directly on the specific object itself, having been explicitly assigned to it — as opposed to a property the object only appears to have because it's accessible through the prototype chain from somewhere further up. From the outside, both kinds of properties often look identical when you access them normally (obj.someProp works the same either way), but the distinction becomes important when you need to know exactly what an object itself contains versus what it merely has access to.

Object.hasOwn(obj, prop) (the modern replacement for the older obj.hasOwnProperty(prop)) checks exclusively for own properties, returning false for anything inherited, even if that inherited property is perfectly accessible via normal dot notation. The in operator and for...in loops, on the other hand, check both own and inherited enumerable properties, which is a common source of bugs when iterating over an object with for...in without an additional hasOwn check to filter out unwanted inherited properties.

Q10. What is composition over inheritance, and why is it often preferred in JavaScript?

Composition is a design approach that builds up complex behavior by combining several small, focused, independent pieces of functionality — functions, objects, or mixins — rather than by building a deep hierarchy of classes that each extend the one before it. Instead of asking "what is this thing a type of?" (the inheritance question), composition asks "what capabilities does this thing need, and which existing pieces can I assemble to provide them?"

Deep inheritance chains have well-known downsides in real-world codebases: they tend to be fragile (a change to a base class can have unpredictable ripple effects on every descendant), they force awkward hierarchies when behavior doesn't cleanly fit a single "is-a" relationship, and they tightly couple unrelated pieces of functionality together just because they happen to share an ancestor. Composition avoids these problems by keeping pieces of functionality small, independently testable, and freely combinable in whatever configuration a given object actually needs — a philosophy that's especially prominent in modern React (hooks and composed components) and general JavaScript idioms.

Q11. What is a mixin in JavaScript?

A mixin is a pattern for sharing a set of reusable methods or behaviors across multiple otherwise-unrelated objects or classes, without requiring them to be linked through a single-inheritance chain. Since JavaScript (like most languages with prototypal or class-based inheritance) only allows an object or class to have one direct prototype/parent, mixins provide a workaround for situations where you want to share functionality from multiple independent sources at once.

The most common implementation copies methods directly from a plain "mixin object" onto a target's prototype, effectively merging the extra behavior in:

class Duck {}
const canFly = { fly() { console.log(`${this.name} is flying`); } };
const canSwim = { swim() { console.log(`${this.name} is swimming`); } };
Object.assign(Duck.prototype, canFly, canSwim);

This lets a single class "borrow" capabilities from as many mixin sources as needed, sidestepping the single-inheritance limitation while keeping each piece of shared behavior small, focused, and independently reusable across completely unrelated class hierarchies.

Next in the series: Asynchronous JavaScript — the event loop, Promises, async/await, and the questions that separate junior from senior candidates.

Enjoying the series? Follow along and share which of these questions you'd actually get asked in an interview!

12 JavaScript Interview Questions Every Dev Should Know — Part 2: Functions, Scope & Closures

Keyur Gohil — Tue, 04 Aug 2026 12:58:10 +0000

Welcome to Part 2 of the JS interview series! This time we're tackling functions, scope, and the topic that trips up even experienced developers in interviews: closures.

Missed Part 1? Check out Fundamentals & Data Types first.

Q1. What is a closure?

A closure is formed whenever a function is created: every function in JavaScript automatically retains a live link to the lexical scope in which it was defined, and can continue to access the variables in that scope for as long as the function itself is reachable — even after the code that originally created that scope has finished running. This isn't a special or occasional behavior; it's a fundamental property of every single function, since JavaScript uses lexical (not dynamic) scoping.

A common but inaccurate way this gets described is "an inner function that remembers its outer function's variables." That's the most useful and most commonly demonstrated case, but nesting one function inside another isn't actually a requirement for a closure to exist. Even a top-level function that references a variable from the global scope is technically forming a closure over that scope:

let x = 10;
function notNested() {
  console.log(x); // still a closure — closing over the global scope
}

What makes nested closures specifically powerful and interview-relevant is that they let an inner function keep access to an outer function's local variables — variables that would otherwise be destroyed once the outer function returns. That's what enables patterns like private state, factory functions, and memoization:

function counter() {
  let count = 0;
  return () => ++count;
}
const inc = counter();
inc(); // 1
inc(); // 2

Here, count would normally be garbage collected once counter() finishes executing — but because the returned arrow function closes over it, count stays alive in memory, and there's no way to reach it from outside except through inc().

Q2. What is lexical scoping?

Lexical scoping (also called static scoping) means that a variable's accessibility is determined entirely by where it's physically written in your source code — not by which function called which, or the order in which functions happen to execute at runtime. When JavaScript compiles your code, it can already determine, just by looking at the nesting of functions and blocks, exactly which variables any given piece of code will be able to see.

This is what allows an inner function to "reach out" to variables declared in the function that contains it, and that function's own container, all the way up to the global scope — a chain often called the scope chain. Because this resolution happens based on code structure rather than call order, the same function will always resolve its outer variables the same way, regardless of where or how many times it's invoked, which is exactly why closures behave predictably.

Q3. What is the difference between function declarations and function expressions?

A function declaration is a function defined as a standalone statement using the function keyword, given a name, and not used as part of any larger expression — for example, function greet() {} written on its own line. Declarations are hoisted completely by the JavaScript engine, meaning both the function's name and its entire body are available before execution even reaches that line in the code, which is why you can call a declared function from earlier in the file, before its definition physically appears.

A function expression is a function that appears as part of an expression, rather than as its own statement — meaning it's defined somewhere a value is expected. Assigning a function to a variable (const greet = function() {}) is the most common example, but it's important not to conflate "function expression" with "assigned to a variable" — those are two different things. A function can be a function expression without ever being assigned to a variable at all, such as when it's passed directly as a callback argument or immediately invoked:

setTimeout(function () { console.log("hi"); }, 1000); // function expression, no variable
(function () { console.log("IIFE"); })();               // function expression, no variable
const greet = function () { console.log("hello"); };     // function expression, assigned to a variable

What actually matters for hoisting behavior is only whether it was assigned to a variable, and if so, which kind. If a function expression is assigned to a var, only the variable name is hoisted (initialized to undefined); if assigned to let/const, the variable is hoisted into the Temporal Dead Zone. Either way, the function itself only becomes callable once that assignment line actually executes — unlike a function declaration, whose entire body is available immediately.

Q4. What are arrow functions, and how do they differ from regular functions?

Arrow functions, introduced in ES6, offer a shorter syntax for writing functions, but the syntax isn't the main reason they matter in interviews — it's their fundamentally different behavior around this. A regular function gets its own this value determined dynamically by how it's called (as a method, standalone, with new, etc.), while an arrow function has no this of its own at all — it simply looks up and uses whatever this value exists in its surrounding lexical scope at the time it was defined.

This makes arrow functions especially well-suited for callbacks where you want to preserve the outer this (like inside a class method's event handler), but poorly suited for object methods or constructors where dynamic this binding is actually needed. Arrow functions also lack their own arguments object, super, and new.target, and they cannot be used as constructors — attempting new someArrowFn() throws a TypeError because arrow functions have no internal [[Construct]] method and no prototype property.

Q5. What is the `this` keyword, and how is its value determined?

this is a special keyword whose value is determined dynamically based on how a function is invoked, not where the function is physically defined in the code (the one major exception being arrow functions, which ignore this rule entirely and inherit this lexically). This dynamic nature is one of the most confusing aspects of JavaScript for developers coming from languages with more rigid this/self semantics.

There's a well-defined precedence order the engine follows to resolve this for any given function call:

new binding — if the function is called with new, this refers to the newly created object.
Explicit binding — if call(), apply(), or bind() was used to set this directly.
Implicit binding — if the function was called as a method on an object (obj.method()), this refers to that object.
Default binding — if none of the above apply, this falls back to the global object in non-strict mode, or undefined in strict mode (which is the default inside ES modules and classes).

Q6. What is the difference between `call()`, `apply()`, and `bind()`?

All three methods exist on every function and let you explicitly control what this refers to when the function runs, overriding whatever the default binding rules would otherwise produce. The key differences are in how arguments are passed and when the function actually executes.

call(thisArg, arg1, arg2, ...) invokes the function immediately, with any additional arguments passed individually, comma-separated, exactly as you'd normally call the function. apply(thisArg, [argsArray]) also invokes immediately, but expects its arguments bundled into a single array — useful when you already have an array of arguments (or historically, before the spread operator existed, for things like Math.max.apply(null, numbersArray)). bind(thisArg, ...) is different in kind: it does not call the function at all — instead, it returns a brand-new function with this permanently locked to the given value, which you can then invoke later, as many times as you like, always with that same this.

Q7. What is currying in JavaScript?

Currying is a functional programming technique where a function that logically takes several arguments is restructured into a chain of nested functions, each accepting exactly one argument, until all the arguments have been supplied and the original computation can run. Instead of calling add(1, 2, 3), a curried version is called as add(1)(2)(3), with each call returning a new function waiting for the next argument.

The real value of currying shows up with partial application — the ability to "lock in" some arguments early and produce a specialized, reusable function for later, without needing all the arguments up front. This is common in functional libraries and React/Redux-style code, for example creating a reusable multiplyByTwo = multiply(2) from a general-purpose curried multiply function, which can then be applied to many different values without repeating the first argument each time.

const add = a => b => c => a + b + c;
add(1)(2)(3); // 6
const add5 = add(5); // partially applied

Q8. What is the `arguments` object?

arguments is a special, array-like object that's automatically available inside every regular (non-arrow) function, containing every argument that was actually passed to the function when it was called — regardless of how many parameters were formally declared in the function's signature. This made it historically useful for writing functions that accept a variable number of arguments, before rest parameters existed.

It's important to note that arguments is only array-like, not a true array: it has a length property and supports index-based access (arguments[0]), but it lacks array methods like .map(), .filter(), or .forEach() directly — you have to convert it first, typically with Array.from(arguments) or the spread operator [...arguments]. It's also completely unavailable inside arrow functions; if you reference arguments inside an arrow function, JavaScript looks it up in the nearest enclosing regular function instead, which is a subtle and common source of bugs.

Q9. What are default parameters?

Default parameters, introduced in ES6, let you specify a fallback value for a function parameter that will be used automatically if the caller either omits that argument entirely or explicitly passes undefined. Before this feature existed, developers had to manually check inside the function body (name = name || "Guest"), which had its own bugs since falsy-but-valid values like 0 or "" would incorrectly trigger the fallback.

function greet(name = "Guest") {
  return `Hello, ${name}`;
}
greet();        // "Hello, Guest"
greet("Sam");   // "Hello, Sam"

Default parameter values aren't limited to simple literals — they can be arbitrary expressions, function calls, or even reference earlier parameters in the same parameter list, and they're evaluated fresh, at call time, every time the function runs without that argument being supplied.

Q10. What is a pure function?

A pure function is one that satisfies two strict guarantees: given the same input, it will always produce exactly the same output, with no exceptions or variation, and it causes no observable side effects anywhere else in the program — it doesn't mutate its arguments, doesn't modify any external or global state, and doesn't perform I/O like network requests, DOM updates, or console logging.

Pure functions are prized in functional programming because they're trivially easy to test (no setup or mocking of external state required), easy to reason about in isolation, safe to run in parallel or in any order, and safe to memoize (cache results for previously seen inputs) since their output is fully determined by their input. Impure functions — like one that reads Date.now(), reads/writes a global variable, or reassigns a property on an object passed in as an argument — break these guarantees and are harder to test and predict.

Q11. What is the difference between synchronous and asynchronous function execution regarding the call stack?

Synchronous code runs immediately, one operation at a time, directly on the call stack — each function call is pushed onto the stack, executes fully, and is popped off before the next line of code can run. This means a long-running synchronous operation (like a large loop or expensive computation) will completely block the rest of the program, including UI updates and user interactions, until it finishes.

Asynchronous operations work differently: rather than executing directly on the call stack, operations like setTimeout, network requests, or file reads are handed off to the browser's or Node's underlying runtime (Web APIs in the browser, libuv in Node), which handles them outside of JavaScript's single thread. Only once that underlying work completes does its associated callback get placed into a queue, and the event loop moves it onto the call stack for execution — but only after the call stack is completely empty, meaning all currently running synchronous code has finished first.

Q12. What is recursion, and what is a common pitfall with it in JavaScript?

Recursion is a technique where a function solves a problem by calling itself with a smaller or simpler version of that same problem, continuing until it reaches a "base case" — a condition simple enough to be answered directly without further recursive calls. Recursive solutions are often more elegant and readable than iterative ones for inherently recursive problems, such as traversing tree structures, computing factorials, or implementing certain sorting algorithms.

The major practical pitfall is the stack overflow error: every recursive call adds a new frame onto the call stack, and if the recursion goes too deep — either because the base case is missing, incorrect, or the input is simply very large — the stack will exceed its size limit and the program crashes. Many languages solve this with tail-call optimization, where the engine can reuse the current stack frame instead of adding a new one when a function's very last action is a recursive call, but despite tail-call optimization being part of the official ES6 specification, most JavaScript engines (including V8, which powers Chrome and Node.js) never actually implemented it — Safari's JavaScriptCore is the notable exception.

That's Part 2 done! Up next: Objects, Prototypes & OOP — prototypal inheritance, this, classes, and more.

Found this useful? Follow for the rest of the series and drop a comment with your favorite closure interview trick question 👇

JavaScript Interview Questions Every Dev Should Know — Part 1: Fundamentals & Data Types

Keyur Gohil — Tue, 28 Jul 2026 07:25:31 +0000

If you're prepping for a JavaScript interview, the fundamentals are where it all starts. Interviewers love probing this area because it separates people who've memorized syntax from people who actually understand how the language behaves under the hood.

This is Part 1 of an 8-part series covering JavaScript interview questions with detailed explanations. Let's dive in. 🚀

If you're prepping for a JavaScript interview, the fundamentals are where it all starts. Interviewers love probing this area because it separates people who've memorized syntax from people who actually understand how the language behaves under the hood.

This is Part 1 of an 8-part series covering JavaScript interview questions with detailed explanations. Let's dive in. 🚀

Q1. What are the primitive data types in JavaScript?

JavaScript has seven primitive types:

string
number
boolean
null
undefined
symbol
bigint

Primitives are immutable and are compared by value, not by reference.

Everything else—objects, arrays, and functions—is a reference type and is compared by reference (memory address).

Q2. What is the difference between `null` and `undefined`?

undefined means a variable has been declared but not assigned a value, a function has no explicit return, or an object property doesn't exist.
null is an intentional assignment representing "no value."

typeof undefined; // "undefined"
typeof null;      // "object" (a long-standing JavaScript bug)

Q3. What is the difference between `==` and `===`?

=== (strict equality) compares both value and type.

== (loose equality) performs type coercion before comparison.

"5" == 5;  // true
"5" === 5; // false

Best practice: Prefer === to avoid unexpected coercion.

Q4. What is `NaN`, and how do you correctly check for it?

NaN ("Not a Number") represents an invalid numeric result.

A unique property:

NaN !== NaN // true

Correct way to check:

Number.isNaN(NaN);     // true
isNaN("hello");        // true (because of coercion)
Number.isNaN("hello"); // false

Q5. What is type coercion in JavaScript?

Type coercion is JavaScript automatically converting one type into another.

Examples:

"5" - 2; // 3
"5" + 2; // "52"

It can also be explicit:

Number("5");
String(5);
Boolean(1);

Q6. What are truthy and falsy values?

Falsy values are:

false
0
-0
0n
""
null
undefined
NaN

Everything else—including {} and []—is truthy.

Q7. What is the difference between `var`, `let`, and `const`?

Keyword	Scope	Redeclare	Reassign
`var`	Function	✅	✅
`let`	Block	❌	✅
`const`	Block	❌	❌

Notes:

var is initialized with undefined.
let and const exist in the Temporal Dead Zone until their declaration.
const prevents reassignment, not object mutation.

Q8. What is variable hoisting?

Hoisting moves declarations to the top of their scope before execution.

console.log(a); // undefined
var a = 10;

With let and const:

console.log(a); // ReferenceError
let a = 10;

Q9. What is the Temporal Dead Zone (TDZ)?

The TDZ is the time between entering a scope and reaching a let or const declaration.

console.log(x); // ReferenceError

let x = 5;

Although x exists internally, it cannot be accessed until its declaration executes.

Q10. What is the difference between deep copy and shallow copy?

A shallow copy copies only the first level.

Nested objects remain shared.

const shallow = { ...original };

A deep copy duplicates every nested object.

const deep = structuredClone(original);

Final Thoughts

Mastering these JavaScript fundamentals is essential for technical interviews because they reveal how well you understand the language beyond syntax.

In Part 2, we'll cover Functions, Scope & Closures—including some of the most frequently asked JavaScript interview questions.

If this article helped, leave a ❤️ and follow for the rest of the series!

Understanding the useEffect Hook in React: A Practical Guide with Examples

Keyur Gohil — Thu, 23 Jul 2026 11:21:21 +0000

React is all about building interactive user interfaces. But sometimes, our components need to interact with the outside world.

For example:

Fetching data from an API
Updating the browser tab title
Setting up timers
Adding event listeners
Working with WebSockets
Subscribing to external services

These operations are called side effects.

In React, the useEffect Hook is used to handle these side effects.

What is `useEffect`?

useEffect is a built-in React Hook that allows you to perform side effects in functional components.

import { useEffect } from "react";

useEffect(() => {
  // Side effect code
}, []);

The useEffect Hook runs after the component renders.

A basic example:

import { useEffect } from "react";

function App() {
  useEffect(() => {
    console.log("Component rendered");
  }, []);

  return <h1>Hello React</h1>;
}

export default App;

In this example, the effect runs after the component is mounted.

What is a Side Effect?

A side effect is an operation that happens outside the normal React rendering process.

Common examples include:

API calls
Browser document updates
Timers
Event listeners
WebSocket connections
Local storage operations

For example, updating the document title is a side effect:

import { useEffect } from "react";

function App() {
  useEffect(() => {
    document.title = "My React App";
  }, []);

  return <h1>Welcome to React</h1>;
}

export default App;

After the component renders, the browser tab title becomes My React App.

Understanding the Dependency Array

The second argument of useEffect is called the dependency array.

It controls when the effect should run.

1. Without a Dependency Array

useEffect(() => {
  console.log("Effect executed");
});

This effect runs after every render.

import { useEffect, useState } from "react";

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

  useEffect(() => {
    console.log("Component rendered");
  });

  return (
    <button onClick={() => setCount(count + 1)}>
      Count: {count}
    </button>
  );
}

export default Counter;

Every time the state changes, the component re-renders and the effect runs again.

2. Empty Dependency Array

useEffect(() => {
  console.log("Component mounted");
}, []);

An empty dependency array means the effect runs only after the component is mounted.

This is commonly used for fetching initial data.

useEffect(() => {
  fetchData();
}, []);

3. With Dependencies

useEffect(() => {
  console.log("Count changed");
}, [count]);

This effect runs whenever the count value changes.

Example: Updating the Document Title

Let's create a counter application:

import { useEffect, useState } from "react";

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

  useEffect(() => {
    document.title = `Count: ${count}`;
  }, [count]);

  return (
    <div>
      <h1>Count: {count}</h1>

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

export default Counter;

Whenever count changes, the browser tab title also changes.

The dependency array is:

[count]

This tells React:

Run this effect whenever count changes.

Fetching Data Using `useEffect`

One of the most common use cases of useEffect is fetching data from an API.

import { useEffect, useState } from "react";

function Users() {
  const [users, setUsers] = useState([]);
  const [loading, setLoading] = useState(true);

  useEffect(() => {
    fetch("https://jsonplaceholder.typicode.com/users")
      .then((response) => response.json())
      .then((data) => {
        setUsers(data);
        setLoading(false);
      });
  }, []);

  if (loading) {
    return <p>Loading...</p>;
  }

  return (
    <ul>
      {users.map((user) => (
        <li key={user.id}>{user.name}</li>
      ))}
    </ul>
  );
}

export default Users;

How does this work?

When the component mounts:

useEffect(() => {
  // API call
}, []);

The API request runs.

After the data is received:

setUsers(data);

React updates the state and re-renders the component.

Fetching Data When a Value Changes

Suppose we want to fetch posts for a specific user.

import { useEffect, useState } from "react";

function UserPosts({ userId }) {
  const [posts, setPosts] = useState([]);

  useEffect(() => {
    fetch(
      `https://jsonplaceholder.typicode.com/posts?userId=${userId}`
    )
      .then((response) => response.json())
      .then((data) => setPosts(data));
  }, [userId]);

  return (
    <div>
      {posts.map((post) => (
        <article key={post.id}>
          <h2>{post.title}</h2>
          <p>{post.body}</p>
        </article>
      ))}
    </div>
  );
}

export default UserPosts;

Whenever userId changes, the effect runs again and fetches the new user's posts.

Cleanup Function in `useEffect`

Some effects need to be cleaned up when a component is removed from the screen.

Examples include:

Timers
Event listeners
WebSocket connections
Subscriptions

The cleanup function is returned from the effect.

useEffect(() => {
  // Setup

  return () => {
    // Cleanup
  };
}, []);

Example: Timer with Cleanup

import { useEffect, useState } from "react";

function Timer() {
  const [seconds, setSeconds] = useState(0);

  useEffect(() => {
    const intervalId = setInterval(() => {
      setSeconds((previousSeconds) => previousSeconds + 1);
    }, 1000);

    return () => {
      clearInterval(intervalId);
    };
  }, []);

  return <h1>{seconds} seconds</h1>;
}

export default Timer;

Here, the timer starts when the component mounts.

When the component is unmounted, the cleanup function runs:

clearInterval(intervalId);

This prevents memory leaks.

Example: Event Listener

import { useEffect, useState } from "react";

function WindowWidth() {
  const [width, setWidth] = useState(window.innerWidth);

  useEffect(() => {
    function handleResize() {
      setWidth(window.innerWidth);
    }

    window.addEventListener("resize", handleResize);

    return () => {
      window.removeEventListener("resize", handleResize);
    };
  }, []);

  return <h1>Window Width: {width}px</h1>;
}

export default WindowWidth;

The event listener is added when the component mounts.

When the component is removed, the listener is removed as well.

Avoid Infinite Loops

Be careful when updating a state variable inside an effect that also depends on that same state.

❌ Bad example:

import { useEffect, useState } from "react";

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

  useEffect(() => {
    setCount(count + 1);
  }, [count]);

  return <h1>{count}</h1>;
}

This creates an infinite loop:

count changes.
The effect runs.
setCount changes count.
The component renders again.
The effect runs again.

And the cycle continues.

Don't Use `useEffect` for Everything

A common mistake is using useEffect when it is not necessary.

For example:

const [fullName, setFullName] = useState("");

useEffect(() => {
  setFullName(`${firstName} ${lastName}`);
}, [firstName, lastName]);

This is unnecessary.

Instead, simply calculate the value:

const fullName = `${firstName} ${lastName}`;

This is simpler and avoids an unnecessary state update.

`useEffect` vs Event Handlers

Use an event handler when something happens because of a user action.

For example:

function Button() {
  function handleClick() {
    console.log("Button clicked");
  }

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

You do not need useEffect for this.

Use useEffect when you need to synchronize your component with an external system.

Simple Mental Model

You can remember the React flow like this:

State or Props Change
        ↓
Component Renders
        ↓
React Updates the DOM
        ↓
useEffect Runs

This makes useEffect useful for tasks that should happen after rendering.

When Should You Use `useEffect`?

Use useEffect when you need to:

Fetch data from an API
Update the document title
Set up timers
Add event listeners
Subscribe to external services
Connect to WebSockets
Work with browser APIs
Synchronize with third-party libraries

When Should You Avoid `useEffect`?

You probably do not need useEffect when:

You are calculating a value from existing state or props.
You are responding directly to a user action.
You can perform the operation during rendering.
You are using an effect only to update another state unnecessarily.

Conclusion

The useEffect Hook is one of the most important Hooks in React.

The key points to remember are:

useEffect is used to handle side effects.
The dependency array controls when the effect runs.
An empty dependency array runs the effect after the initial mount.
Dependencies should include values used inside the effect.
Cleanup functions are important for timers, event listeners, and subscriptions.
Avoid using useEffect when a simple calculation or event handler is enough.

Once you understand when an effect should run and why it should run, using useEffect becomes much easier.

Happy Coding! 🚀

Your Database Will Be Breached Someday. The Question Is: Will Passwords Be Inside?

Keyur Gohil — Thu, 25 Jun 2026 06:41:27 +0000

Most developers think password hashing is about authentication.

It's not. Authentication is just a side effect. Password hashing exists for a much darker reason: because databases get stolen.

Every year, companies invest millions in firewalls, monitoring systems, cloud security, and access controls. Yet breach after breach continues to make headlines.

The uncomfortable truth is that security teams don't assume a breach will never happen.

They assume it eventually will. And when that day comes, one question determines whether the incident becomes a minor security event or a full-scale disaster:
Did you hash the passwords?

The Difference Between an Incident and a Catastrophe

Imagine an attacker gains read access to your production database. Not a far-fetched scenario.

A leaked backup.
A vulnerable API.
A compromised employee account.
A misconfigured cloud bucket.

The attacker runs a simple query:

SELECT email, password FROM users;

If your system stores passwords in plain text, the breach is over. The attacker already won.

No advanced techniques.
No brute force.
No expensive infrastructure.

They now possess something more valuable than your database itself: your users' digital identities.

Because users rarely reuse databases. They reuse passwords.

The same password protecting an account on your platform might also unlock their Gmail, GitHub, LinkedIn, banking app, or company VPN.

What started as your security problem instantly becomes everyone else's.

This Is Not Theoretical

History has repeatedly shown what happens when passwords are handled incorrectly. The RockYou breach exposed more than 30 million passwords stored in plain text. Attackers didn't need to crack anything. They simply read the data.

Years later, those leaked passwords were still appearing in credential stuffing attacks across the internet. A single backend decision survived longer than the company itself. That's the thing about password leaks. They don't expire when the incident report is published.

Why Hashing Changes Everything

A properly hashed password transforms a breach.

Instead of seeing:

john@example.com | John@123

an attacker sees:

john@example.com | $argon2id$v=19$m=65536...

The database is still stolen. But the passwords are not. Now every account becomes a separate cryptographic challenge.

Instead of instantly logging in, attackers must spend time, compute power, and money attempting to recover passwords. Many never become worth the effort.

Hashing doesn't prevent breaches. It limits the blast radius. And that's exactly why security professionals consider it non-negotiable.

The Mistake Many Developers Still Make

Some developers understand hashing but choose fast algorithms like SHA-256. Technically hashed. Practically vulnerable. Modern hardware can calculate billions of SHA-256 hashes every second. For password storage, speed is the enemy.

You want attackers to suffer. That's why algorithms such as Argon2id, bcrypt, and scrypt were created. Their purpose isn't efficiency.

Their purpose is making password cracking painfully expensive.

The Real Job of a Backend Engineer

A good backend engineer doesn't design systems assuming everything goes right. They design systems assuming something eventually goes wrong.

Servers get compromised.
Credentials leak.
Backups get exposed.

Humans make mistakes. The goal isn't building an unbreakable system.
The goal is ensuring that when failure happens, users aren't the ones paying the price.

Password hashing is one of the simplest ways to achieve that. A few lines of code today can prevent millions of credentials from becoming tomorrow's breach headline.

And that's why password hashing isn't a feature. It's a responsibility.

Adding Custom Headers in Axios: A Simple Guide

Keyur Gohil — Wed, 24 Jun 2026 11:47:05 +0000

When working with APIs, you'll often need to send additional information along with your requests. This information is usually passed through HTTP headers for authentication, tracking, content negotiation, and more.

In this article, we'll learn how to send custom headers using Axios.

Understanding Axios Request Syntax

Axios methods generally follow this pattern:

axios.method(url, data, options);

Where:

url → API endpoint
data → Request payload (for POST, PUT, PATCH, etc.)
options → Configuration object containing headers and other settings

For GET requests, there is no request body:

axios.get(url, options);
Adding Custom Headers

Custom headers are passed inside the headers property of the configuration object.

GET Request Example

axios.get('https://api.example.com/users', {
  headers: {
    'custom-header-key': 'your value'
  }
});

POST Request Example

axios.post(
  'https://api.example.com/users',
  {
    name: 'John Doe'
  },
  {
    headers: {
      'custom-header-key': 'your value'
    }
  }
);

Multiple Custom Headers

You can send multiple headers in the same request.

axios.get('https://api.example.com/users', {
  headers: {
    'Authorization': 'Bearer your-token',
    'X-App-Version': '1.0.0',
    'custom-header-key': 'your value'
  }
});

Using Variables for Headers

In real-world applications, header values are often dynamic.

const token = localStorage.getItem('token');

axios.get('https://api.example.com/profile', {
  headers: {
    Authorization: `Bearer ${token}`
  }
});

Creating Reusable Axios Instances

If you use the same headers across multiple requests, create an Axios instance.

import axios from 'axios';

const api = axios.create({
  baseURL: 'https://api.example.com',
  headers: {
    'custom-header-key': 'your value'
  }
});

api.get('/users');
api.post('/posts', {
  title: 'Hello World'
});

Complete Example

import axios from 'axios';

axios.post(
  'https://api.example.com/login',
  {
    email: 'user@example.com',
    password: 'password123'
  },
  {
    headers: {
      'custom-header-key': 'your value',
      'Content-Type': 'application/json'
    }
  }
)
.then(response => {
  console.log(response.data);
})
.catch(error => {
  console.error(error);
});

Key Takeaways

Custom headers are added inside the headers object.
For GET requests, pass headers as the second argument.
For POST, PUT, and PATCH requests, headers are passed in the third argument.
Use Axios instances to avoid repeating common headers.
Headers are commonly used for authentication, API keys, and request metadata.

That's all! Adding custom headers in Axios is straightforward and helps you communicate additional information with your API requests efficiently.

DEV Community: Keyur Gohil

11 JavaScript Interview Questions Every Dev Should Know — Part 3: Objects, Prototypes & OOP

Q1. How does prototypal inheritance work in JavaScript?

Q2. What is the difference between Object.create() and a constructor function?

Q3. What is the difference between classical inheritance and prototypal inheritance?

Q4. What are ES6 classes, and are they truly a new object model?

Q5. What is the difference between an instance property and a prototype method?

Q6. What is the purpose of the new keyword?

Q7. What is a getter and setter in JavaScript objects?

Q8. What is the difference between Object.freeze() and Object.seal()?

Q9. What is the difference between an object's own properties and inherited properties?

Q10. What is composition over inheritance, and why is it often preferred in JavaScript?

Q11. What is a mixin in JavaScript?

12 JavaScript Interview Questions Every Dev Should Know — Part 2: Functions, Scope & Closures

Q1. What is a closure?

Q2. What is lexical scoping?

Q3. What is the difference between function declarations and function expressions?

Q4. What are arrow functions, and how do they differ from regular functions?

Q5. What is the this keyword, and how is its value determined?

Q6. What is the difference between call(), apply(), and bind()?

Q7. What is currying in JavaScript?

Q8. What is the arguments object?

Q9. What are default parameters?

Q10. What is a pure function?

Q11. What is the difference between synchronous and asynchronous function execution regarding the call stack?

Q12. What is recursion, and what is a common pitfall with it in JavaScript?

JavaScript Interview Questions Every Dev Should Know — Part 1: Fundamentals & Data Types

Q1. What are the primitive data types in JavaScript?

Q2. What is the difference between null and undefined?

Q3. What is the difference between == and ===?

Q4. What is NaN, and how do you correctly check for it?

Q5. What is type coercion in JavaScript?

Q6. What are truthy and falsy values?

Q7. What is the difference between var, let, and const?

Q8. What is variable hoisting?

Q9. What is the Temporal Dead Zone (TDZ)?

Q10. What is the difference between deep copy and shallow copy?

Final Thoughts

Understanding the useEffect Hook in React: A Practical Guide with Examples

What is useEffect?

What is a Side Effect?

Understanding the Dependency Array

1. Without a Dependency Array

2. Empty Dependency Array

3. With Dependencies

Example: Updating the Document Title

Fetching Data Using useEffect

How does this work?

Fetching Data When a Value Changes

Cleanup Function in useEffect

Example: Timer with Cleanup

Example: Event Listener

Avoid Infinite Loops

Don't Use useEffect for Everything

useEffect vs Event Handlers

Simple Mental Model

When Should You Use useEffect?

When Should You Avoid useEffect?

Conclusion

Your Database Will Be Breached Someday. The Question Is: Will Passwords Be Inside?

The Difference Between an Incident and a Catastrophe

This Is Not Theoretical

Why Hashing Changes Everything

The Mistake Many Developers Still Make

The Real Job of a Backend Engineer

Adding Custom Headers in Axios: A Simple Guide

Understanding Axios Request Syntax

Multiple Custom Headers

Using Variables for Headers

Creating Reusable Axios Instances

Key Takeaways

Q2. What is the difference between `Object.create()` and a constructor function?

Q6. What is the purpose of the `new` keyword?

Q8. What is the difference between `Object.freeze()` and `Object.seal()`?

Q5. What is the `this` keyword, and how is its value determined?

Q6. What is the difference between `call()`, `apply()`, and `bind()`?

Q8. What is the `arguments` object?

Q2. What is the difference between `null` and `undefined`?

Q3. What is the difference between `==` and `===`?

Q4. What is `NaN`, and how do you correctly check for it?

Q7. What is the difference between `var`, `let`, and `const`?

What is `useEffect`?

Fetching Data Using `useEffect`

Cleanup Function in `useEffect`

Don't Use `useEffect` for Everything

`useEffect` vs Event Handlers

When Should You Use `useEffect`?

When Should You Avoid `useEffect`?