Lesson 6 of 30

Strings Are Arrays of Characters Underneath

Q: Explain why JavaScript strings are described as immutable, and how that connects to the way arrays are laid out in memory.

A strong answer covers: Describes a string as characters laid out side by side, the same shape as an array; Explains that immutable means a string can never be edited in place — any change builds a new string; Contrasts this with arrays, where an individual item genuinely can be updated in place.

A string is a row of characters sitting side by side, just like the array of boxes from the last lesson. That's why some string operations are slow, and why JavaScript strings can't be changed in place.

10 min read

Check your understanding

Every option explains itself — why the right one is right, and why each wrong one is wrong. Miss one and it comes back later on a spaced-repetition schedule.

No quiz for this one — it's a practical topic

This topic is about judgment and practical tradeoffs more than a single right answer — a mock interview is the better way to test yourself on it.

Be interviewed on this →

Stuck? Ask the AI tutor

Hints without spoilers, and a plain explanation of why a wrong answer was wrong — answered only from this lesson. Free account, no card.

Interview questions on Strings Are Arrays of Characters Underneath

What interviewers actually ask about this, and what a strong answer has to cover.

Explain why JavaScript strings are described as immutable, and how that connects to the way arrays are laid out in memory.

A strong answer covers

Describes a string as characters laid out side by side, the same shape as an array
Explains that immutable means a string can never be edited in place — any change builds a new string
Contrasts this with arrays, where an individual item genuinely can be updated in place

Likely follow-ups

Why might repeatedly gluing pieces onto a string inside a loop end up being costly?
Why is reading a single character from a string just as fast as reading a single item from an array?

Practice these with the AI interviewer →

The plain-language idea

Remember the library shelf from the last lesson — a row of numbered boxes sitting side by side? A string is that exact same picture, except each box holds one character instead of one book. "hello" is five boxes in a row: h, e, l, l, o, at spots 0 through 4.

Because it's the same shape as an array, strings inherit the same trade-offs. Reading a single character by position, like "hello"[1], is instant — a direct walk to spot #1, the same O(1) jump you saw with arrays. But building a longer string by repeatedly gluing smaller pieces onto it can turn slow for the same reason middle-inserts were slow on an array: under the hood, gluing on more characters can mean creating a brand new row of boxes and copying the old ones over, rather than just adding one box.

Here's the beginner surprise this lesson is named for: in JavaScript, strings are immutable, meaning once a string is created, it can never be changed in place — not even one character. Line up the boxes for "hello", and you cannot reach in and swap the h for a j. Instead, JavaScript creates an entirely new row of boxes for "jello" and points your variable at that new row. The old "hello" boxes still exist for a moment, unchanged, until nothing refers to them anymore.

This is different from arrays, where you genuinely can reach in and change one box (array[0] = "New Book" really does update that box in place). Strings don't offer that — every "change" to a string is secretly "build a whole new string."

See it in a real thing: reading vs. "changing" a string

const word = "hello";

// Reading one character by position is instant — same as an array.
console.log(word[1]); // "e"

// Strings are immutable: this can't change "hello" in place.
// In modern JS (strict mode), trying to write to a character throws.
try {
  word[0] = "j";
} catch (err) {
  console.log("can't edit a string in place"); // this line runs instead
}
console.log(word); // still "hello" — unchanged

// To get a different string, you build a brand new one instead.
const newWord = "j" + word.slice(1);
console.log(newWord); // "jello" — a completely separate row of boxes

What people usually miss

Watch out

They try to change a string character directly, like an array. word[0] = "j" can't update word in place — in modern JavaScript it throws, and in older sloppy-mode code it just silently does nothing. This trips up almost everyone once. The fix is building a new string with .slice(), template literals, or similar.
They think immutability is a bug or a limitation. It's a deliberate design choice. Because a string can never change after it's made, JavaScript can safely let many parts of your code share the exact same string in memory, without worrying that one of them might alter it underneath the others.
They assume all string operations are automatically slow. Reading one character by position is just as instant as reading one array item. It's specifically repeated building and rebuilding of strings that can add up.

The genealogy: where this leads

This lesson closes the loop on the "row of numbered boxes" picture from the arrays lesson — the same idea, applied to text instead of books. Together with Big O, the time-space trade-off, and the four common complexity patterns, you now have the core toolkit this whole track builds on.