Start with the simple idea: a variable is a label

Before comparing keywords, let us agree on what a variable is. A variable is a name attached to a value so that you can use that value later. Imagine a jar in your kitchen with a sticky label that says “sugar”. The label lets you find what is inside without opening every jar. In code, price is the label and 250 is what is in the jar.

When you declare a variable, you are doing two things: creating the label, and deciding the rules for that label. Can you peel it off and stick it on a different jar later? Who in the house is allowed to see it? Can you use the label before you have written it? Those three questions, reassignment, scope and timing, are exactly where var, let and const differ.

Why does JavaScript have three?

JavaScript was created in 1995 and for its first twenty years it had exactly one way to declare a variable: var. It worked, but its rules were different from nearly every other popular language, and those differences caused bugs that confused beginners and experts alike.

In 2015, the language standard known as ES2015 (many people call it ES6) added two new keywords, let and const, with rules that behave the way programmers coming from other languages expect. The old keyword could not be changed or removed, because millions of existing websites depend on it. So JavaScript ended up with all three. That is the whole story: two modern tools sitting next to an old one that has to stay for compatibility.

The first big difference: scope

Scope answers the question: where in my code can I use this variable? A useful way to picture it is a house. A function scope is the whole house: anyone inside, in any room, can use what is stored in the hallway. A block scope is a single room: what you put in the bedroom stays in the bedroom. A block in JavaScript is any pair of curly braces, such as the body of an if statement or a for loop.

• var is function-scoped. It ignores the curly braces of an if or a loop and is visible everywhere in the surrounding function.
• let and const are block-scoped. They exist only inside the braces where you declared them.

I do not want you to take that on trust, so here is a short test. It declares one variable of each kind inside an if block and then tries to use each one outside it.

// 1. Scope: does the variable survive outside the block?
if (true) {
  var oldWay = "I am var";
  let newWay = "I am let";
  const fixed = "I am const";
}
console.log("var outside the block  :", oldWay);
try { console.log(newWay); } catch (e) { console.log("let outside the block  :", e.name + ": " + e.message); }
try { console.log(fixed); } catch (e) { console.log("const outside the block:", e.name + ": " + e.message); }

// 2. A loop counter
for (var i = 0; i < 3; i++) {}
console.log("var i after the loop  :", i);
for (let j = 0; j < 3; j++) {}
console.log("typeof j after loop   :", typeof j);

// 3. Redeclaring
var price = 100;
var price = 250;          // allowed, silently
console.log("var redeclared        :", price);

Output (run with Node 22):

var outside the block  : I am var
let outside the block  : ReferenceError: newWay is not defined
const outside the block: ReferenceError: fixed is not defined
var i after the loop  : 3
typeof j after loop   : undefined
var redeclared        : 250

The var value leaked out of the block and printed normally. The let and const values did not exist outside the block, so JavaScript threw a ReferenceError. The loop counter shows the same behaviour: after a for (var i...) loop, i is still alive and holds 3. After a for (let j...) loop, j is gone.

Leaking sounds harmless, but think about a long function with several loops that all use var i. They share one variable. A value left behind by the first loop can quietly change the behaviour of the third. Block scope is a safety feature: it keeps each piece of code from trampling the variables of its neighbours.

The second difference: redeclaring

With var, you can declare the same name twice in the same scope and JavaScript says nothing. The last line of the scope test shows it: var price = 100; followed by var price = 250; is allowed, and the value simply becomes 250.

That is dangerous in a big file. Suppose you are 400 lines into a function and you declare var total, forgetting that you already used total near the top for something else. You have just overwritten the earlier value with no warning. With let and const, declaring the same name twice in the same scope is a syntax error, and your editor will usually underline it before you even run the code. A loud mistake is far cheaper than a silent one.

The third difference: hoisting and the “dead zone”

This is the topic that scares people, but the idea is simple. Before JavaScript runs your code, it reads through it once and notes every declaration. This is called hoisting, as if the declarations were lifted to the top of their scope. What happens to the variable next depends on the keyword.

• var is hoisted and given the starting value undefined. You can read it before its line, and you just get undefined.
• let and const are hoisted too, but they stay uninitialised until execution reaches their line. Touching them earlier throws an error. The stretch between the top of the scope and the declaration line is called the temporal dead zone.

// Hoisting: using a variable before the line that declares it
console.log("var before its line   :", early);
var early = 5;

try {
  console.log(late);
} catch (e) {
  console.log("let before its line   :", e.name + ": " + e.message);
}
let late = 5;

try {
  console.log(never);
} catch (e) {
  console.log("const before its line :", e.name + ": " + e.message);
}
const never = 5;

// A function declaration is hoisted completely
console.log("function hoisted      :", greet());
function greet() { return "hello"; }

Output:

var before its line   : undefined
let before its line   : ReferenceError: Cannot access 'late' before initialization
const before its line : ReferenceError: Cannot access 'never' before initialization
function hoisted      : hello

The var variable quietly printed undefined, which is the worst kind of result: no crash, but a wrong value flowing into the rest of your program. The let and const versions failed immediately with a clear message: “Cannot access ‘late’ before initialization”. The error names the variable and tells you what went wrong, so you fix it in seconds.

The last line shows that function declarations are the exception. A function declared with the function keyword is hoisted completely, body and all, so you can call it above where it is written. A function stored in a variable, such as var greet = function() {...}, follows the variable rules instead: the name exists but holds undefined, and calling it early gives a TypeError.

The fourth difference: reassigning

Here let and const part company. A let variable can be given a new value as often as you like. A const variable cannot be pointed at something else once it has been set. It also must be given a value at the moment it is declared.

Use let for things that genuinely change: a running total, a counter, a flag that flips when something happens. Use const for everything else. In real programs, the large majority of variables never need to change after they are first set, so const ends up being the most common keyword in well-written code.

The part everyone gets wrong: const is not “frozen”

New developers often assume const means the value can never change. It does not. It means the label cannot be moved to a different jar. If the jar holds an object or an array, you can still change what is inside it. Watch:

"use strict";
const rate = 0.18;
try { rate = 0.2; } catch (e) { console.log("reassign const      :", e.name + ": " + e.message); }

const cart = ["rice", "dal"];
cart.push("tea");                       // allowed: the array changes, the label does not
console.log("push into const array :", cart);

try { cart = ["new"]; } catch (e) { console.log("point const elsewhere :", e.name + ": " + e.message); }

const user = { name: "Asha", plan: "free" };
user.plan = "pro";                      // allowed
console.log("edit const object     :", user);

const locked = Object.freeze({ plan: "free" });
try { locked.plan = "pro"; } catch (e) { console.log("frozen object edit   :", e.name + ": " + e.message); }
console.log("frozen stays         :", locked);

let count = 0;
count = count + 1;
console.log("let can be reassigned:", count);

Output:

reassign const      : TypeError: Assignment to constant variable.
push into const array : [ 'rice', 'dal', 'tea' ]
point const elsewhere : TypeError: Assignment to constant variable.
edit const object     : { name: 'Asha', plan: 'pro' }
frozen object edit   : TypeError: Cannot assign to read only property 'plan' of object '#<Object>'
frozen stays         : { plan: 'free' }
let can be reassigned: 1

Reassigning the constant failed, as expected. But pushing a new item into a const array worked, and so did changing a property of a const object. The label still points at the same array and the same object; only their contents changed. If you truly need an object that cannot be edited, Object.freeze() locks it, as the last lines show. The freeze is shallow, meaning it protects the top level only, so nested objects still need their own freezing if you want them locked.

The sneaky one: var and the global object

There is one more difference that matters in browsers. A var declared at the top level of a normal script becomes a property of the global window object. That means it can collide with other scripts on the same page, including ad scripts, analytics and plugins. A let or const at the top level does not attach to window. I tested it in a real browser:

// Run as a normal <script> in a browser page
var a = 1;
let b = 2;
const c = 3;
console.log(window.a, window.b, window.c);

Output:

1 undefined undefined

Only the var landed on window. On a WordPress site with a dozen plugins each adding scripts, that is not a small matter. Two plugins that both declare var data at the top level can overwrite each other and produce bugs that appear only on certain pages.

The bug that made everyone switch: loops and callbacks

If you only remember one example from this article, make it this one. You want three delayed messages, each reporting its own loop number. Here is the code with var and then with let:

// The classic bug: three delayed callbacks
console.log("with var:");
for (var a = 0; a < 3; a++) {
  setTimeout(() => console.log("  var  sees", a), 0);
}
setTimeout(() => {
  console.log("with let:");
  for (let b = 0; b < 3; b++) {
    setTimeout(() => console.log("  let  sees", b), 0);
  }
}, 10);

Output:

with var:
  var  sees 3
  var  sees 3
  var  sees 3
with let:
  let  sees 0
  let  sees 1
  let  sees 2

With var every callback printed 3. With let they printed 0, 1 and 2, as you probably hoped. Why? A var loop counter is one single variable shared by the whole function. By the time the delayed callbacks run, the loop has already finished and the variable holds its final value of 3, so every callback sees 3. A let loop counter gets a fresh copy for each pass through the loop, and each callback remembers its own copy.

This is not an obscure puzzle. It shows up in real pages: a row of buttons where each one should report its own number, a photo gallery where each thumbnail should open its own image, a set of tabs. Before let existed, the standard fix was to wrap the body of the loop in an extra function, a pattern that confused many newcomers. Today the fix is to change one word.

All the differences in one table

Real-life examples: which keyword fits?

Rules are easier to remember when they are tied to everyday situations. Click through the five tabs below. Each one is a small, real scenario and the keyword that suits it.

A simple decision guide

When I review code, I ask the same short sequence of questions. It takes a few seconds, and after a week it becomes automatic.

Habits that save you from bugs

• Default to const. If the linter or your editor complains that you tried to reassign, you have just learned something useful: this variable changes, so switch that one to let. Starting with const makes the changing variables stand out.
• Declare as late as you can. Put the variable close to where it is first used and in the narrowest block possible. Short lifetimes mean fewer places for things to go wrong.
• One declaration per line. Writing let a = 1, b = 2, c = 3; on one line is legal, but separate lines are easier to read and easier to change.
• Use a linter. ESLint has the rules no-var and prefer-const, which flag exactly the habits in this article automatically.
• Pick descriptive names. const taxRate tells you a lot more than const t. Constants that are truly fixed, like a maximum limit, are often written in capitals, such as MAX_ITEMS.
• Do not choose for speed. For ordinary code, the three keywords perform about the same. Pick for clarity, not performance.

Common mistakes and how to avoid them

• Thinking const means immutable. It locks the label, not the contents. Objects and arrays stored in a const can still change.
• Using var in a loop with callbacks. Every callback ends up seeing the final value. Use let.
• Declaring let twice in one scope. That is a syntax error. Check whether you really want a second variable or just a new value.
• Using a variable before its declaration. With let and const this throws an error. Move the declaration up, or restructure the code.
• Declaring the same let inside two switch cases. All the cases of a switch share one block, so two let x lines clash. Wrap each case body in its own curly braces.
• Declaring a const without a value. const total; is a syntax error. A const must be set when it is created.
• Rewriting old var code blindly. Changing every var to let can break code that relied on function scope or hoisting. Convert gradually, and test as you go.
• Forgetting that top-level var joins window. In a browser script, that can clash with other scripts. Use let, const or a module.

What about reading old code full of var?

You will meet it. Older tutorials, Stack Overflow answers from before 2015 and many WordPress plugins still use var everywhere. That is not a reason to panic, and it is not a reason to copy the habit. Read the code knowing that every var is function-scoped and hoisted, mentally move its declaration to the top of the function, and you will understand how it behaves.

When you write new code, use the modern keywords. When you edit old code, resist the urge to convert everything in one sitting. Change a variable when you are already touching the lines around it, run your tests, and move on. This is how experienced teams modernise large codebases without breaking them.

A mental model that sticks

Here is how I explain it to new developers. Imagine a whiteboard in a meeting room. A let variable is something written in erasable marker: you can wipe it and write a new value. A const variable is written in permanent marker: you cannot rewrite it, though if the thing you wrote is the name of a notebook, the notebook’s pages can still change. A var variable is a note that gets written on the whiteboard in the corridor as well: everyone in the building can read it, and anyone can overwrite it by accident.

Practice problems with answers

Try each one before you tap to check.

Test yourself: five quick questions

Tap a question to reveal the answer. The correct option is marked.

Frequently asked questions

The post Var vs Let vs Const: Why JavaScript Has Three Ways to Declare Variables appeared first on Learn With Examples.

Why computers need types at all

A computer’s memory is a very long row of tiny switches, each either off or on. That is all it holds: zeros and ones. There is no such thing as a “number” or a “letter” down there. The pattern 01000001, for example, can mean the whole number 65, or it can mean the capital letter A, or it can be one tiny piece of a colour in a photograph. The bits themselves do not say which.

The data type is the label that tells the computer how to read a pattern. It answers three questions at once: how many switches does this value use, how should those switches be interpreted, and which operations make sense on it. You can add two numbers, but adding two pieces of text sticks them together instead, and asking whether a yes/no answer is “greater than 7” makes no sense at all.

Think of a kitchen. A measuring jug, a kitchen scale and a thermometer all give you a number, but you would not use the thermometer to weigh flour. Each tool suits a kind of question. Data types are the same: tools for different kinds of facts.

Integers: whole numbers, exact answers

An integer is a number with no fractional part: −3, 0, 7, 52,314. It is the type for anything you count. The number of people in a stadium, the number of items in a shopping cart, a person’s age in years, the page you are on: all integers. You cannot have 2.5 people in the stadium, so the type simply has no room for a fraction.

The big strength of integers is that they are exact. If you add 3 and 4, you get precisely 7, every time, forever. There is no rounding and no hidden error. That reliability is why money, counters, loops and array positions all lean on integers.

How an integer is stored

Computers store integers in binary, using a fixed number of bits. With 8 bits you have 256 possible patterns. If all of them are used for non-negative numbers (an “unsigned” integer), the range is 0 to 255. That is exactly why colour values on a screen run from 0 to 255: each of red, green and blue gets one byte.

If you also want negative numbers (a “signed” integer), one bit effectively goes to the sign, and the same 256 patterns cover −128 to 127. Wider integers get far more room: 16 bits cover −32,768 to 32,767, 32 bits cover about −2.1 billion to 2.1 billion, and 64 bits cover roughly −9.2 quintillion to 9.2 quintillion.

Overflow: when the number does not fit

Here is where integers can bite. A fixed-width integer has a biggest value, and adding one more does not produce an error in many languages. It wraps around, like a car odometer rolling from 99999 back to 00000.

I ran the numbers to be sure I was not just repeating folklore. This short program simulates what a signed integer of each width does when you add one to its maximum, and also shows the famous Unix time limit.

import struct
from datetime import datetime, timezone

def wrap(value, bits):
    """What a signed integer of this width does when it overflows."""
    m = 1 << bits
    v = value % m
    return v - m if v >= m // 2 else v

for bits in (8, 16, 32):
    top = 2 ** (bits - 1) - 1
    print(f"{bits:>2}-bit signed: max {top:>11,}   max + 1 wraps to {wrap(top + 1, bits):>14,}")

print()
last = 2 ** 31 - 1
print("32-bit Unix time limit:", datetime.fromtimestamp(last, tz=timezone.utc))
print("one second later wraps to:", datetime.fromtimestamp(wrap(last + 1, 32), tz=timezone.utc))

print()
print("Python int keeps going: 2**63 =", 2 ** 63)
print("float loses whole numbers:", float(2 ** 53) + 1 == float(2 ** 53))
print()
for code, name in (("b", "tiny int"), ("h", "short int"), ("i", "int"), ("q", "long int"), ("f", "float32"), ("d", "float64"), ("?", "boolean")):
    print(f"{name:<10} {struct.calcsize(code)} byte(s)")

Output:

 8-bit signed: max         127   max + 1 wraps to           -128
16-bit signed: max      32,767   max + 1 wraps to        -32,768
32-bit signed: max 2,147,483,647   max + 1 wraps to -2,147,483,648

32-bit Unix time limit: 2038-01-19 03:14:07+00:00
one second later wraps to: 1901-12-13 20:45:52+00:00

Python int keeps going: 2**63 = 9223372036854775808
float loses whole numbers: True

tiny int   1 byte(s)
short int  2 byte(s)
int        4 byte(s)
long int   8 byte(s)
float32    4 byte(s)
float64    8 byte(s)
boolean    1 byte(s)

Look at the date line. Many systems count time as the number of seconds since 1 January 1970, stored in a signed 32-bit integer. That counter runs out at 03:14:07 UTC on 19 January 2038. One second later it wraps to a large negative number, which a computer reads as December 1901. This is the “Year 2038 problem”, and engineers have been moving systems to 64-bit time to avoid it.

Real overflow stories

Overflow is not only a classroom curiosity. In 1996 the first launch of Europe’s Ariane 5 rocket ended in self-destruction after a value converted from a 64-bit floating-point number into a 16-bit signed integer was too large to fit. In December 2014, the view counter for the video “Gangnam Style” passed 2,147,483,647, the top of a 32-bit signed integer, and YouTube said it had to switch the counter to 64 bits. Both are reminders that the width of an integer is a decision, not a detail.

Python has an unusual comfort here: its integers grow as large as memory allows, so 2¹⁰⁰ is simply 1,267,650,600,228,229,401,496,703,205,376. Languages such as C, Java and Go use fixed widths, and there you must choose carefully.

Floats: numbers with a decimal point

A float, short for floating-point number, is for values that can have a fractional part: 3.14, 36.6, 0.0001, 6.02 × 10²³. Use it for things you measure rather than count: body temperature, the length of a table, the speed of a car, the voltage across a battery.

The name “floating point” describes how the number is stored. Instead of fixing the decimal point in one place, the computer keeps two pieces: the significant digits, and an exponent that says where the point floats to. It is the same idea as scientific notation. The number 6,020,000 can be written 6.02 × 10⁶: the digits 6.02 and the exponent 6. A float stores a pair like that, but in binary.

This design gives floats a huge range. A standard 64-bit float, which most languages call a “double”, reaches from about 2.2 × 10⁻³⁰⁸ up to about 1.8 × 10³⁰⁸. No integer of the same size comes close. The price is exactness.

The 0.1 + 0.2 mystery, solved

Let me show you the thing that confuses everyone, then explain it. In Python:

import math

print("7           ->", type(7).__name__)
print("7.0         ->", type(7.0).__name__)
print("True        ->", type(True).__name__)
print('"7"         ->', type("7").__name__)
print()
print('"5" + "5"           =', repr("5" + "5"))
print('5 + 5               =', 5 + 5)
print('int("5") + int("5") =', int("5") + int("5"))
print()
print("10 / 4  =", 10 / 4)
print("10 // 4 =", 10 // 4)
print("10 % 4  =", 10 % 4)
print()
print("True + True       =", True + True)
print("isinstance(True, int) =", isinstance(True, int))
print("0.1 + 0.2         =", 0.1 + 0.2)
print("0.1 + 0.2 == 0.3  =", 0.1 + 0.2 == 0.3)
print("isclose           =", math.isclose(0.1 + 0.2, 0.3))
print("2 ** 100          =", 2 ** 100)

Output:

7           -> int
7.0         -> float
True        -> bool
"7"         -> str

"5" + "5"           = '55'
5 + 5               = 10
int("5") + int("5") = 10

10 / 4  = 2.5
10 // 4 = 2
10 % 4  = 2

True + True       = 2
isinstance(True, int) = True
0.1 + 0.2         = 0.30000000000000004
0.1 + 0.2 == 0.3  = False
isclose           = True
2 ** 100          = 1267650600228229401496703205376

Toward the bottom you will see 0.1 + 0.2 comes out as 0.30000000000000004, and the comparison with 0.3 is false. Python is not being silly. The same result appears in JavaScript, Java, C and nearly every language, because it comes from how binary stores fractions.

Here is the analogy I use with students. Try writing one third in decimal. You get 0.3333… and it never ends. You can write as many 3s as you like, but you can never write it exactly. Now notice that one third is a perfectly ordinary number. It is only awkward because our counting system is base ten, and ten is not divisible by three.

Computers use base two. In base two, one tenth is the awkward one. It becomes 0.0001100110011… repeating forever, so it has to be cut off somewhere. What the computer actually stores for 0.1 is a very slightly different number. I printed it:

from decimal import Decimal
import struct, sys

print("0.1 is really stored as:", Decimal(0.1))
print("0.5 is stored as       :", Decimal(0.5), "(a power of two, so exact)")
print("0.75 is stored as      :", Decimal(0.75))
bits = format(struct.unpack(">Q", struct.pack(">d", 0.1))[0], "064b")
print("64 bits of 0.1:", bits[0], bits[1:12], bits[12:])
print("largest float  :", sys.float_info.max)
print("smallest float :", sys.float_info.min)
print("digits of care :", sys.float_info.dig)
import math
print()
print("gap between neighbouring floats:")
print("  near 1             :", math.ulp(1.0))
print("  near 1e15          :", math.ulp(1e15))
print("  near 2**53 (9e15)  :", math.ulp(2.0 ** 53))

Output:

0.1 is really stored as: 0.1000000000000000055511151231257827021181583404541015625
0.5 is stored as       : 0.5 (a power of two, so exact)
0.75 is stored as      : 0.75
64 bits of 0.1: 0 01111111011 1001100110011001100110011001100110011001100110011010
largest float  : 1.7976931348623157e+308
smallest float : 2.2250738585072014e-308
digits of care : 15

gap between neighbouring floats:
  near 1             : 2.220446049250313e-16
  near 1e15          : 0.125
  near 2**53 (9e15)  : 2.0

So the stored 0.1 is 0.1000000000000000055511… Not exactly one tenth, but close enough that you normally never notice. Add two such slightly-off values and the tiny errors can show up at the sixteenth or seventeenth digit. Notice too that 0.5 and 0.75 are stored exactly, because they are built from powers of two (a half, a quarter). A float is only exact when the fraction is made of halves, quarters, eighths and so on.

Floats lose precision as they get big

There is a second quirk. A 64-bit float has only about 15 to 16 reliable decimal digits, and the gaps between neighbouring floats grow as the numbers grow. That is the output at the bottom of the block above: near 1, neighbouring floats are about 0.0000000000000002 apart. Near 9 quadrillion, they are 2 apart, so the float simply cannot represent every whole number.

The practical rule: beyond 2⁵³, which is 9,007,199,254,740,992, floats skip whole numbers. In JavaScript, where every number is a float, this is why the biggest integer you can trust is 9,007,199,254,740,991. It is also why you should never store something like a 19-digit ID in a float.

How to compare floats safely

Because of those tiny errors, never ask whether two floats are exactly equal after calculation. Ask whether they are close enough. In Python, the function math.isclose does it. In other languages, take the absolute difference and compare it with a small tolerance, such as 0.000001, chosen to suit your problem. This one habit prevents a surprising number of bugs.

Booleans: the simplest type of all

A boolean has exactly two possible values: true or false. It is named after the mathematician George Boole, who built a branch of logic around exactly this idea in the nineteenth century. In everyday life, a boolean is any yes/no fact: is the user logged in, is the light on, has the invoice been paid, is the stock above its limit.

Booleans are the type that makes decisions possible. Every if statement and every loop condition eventually boils down to a boolean. When you write “if age is at least 18”, the comparison produces true or false, and the program picks a path based on it.

Storage: one bit of information, one byte of space

A boolean carries one bit of information, since there are only two answers. Yet most systems store it in a whole byte, because computers address memory in bytes and it is faster to read a full byte than to dig out a single bit. The little table at the end of the overflow code printed this: a boolean takes 1 byte, the same as a tiny integer. Programmers who need to store millions of flags sometimes pack eight of them into a single byte for exactly this reason.

Booleans in Python are secretly integers

In Python, True behaves like 1 and False behaves like 0. The code above showed that True + True gives 2 and that a boolean passes the test for being an integer. That is occasionally handy, for example counting how many items in a list satisfy a test by adding up their true/false results. It is also a source of odd bugs, so keep it in mind.

A more important trap involves text. The string “False” is not the boolean False. In Python, any non-empty string counts as true, so bool(“False”) is True. This bites people reading settings from a file or a web form, where everything arrives as text. Convert the value deliberately, instead of trusting it.

Why they differ: a side-by-side view

With all three in front of you, the differences are easier to see in one place.

Notice that each type’s strength and weakness come from the same decision. Integers are exact because they cannot hold fractions. Floats can hold fractions because they give up exactness. Booleans are simple because they hold almost nothing. There is no free lunch, just a trade-off chosen for each job.

The fourth type that fools people: strings

Strictly speaking this article is about three types, but one more deserves a mention because beginners confuse it with integers all the time. A string is text: letters, digits, spaces, anything in quotation marks. The string “5” and the integer 5 look alike but behave very differently. Adding the two integers 5 + 5 gives 10. Adding the two strings “5” + “5” gives “55”, the text glued together.

This matters whenever data comes from outside your program. Form fields, CSV files and web pages deliver everything as text. If you forget to convert with int() or float(), you will get joined-up text instead of sums, or an error. The sample output earlier shows all three results side by side.

The reverse mistake is just as common. A phone number, PIN code or postal code is made of digits, but you never add or average them. Store them as strings. A PIN of 0482 stored as an integer becomes 482, and the leading zero is gone for good.

The money rule: never use floats

If there is one lesson from this article that will save you real trouble, it is this: do not store money in floats. It is the most common serious data-type mistake in shops, billing systems and spreadsheets. Here is a test. A shop sells 1,000 sweets at 0.10 each. I added the price one thousand times three ways:

from decimal import Decimal

# A shop sells 1,000 sweets at 0.10 each. Add the prices one by one.
total_float = 0.0
for _ in range(1000):
    total_float += 0.10
print("float total   :", total_float, "| equals 100.0?", total_float == 100.0)

total_dec = Decimal("0")
for _ in range(1000):
    total_dec += Decimal("0.10")
print("Decimal total :", total_dec, "| equals 100?", total_dec == 100)

paise = 0
for _ in range(1000):
    paise += 10                      # store money as whole paise (integers)
print("integer paise :", paise, "-> rupees", paise / 100)

print()
print("19.99 * 3       =", 19.99 * 3)
print("1999 * 3 paise  =", 1999 * 3, "-> 59.97")

Output:

float total   : 99.9999999999986 | equals 100.0? False
Decimal total : 100.00 | equals 100? True
integer paise : 10000 -> rupees 100.0

19.99 * 3       = 59.97
1999 * 3 paise  = 5997 -> 59.97

The float total is 99.9999999999986 and fails the check against 100. The Decimal type, which stores decimal digits exactly, gets 100.00. And whole units, in this case paise, get exactly 10,000, which is 100 rupees. The tiny 0.0000000000014 error would never show up on a receipt, but it can break an equality check, trip a reconciliation report or make a daily total off by a cent when multiplied by millions of transactions.

To be fair, floats do not always misbehave. At the bottom of the output, 19.99 × 3 prints a clean 59.97. That is the danger: it works nearly every time, so you trust it, and then one day it does not. Whenever correctness matters, use one of two safe approaches:

• Integer smallest units. Store 19.99 rupees as 1999 paise, or 19.99 dollars as 1999 cents. Calculate in whole numbers, and divide by 100 only when displaying.
• A decimal type. Python has Decimal, Java has BigDecimal, and most databases have a DECIMAL or NUMERIC column. These store decimal digits exactly.

Data types in everyday life

You do not need to be a programmer to meet these types. Click a tab to see five everyday situations and which type fits each one, and why.

Choosing the right type: a quick decision guide

When I design a new database table or a form, I go through the same short list. Read the questions top to bottom and stop at the first yes.

Converting between types

Programs constantly change a value from one type to another, and some conversions lose information. Knowing which is useful.

• Integer to float is usually safe for small numbers. 7 becomes 7.0. Very large integers can lose digits, as we saw past 2⁵³.
• Float to integer throws away the fraction. In Python, int(3.9) gives 3 and int(−3.9) gives −3, since it chops toward zero instead of rounding. If you want rounding, call round() on purpose.
• Rounding has quirks. Python’s round() uses “round half to even”, so round(2.5) is 2 and round(3.5) is 4. It is designed to avoid a bias when many values are rounded, but it surprises people who expect 2.5 to become 3.
• String to number needs int() or float(), and it fails with an error if the text is not a valid number. Always handle that case when reading user input.
• Anything to boolean follows the language’s own rules. In Python, zero, empty text and empty lists count as false, and almost everything else counts as true, including the string “False”.
• Division is a type decision too. In Python, 10 / 4 is 2.5, a float, while 10 // 4 is 2, whole-number division, and 10 % 4 is the remainder, 2. In some older languages, dividing two integers silently gives an integer, which has caused many off-by-a-fraction bugs.

Common mistakes and how to avoid them

• Using floats for money. Use integer paise or cents, or a decimal type.
• Comparing floats with ==. Compare with a tolerance instead.
• Storing IDs, phone numbers and PINs as numbers. If you never do arithmetic on it, it is probably a string.
• Ignoring the width of an integer. If a counter could ever pass about two billion, use a 64-bit integer from the start.
• Trusting text as a boolean. The text “false” is true in most languages. Convert it deliberately.
• Forgetting that form data is text. Everything from a web form arrives as a string until you convert it.
• Assuming integer division behaves the same everywhere. Check how your language divides whole numbers.
• Storing huge whole numbers in floats. Beyond about nine quadrillion, floats skip numbers.

A mental model that sticks

If you remember only one picture, make it this. An integer is a staircase: you are on step 4 or step 5, never in between, and each step is exactly where it says it is. A float is a ramp with markers painted on it: you can stand anywhere, but the markers are only approximate, and they are spaced further apart as you climb. A boolean is a light switch: on or off, nothing else. Pick the staircase when you count, the ramp when you measure and the switch when you decide.

Practice problems with answers

Try each one before you tap to check.

Test yourself: five quick questions

Tap a question to reveal the answer. The correct option is marked.

Frequently asked questions

The post Data Types Explained: Integers, Floats, Booleans and Why They Differ appeared first on Learn With Examples.

The rule everyone dreads

If you have a function made by dividing one function by another, say f(x) divided by g(x), its derivative is given by the quotient rule:

That is the whole rule. It looks harmless on one line. In practice, it is where marks get lost: a sign flipped, a square forgotten, an algebra slip while expanding the top. After many years of tutoring and teaching this, I can tell you that most of the errors come from using the rule when you did not have to.

The good news is that the quotient rule is not a new idea. It is the product rule and a bit of algebra wearing a different coat, and that insight is what lets you skip it so often. Let us start by getting the rule itself solid, then earn the right to avoid it.

First, a trap: you cannot divide the derivatives

When you meet the product rule or the quotient rule for the first time, a natural thought arises: surely the derivative of f divided by g is just f′ divided by g′? It would be so convenient. It is also wrong, and a two-line test shows it.

Take f = x² and g = x. Their quotient is x²/x = x, whose derivative is clearly 1. But f′/g′ is 2x/1 = 2x. At x = 3, the true slope is 1 and the “divide the derivatives” answer is 6. They disagree, so the shortcut is false. Derivatives of fractions need their own rule, and that rule is where the extra terms in the formula come from.

The rule in a picture

The formula has four ingredients: the top f, the bottom g, and their derivatives f′ and g′. A well-known chant helps you keep them in order. Call the top “high” and the bottom “low”:

Say it aloud a few times: low d-high minus high d-low, over low squared. It sounds silly, but it works, and it pins down the part that hurts students most. The first product in the numerator is the derivative of the top times the bottom. Swap the order and the sign of your whole answer flips.

A full worked example

Let us differentiate y = (x² + 1) / (x − 3) with the rule, slowly. I always begin by writing the four ingredients in a small table, because it prevents most slips.

Now fill in the formula:

• Numerator: f′g − fg′ = 2x(x − 3) − (x² + 1)(1).
• Expand: 2x² − 6x − x² − 1.
• Simplify: x² − 6x − 1.
• Denominator: (x − 3)², kept as a square.

So the derivative is (x² − 6x − 1) / (x − 3)². At x = 2, that is (4 − 12 − 1)/1 = −9. I checked it against a numerical slope in the code later in this article, and it matches. Notice that the top of the answer will not factor nicely and the bottom will not cancel. This is a fraction that genuinely needs the rule, and we will use it as our example of “a case you cannot skip.”

Where the rule comes from

Understanding the origin removes the fear. Suppose y = f/g. Multiply both sides by g and you get y · g = f. That is a product of two functions, y and g, and we know how to differentiate a product:

Now solve for y′. Move the y·g′ term across and divide by g:

Put y = f/g back in, so the numerator becomes f′ − (f/g)g′. Multiply the top and bottom of the whole fraction by g to clear the little fraction, and you get exactly (f′g − fg′)/g². That is the quotient rule, derived in four lines from the product rule.

There is a second way to see it. Write f/g as f · g⁻¹, a product with a negative power. The product rule gives f′g⁻¹ + f · (−1)g⁻²g′, and putting that over a common denominator gives the same formula again. The practical meaning is liberating: anything the quotient rule can do, you can also do with the product rule and a negative exponent. If you only ever remember one of the two, the product rule is the safer one to keep.

Why you can often skip it

Here is the heart of this article. The quotient rule is the tool for the hardest case, where a fraction has a complicated top and a complicated bottom that do not simplify. But a large share of the fractions you will meet in homework, exams and real formulas are easier than that. They can be rewritten, and once rewritten they need only the power rule and the constant multiple rule from earlier lessons.

I use a four-question checklist. Ask the questions in this order and stop at the first “yes”.

Shortcut 1: the denominator is just a number

If you are dividing by a constant, you are really multiplying by a constant, and the constant multiple rule says a number out in front simply comes along for the ride.

Shortcut 2: the numerator is a number, or the denominator is a single power of x

Fractions like 12/x² are secretly powers with negative exponents. Rewrite and use the power rule.

The same idea handles a numerator with several terms over a single power. Split it into separate fractions first.

Shortcut 3: split and cancel

When the denominator is a single term, you can divide it into every term of the numerator and cancel as you go.

Shortcut 4: factor the top and cancel

Sometimes the numerator and denominator share a factor, and the fraction collapses to something simple. Always look for this before reaching for the rule.

A small point of honesty here. The original function has a hole at x = 3, because you cannot divide by zero, so the neat answer applies at every x except 3. For most coursework that is fine, but if your question is about behaviour exactly at x = 3, remember the hole.

Shortcut 5: use a negative exponent with the product rule

This is the “quotient rule in disguise” trick. If the denominator is a simple power but the top is complicated, rewrite the fraction as a product with a negative exponent and use the product rule. Many students find it less error-prone than memorising the quotient formula, because the product rule has no minus sign to flip.

A side-by-side comparison

Here is a summary you can keep. Each fraction is paired with the quickest method and the final answer.

Five of the seven rows needed no quotient rule at all. In my experience that ratio is about right for typical textbook sets, and it is one reason I tell students to try simplification first.

Proof by computer: both routes agree

I do not like asking you to trust me, so I tested every row. The program below computes each derivative three ways at x = 2: a numerical slope from two nearby points, the quotient rule applied mechanically, and the shortcut answer from the table.

def slope(f, x, h=1e-6):
    return (f(x + h) - f(x - h)) / (2 * h)          # numeric derivative

def quotient_rule(f, fp, g, gp, x):
    """(f/g)' = (f'g - f g') / g^2"""
    return (fp(x) * g(x) - f(x) * gp(x)) / g(x) ** 2

# name, f, f', g, g', shortcut answer, can we skip the quotient rule?
cases = [
    ("(x^3 + 4x) / 5",   lambda x: x**3 + 4*x,    lambda x: 3*x**2 + 4,       lambda x: 5,      lambda x: 0,     lambda x: (3*x**2 + 4) / 5,  "skip: constant denominator"),
    ("12 / x^2",         lambda x: 12,            lambda x: 0,                lambda x: x**2,   lambda x: 2*x,   lambda x: -24 / x**3,        "skip: write as 12x^-2"),
    ("(4x^2+3x+2) / x^2",lambda x: 4*x**2+3*x+2, lambda x: 8*x+3,            lambda x: x**2,   lambda x: 2*x,   lambda x: -3 / x**2 - 4 / x**3, "skip: split into terms"),
    ("(x^3+5x^2-7x) / x",lambda x: x**3+5*x**2-7*x, lambda x: 3*x**2+10*x-7,  lambda x: x,      lambda x: 1,     lambda x: 2*x + 5,           "skip: split and cancel"),
    ("(x^2 - 9) / (x-3)",lambda x: x**2 - 9,      lambda x: 2*x,              lambda x: x - 3,  lambda x: 1,     lambda x: 1,                 "skip: factor and cancel"),
    ("(x^2 + 1) / (x-3)",lambda x: x**2 + 1,      lambda x: 2*x,              lambda x: x - 3,  lambda x: 1,     lambda x: (x**2 - 6*x - 1) / (x - 3)**2, "use the rule"),
    ("5x / (x^2 + 1)",   lambda x: 5*x,           lambda x: 5,                lambda x: x**2+1, lambda x: 2*x,   lambda x: 5*(1 - x**2) / (x**2 + 1)**2, "use the rule"),
]

x = 2
print(f"At x = {x}")
print(f"{'function':<22}{'numeric':>10}{'quotient':>10}{'answer':>10}   note")
for name, f, fp, g, gp, ans, note in cases:
    num = slope(lambda t: f(t) / g(t), x)
    q = quotient_rule(f, fp, g, gp, x)
    print(f"{name:<22}{num:>10.4f}{q:>10.4f}{ans(x):>10.4f}   {note}")

Output:

At x = 2
function                 numeric  quotient    answer   note
(x^3 + 4x) / 5            3.2000    3.2000    3.2000   skip: constant denominator
12 / x^2                 -3.0000   -3.0000   -3.0000   skip: write as 12x^-2
(4x^2+3x+2) / x^2        -1.2500   -1.2500   -1.2500   skip: split into terms
(x^3+5x^2-7x) / x         9.0000    9.0000    9.0000   skip: split and cancel
(x^2 - 9) / (x-3)         1.0000    1.0000    1.0000   skip: factor and cancel
(x^2 + 1) / (x-3)        -9.0000   -9.0000   -9.0000   use the rule
5x / (x^2 + 1)           -0.6000   -0.6000   -0.6000   use the rule

All three columns agree on every row. That confirms two things at once: the shortcuts are not tricks, they are legitimate, and the quotient rule gives the same value whether it was needed or not. The only difference is how much work it took to get there.

When you really cannot skip it

Now the fair half of the story. Some fractions have a complicated top and a complicated bottom that share nothing, and rewriting them does not help. In that case, use the rule, and use it with confidence. Here are the signs:

• The denominator has more than one term and does not cancel. For instance, x² + 1 or x − 3 sitting underneath something that is not a multiple of it.
• The top is not a constant, and nothing factors. You are stuck with two live functions.
• Trigonometric or exponential parts are involved. The derivative of (sin x)/x is (x cos x − sin x)/x², and there is no simpler route.

Here is my method for these cases, which has saved me from countless slips:

• Write the four-row table of f, f′, g and g′ before doing anything else.
• Put brackets around everything when you substitute, especially around g and f in the subtracted term, since a missing bracket is how minus signs go wrong.
• Expand the numerator only and collect like terms. Leave the denominator as a square, because a factored denominator is usually easier to read and to work with later.
• Check one value numerically. Pick an easy x, evaluate your formula, and compare with a rough slope between two nearby points.

The quotient rule in real life

Fractions of changing quantities appear everywhere: cost per unit, speed, electrical current, pressure and the concentration of a medicine. Click a tab below to see five examples, and notice which ones can skip the rule. This is the whole theme of the article in action.

Checking the real examples with numbers

I checked the five examples from the tabs with the same approach: compute the derivative with the shortcut or the rule, then compare with a purely numerical slope.

def slope(f, x, h=1e-6):
    return (f(x + h) - f(x - h)) / (2 * h)

print("Average cost per unit  AC = (500 + 2q) / q  at q = 50")
print("  skip method  -500/q^2          =", round(-500 / 50**2, 4), "dollars per extra unit")
print("  numeric slope                  =", round(slope(lambda q: (500 + 2*q) / q, 50), 4))
print("Average speed  (40t + 5t^2) / t  at t = 2 h")
print("  skip method  derivative of 40+5t =", 5, "km/h per hour")
print("  numeric slope                  =", round(slope(lambda t: (40*t + 5*t**2) / t, 2), 4))
print("Ohm's law  I = 12 / R  at R = 4 ohms")
print("  skip method  -12/R^2           =", round(-12 / 4**2, 4), "A per ohm")
print("  numeric slope                  =", round(slope(lambda r: 12 / r, 4), 4))
print("Boyle's law  P = 100 / V  at V = 5 L")
print("  skip method  -100/V^2          =", round(-100 / 5**2, 4), "kPa per litre")
print("  numeric slope                  =", round(slope(lambda v: 100 / v, 5), 4))
C = lambda t: 5 * t / (t**2 + 1)
Cp = lambda t: 5 * (1 - t**2) / (t**2 + 1) ** 2
print("Drug concentration  C = 5t / (t^2 + 1)  (quotient rule needed)")
for t in (0.5, 1, 3):
    print(f"  t = {t:<3}  C = {C(t):.3f}   rule C' = {Cp(t):+.4f}   numeric = {slope(C, t):+.4f}")

Output:

Average cost per unit  AC = (500 + 2q) / q  at q = 50
  skip method  -500/q^2          = -0.2 dollars per extra unit
  numeric slope                  = -0.2
Average speed  (40t + 5t^2) / t  at t = 2 h
  skip method  derivative of 40+5t = 5 km/h per hour
  numeric slope                  = 5.0
Ohm's law  I = 12 / R  at R = 4 ohms
  skip method  -12/R^2           = -0.75 A per ohm
  numeric slope                  = -0.75
Boyle's law  P = 100 / V  at V = 5 L
  skip method  -100/V^2          = -4.0 kPa per litre
  numeric slope                  = -4.0
Drug concentration  C = 5t / (t^2 + 1)  (quotient rule needed)
  t = 0.5  C = 2.000   rule C' = +2.4000   numeric = +2.4000
  t = 1    C = 2.500   rule C' = +0.0000   numeric = -0.0000
  t = 3    C = 1.500   rule C' = -0.4000   numeric = -0.4000

The first four were handled by shortcuts and the last needed the rule. The two columns agree each time. The drug example is worth a second look, because it shows what a derivative can tell you that a table of values cannot: the slope is positive at t = 0.5, exactly zero at t = 1, and negative at t = 3. A slope of zero between a rising and a falling stretch marks the peak.

And here is how fast average cost slows down as production grows in the first example. The slope is −500/q², so it flattens quickly:

Common mistakes and how to avoid them

• Dividing the derivatives. (f/g)′ is not f′/g′. We showed this with x²/x earlier.
• Swapping the order in the numerator. It is f′g − fg′, derivative of the top first. Reversed, your whole answer has the wrong sign.
• Forgetting to square the denominator. The bottom of the answer is g², not g.
• Squaring only part of the denominator. If g = x − 3, the denominator is (x − 3)², which is not x² − 9.
• Losing a minus sign while expanding. In f′g − fg′, the minus applies to the whole product fg′. Use brackets.
• Using the rule when a shortcut was available. It is not wrong, just slower and riskier. Run the four-question checklist first.
• Ignoring the hole after cancelling. After simplifying (x² − 9)/(x − 3) to x + 3, remember x = 3 is still excluded from the original function.
• Not simplifying the final answer. Leaving an expanded numerator uncollected costs marks and hides useful structure, such as where the slope is zero.

A quick word on logarithmic differentiation

For fractions that are really long chains of multiplications and divisions, such as a product of five factors over three others, there is a third strategy: take logarithms of both sides first. That turns products and quotients into sums and differences, which are far easier to differentiate. It needs the rules for logarithms and the chain rule, so it belongs to a later lesson, but it is worth knowing it exists. It is the polite way of saying that the quotient rule is not the only tool in the box.

Practice problems with answers

Try each one on paper first, ideally running the checklist before you decide on a method. Then tap to check.

Test yourself: five quick questions

Tap a question to reveal the answer. The correct option is marked.

Frequently asked questions

The post The Quotient Rule, and Why You Can Often Skip It appeared first on Learn With Examples.

The rule in one line

Here is the whole thing. If you have a function f(x) = xⁿ, then its derivative is:

That is the power rule. It turns x² into 2x, x³ into 3x², and x¹⁰ into 10x⁹. It is the first rule most students use to differentiate anything, and it handles an enormous share of the problems you will meet: polynomials, roots, reciprocals and many formulas from physics and economics.

I have taught this to students for many years, and the pattern I see is always the same. The ones who only memorise the rule are fine until the first problem that looks slightly different. The ones who understand where the “n” and the “minus one” come from never get stuck, because they can rebuild the rule on the spot.

First, what is a derivative?

Imagine you are driving and glance at the speedometer. It says 60 km/h. That number is a derivative. It is the rate at which your position is changing, right now, at this instant, not your average over the whole trip.

Graphically, the derivative is the slope of a curve at a single point. For a straight line, the slope is the same everywhere: rise over run. For a curve, such as y = x², the steepness changes as you move along it. Near x = 0 it is almost flat. Further right it climbs more steeply. The derivative gives you the exact steepness at any chosen point.

So when we say “the derivative of x² is 2x”, we mean: at any x, the slope of the curve is twice that x. At x = 3 the slope is 6. At x = 10 it is 20. The curve gets steeper the further you go, and the rule tells you exactly how steep.

Using the rule: three steps

Before we get to why, let us make sure the mechanics are comfortable. There are only three steps.

• Step 1. Identify the exponent n.
• Step 2. Multiply by n.
• Step 3. Subtract 1 from the exponent.

Why does it work? Four ways to see it

Now the real question. I will show you four separate explanations. They all lead to the same place, and different people find different ones convincing. Read them all if you can, and treat the one that clicks as your own.

Explanation 1: just try it with numbers

The honest definition of the derivative is: take two points on the curve that are very close together, draw the line through them, and work out its slope. Then slide the second point closer and closer until it practically sits on top of the first. The slope the lines settle towards is the derivative.

That slope, for two points a small distance h apart, is called the difference quotient: (f(x + h) − f(x)) / h. We do not need any theory to compute it. Here is a program that tries it at x = 3, for the powers 2, 3, 4 and 5, with the gap h shrinking each time:

def diff_quotient(f, x, h):
    """Slope of the line through (x, f(x)) and (x+h, f(x+h))."""
    return (f(x + h) - f(x)) / h

x = 3
print(f"{'h':>8} | " + " | ".join(f"x^{n}" .rjust(9) for n in (2, 3, 4, 5)))
for h in (1, 0.1, 0.01, 0.001, 0.0001):
    row = [diff_quotient(lambda t, n=n: t**n, x, h) for n in (2, 3, 4, 5)]
    print(f"{h:>8} | " + " | ".join(f"{v:9.4f}" for v in row))
print(f"{'power rule':>8} | " + " | ".join(f"{n * x**(n-1):9.4f}" for n in (2, 3, 4, 5)))

This is the output I got:

       h |       x^2 |       x^3 |       x^4 |       x^5
       1 |    7.0000 |   37.0000 |  175.0000 |  781.0000
     0.1 |    6.1000 |   27.9100 |  113.5210 |  432.9151
    0.01 |    6.0100 |   27.0901 |  108.5412 |  407.7090
   0.001 |    6.0010 |   27.0090 |  108.0540 |  405.2701
  0.0001 |    6.0001 |   27.0009 |  108.0054 |  405.0270
power rule |    6.0000 |   27.0000 |  108.0000 |  405.0000

Read down any column. For x³, the slope of the line starts at 37 when h is 1, drops to 27.91, then 27.09, then 27.009, closing in on 27. The bottom row is the power rule’s prediction, 3 × 3² = 27. The same story holds for every column: 6, 27, 108 and 405 are exactly what n · 3ⁿ⁻¹ gives. No proof needed, just a calculator.

This is a real piece of evidence. But it does not say why the answer is n · xⁿ⁻¹ and not something else that happens to match a few numbers. For that, we need the pictures and the algebra.

Explanation 2: the growing square

Picture a square whose sides are each x units long. Its area is x². Now let the sides grow by a tiny amount, call it h, and ask: how much extra area did that add?

Look at the new area as three new pieces. A strip along the right side, which is x long and h wide, so its area is x·h. A strip along the top, with the same area, x·h. And a tiny square in the corner, h by h, with area h².

The total added area is 2xh + h². Divide by h to get the growth per unit of nudge: 2x + h. Now let h shrink towards zero. The leftover h disappears, and we are left with 2x. That is the derivative of x².

Notice why the corner does not matter. If h is 0.01, the strips have area 0.01x each, but the corner is only 0.0001. As h gets smaller, the corner shrinks much faster than the strips. In the limit it vanishes, and only the strips remain. The “2” in 2x is simply the number of strips. There were two edges that could grow, so we got two strips.

Now try a cube with side x. Its volume is x³. Grow each side by h, and the cube sprouts new material on three faces: the right, the top and the front. Each is a flat slab of area x·x = x² and thickness h, so each slab adds x²h. Three slabs make 3x²h. Everything else (the thin edges and the corner cube) involves h² or h³ and vanishes in the limit. So the derivative of x³ is 3x².

Here is the pattern emerging: for a shape with n dimensions each of length x, there are n faces that can grow. Each new slab has size xⁿ⁻¹ (every dimension except the one that grew) times the thickness h. So n slabs of size xⁿ⁻¹h, or n·xⁿ⁻¹ per unit of h. The “n” counts the faces. The “n − 1” counts the dimensions that stayed the same size.

Explanation 3: the algebra (binomial expansion)

Now the same idea in symbols. We want the difference quotient of xⁿ:

The binomial theorem tells us that when you multiply out (x + h)ⁿ, you get:

• xⁿ (the original term),
• plus n · xⁿ⁻¹ · h,
• plus a pile of terms that each contain h² or a higher power of h.

Subtract xⁿ and the original term disappears. Divide by h and every remaining term loses one factor of h:

• The middle term becomes n · xⁿ⁻¹ with no h left.
• Every other term still has at least one h in it.

Now shrink h to zero. All the terms that still have an h vanish. What remains is exactly n · xⁿ⁻¹. That is a complete proof of the power rule for whole-number exponents, and it is only five lines long.

For x² the expansion is x² + 2xh + h², the same three pieces as the square picture. For x³ it is x³ + 3x²h + 3xh² + h³. The coefficient in front of the h term is always n.

Explanation 4: “n ways to choose”

This one is my favourite because it needs no formula at all. Write xⁿ as n copies of x multiplied together:

Now replace x by x + h in every factor. You are multiplying out (x + h)(x + h)(x + h)… and, from each bracket, you must pick either the x or the h. Picking all x gives back xⁿ. Picking exactly one h and the rest x gives a term with a single h and (n − 1) x’s: xⁿ⁻¹h. How many ways can you do that? You can choose the h from the first bracket, or the second, or the third, up to the n-th. That is n ways.

So there are n terms of the form xⁿ⁻¹h. Everything that picks two or more h’s has h² or more, and vanishes in the limit. The change is n · xⁿ⁻¹ · h, and the rate is n · xⁿ⁻¹.

The rule for more than a single power

Real functions are rarely a lone xⁿ. Luckily, three small companion rules extend the power rule to cover almost every polynomial you will see.

The constant rule fits the power rule too. A constant like 9 is 9x⁰, because x⁰ equals 1. Apply the rule: 9 · 0 · x⁻¹ = 0. Nothing changes, so the rate of change is zero, just as you would expect from a flat horizontal line.

Here is a small program that applies the rule to a whole polynomial, term by term, with each term stored as a (coefficient, exponent) pair:

def derivative_power(coef, n):
    """d/dx of coef * x**n  ->  (coef * n) * x**(n - 1)"""
    return coef * n, n - 1

# 3x^4 - 5x^2 + 7x - 9, written as (coefficient, exponent) pairs
poly = [(3, 4), (-5, 2), (7, 1), (-9, 0)]
print("f(x)  =", " ".join(f"{c:+d}x^{n}" for c, n in poly))
d = [derivative_power(c, n) for c, n in poly if n != 0]   # constants vanish
print("f'(x) =", " ".join(f"{c:+d}x^{n}" for c, n in d))

Output:

f(x)  = +3x^4 -5x^2 +7x^1 -9x^0
f'(x) = +12x^3 -10x^1 +7x^0

Reading the printout: x¹ is just x and x⁰ is just 1, so this says the derivative of 3x⁴ − 5x² + 7x − 9 is 12x³ − 10x + 7. The 3 × 4 = 12 and 5 × 2 = 10 come straight from the rule, the 7 survives because the derivative of 7x is 7, and the lone −9 has vanished.

Negative and fractional exponents

This is where the power rule really earns its reputation, because it keeps working when the exponent is not a positive whole number. The trick is to rewrite first, then apply the rule.

Look at the first row. After bringing down the exponent −1, the new exponent is −1 − 1, which is −2, not 0. Subtracting one from a negative number makes it more negative. This is the single most common slip in this topic, and we will return to it in the mistakes section.

The square root case is worth pausing on. The derivative of √x is 1/(2√x). That says the square root curve is very steep near zero and flattens as x grows. It matches what you see on a graph: √x shoots up quickly at first and then slows down. The slope of √x at x = 1 is 1/2, and at x = 100 it is only 1/20.

A note on rigour: the algebra proof above works for whole-number exponents. The rule also holds for negative and fractional exponents, but proving that takes extra tools, namely the quotient rule for negative powers and implicit differentiation or logarithms for fractions. You do not need those to use the rule confidently, and the numeric check from Explanation 1 works on any of these cases if you want reassurance.

The power rule in real life

The rule is not just classroom exercise. Here are five places it turns up. Click a tab to explore each one.

Checking the numbers: five real formulas

I took the five examples from the tabs and checked each one two ways: with the power rule, and with a purely numerical slope (the same two-close-points idea as before, using points on both sides of the target). If the power rule is right, the two answers should agree.

import math

def slope(f, x, h=1e-6):
    return (f(x + h) - f(x - h)) / (2 * h)       # centred difference

g = 9.8
print("Falling object  s = 4.9 t^2, at t = 3 s")
print("  power rule  v = 9.8 t       =", round(g * 3, 4), "m/s")
print("  numeric slope               =", round(slope(lambda t: 4.9 * t**2, 3), 4))
print("Circle  A = pi r^2, at r = 5")
print("  power rule  2 pi r          =", round(2 * math.pi * 5, 4))
print("  numeric slope               =", round(slope(lambda r: math.pi * r**2, 5), 4))
print("Sphere  V = 4/3 pi r^3, at r = 5")
print("  power rule  4 pi r^2        =", round(4 * math.pi * 25, 4))
print("  numeric slope               =", round(slope(lambda r: 4/3 * math.pi * r**3, 5), 4))
print("Kinetic energy  E = 1/2 m v^2, m = 1000 kg, at v = 20 m/s")
print("  power rule  m v             =", 1000 * 20, "J per m/s")
print("  numeric slope               =", round(slope(lambda v: 0.5 * 1000 * v**2, 20), 4))
mu = 0.7
d = lambda v: v**2 / (2 * mu * g)
print("Braking distance  d = v^2 / (2 mu g), mu = 0.7")
print("  at 20 m/s =", round(d(20), 1), "m,  at 40 m/s =", round(d(40), 1), "m")
print("  power rule  v / (mu g) at 20 =", round(20 / (mu * g), 3), "m per m/s")
print("  numeric slope                =", round(slope(d, 20), 3))

Output:

Falling object  s = 4.9 t^2, at t = 3 s
  power rule  v = 9.8 t       = 29.4 m/s
  numeric slope               = 29.4
Circle  A = pi r^2, at r = 5
  power rule  2 pi r          = 31.4159
  numeric slope               = 31.4159
Sphere  V = 4/3 pi r^3, at r = 5
  power rule  4 pi r^2        = 314.1593
  numeric slope               = 314.1593
Kinetic energy  E = 1/2 m v^2, m = 1000 kg, at v = 20 m/s
  power rule  m v             = 20000 J per m/s
  numeric slope               = 20000.0
Braking distance  d = v^2 / (2 mu g), mu = 0.7
  at 20 m/s = 29.2 m,  at 40 m/s = 116.6 m
  power rule  v / (mu g) at 20 = 2.915 m per m/s
  numeric slope                = 2.915

Every pair agrees. That is the power rule doing its job on a falling stone, a circle, a sphere, a moving car and a braking distance. One caution on the last one: the braking formula is an idealised model that ignores the driver’s reaction time and assumes a steady friction value of 0.7, so treat the numbers as an illustration, not as a safety guide.

Common mistakes and how to avoid them

• Forgetting to subtract one. The derivative of x⁵ is 5x⁴, not 5x⁵. After you bring the exponent down, the power must come down too.
• Getting the sign wrong with negative exponents. The derivative of x⁻² is −2x⁻³. Subtracting one from −2 gives −3, not −1.
• Mixing up xⁿ and n^x. The power rule needs the variable in the base and a fixed number in the exponent. For 2^x, where the variable is in the exponent, the power rule does not apply. That is an exponential function with a different rule.
• Applying it to something bigger inside. (x² + 1)³ is not 3(x² + 1)². The inside also changes with x, and you need the chain rule to account for it. The power rule alone only works when the base is plain x.
• Treating a constant like a variable. The derivative of 5 is 0, not 5 · x⁻¹. And in a formula like 6x, the 6 is a multiplier, not something you differentiate.
• Not rewriting roots and fractions first. Convert √x, 1/x and 1/x³ into powers of x, and the rule applies directly.
• Dropping the multiplier on the “answer”. The derivative of 7x³ is 21x². You multiply the 7 by the 3, not discard it.

The power rule in reverse

If differentiating lowers the exponent, then undoing it should raise it. That is integration, the reverse process, and its power rule runs backwards: add one to the exponent, then divide by the new exponent.

Check it by differentiating the answer. The derivative of x⁴/4 is (4 · x³)/4 = x³, which is what we integrated. The 4 on top cancelled the 4 underneath, so the two rules are perfect mirror images of one another. The exception n = −1 would mean dividing by zero, and that case leads to the natural logarithm, a story for another article.

Practice problems with answers

Try each one on paper first, then tap to check yourself.

Test yourself: five quick questions

Tap a question to reveal the answer. The correct option is marked.

Frequently asked questions

The post The Power Rule Explained: Why the Exponent Drops Down appeared first on Learn With Examples.

The magic trick, and why it needs engineering

Search-as-you-type looks simple until you ask what the phone is really being asked to do. Every single keystroke is a new question. By the time you type the fourth letter of a name, the phone has answered four separate searches, and it has to finish each one before your finger lands on the next key. Usability researchers have used a rule of thumb for decades: if a response arrives in about a tenth of a second, people experience it as instant. Anything much slower and the interface starts to feel like it is lagging behind you.

Now picture the other side of the problem. A phone might hold a few hundred contacts, but plenty of people have thousands, once you count work contacts, old numbers and group chats. And each contact is not just a name. It has several numbers, an email, a nickname, a company. The search has to be fast, forgiving, and sensible about which result to put first.

I have built search boxes for products of every size over the years, and I always start new engineers with this exact exercise. It teaches normalisation, data structures, ranking and the limits of “just loop over everything” in one small, familiar problem.

The pipeline in one picture

Whatever the app, the path from keystroke to list looks about the same.

Let us walk through the stages in order, starting with the most naive version that works, because the way it fails shows you why each later trick exists.

Step 1: clean up what people type (normalisation)

Before any matching happens, both the typed text and the stored names need to be put into the same shape. People type “jose” for José, they type in lower case, and they put dots and dashes into names such as “Anne-Marie” or “O’Brien”. If you compare raw text, none of those match.

So the first stage lowercases everything, strips accents, replaces punctuation with spaces and splits the name into words. That is called normalisation, and it is the unglamorous step that makes the rest work. Skipping it is the number one reason homemade search feels “broken.”

Below is a first version of the whole search in about twenty lines. It normalises, then checks every contact. A contact matches when every word you typed is the beginning of some word in the name.

import unicodedata, re

def normalise(text):
    """Lowercase, strip accents, turn punctuation into spaces."""
    text = unicodedata.normalize("NFKD", text)
    text = "".join(c for c in text if not unicodedata.combining(c))
    return re.sub(r"[^a-z0-9 ]+", " ", text.lower()).split()   # list of words

def linear_search(contacts, query):
    """Slowest idea that works: look at every contact on every keystroke."""
    q = normalise(query)
    hits = []
    for cid, words in contacts:                  # contacts = [(id, [words...]), ...]
        # every typed word must be the start of some word in the name
        if all(any(w.startswith(t) for w in words) for t in q):
            hits.append(cid)
    return hits

This already behaves like a real contact search. Type “sh” and you find both Onam Sharma (the surname starts with sh) and Shalini Rao (the first name does). Type “on sh” and only Onam Sharma remains, because each typed word must begin some word in the name. Matching at the start of any word is what makes phone searches feel natural: you can type the first or the last name, in any order.

Step 2: watch the results shrink as you type

Here is something satisfying to see. I generated 5,000 made-up contacts (random first and last names) and ran the search above while “typing” the name anit, one letter at a time. My test names lean heavily towards names beginning with A, so the early numbers are larger than a real address book would give, but the shape is what matters.

This shrinking is the whole reason search-as-you-type works so well. The first letter does the least work and returns the longest list, which the phone only needs to display the top of. Every next letter cuts the list further, and by the fourth or fifth letter you are usually looking at a handful of names.

It also hides a second, very practical trick. Every result for “ani” is guaranteed to also be a result for “an”, because anything starting with “ani” also starts with “an”. So instead of searching all contacts again, you can search only the list you already have. I counted the name checks for typing anit across 10,000 contacts: scanning everything on every keystroke took 40,000 checks, while reusing the previous results took 13,852. That is about two-thirds fewer, for a change of a few lines of code.

Step 3: stop scanning, start looking up (the index)

The scan-and-reuse approach is fine for a thousand contacts. But it still touches every candidate on the first keystroke, and the cost grows with the size of the list. Real search systems avoid scanning entirely. They do the hard work once, ahead of time, and build an index, which is a structure designed to answer one specific question quickly. For “which words start with these letters?” the classic answer is a trie.

What is a trie?

A trie (said “try”) is a tree where each step down spells one more letter. All words that share a start share the same path. To find everything starting with “ani”, you walk three steps down and you are standing on the answer: every contact reachable from that spot begins with those letters. You never look at the other thousands of contacts at all.

The cost of a lookup depends on the length of what you typed, not on how many contacts you own. A person with 100 contacts and a person with 100,000 both pay the same few steps for “ani”. That is the property that makes it scale.

Here is a compact version. In this one, every node remembers the set of contacts passing through it, so reading the answer is instant:

class Trie:
    """Every node remembers which contacts pass through it."""
    def __init__(self):
        self.root = {}
    def add(self, word, cid):
        node = self.root
        for ch in word:
            node = node.setdefault(ch, {})
            node.setdefault("#", set()).add(cid)  # '#' holds contact ids
    def prefix(self, text):
        node = self.root
        for ch in text:
            node = node.get(ch)
            if node is None:
                return set()
        return node.get("#", set())

def build(contacts):
    t = Trie()
    for cid, words in contacts:
        for w in words:
            t.add(w, cid)
    return t

def trie_search(t, query_words):
    sets = [t.prefix(w) for w in query_words]
    return set.intersection(*sets) if sets else set()

The trade-off is memory. The trie stores extra information so lookups are fast, which is the oldest bargain in computing: spend space and preparation time to buy speed.

A simpler cousin: the sorted list and binary search

If a trie sounds like more machinery than you want, there is a leaner way to get the same effect. Keep every word in one alphabetically sorted list. All words starting with “ani” sit together in one block, because they sort together. Use binary search to find where that block begins and ends, which takes only about seventeen steps even for a hundred thousand words. If you read our article on heaps and sorted arrays, this is the same “sorted array” idea put to a different job. It uses less memory than a trie and is easier to write, and it is a perfectly good choice.

The numbers: how much faster is an index?

I built all three versions (scan, sorted list with binary search, and trie), checked that they return identical results on 500 random queries, and then timed them. The test is typing the four letters anit, taking the best of five runs, with different address book sizes. These figures come from Python on a cloud machine, so a real phone running compiled code will be quicker in absolute terms. What matters is the ratio.

Look at the first row of the table. With 1,000 contacts, every method finishes in a few milliseconds or less, and nobody would notice a difference. That is the honest takeaway: for a normal-sized address book, even the naive scan is fast enough. The index only earns its keep as the data grows. At 100,000 entries the scan needed about a third of a second to answer four keystrokes, which is long enough to feel sluggish, while the trie needed about a millisecond.

Step 4: searching by phone number

Name search matches the start of words. Number search needs different rules, because people remember numbers differently. They recall the last four digits, or the number without the country code, or they type it with spaces and dashes that were never stored.

The standard solution is to normalise numbers the same way we normalised names. Strip everything that is not a digit, and maybe drop a leading country code such as +91, so that “+91 98765-43210”, “098765 43210” and “9876543210” all become the same string. Then, instead of matching only at the beginning, you let the typed digits match anywhere in the number, or at the end for the “last four digits” habit.

Because digits have only ten possible characters, a similar trie or sorted index works well. For suffix searching, you can index the reversed number so “last four digits” becomes an ordinary prefix lookup.

Step 5: put the most likely person first (ranking)

Finding matches is only half the job. If typing “sha” returns thirty people in alphabetical order, the one you wanted may be on the third screen. So the list has to be ranked.

The idea is to give every match a score from several signals, then sort by score. The signals I always start with are: how well the text matches (the whole name starts with it, a word starts with it, or it appears in the middle), whether you marked the person as a favourite, and how often or how recently you contact them.

from norm import normalise

def score(contact, query):
    """Higher is better. contact = dict(name, favorite, calls)."""
    words = normalise(contact["name"])
    q = normalise(query)
    s = 0
    if " ".join(words).startswith(" ".join(q)):
        s += 100                      # the whole name starts with what you typed
    elif all(any(w.startswith(t) for w in words) for t in q):
        s += 60                       # every typed word starts some word in the name
    elif all(t in " ".join(words) for t in q):
        s += 20                       # typed text appears inside a word
    else:
        return 0
    s += 30 if contact["favorite"] else 0
    s += min(contact["calls"], 50) * 0.5   # frequent contacts float up
    return s

contacts = [
    {"name": "Shalini Rao",   "favorite": False, "calls": 2},
    {"name": "Onam Sharma",   "favorite": False, "calls": 40},
    {"name": "Sharad Verma",  "favorite": True,  "calls": 12},
    {"name": "Ashwin Shah",   "favorite": False, "calls": 5},
    {"name": "Harsh Gupta",   "favorite": False, "calls": 60},
]
query = "sha"
ranked = sorted(((score(c, query), c["name"]) for c in contacts), reverse=True)
for s, name in ranked:
    if s: print(f"{s:6.1f}  {name}")

Running it for the typed text “sha” gives:

 136.0  Sharad Verma
 101.0  Shalini Rao
  80.0  Onam Sharma
  62.5  Ashwin Shah

Notice the order. Sharad Verma is first because his name starts exactly with “sha” and he is a favourite. Shalini Rao is next on pure match quality. Onam Sharma follows, as only the surname starts with “sha”, even though he is called often. Ashwin Shah comes last of the matches, and Harsh Gupta does not appear at all because “sha” never occurs in his name. The weights (100, 60, 20, 30 and the call bonus) are just numbers I chose to demonstrate. In a real product, teams tune them with usage data, and that tuning is the difference between a search that is merely correct and one that feels uncannily helpful.

Step 6: forgiving typos (fuzzy matching)

Thumbs are clumsy and names have many spellings. Is it Anita or Anitha? Sunita or Suneeta? Strict prefix matching treats any typo as a complete failure. Fuzzy matching asks a gentler question: how many small edits would it take to turn what you typed into this name?

The classic measure is edit distance, also called Levenshtein distance, which counts single-letter insertions, deletions and replacements. Here it is in a few lines:

def edit_distance(a, b):
    """Minimum single-letter edits (insert, delete, replace) to turn a into b."""
    prev = list(range(len(b) + 1))
    for i, ca in enumerate(a, 1):
        cur = [i]
        for j, cb in enumerate(b, 1):
            cur.append(min(prev[j] + 1, cur[j-1] + 1, prev[j-1] + (ca != cb)))
        prev = cur
    return prev[-1]

names = ["Anita", "Amit", "Anil", "Ankit", "Anjali"]
typed = "Anitha"           # another common spelling of "Anita"
for name in sorted(names, key=lambda n: edit_distance(typed.lower(), n.lower())):
    print(f"{name:<7} distance {edit_distance(typed.lower(), name.lower())}")

The output:

Anita   distance 1
Amit    distance 3
Anil    distance 3
Ankit   distance 3
Anjali  distance 4

“Anitha” is one deletion away from “Anita”, so Anita comes first, and everything else is at least three edits away. A search that falls back to fuzzy matching only when the exact search finds nothing gives you the best of both: exact results are fast and clean, and typos still find someone.

One small warning from experience: in plain edit distance, swapping two neighbouring letters (typing “Aniat” for “Anita”) costs two edits, not one, even though it is the most common typing mistake. A variant called Damerau-Levenshtein counts a swap as one. Also, comparing your text against every contact is slow, so real systems use fuzzy matching sparingly, usually on a shortlist, or use clever indexes built for it.

A fun relic: the keypad dialer

Many phone dialers let you type digits on the number pad and show contacts whose names could be spelled with those keys. It is the old keypad letter layout (2 for ABC, 3 for DEF and so on) doing a modern job.

KEYS = {"2":"abc","3":"def","4":"ghi","5":"jkl","6":"mno","7":"pqrs","8":"tuv","9":"wxyz"}
LETTER = {ch: d for d, chars in KEYS.items() for ch in chars}

def to_digits(name):
    return "".join(LETTER[c] for c in name.lower() if c in LETTER)

for name in ["Anita", "Amit", "Anil", "Ankit"]:
    print(f"{name:<6} -> {to_digits(name)}")

typed = "26"                          # you pressed 2 then 6 on the dialer
matches = [n for n in ["Anita", "Amit", "Anil", "Ankit", "Rahul"] if to_digits(n).startswith(typed)]
print("typed", typed, "matches", matches)

Anita  -> 26482
Amit   -> 2648
Anil   -> 2645
Ankit  -> 26548
typed 26 matches ['Anita', 'Amit', 'Anil', 'Ankit']

Pressing 2 then 6 matches every name whose first letter lives on the 2 key and whose second letter lives on the 6 key, which is why Anita, Amit, Anil and Ankit all appear. Add a 4 and Ankit drops out, because its third letter, K, sits on the 5 key. Add an 8 and Anil drops out too, leaving Amit and Anita. Working a few of these by hand is a good way to check that you really understand the mapping.

The same idea in five real settings

This pattern appears far beyond contacts. Click a tab to see it in other places.

When the data is not on your phone: debouncing and races

Everything so far searched a local list, where each lookup takes microseconds. Things change when the search has to ask a server, such as a company directory with a million staff or a search box on a website. Now each keystroke could trigger a network request taking 100 to 500 milliseconds, and two new problems appear.

• Too many requests. Typing a seven-letter name could send seven requests in a second. The fix is debouncing: wait until the user pauses for a short time, often 150 to 300 milliseconds, before sending anything. The delay is barely noticeable, and the request count drops sharply.
• Answers arriving out of order. The reply for “an” might arrive after the reply for “ani”, and the screen ends up showing results for the wrong text. The fix is to cancel the old request, or to tag each request with a number and ignore any reply that is not for the latest one.

Phone contact lists are local, so they rarely need debouncing. A server-backed search box almost always does. Knowing which situation you are in is half the design.

Hard cases that break simple search

• Names in other scripts. A contact saved in Devanagari or Arabic script cannot be found by typing Latin letters unless the system stores a transliteration or the user switches keyboards. Many real apps index several forms of the same name.
• Prefixes in surnames. “McDonald”, “de la Cruz” and “Al-Farsi” do not split into words the way English names do. Treat the hyphen and the apostrophe thoughtfully.
• Accent rules differ by language. Stripping the dots from “ü” helps in French and Spanish but may be wrong in German searches, where “ue” is the usual substitute.
• Sorting order. The alphabet itself differs between languages. Sorting by raw character codes puts all capitals before all lowercase letters. Use a locale-aware sort.
• Duplicates. The same person saved twice with slightly different details should usually appear as one result.

Which approach should you choose?

Common mistakes when building search-as-you-type

• Skipping normalisation. Case and accent mismatches make good data look broken.
• Matching anywhere instead of at word starts. Typing “an” returns “Hannah” and “Joanna” before “Anita”, because they contain “an” in the middle. Prefer word-start matches and rank anywhere-matches lower.
• Not ranking at all. An alphabetical list of thirty matches is a correct answer and a poor experience.
• Rebuilding the index on every keystroke. Build once, update when contacts change.
• Doing the work on the main thread. Heavy searching on the thread that draws the screen makes the typing itself stutter.
• Forgetting empty results. Show something helpful, such as “no match” or a fuzzy suggestion, not a blank screen.

Test yourself

Tap a question to reveal the answer. The correct option is marked.

Frequently asked questions

The post How a Phone’s Contact Search Finds Matches as You Type appeared first on Learn With Examples.

How to use this guide

Read the questions in order the first time, because later answers lean on earlier ones. Subnets make more sense after IP addresses, and the “what happens when you type a URL” question ties together half the list. After that, use the headings to jump to whatever you are weakest on.

Questions 1 to 5 cover the foundations. Questions 6 to 11 cover the protocols that make the internet work. Questions 12 to 15 cover devices and routing, and 16 to 20 cover security and troubleshooting.

Part 1: The foundations

Q1 What is a computer network, and what are LAN, WAN and MAN?

A network is two or more devices connected so they can exchange data. Everything else is about scale. A LAN (local area network) covers a small area such as a home, an office floor or a school lab. A MAN (metropolitan area network) spans a city or a campus. A WAN (wide area network) links networks across cities or countries, and the internet is the largest WAN there is.

Q2 Explain the OSI model and the TCP/IP model.

The OSI model is a seven-layer teaching framework for how data travels. Each layer does one job and talks only to the layers directly above and below it. The TCP/IP model is the four-layer version the real internet is built on. Interviewers love asking for both because the layers give you a map for troubleshooting.

A handy memory trick for the OSI layers from the top is: All People Seem To Need Data Processing (Application, Presentation, Session, Transport, Network, Data Link, Physical). In practice, people use the layer numbers as shorthand. When an engineer says “layer 2 problem,” they mean something about switches and MAC addresses. “Layer 3” means IP and routing, and “layer 4” means TCP or UDP ports.

Q3 What is an IP address? What is the difference between IPv4 and IPv6, and between public and private?

An IP address is the logical address of a device on a network, used to route data to it. IPv4 addresses are 32 bits long, written as four numbers such as 192.168.1.10, giving about 4.29 billion possible addresses (2³² is exactly 4,294,967,296). That turned out not to be enough for a world of phones and sensors. IPv6 addresses are 128 bits, which gives roughly 3.4 × 10³⁸ addresses, an almost unimaginable number.

Private addresses are reserved for use inside networks and are not routed on the public internet. The three ranges are 10.0.0.0/8, 172.16.0.0/12 and 192.168.0.0/16. Public addresses are unique across the internet. Because many homes reuse the same private ranges, NAT (Question 13) lets them all share one public address.

Q4 What is a subnet mask and what is subnetting?

A subnet mask tells a device which part of an IP address identifies the network and which part identifies the host. The mask 255.255.255.0 means the first three numbers name the network and the last one names the device. Engineers also write it as CIDR notation: 192.168.10.0/24, where 24 is the count of network bits.

Subnetting means cutting one large network into smaller ones, usually for tidiness, security or to reduce broadcast traffic. The useful formula: a network with a prefix length of n has 2^{(32 − n)} addresses, and two of those are reserved (the network address and the broadcast address), so the usable host count is 2^{(32 − n)} − 2. A /24 gives 254 hosts. A /26 gives 62.

Here is a short Python program that does the arithmetic with the standard ipaddress module. It splits a /24 into four /26 subnets.

import ipaddress

net = ipaddress.ip_network("192.168.10.0/24")
print(net, "has", net.num_addresses, "addresses,", net.num_addresses - 2, "usable hosts")
print("mask:", net.netmask)
print()
print("Split into four /26 subnets:")
for s in net.subnets(new_prefix=26):
    hosts = list(s.hosts())
    print(f"{str(s):<18} hosts {hosts[0]} - {hosts[-1]}   broadcast {s.broadcast_address}")

Output:

192.168.10.0/24 has 256 addresses, 254 usable hosts
mask: 255.255.255.0

Split into four /26 subnets:
192.168.10.0/26    hosts 192.168.10.1 - 192.168.10.62   broadcast 192.168.10.63
192.168.10.64/26   hosts 192.168.10.65 - 192.168.10.126   broadcast 192.168.10.127
192.168.10.128/26  hosts 192.168.10.129 - 192.168.10.190   broadcast 192.168.10.191
192.168.10.192/26  hosts 192.168.10.193 - 192.168.10.254   broadcast 192.168.10.255

Read each line as a mini network: the first usable host, the last usable host, and the broadcast address at the end. Interviewers who ask this question often give you a block like 192.168.10.0/24 and ask you to carve out four equal subnets. The answer is the table above, and the trick is that each /26 holds 64 addresses, so the blocks start at 0, 64, 128 and 192.

Q5 What is the difference between a MAC address and an IP address?

A MAC address is a 48-bit hardware identifier burned into a network card, written like 3C:52:82:AB:12:EF. It is used for delivery within one local network. An IP address is assigned by software or a DHCP server, can change, and is used to route data between networks.

One more detail worth saying: as a packet crosses several routers, the IP addresses at both ends stay the same, but the MAC addresses are rewritten at every hop. That single sentence tells an interviewer you understand how layers 2 and 3 cooperate.

Part 2: The protocols that run the internet

Q6 What is the difference between TCP and UDP?

TCP is connection-oriented. It sets up a connection first, numbers the data, retransmits what is lost and delivers it in order. UDP is connectionless. It just sends packets with no handshake, no retransmission and no ordering guarantee, so it is faster and lighter.

Q7 Explain the TCP three-way handshake.

Before TCP sends any data, the two sides agree to talk. The client sends a SYN (“I want to connect, my starting sequence number is X”). The server answers with SYN-ACK (“Got it, here is mine, Y”). The client finishes with an ACK (“Got yours too”). Now both sides know the other is alive and reachable, and they have agreed on sequence numbers for tracking data.

A bonus line that impresses: a SYN flood attack sends huge numbers of SYNs and never completes the handshake, leaving the server holding half-open connections. Defences include SYN cookies and rate limits.

Q8 What is DNS and how does a lookup work?

DNS, the Domain Name System, is the internet’s phone book. People remember names like example.com, but computers need IP addresses, and DNS translates one into the other.

When your device needs an address, it asks a recursive resolver, usually run by your ISP or a public DNS service. If the resolver does not already have the answer cached, it asks a root server, which points it to the server for the top-level domain (.com, .org, .in). That server points to the domain’s authoritative server, which gives the real answer. The resolver returns it to you and remembers it for the record’s time to live (TTL).

Know the common record types: A (name to IPv4), AAAA (name to IPv6), CNAME (an alias to another name), MX (mail servers) and NS (which servers are authoritative). Plain DNS uses UDP port 53, and TCP port 53 is used for large responses.

Q9 What is DHCP and how does it work?

DHCP, the Dynamic Host Configuration Protocol, automatically gives a device an IP address, subnet mask, default gateway and DNS servers when it joins a network. The exchange is nicknamed DORA: the client broadcasts a Discover, the server sends an Offer, the client sends a Request for that offer, and the server sends an Acknowledge. The address is a lease, not a permanent grant, and the client renews it before it expires.

Q10 What is ARP and why is it needed?

On a local network, devices deliver frames by MAC address, but programs only know IP addresses. ARP, the Address Resolution Protocol, bridges the gap. When your PC wants to reach 192.168.1.1 and does not know its MAC, it broadcasts “Who has 192.168.1.1?” to everyone. The owner replies with its MAC address. Your PC stores the answer in its ARP cache for a while, so it does not need to ask again.

The classic security follow-up is ARP spoofing: an attacker sends false ARP replies so that traffic meant for the gateway flows through their machine. Managed switches can defend against it with features such as dynamic ARP inspection.

Q11 What happens when you type a URL into your browser and press Enter?

Here is the version I recommend you tell, in order:

• 1. The browser checks its caches and the operating system’s cache for a known address.
• 2. DNS lookup. If nothing is cached, it resolves the name to an IP address (Question 8).
• 3. TCP connection. The browser opens a connection to port 443 with the three-way handshake (Question 7).
• 4. TLS handshake. For HTTPS, both sides agree on encryption and the server proves its identity with a certificate.
• 5. HTTP request. The browser sends GET / with headers.
• 6. The server responds with a status code (200 for success) and the page.
• 7. The browser renders the page, requesting images, scripts and styles, often over the same connection.

Mention that on your local network, the first packet needs ARP to find the gateway’s MAC address, and that routers along the way forward the packet by IP. That shows you can connect every layer in one story.

Part 3: Devices and routing

Q12 What is the difference between a hub, a switch and a router?

Q13 What is NAT?

NAT, Network Address Translation, lets many devices with private addresses share one public IP address. The router rewrites the source address and port of outgoing packets and keeps a table. When replies come back, it looks up the table and forwards them to the right internal device. The common form, where ports tell the devices apart, is often called PAT or NAT overload.

Know the side effects. NAT helped the world survive IPv4 exhaustion, and it hides internal addresses from the outside. But it is not a firewall, and it breaks anything that needs inbound connections, which is why we use port forwarding to reach a server inside a home network.

Q14 What is a default gateway, and how does a router choose where to send a packet?

A default gateway is the router a device uses for any destination outside its own subnet. Your laptop does not know how to reach the whole internet, so it hands everything non-local to the gateway.

A router keeps a routing table, a list of destination networks and where to send traffic for each. When a packet arrives, the router finds every entry that matches the destination and picks the most specific one, meaning the longest prefix. That is the longest prefix match. The entry 0.0.0.0/0 is the default route and matches everything, but because it is the least specific, it only wins when nothing better matches.

Here is a tiny router in Python with four routes:

import ipaddress

routes = {
    "0.0.0.0/0":   "ISP (default route)",
    "10.0.0.0/8":  "Head office core",
    "10.1.0.0/16": "Branch office",
    "10.1.2.0/24": "Branch lab network",
}

def lookup(dest):
    ip = ipaddress.ip_address(dest)
    best = None
    for prefix, hop in routes.items():
        net = ipaddress.ip_network(prefix)
        if ip in net and (best is None or net.prefixlen > best[0].prefixlen):
            best = (net, hop)
    return best

for dest in ["10.1.2.50", "10.1.9.9", "10.7.7.7", "8.8.8.8"]:
    net, hop = lookup(dest)
    print(f"{dest:<10} matches {str(net):<12} -> {hop}")

Output:

10.1.2.50  matches 10.1.2.0/24  -> Branch lab network
10.1.9.9   matches 10.1.0.0/16  -> Branch office
10.7.7.7   matches 10.0.0.0/8   -> Head office core
8.8.8.8    matches 0.0.0.0/0    -> ISP (default route)

Look at the first line. The address 10.1.2.50 matches the /8, the /16 and the /24, and the /24 wins because it is the most specific. The last line matches only the default route, which sends it to the ISP.

One more thing interviewers like: routes can be static (written by an administrator) or dynamic (learned from other routers using protocols such as OSPF inside an organisation and BGP between internet providers). Static is simple and predictable. Dynamic adapts when links fail.

Q15 What is a VLAN and why would you use one?

A VLAN, virtual LAN, splits one physical switch into several logical networks. Devices in different VLANs cannot talk directly even if they are plugged into the same switch, and they need a router (or a layer 3 switch) to communicate. Frames carry a VLAN tag following the 802.1Q standard when they travel between switches.

The reasons to use them are security (keep guest Wi-Fi away from the finance team), performance (smaller broadcast domains) and tidiness (group devices by function, not by cable location).

Part 4: Security and troubleshooting

Q16 What is a firewall?

A firewall filters network traffic by rules, allowing or blocking it based on things like source, destination, port and protocol. A stateless firewall checks each packet alone against the rules. A stateful firewall tracks connections, so it knows that an incoming packet is a reply to something you started, and it allows it automatically. Modern “next-generation” firewalls also look at applications and can detect certain threats.

The principle to quote is default deny: block everything, then allow only what you need. That way, a mistake leaves you too closed instead of too open.

Q17 What is the difference between HTTP and HTTPS?

HTTP sends web traffic in plain text on port 80, so anyone on the path can read or alter it. HTTPS is the same protocol carried inside TLS encryption, usually on port 443. TLS gives you three things: confidentiality (nobody can read it), integrity (nobody can change it unnoticed) and authentication (a certificate proves you reached the real site).

If asked how the handshake works, a safe outline is: the client says hello and lists its supported options, the server answers with its certificate, the client checks the certificate against trusted authorities, and both sides agree on session keys, which then encrypt the data. Modern TLS also uses temporary keys, so recorded traffic stays unreadable even if a server key leaks later.

Q18 What is a VPN, and how is it different from a proxy?

A VPN creates an encrypted tunnel between your device and a VPN server, and typically sends all your traffic through it. Companies use VPNs so remote staff can reach internal systems as if they were in the office. A proxy is a server that makes requests on your behalf, usually for particular applications, and it may not encrypt anything. A VPN protects the whole path to the VPN server. A proxy mainly changes where the request appears to come from or adds filtering and caching.

Be careful with claims. A VPN hides your traffic from the local network and your ISP, but the VPN provider can see it instead. It does not make you anonymous.

Q19 How do you troubleshoot “the internet is not working”? What do ping and traceroute do?

Ping sends a small ICMP echo request and waits for a reply. It tells you whether a host is reachable and how long the round trip takes. Traceroute (called tracert on Windows) lists the routers on the path by sending packets with increasing TTL values, so each router in turn reports back when the TTL runs out. It shows you where along the path things slow down or stop.

My own habit is a four-step ladder, working outward until something fails:

• Ping 127.0.0.1. If this fails, the network software on your own machine is broken.
• Ping the default gateway. If this fails, the problem is local: cable, Wi-Fi, switch or gateway.
• Ping a public IP such as 8.8.8.8. If this works but names fail, you are nearly at DNS. If it fails, the problem is beyond the gateway, maybe the ISP.
• Ping a domain name. If the IP works but the name does not, DNS is the culprit.

Also check the basics early: is the address a 169.254 one (DHCP failed), is the cable plugged in, and did anything change recently? In my experience, most “mysterious” outages are one of those three.

Q20 What is the difference between bandwidth, latency and throughput?

Bandwidth is the maximum amount of data a link can carry per second, like the number of lanes on a highway. Latency is how long a single piece of data takes to get there, like the time for one car to complete the trip. Throughput is the amount that actually gets through in practice, which is usually lower than bandwidth because of congestion, errors and protocol overhead.

It is worth adding that a bigger plan does not fix a latency problem. When someone says “my connection is fast but pages feel slow,” look at latency, DNS and packet loss before blaming bandwidth.

How the same question changes by role

The twenty questions above are common, but interviewers adjust the depth to the job. Click a tab to see what each role is really probing for.

Common mistakes candidates make

• Reciting definitions with no example. A definition shows memory. An example shows understanding.
• Mixing up layers. Saying a switch “routes” or that IP is at layer 2 is the quickest way to lose credibility.
• Confusing the port with the protocol. Port 443 is conventionally HTTPS, but a program can use any port.
• Forgetting that DNS uses UDP. Most do not mention that TCP is used for large answers and zone transfers.
• Claiming NAT is a firewall. It hides addresses as a side effect. It does not enforce a security policy.
• Guessing in troubleshooting questions. Describe your method out loud. Interviewers care more about how you think than what you land on.
• Bluffing. “I have not used that, but here is how I would find out” works far better than inventing an answer.

A study plan that actually works

If you have two weeks, here is the order I recommend. Spend the first few days on layers, IP, subnets and TCP versus UDP, and practise subnetting by hand until the powers of two come automatically. In the middle days, trace one full web request (Question 11) on paper, then capture a real one using a packet analyser such as Wireshark and watch the DNS query, handshake and TLS hello appear. In the last days, build a small lab. The free Packet Tracer simulator from Cisco Networking Academy is excellent for this, and you can also run a few Linux virtual machines. Break something on purpose, then fix it using the ping ladder.

Nothing replaces hands-on practice. The people who stand out are the ones who say “when I set this up at home, I noticed…” because that cannot be memorised.

Test yourself: five-question mock round

Tap a question to reveal the answer. The correct option is marked.

Frequently asked questions

The post Top 20 Networking Interview Questions with Plain-English Answers appeared first on Learn With Examples.

The problem ports solve

Think about what happens when you open a website while a video call is running, a music app is streaming and your email is syncing in the background. All of that traffic arrives at your laptop through one network connection, addressed to one IP address. Yet the website data ends up in the browser, the call audio in the call app, and the emails in the mail client. They never get mixed up.

The IP address cannot do that job, because it only identifies the machine. You need a second number that identifies the program or service on that machine. That number is the port.

An everyday analogy: the apartment building

Imagine you send a parcel to “42 Mall Road.” The courier finds the building, which is what an IP address does. But 42 Mall Road is an apartment block with a hundred flats. Without a flat number the parcel sits in the lobby. Write “Flat 443” on it and the right resident receives it.

The analogy also explains why some flat numbers are famous. Everybody knows the front desk is Flat 1, so visitors do not have to ask. Ports work the same way. If every web server on Earth listens on 443 for secure traffic, your browser can reach any of them without being told the number.

Where ports live: the transport layer

Ports belong to the transport layer of networking, and the two protocols that use them are TCP and UDP.

• TCP sets up a connection first, guarantees delivery and keeps the data in order. Web pages, email and file transfers use it.
• UDP just fires packets without a handshake or guarantees. It suits things where speed matters more than perfection, such as DNS lookups, live video, voice calls and games.

TCP port 53 and UDP port 53 are different doors that happen to share a number. Each protocol has its own full set of 65,536 ports, which is why you will see written forms like 443/tcp and 443/udp. In fact, modern HTTP/3 uses UDP port 443, while ordinary HTTPS uses TCP port 443.

Why exactly 0 to 65535?

The port number is stored in 16 bits in the TCP and UDP headers. Sixteen bits give 2¹⁶, or 65,536 possible values, counting from zero. That is the whole reason for the limit. Port 0 is reserved and is not used for ordinary traffic, so in practice you work with 1 to 65535.

The three port ranges

The internet’s numbering authority, IANA, divides the 65,536 numbers into three zones.

One caution: operating systems do not all follow the IANA suggestion for temporary ports. Modern Windows uses 49152 to 65535 by default. Linux commonly uses 32768 to 60999, and you can read the exact range in /proc/sys/net/ipv4/ip_local_port_range. That is a tuning detail worth knowing when you debug connection limits.

The ports every beginner should memorise

These are conventions, not laws. Nothing in physics forces a web server to listen on 80. It is simply the agreed default, and the agreement is what lets browsers and servers find each other without negotiation.

Why 80, 443 and 22 matter so much

Port 80: the original web

When you type http://example.com, your browser quietly adds :80. This is plain, unencrypted HTTP. Anyone on the path, such as the coffee shop Wi-Fi owner, can read or modify what travels over it. Today port 80 mostly survives to redirect visitors to the secure version.

Port 443: the secure web

When you type https://example.com, the browser adds :443. The same HTTP conversation happens, but wrapped in TLS encryption. This is the port that matters most for any site you run. Search engines, browsers and users all expect it. If you want to run a site that ranks and earns trust, port 443 must be open, and the certificate behind it must be valid.

Port 22: the administrator’s door

SSH is how people manage servers from afar. It is also, unfortunately, one of the most attacked doors on the internet. If you have ever put a server online and checked its logs an hour later, you have seen strangers hammering port 22 with guessed passwords. We will come back to what to do about that.

You can use any port in a URL by writing it after a colon. https://example.com:8443 tells the browser to use 8443 instead of 443. Developers do this constantly, and the reason is a ritual every programmer knows: local test servers run on ports like 3000, 5000, 8000 or 8080, so that they do not clash with the real web ports.

The key idea: a connection is four numbers

Here is the part that clears up the most confusion. When your browser connects to a web server, it uses a port on both sides. The server side is the well-known one (443). Your side is a temporary number the operating system picks from the dynamic range.

A TCP connection is uniquely identified by four values: your IP address, your port, the server’s IP address and the server’s port. Change any one of them and it is a different connection. That is how you can open ten tabs to the same website, all talking to the same server on the same port 443, without the answers colliding. Each tab uses a different source port on your side.

See it for yourself in about twenty lines of Python

I like proving things in code rather than asking you to believe them. The script below starts a small server, connects to it three times, and prints which ports each side used. Then it tries to start a second server on the same port.

import socket, threading

# 1. A server listens on one port. We let the OS pick a free one (port 0).
server = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
server.bind(("127.0.0.1", 0))
server.listen()
host, port = server.getsockname()
print("server listening on port", port)

# 2. Three clients connect to that single server port.
def serve():
    for _ in range(3):
        conn, addr = server.accept()
        conn.close()
threading.Thread(target=serve, daemon=True).start()

for n in range(3):
    c = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
    c.connect((host, port))
    print(f"client {n+1}: my port {c.getsockname()[1]} -> server port {c.getpeername()[1]}")
    c.close()

# 3. A second server cannot grab the same port.
dup = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
try:
    dup.bind((host, port))
except OSError as e:
    print("second bind failed:", e.strerror)

This is the output from one run on my machine. Your numbers will differ, because the operating system picks them:

server listening on port 54875
client 1: my port 47676 -> server port 54875
client 2: my port 47684 -> server port 54875
client 3: my port 47700 -> server port 54875
second bind failed: Address already in use

Three things are worth noticing. First, the server uses one port, 54875 in this run, for all three clients. Second, each client received a different temporary port of its own. Third, the attempt to bind a second server to the same address and port failed with “Address already in use.” Only one program can listen on a given port at a time, which explains an error that confuses beginners every single week.

The same idea in five real settings

Click a tab to see ports at work in different places. No reload, nothing to install.

How your router uses ports: NAT in plain English

Your home has one public IP address from your internet provider, yet a dozen devices share it. How do replies find the right device? The router performs NAT, network address translation, and ports are the trick that makes it work.

Suppose your phone (192.168.1.20) opens a connection to a web server from its local port 51000. The router rewrites the outgoing packet so it appears to come from the router’s own public address, using its own chosen port, say 40001. It remembers the pairing in a table. When the reply returns to port 40001, it looks it up and forwards the data to the phone at 192.168.1.20 port 51000. Your laptop doing the same thing would get a different public port.

The numbers in the table are illustrative, since real routers pick their own. Notice that the phone and laptop both used private port 51000 and nothing broke. The router separates them by assigning different public ports.

Port forwarding: the reverse trick

NAT works naturally for connections that start inside your home. Connections that start outside have a problem: the router has no table entry, so it drops them. If you want a friend to join a game server running on your PC, you create a port forwarding rule: “anything arriving on public port 25565 goes to 192.168.1.50, port 25565.” That is exactly what the home-router tab above shows.

Firewalls: deciding which doors are open

A firewall is largely a list of rules about ports. A typical server firewall says: allow incoming 443, allow incoming 22 only from my office, and drop everything else. Because a program can only receive connections if something is listening, closing a port you do not need means that if the software behind it has a flaw, the flaw is unreachable.

When you scan a machine for open ports, there are usually three results:

• Open. A program is listening and accepted the connection.
• Closed. The machine is reachable, but nothing listens there, and it politely refuses.
• Filtered. A firewall dropped the attempt, so you get no answer at all.

The practical rule I teach every junior: every open port is a promise to answer strangers. Keep that list as short as you can.

Commands to see ports on your own machine

Tool options vary slightly between systems and versions, so treat these as reliable starting points. Only scan machines you own or have permission to test. Scanning other people’s networks can break rules or laws.

Limits you can actually hit: running out of ports

Because each outgoing connection needs a temporary port, a single client talking to a single server address and port has a ceiling. With Windows’ default dynamic range of 49152 to 65535, that is 16,384 simultaneous connections. With Linux’s common default of 32768 to 60999, it is 28,232. After that, new connections fail until old ones close.

Most users never see this. Busy servers and load balancers do, and the same arithmetic hits NAT gateways that funnel thousands of devices through one public address. When people say a service “ran out of ephemeral ports,” this is what they mean. The usual fixes are reusing connections (keep-alive and connection pooling), widening the range, or adding more addresses.

Security myths about ports

Myth: changing the SSH port makes it secure

Moving SSH from 22 to something obscure reduces noise in your logs because the lazy scanners that probe only port 22 stop finding you. It does not stop a determined scanner, which checks all ports in minutes. Real protection comes from key-based login instead of passwords, disabling root login, keeping software updated, and restricting who may connect at all. Treat a port change as tidiness, not security.

Myth: a closed port means the machine is invisible

A closed port still reveals that the machine exists. Only a firewall that silently drops traffic hides that, and even then the machine can leak information in other ways.

Myth: databases are safe on their default port because nobody knows the number

Everybody knows the number. MySQL on 3306, PostgreSQL on 5432, Redis on 6379 and MongoDB on 27017 are scanned constantly. A database should normally listen only on a private interface, with the firewall blocking public access.

Common mistakes beginners make

• Confusing the port with the protocol. Port 443 is conventionally HTTPS, but a program can run anything on any port. The convention is not enforced.
• Forgetting TCP versus UDP. Opening TCP 53 in a firewall does nothing for DNS queries that use UDP 53.
• Opening a port without checking what listens behind it. You have just exposed that program to the whole internet.
• Forwarding a port on the router but not opening it on the PC firewall. The traffic arrives and is dropped by the last gate.
• Assuming a number above 1023 needs no thought. Registered ports can be just as dangerous as well-known ones when they hold a database.
• Running a second copy of a server and ignoring “Address already in use.” Something already owns that port.

Test yourself

Tap a question to reveal the answer. The correct option is marked.

Frequently asked questions

The post What Is a Port Number? Why 80, 443 and 22 Matter appeared first on Learn With Examples.

The problem DHCP solves

Every device on a network needs an IP address, which is the number other devices use to send it data. If you set one by hand, you have to pick a number nobody else is using, enter the right subnet mask, the right gateway, and at least one DNS server. Get one digit wrong and the device either cannot talk to anyone or, worse, collides with another device and knocks it offline.

I have done this by hand on more machines than I care to count, back when a small office meant a spreadsheet of addresses taped inside the server cabinet. It works for ten machines. It collapses at a hundred, and it is hopeless for phones that join and leave a network several times a day.

The fix is DHCP, the Dynamic Host Configuration Protocol. A DHCP server owns a range of addresses and a set of settings. Any device that joins the network asks for them, receives a loan of one address, and uses it until the loan runs out. The key word is loan, and it explains almost everything else in this article.

An everyday analogy: the hotel front desk

Picture a hotel with fifty rooms. You arrive with a suitcase and no room number. You do not walk the corridors trying doors. You go to the front desk, and the clerk checks which rooms are free, assigns you one, and hands over a key card that works until checkout. If you stay longer, you stop by the desk and extend it. If you leave without telling anyone, the key card simply stops working at checkout time and the room goes back into the pool.

Map it across: the hotel is the network, the rooms are IP addresses, the guest is your device, and the clerk is the DHCP server. The checkout time is the lease. That last detail matters more than it looks, and we will see why when the café runs out of rooms.

What exactly does a DHCP server hand out?

An IP address is only the headline. A device usually receives a small bundle of settings, delivered as numbered “options” inside the DHCP messages.

The ordinary home values above are only an example. Many routers use 192.168.0.x or 10.0.0.x instead, and lease times vary by manufacturer and by network. There are many more options (a domain name, time servers, boot file locations for network booting), but these five are the ones you will see in daily life.

The big question: how can you ask for an address when you have none?

Here is the puzzle that makes DHCP clever. Your phone has just joined the Wi-Fi. It has no IP address, no idea what the network looks like, and no idea where the DHCP server is. How do you send a message to someone you cannot address?

The answer is broadcast. The phone sends its first message from the address 0.0.0.0 (“I am nobody yet”) to 255.255.255.255 (“everybody on this local network”). It does not know who the server is, so it shouts to the whole room. Every device on the local network hears it, but only a DHCP server answers. DHCP runs over UDP, with clients using port 68 and servers using port 67.

DORA: the four-message conversation

Network engineers use the nickname DORA for the four steps. Here is the whole exchange.

1. Discover

The client broadcasts: “Is there a DHCP server out there? I need an address.” The message carries the client’s hardware (MAC) address so the server knows who is asking.

2. Offer

A DHCP server picks a free address from its pool and replies: “I can lend you 192.168.1.134, with this mask, this gateway, these DNS servers, for 24 hours.” Notice it is an offer, not a grant. The address is held aside for the client, but the deal is not done.

3. Request

The client says: “Yes, I would like that address from that server.” This message is still broadcast, and that is deliberate. If two DHCP servers both made offers, the broadcast tells every server which offer the client accepted, so the others can release the address they had reserved.

4. Acknowledge

The server confirms: “It is yours.” Only now does the client configure its network interface with the address. The conversation takes a fraction of a second on a healthy network.

The lease: an address is borrowed, not owned

When the server says “24 hours,” the clock starts. The client does not wait until the last second. It follows two timers defined in the DHCP standard (RFC 2131):

• T1, the renewal time, defaults to 50 percent of the lease. The client quietly asks the same server, directly, to extend the lease.
• T2, the rebinding time, defaults to 87.5 percent of the lease. If the original server has not answered, the client now broadcasts, asking any DHCP server to extend.
• Expiry at 100 percent. If no server has answered, the client must stop using the address and start over with Discover.

On a normal network, renewal succeeds at the 12-hour mark and the lease clock resets. Your laptop can keep the same address for months without you noticing. The lease exists for the opposite case: devices that vanish. A phone that walks out of range never says goodbye, so the server needs a way to reclaim its address. That is what expiry does.

Let us build a tiny DHCP pool

Reading about leases is one thing. Seeing one is better. Here is a small address pool in Python that hands out addresses, renews them and reclaims expired ones. It is not a real DHCP server (there are no network packets), but it implements the same bookkeeping that real servers do.

import ipaddress
from collections import deque

class DhcpPool:
    """A tiny DHCP address pool: hand out, renew and reclaim leases."""
    def __init__(self, first, last, lease_seconds):
        a = int(ipaddress.IPv4Address(first))
        b = int(ipaddress.IPv4Address(last))
        self.free = deque(str(ipaddress.IPv4Address(i)) for i in range(a, b + 1))
        self.lease = lease_seconds
        self.leases = {}                     # mac -> (ip, expires_at)

    def reclaim(self, now):
        for mac, (ip, exp) in list(self.leases.items()):
            if exp <= now:
                del self.leases[mac]
                self.free.append(ip)         # reused last, like many servers

    def request(self, mac, now):
        self.reclaim(now)
        if mac in self.leases:               # renewal: same address, fresh clock
            ip = self.leases[mac][0]
        elif self.free:
            ip = self.free.popleft()
        else:
            return None                      # pool exhausted
        self.leases[mac] = (ip, now + self.lease)
        return ip

def timers(lease_seconds):
    """RFC 2131 defaults: renew at 50 percent, rebind at 87.5 percent."""
    return lease_seconds * 0.5, lease_seconds * 0.875

# demo
pool = DhcpPool("192.168.1.100", "192.168.1.102", lease_seconds=3600)
print("phone  ->", pool.request("aa:aa", 0))
print("laptop ->", pool.request("bb:bb", 10))
print("tv     ->", pool.request("cc:cc", 20))
print("tablet ->", pool.request("dd:dd", 30), "(pool is empty)")
print("phone renews at 1800s ->", pool.request("aa:aa", 1800))
print("tablet at 3700s ->", pool.request("dd:dd", 3700), "(laptop and tv expired)")
t1, t2 = timers(86400)
print("24h lease: renew at %.0fh, rebind at %.1fh" % (t1/3600, t2/3600))

Running it with a pool of only three addresses and a one-hour lease produces this:

phone  -> 192.168.1.100
laptop -> 192.168.1.101
tv     -> 192.168.1.102
tablet -> None (pool is empty)
phone renews at 1800s -> 192.168.1.100
tablet at 3700s -> 192.168.1.101 (laptop and tv expired)
24h lease: renew at 12h, rebind at 21.0h

Read it line by line. The first three devices get consecutive addresses. The tablet asks while the pool is empty and gets nothing, which is exactly what a real device experiences when a network runs out of addresses. The phone renews at the half-hour mark and keeps the same address. By 3,700 seconds, the laptop and TV leases have expired without anyone releasing them, so the tablet finally gets the laptop’s old address.

When the hotel runs out of rooms: a café simulation

Lease length sounds like a boring setting until you see it break something. So I simulated a café with Wi-Fi. About one new customer device joins every minute, stays for roughly half an hour on average, and leaves without telling the network. The DHCP pool has 100 addresses. I ran ten hours of café time, repeated twenty times with different random seeds, and varied only the lease length. Devices renew at the 50 percent mark while they are present, just like real ones.

The shape of the result is the lesson. With a 10 or 30-minute lease, nobody was turned away. At one hour, a handful of devices failed during the busiest moments. At four hours, about half of all arriving devices found no free address, and at 24 hours more than four out of five did. The crowd was identical in every run. The only difference was how long departed devices kept their addresses reserved.

The figures come from a simplified model: random arrivals, a random stay time and no early release. Real cafés have more variety, and the exact percentages will differ. The pattern will not. A short lease is the right tool for a transient crowd, and a long lease is the right tool for a stable one. Home and office networks, where the same devices come back every day, can use long leases comfortably. Hotels, airports, conferences and cafés should use short ones.

The same idea in five real settings

Click a tab to see DHCP in different places. Nothing to install and no page reload.

Dynamic, static and reserved: three ways to get an address

DHCP is not all-or-nothing. Most real networks mix three approaches.

My own rule after fifteen-odd years: configure a reservation on the DHCP server rather than a static address on the device whenever you can. All the addressing then lives in one place, and you can see and change it from the server. Static addresses scattered across devices are how networks accumulate mysteries.

What happens when DHCP fails?

If a device sends Discover and nobody answers, it does not give up silently. Modern operating systems fall back to a link-local address in the range 169.254.0.0 to 169.254.255.255 (defined in RFC 3927, and called APIPA on Windows). The device picks one at random in that range and checks that nobody else is using it.

That fallback only lets the device talk to other link-local devices on the same local network. There is no gateway, so there is no internet. If you ever open your network settings and see an address starting with 169.254, read it as a message: “I asked for an address, and nobody gave me one.”

Commands you can run yourself

Seeing the lease on your own machine makes this concrete. The commands vary a little by operating system.

On Windows, ipconfig /all prints a “DHCP Server” line plus “Lease Obtained” and “Lease Expires” times. That is the lease we have been discussing, sitting right there on your screen. The macOS interface name (en0 here) can differ between machines, and Linux tools differ between distributions, so treat these as starting points.

Beyond one subnet: relay agents

There is an obvious catch with broadcasts. Routers do not forward them, so a DHCP broadcast stays inside its own local network. In a company with separate networks for staff, guests and printers, would you need a DHCP server in every one?

No. The trick is a DHCP relay agent, usually a setting on the router (often called “IP helper”). It listens for broadcasts on one network, wraps them in a unicast message and forwards them to a central DHCP server. The relay stamps in the address of the network the request came from, so the server knows which pool to use. One central server can then serve dozens of separate networks, each with its own address range.

IPv6 and DHCPv6, briefly

Everything above is DHCP for IPv4. IPv6 networks have another automatic option called SLAAC (stateless address autoconfiguration), where a device builds its own address from information advertised by the router. DHCPv6 also exists, and networks use it when they want central control over addresses or need to pass out extra settings. The two are not rivals so much as tools, and many networks use them together. The details deserve their own article.

Security: DHCP trusts everyone

DHCP was designed for a friendlier era. A client believes the first offer it likes, with no authentication. That creates two classic problems.

Rogue DHCP servers

Someone plugs in a router, or a misconfigured device starts running a DHCP service. Clients that hear its offer first accept it, and now they receive a wrong gateway or a malicious DNS server. At best, people lose internet access and nobody can explain why. At worst, traffic is redirected through an attacker. The defence on managed switches is DHCP snooping, which only allows DHCP server messages from ports marked as trusted.

Address starvation

An attacker, or a buggy device, sends a flood of requests with fake MAC addresses until the pool is empty and real users get nothing. Switch features that limit the number of MAC addresses per port, and short leases on guest networks, reduce the damage.

Common problems and how I debug them

• Two DHCP servers on one network. A very common home mistake is plugging a second router into the first one with its DHCP still enabled. Devices randomly get settings from either, and some end up with the wrong gateway. Turn off DHCP on one of them.
• The 169.254 address. No reply from any server. Check cabling, Wi-Fi network, and whether the DHCP service is running.
• Duplicate address warnings. A device with a manually typed address inside the DHCP pool range. Move the static address outside the pool, or create a reservation instead.
• Pool exhaustion. Leases too long for the crowd, or the pool simply too small. Widen the range or shorten the lease, as in the café simulation.
• The printer keeps “disappearing.” It got a new address after a long power-off. Give it a reservation.
• Everything works by IP but not by name. The DHCP server handed out a bad DNS setting. Check the DNS option in the lease, not the website.

Common mistakes beginners make

• Thinking DHCP and DNS are the same thing. DHCP assigns addresses. DNS translates names into addresses. DHCP merely tells you which DNS server to use.
• Assuming a DHCP address is permanent. It is a lease. It often stays the same in practice, but nothing guarantees it.
• Setting a static address inside the DHCP pool. The server may hand the same address to someone else.
• Forgetting to exclude the router. The gateway itself should sit outside the dynamic range, typically at the start of the subnet.
• Using a 24-hour lease on a public Wi-Fi network. You now know how that ends.

Test yourself

Tap a question to reveal the answer. The correct option is marked.

Frequently asked questions

The post What Is DHCP? How Your Device Gets an IP Address Automatically appeared first on Learn With Examples.

The problem: always give me the most urgent thing

I have been writing and reviewing code for a little over fifteen years, and the same question comes back every couple of years in a new costume. A job scheduler needs the next job to run. A game server needs the next event to fire. A routing service needs the next closest intersection. Different industries, same shape: items arrive in any order, each carries a priority, and at any moment somebody asks for the single most important item.

The abstract name for this is a priority queue. It is a queue where the order of leaving is decided by priority, not by arrival. You need exactly three operations, and almost nothing else.

The three operations that matter

• insert(item, priority) adds a new item.
• peek() shows the most urgent item without removing it.
• extract() removes and returns the most urgent item.

That is the whole contract. How you store the items behind the scenes is your business, and the storage choice decides how fast each of those three runs. In this article, “most urgent” is just whichever end of the ordering you care about. Python’s standard library treats the smallest number as most urgent, so I will use that convention for the heap. For the sorted array I will keep the list in ascending order and call the highest number most urgent, which keeps removal cheap. The two structures can be flipped either way, and the cost is the same.

Where priority handling shows up in real life

Before we compare structures, it helps to see how often this pattern appears. Here are the ones I run into most.

• Hospital triage. A broken wrist waits, chest pain does not.
• Task and job schedulers. Run the highest-priority job whose time has come.
• Shortest-path routing. Dijkstra’s algorithm repeatedly asks for the closest unvisited place.
• Top-K tracking. Keep the ten best scores out of a stream of millions.
• Event simulation and timers. Always fire the event with the earliest timestamp next.
• Merging sorted logs. Pull the smallest head item from many sorted files.

We will return to each of these in the interactive panel later. For now, hold on to the hospital, because it makes the data-structure question concrete.

Why a plain queue or an unsorted list is not enough

Start with the two ideas everybody tries first.

Attempt 1: a normal queue

A normal queue serves first come, first served. That is fair at a bakery and a disaster at a hospital. The chest-pain patient who arrived last would wait behind everyone with a sprained ankle. A plain queue ignores priority entirely, so it cannot be the answer.

Attempt 2: an unsorted list

Throw items into a list in any order. Insertion is instant, you just append. But to find the most urgent item you have to scan the whole list, which costs O(n). With ten items that is nothing. With a million items and a million requests, you are doing about a trillion comparisons. The unsorted list moves all the cost to the extraction side.

So the real design question is where to spend your effort: at insertion time, at extraction time, or a little at each. That is exactly the difference between our two contenders.

Contender one: the sorted array

The idea is simple enough to explain to anyone. Keep the array sorted at all times. If the most urgent item is at one end, extraction is trivial. If you keep the array ascending and treat the largest as most urgent, the best item sits at the last position, and removing the last element of an array costs O(1). Peeking costs O(1) too.

Insertion is where you pay. To add a new item, you first find where it belongs. Because the array is sorted, you can use binary search and find the spot in O(log n) comparisons. That part is cheap. The expensive part is that everything after that spot has to slide one position to the right to make room. On average that is half the array.

Here is the whole thing in Python. It uses the bisect module, which does the binary search and the insertion for you.

from bisect import insort

class SortedPQ:
    """Highest number = most urgent. Kept in ascending order,
    so the most urgent item is always at the end of the list."""
    def __init__(self):
        self.a = []

    def push(self, x):
        insort(self.a, x)                 # binary search + shift: O(n)

    def pop(self):
        return self.a.pop()               # remove from the end: O(1)

    def peek(self):
        return self.a[-1]

That is nearly all of it. The simplicity is a real virtue, and I do not want to understate it. A sorted array is cache-friendly, easy to debug, easy to print, and the memory move that does the shifting is one of the most heavily optimised operations a computer knows. We will come back to that, because it changes the verdict for small data.

Contender two: the binary heap

A heap makes a different bargain. It refuses to keep everything sorted. It only promises one thing: every parent is at least as urgent as its children. That single rule guarantees the most urgent item is at the top, and it is much cheaper to maintain than a full ordering.

The clever part is how it is stored. A heap is conceptually a tree, but it lives in a plain array with no pointers at all. The tree is kept complete, filled level by level from left to right, so the position of every relative is just arithmetic:

• The parent of index i is at (i - 1) // 2.
• The children of index i are at 2i + 1 and 2i + 2.
• The root, the most urgent item, is at index 0.

Here is what happens if you insert 5, 3, 8, 1, 9 and 2 into a min-heap, one at a time. The array and the tree below are the same data seen two ways.

Notice that the array [1, 3, 2, 5, 9, 8] is not sorted. The 3 sits before the 2. A heap does not care. It only cares that the 1 at the top is the smallest and that each parent beats its children.

Inserting: sift up

To add an item, append it at the end of the array, which is the next free slot in the tree. Then compare it with its parent. If it is more urgent, swap them. Repeat until it is in a good place or reaches the root. The tree has about log₂(n) levels, so you do at most that many swaps. A million items means roughly twenty levels, not a million moves.

Removing: sift down

The top item is the one you want. Take it out, which leaves a hole at the root. Fill the hole by moving the last array element to the root, then let it sink: compare it with its two children, swap with the more urgent child, and repeat. Again at most about log₂(n) swaps.

The full implementation is short enough to read in one sitting. I wrote it by hand so you can see the mechanics, though in real projects you would reach for a library.

class MinHeap:
    def __init__(self):
        self.a = []                       # the heap lives in a plain list

    def push(self, x):
        a = self.a
        a.append(x)                       # 1. put it at the end
        i = len(a) - 1
        while i > 0:                      # 2. sift up while smaller than parent
            parent = (i - 1) // 2
            if a[i] >= a[parent]:
                break
            a[i], a[parent] = a[parent], a[i]
            i = parent

    def pop(self):
        a = self.a
        top = a[0]
        last = a.pop()                    # 1. remove the last item
        if a:
            a[0] = last                   # 2. move it to the root
            i, n = 0, len(a)
            while True:                   # 3. sift down
                left, right, small = 2 * i + 1, 2 * i + 2, i
                if left < n and a[left] < a[small]:
                    small = left
                if right < n and a[right] < a[small]:
                    small = right
                if small == i:
                    break
                a[i], a[small] = a[small], a[i]
                i = small
        return top

    def peek(self):
        return self.a[0]

Python ships the same idea in the heapq module, which operates on an ordinary list. Here it is running a small emergency-room queue, where a lower number means a sicker patient.

import heapq
from itertools import count

queue, tie = [], count()                  # tie-breaker keeps arrival order

def add(priority, name):
    heapq.heappush(queue, (priority, next(tie), name))

add(3, "Ana")
add(5, "Ben")
add(2, "Chi")
add(2, "Dev")
add(1, "Eli")

while queue:
    priority, _, name = heapq.heappop(queue)
    print(priority, name)

The output is, in order: Eli (1), Chi (2), Dev (2), Ana (3), Ben (5). Chi and Dev share priority 2 and come out in the order they arrived, thanks to the little counter in the tuple. That detail matters in production, and I will say more about it in the pitfalls section.

The complexity table

Here is how the common ways of building a priority queue compare. N is the number of items stored.

Read the table by asking which column your program hammers. If you insert once and then extract a million times, the sorted array looks great. If you interleave inserts and extracts all day, the heap’s O(log n) on both sides is the safer bet.

Counting the actual work

Big-O is a promise about growth, not a stopwatch. So I measured. In the experiment below, I generated n random priorities, inserted all of them, and then extracted everything. Instead of timing, I first counted the elementary moves, because counts are the same on every machine.

At a hundred thousand items, the sorted array shuffled about 2.5 billion elements while the heap made around 1.5 million swaps. That is a gap of roughly 1,600 times. Notice how the sorted array’s cost grows about a hundredfold every time n grows tenfold. That is the quadratic growth you would expect from n inserts that each cost O(n). The heap’s cost grows only a little faster than n itself.

Now the stopwatch, and an honest surprise

Counts are tidy, but you pay in seconds. I timed the same insert-everything-then-extract-everything test using the sorted array above against Python’s heapq. Timings depend on the machine, so treat the shape as the lesson and not the exact digits.

The gap opens exactly as theory says. At 100,000 items the sorted array needed about a second and the heap about 0.04 seconds. But look at the small end. At a thousand items both finish in well under a millisecond, and that points to something that surprises many people.

The reason is that shifting elements in a Python list is not a Python loop. It is a single memory-move operation written in C, and modern processors copy contiguous memory astonishingly fast. A heap, on the other hand, does a lot of small comparisons and swaps with a fair amount of overhead per step. When n is small, a very fast O(n) move can beat a slower O(log n) procedure.

To test this properly I ran a second experiment that looks more like a real service: a queue that stays at a steady size while 50,000 insert-then-extract pairs flow through it.

This is the part I most want you to take away. For queues holding a hundred or a thousand items, the sorted array was actually a little faster in my run. By ten thousand items the heap was already about twice as fast, and at a hundred thousand it was nearly thirty times faster. The crossover point depends on your language and hardware, but it is real, and it is usually somewhere in the low thousands.

The same idea in five real settings

Click a tab below to see how priority handling looks in different places. No page reload, nothing to install.

How to choose: a decision table

Building a heap in one go: heapify

There is a trick worth knowing. If you already have all n items, you do not need to insert them one by one, which would cost O(n log n). Python’s heapq.heapify(list) rearranges the list in place into a valid heap in O(n) time. It works by sifting down every non-leaf node, starting from the bottom, and the maths happens to add up to linear time because most nodes sit near the bottom where there is almost nothing to sift.

The practical rule: when you have the data up front, heapify. When it arrives over time, push one at a time. And if you are going to sort everything anyway, a plain sort is simpler still.

Pitfalls I have seen in production

1. Python’s heapq is a min-heap only

If you want the largest item first, negate the priorities when you push and negate them again when you pop. Forgetting this is a classic source of “why is my queue upside down?” bugs. Java’s PriorityQueue is also a min-heap by default, while C++’s std::priority_queue is a max-heap by default. The defaults differ across languages, so check before you trust.

2. Equal priorities have no guaranteed order

A heap is not stable. Two items with the same priority can come out in either order. If fairness matters, and in a job queue it nearly always does, add a tie-breaker such as an incrementing counter, as we did in the tuple earlier. Also be aware that if your items are not comparable (two dictionaries, say), Python raises an error when priorities tie. The counter in the middle of the tuple prevents that comparison from ever reaching the payload.

3. There is no cheap way to change a priority

Say a task becomes more urgent after it is queued. Finding an arbitrary item inside a heap takes O(n), because the heap only organises the top. The common workaround, used in Dijkstra implementations everywhere, is lazy deletion: push a new entry with the better priority, and when you pop a stale entry later, notice it is outdated and skip it.

4. A heap is not sorted

Printing the underlying list gives you something that looks almost sorted, which tempts people to iterate over it directly. Do not. The only guaranteed position is index 0. To get everything in order you must pop repeatedly, or just sort a copy.

5. Thread safety is on you

Neither structure is safe for concurrent writers. Wrap access in a lock, or use a purpose-built concurrent queue such as Python’s queue.PriorityQueue, which is a heap plus locking.

What the standard libraries give you

You will rarely write a heap by hand outside of an interview or a learning exercise. Python gives you heapq for lists and queue.PriorityQueue for threads. Java gives you PriorityQueue. C++ gives you std::priority_queue. JavaScript has no built-in priority queue, so people either write a small heap or pull in a package. All of these are heaps underneath. For a sorted array in Python, bisect is the standard tool, and the third-party sortedcontainers package offers a sorted list with much better insertion behaviour for large sizes.

Common mistakes when comparing the two

• Benchmarking only big inputs. You will miss the small-n region where the simple option wins.
• Benchmarking only small inputs. Your prototype works fine and then collapses on production data.
• Forgetting the workload mix. Insert-heavy, extract-heavy and balanced workloads can favour different structures.
• Using sort() in a loop. Re-sorting after every insertion is O(n log n) per insert. Insert with bisect or use a heap instead.
• Ignoring the tie rule. Equal priorities need a decision, not a surprise.

Test yourself

Tap a question to reveal the answer. The correct option is marked.

Frequently asked questions

The post Heap vs Sorted Array for Priority Handling appeared first on Learn With Examples.

Why this problem shows up everywhere

If you have ever sat through a software interview, you have probably met this question: “Design a data structure that follows a Least Recently Used cache.” It is a favourite of interviewers for good reason. It is short to state, it cannot be solved with a single built-in structure, and the solution reveals whether you understand how data structures complement each other.

But it is far more than an interview trick. I have used LRU caches to speed up image thumbnails, to keep recent database lookups in memory, and to throttle expensive API calls. The idea is so useful that it appears at almost every level of computing, from the cache inside your processor to the apps in your phone’s switcher.

In this article we will build an LRU cache from scratch. I will explain the idea with everyday examples, show why each simple approach fails, then assemble the real solution step by step with working code you can paste and run. There are diagrams, a traced example, a simulation comparing LRU with other policies, and a quiz.

What is a cache, and why does it need to forget?

A cache is a small, fast store that holds copies of things that are slow to get. If you read the same record from a database a thousand times, it makes sense to keep the answer in memory rather than asking the database again.

The catch is that fast storage is small. Memory is limited, so the cache must have a maximum size, called its capacity. Once it is full and a new item arrives, something has to go. Deciding what to remove is the job of the eviction policy.

Think of a small desk. You can keep ten books on it. Whenever you need an eleventh book, you must send one back to the shelf. Which one? You would probably return the book you have not touched for the longest time, because you are least likely to need it soon. That intuition is the entire LRU policy.

Eviction policies compared

LRU is not the only choice. Here are the common ones in plain words.

LRU strikes a very good balance. It is easy to explain, it adapts quickly to changing behaviour, and as we will see in a simulation, it beats FIFO and random eviction on realistic access patterns.

The job description: what our cache must do

We need a class with two operations:

• get(key) returns the stored value, or -1 if the key is not there. If it is there, it counts as a use.
• put(key, value) stores or updates a value. If the cache is already at capacity and the key is new, it first evicts the least recently used item.

And here is the demanding part: both operations must run in O(1) time, meaning constant time no matter how many items are cached. That requirement is what makes the problem interesting.

Why one data structure is not enough

Let us test the obvious ideas first, because the failures teach you the design.

Attempt 1: just a hash map

A hash map (a dictionary in Python, an object or Map in JavaScript) finds a value by key in constant time. Perfect for get. But a plain hash map has no useful notion of “least recently used.” When the cache is full, you would have to scan every entry to find the oldest. That makes eviction O(n).

Attempt 2: just a list or array

Keep items in an array, most recent at the front. Now the order is explicit and the least recent is always at the end. But finding a key means searching the array, which is O(n). And moving an item to the front means shifting the others. Both are slow.

The insight

The hash map is excellent at finding things and terrible at order. The list is excellent at order and terrible at finding things. So use both: the hash map finds the item instantly, and the list tracks order. To connect them, the hash map does not store values directly. It stores a pointer to the item’s node in the list.

Why a doubly linked list

A linked list is a chain of nodes where each node points to the next. In a singly linked list you can only move forward. A doubly linked list also keeps a pointer to the previous node.

That second pointer is the whole trick. When the hash map hands us a node in the middle of the list, we want to cut it out and move it to the front. Cutting out requires updating the previous node’s next pointer and the following node’s prev pointer. With a doubly linked list, the node already knows both neighbours, so removal takes a few assignments, with no searching. That is O(1).

We also add two dummy nodes, a head and a tail, that never hold data. They sit at the two ends so we never have to write special code for an empty list or for the first and last real node. This small habit eliminates a whole class of bugs.

Notice that the hash map keys (A, C, D) are in no particular order, and the lines cross. That is fine. The map only answers “where is this item?” The list answers “which item is oldest?”

The four moves

Every operation reduces to a handful of pointer moves.

Move 1: get on a hit

Look up the node through the map, unlink it from where it is, and insert it right after HEAD. Return its value.

Move 2: get on a miss

If the key is not in the map, return -1. The order does not change.

Move 3: put on an existing key

Update the stored value, then move the node to the front, because writing counts as a use.

Move 4: put on a new key

If the cache is full, remove the node just before TAIL, and delete its key from the map. Then create a new node, add it to the map, and insert it after HEAD.

The full Python implementation

Here is the whole thing. It is about fifty lines, and I have tested it against a second implementation on thousands of random operations.

class Node:
    __slots__ = ("key", "value", "prev", "next")

    def __init__(self, key=0, value=0):
        self.key = key
        self.value = value
        self.prev = None
        self.next = None


class LRUCache:
    def __init__(self, capacity):
        self.capacity = capacity
        self.map = {}                 # key -> Node
        self.head = Node()            # dummy node on the "most recent" side
        self.tail = Node()            # dummy node on the "least recent" side
        self.head.next = self.tail
        self.tail.prev = self.head

    def _remove(self, node):          # unlink a node from the list
        node.prev.next = node.next
        node.next.prev = node.prev

    def _add_front(self, node):       # insert right after head
        node.prev = self.head
        node.next = self.head.next
        self.head.next.prev = node
        self.head.next = node

    def get(self, key):
        node = self.map.get(key)
        if node is None:
            return -1
        self._remove(node)            # it was just used,
        self._add_front(node)         # so move it to the front
        return node.value

    def put(self, key, value):
        if self.capacity <= 0:
            return
        node = self.map.get(key)
        if node is not None:          # key exists: update and refresh
            node.value = value
            self._remove(node)
            self._add_front(node)
            return
        if len(self.map) >= self.capacity:
            lru = self.tail.prev      # least recently used node
            self._remove(lru)
            del self.map[lru.key]     # this is why nodes store their key
        node = Node(key, value)
        self.map[key] = node
        self._add_front(node)

    def order(self):                  # helper for demos: most recent first
        out, cur = [], self.head.next
        while cur is not self.tail:
            out.append(cur.key)
            cur = cur.next
        return out

Let us walk through the key details.

• Dummy head and tail: the real nodes always live between them, so _remove and _add_front never meet a null neighbour.
• _remove and _add_front: these two helpers do all the pointer surgery. Every public method is built from them, which keeps the code short and the bugs few.
• Storing the key in the node: when we evict the tail node, we only have the node in our hand. We need its key to delete the matching entry from the map. Forget this and the map slowly fills with stale entries.
• Order of operations in put: check for an existing key first, then evict if full, then insert. Mixing the order leads to evicting the very key you are about to update.
• Capacity guard: a capacity of zero or less simply stores nothing.

Tracing it by hand

Code is easier to trust when you have watched it work. Here is a run with capacity 3. The last column shows the list from most recent to least recent after each step. I generated this table by actually running the code above.

Look at step 5. The cache holds A, C, B with B at the back, so adding D evicts B. At step 6 we ask for B and get -1, because it was evicted. Step 7 updates C, and step 9 evicts A, which has not been touched since step 4. Every eviction was the item that had waited longest.

The shortcut: OrderedDict in Python

Python gives you a dictionary that remembers insertion order and can move items to the end in constant time. That means you can write an LRU cache in about fifteen lines.

from collections import OrderedDict

class LRUCache:
    def __init__(self, capacity):
        self.capacity = capacity
        self.data = OrderedDict()

    def get(self, key):
        if key not in self.data:
            return -1
        self.data.move_to_end(key)          # mark as most recently used
        return self.data[key]

    def put(self, key, value):
        if self.capacity <= 0:
            return
        if key in self.data:
            self.data.move_to_end(key)
        self.data[key] = value
        if len(self.data) > self.capacity:
            self.data.popitem(last=False)   # drop the oldest entry

This version is shorter, and in real projects it is usually the right choice. But in an interview, or when you want to understand the machinery, build the manual version first. Interviewers often use the OrderedDict version as a follow-up: “Great, now tell me how that works inside.” The answer is that it is a hash map plus a doubly linked list, exactly like ours.

There is also a ready-made option for caching function results. The functools.lru_cache decorator wraps a function and remembers its most recent calls, discarding the least recently used when it hits its limit.

The same idea in JavaScript

JavaScript’s Map remembers insertion order too. Delete and re-insert a key to make it the most recent, and the first key in the map is always the least recent.

class LRUCache {
  constructor(capacity) {
    this.capacity = capacity;
    this.map = new Map();               // Map remembers insertion order
  }
  get(key) {
    if (!this.map.has(key)) return -1;
    const value = this.map.get(key);
    this.map.delete(key);
    this.map.set(key, value);           // re-insert = most recent
    return value;
  }
  put(key, value) {
    if (this.capacity <= 0) return;
    if (this.map.has(key)) this.map.delete(key);
    this.map.set(key, value);
    if (this.map.size > this.capacity) {
      const oldest = this.map.keys().next().value;
      this.map.delete(oldest);          // first key = least recent
    }
  }
}

This is neat for small caches. For very large or very hot caches, a hand-built linked list can have better performance characteristics, since the delete-and-reinsert approach relies on the engine’s implementation details. For most web applications, this version is perfectly good.

Why it is O(1)

Every step is constant time, so get and put are O(1) on average. The memory cost is O(capacity), because we store at most that many nodes and map entries.

Where LRU caches live in the real world

Tap through five places you already rely on, each with the reasoning behind it.

maxmemory 100mb
maxmemory-policy allkeys-lru

from functools import lru_cache

@lru_cache(maxsize=128)
def get_rate(currency):
    ...  # slow work here

get_rate("USD")
print(get_rate.cache_info())

Notice how often real systems use an approximation of LRU. Perfect order tracking costs memory and time on every access, so engineers trade a little accuracy for a lot of speed. Understanding the exact version, which is what we built, is what lets you reason about those approximations.

Does LRU actually beat the alternatives? A simulation

Claims are cheap, so I ran an experiment. I generated 20,000 requests over 200 different keys, with some keys far more popular than others, which is how real traffic tends to behave. Then I replayed the same requests against LRU, FIFO and random eviction at four cache sizes.

LRU gets roughly four to six percentage points more hits than FIFO and random eviction at each size. That may sound modest, but remember what a hit means: a request answered from fast memory instead of a slow database or network call. Across millions of requests, those extra hits add up to real money and real seconds.

The result also shows something else: bigger caches help a lot. Going from 10 slots to 80 lifts LRU from about 32% to about 77%. Eviction policy matters, but capacity matters more.

When LRU fails

I would be misleading you if I presented LRU as perfect. It has two classic weaknesses, and knowing them is the mark of someone who has used caches in production.

The looping worst case

Suppose your cache holds 10 items and your program loops over 11 different keys, again and again. Every time you ask for a key, it has just been evicted, because it was the least recently used. The result: a hit rate of exactly 0%. I confirmed this by running it: with a loop of 11 keys and a capacity of 10, both LRU and FIFO miss on every single request after the first pass.

The big scan

Imagine a database that caches popular rows, and then someone runs a report that reads every row once. Each of those one-time reads enters the cache as the “most recently used” and pushes out the genuinely popular items, which are never used again by the scan. This is called cache pollution. Variants such as 2Q, LRU-K and ARC, or a midpoint-insertion scheme, exist specifically to resist it.

The lesson is not to avoid LRU. It is to know that no policy is best for every workload, and to measure your own traffic before deciding.

Testing your implementation

When I review an LRU cache, I look for these cases. They catch most bugs.

• Missing key: get on an empty cache returns -1.
• Capacity of one: every new put evicts the previous key.
• Update an existing key: the value changes, the size does not, and the key becomes most recent.
• Get refreshes recency: after a successful get, that key must survive the next eviction.
• Zero capacity: nothing is stored, and nothing crashes.
• Randomised comparison: run thousands of random operations against a trusted version, such as the OrderedDict one, and compare every result.

The randomised check is my favourite. It finds the strange edge cases you did not think to write by hand.

Six mistakes people make (tap to open)

Quick quiz: test yourself

Tap each question to reveal the answer and its reasoning.

Frequently asked questions

The post LRU Cache: Build One With a Hash Map and a Linked List appeared first on Learn With Examples.