JavaScript String Interview Questions

Are strings mutable in JavaScript?

No. Strings are primitives and immutable — every method that looks like it changes a string actually returns a new one, and the original is untouched. Assigning to an index silently does nothing in sloppy mode and throws in strict mode, which surprises people coming from languages with mutable character arrays.

The practical consequence is that building a string in a loop with `+=` creates a new string on every iteration. Modern engines optimise this heavily so it rarely matters in practice, but for very large concatenations pushing into an array and calling `join("")` once is the answer interviewers are looking for.

What are template literals and tagged templates?

Template literals are backtick strings with interpolation and real multi-line support, which removes the escaped-newline concatenation that used to litter JavaScript. The part fewer candidates know is tagged templates: put a function name before the backticks and it receives the literal string pieces and the interpolated values separately, letting it process them.

Tagged templates are worth a sentence even if you never write one, because they explain a library people use daily. When you write a styled-component, the CSS you type between backticks arrives at a function as an array of static chunks plus the interpolated values, which is how it can hash the result and inject a class. Being able to say that turns a syntax question into evidence you understand the ecosystem.

What is the difference between slice, substring and substr?

All three extract part of a string and none of them mutate it. `slice` is the one to use: it accepts negative indices that count from the end, and returns an empty string if the start is after the end. `substring` treats negative numbers as zero and silently swaps its arguments if they are the wrong way round — behaviour that hides bugs rather than surfacing them. `substr` takes a length instead of an end index and is deprecated.

There is one more member of this family worth knowing: `split` with a limit, and `at` for indexing from the end. `at(-1)` reads far better than `s[s.length - 1]` and works identically on arrays, which is the kind of small consistency that makes code easier to scan. None of these methods mutate, so they compose freely — chaining slice into replace into trim never surprises you.

How do you reverse a string?

The textbook answer is split, reverse, join. It is what the interviewer expects, and you should give it — but the follow-up worth having ready is that it is wrong for anything outside the Basic Multilingual Plane. `split("")` splits into UTF-16 code units, so an emoji or any character built from a surrogate pair gets torn in half and the output is mojibake.

Whether you should volunteer the Unicode caveat depends on the room. In a fast screening round, give the one-liner and move on. If the interviewer asks whether it always works, or the role involves user-generated content, that is the moment — a reverse that mangles emoji is a real production bug in any product with a comments field, and the fix is a single character change from `split("")` to a spread.

How do you check for a palindrome?

Normalise first, then compare. The naive one-liner reversing the whole string is fine and readable; the two-pointer version avoids allocating a second string and is what to reach for if the interviewer asks about memory. Say which one you are writing and why.

The normalisation step is where most palindrome answers fail rather than the reversal. Interviewers usually feed a sentence with punctuation and mixed case specifically to see whether you thought about it. Say what you are normalising and why — stripping non-alphanumerics and lowercasing — because a candidate who states the assumption is treated very differently from one who happens to handle it.

How do you check if two strings are anagrams?

Sorting both and comparing is the obvious answer and runs in O(n log n). The frequency-map version is O(n) and is what to offer as the optimisation — count characters up for the first string, down for the second, and check nothing is left over.

A useful extension to have ready is grouping anagrams: given a list of words, bucket them by their sorted letters. It reuses the same normalise-and-key idea, and it is a common follow-up because it moves the problem from comparing two strings to indexing many. Both versions above also assume the two inputs are the same alphabet — mentioning that you would decide how to treat spaces and case with the interviewer is a cheap way to show you gather requirements.

Which string methods should you actually know?

Interviewers rarely quiz the whole API, but they do expect fluency with the handful that appear in real code. Knowing which ones mutate is a trick question — none of them do.

• →includes, startsWith, endsWith — readable membership checks that replaced indexOf !== -1.
• →replace and replaceAll — replace only swaps the first match unless you pass a global regex; replaceAll always swaps every one.
• →trim, trimStart, trimEnd — whitespace only, and a frequent source of failed form validation.
• →padStart and padEnd — formatting timestamps and ids without a helper.
• →split and join — the pair behind most string manipulation.
• →at — accepts negative indices, unlike charAt.
• →localeCompare — the correct way to sort strings, especially with non-English characters.
• →normalize — collapses different Unicode representations of the same visible text.

One habit worth carrying into any string round: prefer the method whose name states the intent. `includes` over `indexOf !== -1`, `startsWith` over a slice comparison, `at(-1)` over arithmetic on length. It costs nothing, it removes a class of off-by-one mistakes, and reviewers read it faster — which is exactly the argument you would make on a real team.

How do you count character occurrences or find the first unique character?

Both are frequency-map problems and they come up constantly as warm-ups. Build the map in one pass, then answer the question in a second pass. Doing it in two passes rather than one nested loop is the whole point — it takes the solution from O(n²) to O(n).

A `Map` is the right container here rather than a plain object. Object keys are always strings, so a numeric character would be coerced, and an inherited property name like `constructor` can collide with the prototype and give you a count that was never there. `Map` accepts any key type, preserves insertion order, and reports its size directly, which is why it is the default choice for frequency counting in modern code.

How do you capitalise words or convert case?

A small prompt that tests whether you reach for a regex or a split. Both are acceptable; the regex version handles multiple spaces and punctuation more gracefully, which is worth pointing out.

Case conversion has a locale trap that is worth knowing about even though it rarely appears in interviews. `toUpperCase` on a Turkish dotless i produces the wrong letter unless you use `toLocaleUpperCase` with the right locale, and comparing case-insensitively by uppercasing both sides can therefore disagree with what a user expects. For anything user-facing, `localeCompare` with the `sensitivity` option is the safer tool.

The kebab and camel converters are also a neat demonstration of the replace callback. Passing a function as the second argument gives you the match and its capture groups, so you can transform rather than substitute a fixed string. That single feature covers most of the ad-hoc text munging people otherwise reach for a library to do.

How do strings compare, and what is string interning?

Strings compare by value with both `==` and `===`, so two separately built strings with the same characters are equal — unlike arrays and objects, which compare by reference. Relational operators compare code unit by code unit, which is why uppercase letters sort before lowercase ones and why `localeCompare` exists.