Linked Lists Explained: A Visual, Beginner-to-Expert Guide (Java & Kotlin)

A linked list is nothing more than boxes and arrows: a piece of data, and a note telling you where the next piece lives. That's it. Everything else in this guide is just consequences of that one idea. We'll build it up node by node, with a diagram for every move, from your first "what even is this" to writing cycle-detection code from memory.

FIG. 0 — a linked list is a chain of nodes, each one pointing to the next

Why not just use an array?

Before drawing a single node, it helps to know the problem a linked list is solving. Arrays are great — until you need to grow, shrink, or rearrange them a lot.

Array in memory

An array is one continuous block of memory. That makes reading element [i] instant — the computer just does math on the address. But inserting a new value in the middle means physically sliding every element after it over by one slot.

Linked list in memory

A linked list's nodes can live anywhere in memory. Nothing has to move when you insert — you just rewrite two arrows. The trade-off: to reach node 5, you must walk through nodes 1 through 4 first. There is no "jump straight to index i."

Anatomy of a single node

Every node is a tiny two-part container. Learn this shape and the rest of the guide is just this shape, repeated.

FIG. 1 — a node holds a value, and the address of whoever comes next

In code, that's a small class or struct with two fields. Nothing more.

Node — 2 fields

Java

class Node {
    int data;
    Node next; // reference to the next node, or null

    Node(int data) {
        this.data = data;
        this.next = null;
    }
}

Kotlin

class Node(var data: Int, var next: Node? = null)
// next is nullable — null means "nothing comes after me"

That's the entire vocabulary. A linked list itself is just a class that remembers where the chain starts:

LinkedList — the entry point

Java

class LinkedList {
    Node head; // the only thing we truly need to remember
    int size = 0;
}

Kotlin

class LinkedList {
    var head: Node? = null // the only thing we truly need to remember
    var size = 0
}

The singly linked list, assembled

Chain a few nodes together and you have a singly linked list — "singly" because each node only points forward, never back. There's no way to walk backward once you've stepped off a node.

FIG. 2 — head → 4 → 11 → 8 → NULL. Lose the head reference and the whole chain is unreachable.

Insert & delete: rewiring two arrows

This is the part that actually earns a linked list its keep. Every insert or delete is just: point the new arrow, then let go of the old one. Nothing shifts.

Insert at the head

Cheapest operation in the whole structure — O(1), no walking required.

before

after — new node 9 becomes the head

insertAtHead — O(1)

Java

void insertAtHead(int value) {
    Node newNode = new Node(value);
    newNode.next = head; // point forward into the old chain
    head = newNode;       // then move the door
    size++;
}

Kotlin

fun insertAtHead(value: Int) {
    val newNode = Node(value, next = head) // point forward into the old chain
    head = newNode                         // then move the door
    size++
}

Insert at the tail

You have to walk to the last node first — O(n) — then attach after it.

FIG. 3 — reaching the tail costs the walk; attaching itself is instant

insertAtTail — O(n)

Java

void insertAtTail(int value) {
    Node newNode = new Node(value);
    if (head == null) {
        head = newNode;
        size++;
        return;
    }
    Node current = head;
    while (current.next != null) { // walk until the last node
        current = current.next;
    }
    current.next = newNode; // attach after it
    size++;
}

Kotlin

fun insertAtTail(value: Int) {
    val newNode = Node(value)
    if (head == null) {
        head = newNode
        size++
        return
    }
    var current = head
    while (current?.next != null) { // walk until the last node
        current = current.next
    }
    current?.next = newNode // attach after it
    size++
}

Delete a node

Deleting isn't destruction — it's just skipping. Point the previous node's arrow past the one you're removing, and it quietly falls out of reach.

before — target: 11

after — the arrow leapfrogs it; 11 is now unreachable

delete — O(n)

Java

void delete(int value) {
    if (head == null) return;
    if (head.data == value) { // special case: removing the head
        head = head.next;
        size--;
        return;
    }
    Node current = head;
    while (current.next != null && current.next.data != value) {
        current = current.next;
    }
    if (current.next != null) {
        current.next = current.next.next; // leapfrog the target
        size--;
    }
}

Kotlin

fun delete(value: Int) {
    if (head == null) return
    if (head?.data == value) { // special case: removing the head
        head = head?.next
        size--
        return
    }
    var current = head
    while (current?.next != null && current.next?.data != value) {
        current = current.next
    }
    current?.next?.let {
        current.next = it.next // leapfrog the target
        size--
    }
}

Search & traverse

No shortcuts here — to find anything, you follow the arrows one at a time until you either find it or fall off the end.

contains / traverse — O(n)

Java

boolean contains(int value) {
    Node current = head;
    while (current != null) {
        if (current.data == value) return true;
        current = current.next; // step forward
    }
    return false;
}

void printAll() {
    Node current = head;
    while (current != null) {
        System.out.print(current.data + " -> ");
        current = current.next;
    }
    System.out.println("NULL");
}

Kotlin

fun contains(value: Int): Boolean {
    var current = head
    while (current != null) {
        if (current.data == value) return true
        current = current.next // step forward
    }
    return false
}

fun printAll() {
    var current = head
    val sb = StringBuilder()
    while (current != null) {
        sb.append(current.data).append(" -> ")
        current = current.next
    }
    println(sb.append("NULL"))
}

This is the pattern behind almost every linked-list function you'll ever write: current = head, loop while current != null, step with current = current.next. Memorize that shape and the rest is details.

Doubly linked lists

Give every node a second arrow pointing backward, and you can walk the list in either direction — at the cost of one extra pointer to keep correct on every operation.

FIG. 4 — two arrows per node: next and prev

DoublyNode — 3 fields

Java

class DoublyNode {
    int data;
    DoublyNode next;
    DoublyNode prev;

    DoublyNode(int data) {
        this.data = data;
    }
}

Kotlin

class DoublyNode(
    var data: Int,
    var next: DoublyNode? = null,
    var prev: DoublyNode? = null
)

Circular linked lists

Take the last node's arrow and, instead of pointing to NULL, point it back to the head. Now there's no end — just a loop.

FIG. 5 — the last node's arrow (in orange) loops back to the first

Handy anywhere something repeats in a cycle with no natural "end": a music playlist on repeat, round-robin CPU scheduling, or a multiplayer game rotating through players' turns.

The cost sheet

Same operations, four structures. This table is the one thing worth memorizing before an interview.

* amortized, assumes room at the end. ** when a tail reference is kept.

Where this actually shows up

Not just an interview topic — you're using linked lists constantly without noticing.

Practice problems

These three questions cover most of what actually gets asked. Try each one on paper before opening the answer.

Node reverse(Node head) {
    Node prev = null;
    Node current = head;
    while (current != null) {
        Node next = current.next; // save before we overwrite it
        current.next = prev;      // flip the arrow
        prev = current;
        current = next;
    }
    return prev; // prev is now the new head
}

fun reverse(head: Node?): Node? {
    var prev: Node? = null
    var current = head
    while (current != null) {
        val next = current.next // save before we overwrite it
        current.next = prev     // flip the arrow
        prev = current
        current = next
    }
    return prev // prev is now the new head
}

boolean hasCycle(Node head) {
    Node slow = head, fast = head;
    while (fast != null && fast.next != null) {
        slow = slow.next;
        fast = fast.next.next;
        if (slow == fast) return true; // they lapped each other
    }
    return false;
}

fun hasCycle(head: Node?): Boolean {
    var slow = head
    var fast = head
    while (fast?.next != null) {
        slow = slow?.next
        fast = fast.next?.next
        if (slow === fast) return true // they lapped each other
    }
    return false
}

Node findMiddle(Node head) {
    Node slow = head, fast = head;
    while (fast != null && fast.next != null) {
        slow = slow.next;
        fast = fast.next.next;
    }
    return slow; // standing at the midpoint
}

fun findMiddle(head: Node?): Node? {
    var slow = head
    var fast = head
    while (fast?.next != null) {
        slow = slow?.next
        fast = fast.next?.next
    }
    return slow // standing at the midpoint
}

Expert notes: what the diagrams don't show

Everything above is correct, and also slightly idealized. Here's what changes once you're optimizing for real hardware.