Question 1

What does it mean that strings are immutable, and what is the practical consequence?

Accepted Answer

Keep the definition + reason + consequence structure. Definition: once created, a string's content cannot change; every operation like replace, toUpperCase or + returns a new string and leaves the original alone. Reason: safe sharing (passing a reference means nobody can change it underneath you), a cacheable hash (which makes strings ideal hash-map keys), thread safety, and optimisations like interning. Practical consequence — the important part: concatenating with += in a loop is O(n²), because each step copies everything. So when building long text I collect pieces in an array and join in JS, use StringBuilder/buildString in Kotlin, and StringBuffer in Dart. If they ask "when does it not matter?": joining a handful of pieces is fine — O(n²) only bites when the loop length depends on the input.

Question 2

How would you reverse a string? What are the edge cases?

Accepted Answer

First ask questions — that behaviour is what interviewers are grading: can the input contain Unicode/emoji? Should it change in place or return a new string? Then describe the solution: since strings are immutable you cannot reverse in place — I convert to a character array, reverse it with two pointers (or the built-in reverse), and rebuild the string. O(n) time, O(n) space; the fact that space is not O(1) is a direct consequence of immutability and worth saying out loud. Edge cases: empty string and single character (return unchanged), whitespace-only input, and surrogate pairs — split('') cuts an emoji in half and corrupts the output; [...s] in JS and s.runes in Dart fix that. For the most precise answer, add that full correctness requires working at the grapheme cluster level (combining diacritics, flag emoji) — usually a job for a library. Be ready for the variant "reverse the word order" too: split(' ') → reverse → join(' '), minding extra whitespace.

Question 3

How do you check whether two strings are anagrams, and which solution do you choose?

Accepted Answer

Contrast the two solutions — that comparison is exactly what the interviewer wants to hear. Solution 1 (sorting): sort both strings and compare. Simple, a one-liner, but O(n log n) time and O(n) space. Solution 2 (frequency counting): accumulate the first string's character frequencies in a hash map (or a fixed-size array for a bounded alphabet), then decrement while walking the second; if any count goes negative or a character is missing, it's not an anagram. O(n) time, O(k) space where k is the alphabet size. The choice: the second, because it's linear. If the alphabet is just a-z, an IntArray(26) makes space effectively O(1) — mentioning that detail lands well. Edge cases and clarifying questions: differing lengths mean an immediate false (a free early exit); does case matter; do spaces and punctuation count ("listen/silent" vs "conversation/voices rant on"); and with Unicode you must count code points, not code units.

Question 4

How do you keep performance in mind when building large text?

Accepted Answer

Start with the problem: because strings are immutable, += in a loop copies everything at each step — O(n²). Building a 100,000-line report, that is the difference of seconds. Then list the fixes: Collect pieces, join once — parts.push(...) + parts.join('') in JS; StringBuilder/buildString in Kotlin; StringBuffer in Dart. All O(n). Avoid materialising at all where possible — if the result goes to a file or the network, write it in chunks/streams; there's no need to hold the whole text in memory. Avoid repeated substring work — substring/slice inside a loop allocates an O(k) copy; working with indices and slicing once at the end is cheaper. Pre-allocate when the size is known — StringBuilder(capacity) removes growth copying. Name the balance point too: this only matters when the loop length depends on the input. Concatenating three or four pieces with + is readable and fine — premature optimisation just complicates the code. Close with: "I measure first and optimise second; but accumulating strings in a loop is one of the cases worth fixing without measuring."

Question 5

What Unicode pitfalls do you watch out for when working with strings?

Accepted Answer

Separate the levels — the distinction itself signals maturity: bytes, code units (UTF-16 in JS and Dart), code points, and finally the grapheme clusters users actually see. Typical pitfalls: "👍".length === 2 — length counts code units, so length checks and character limits misbehave. split('') and index iteration split a surrogate pair and produce a broken character. Correct alternatives: [...s] or Intl.Segmenter in JS, s.runes in Dart, codePoints() in Kotlin. Locale-sensitive case conversion: in Azerbaijani and Turkish the i/İ and ı/I pairs come out wrong with a default toUpperCase() — you must pass a locale. Normalisation: identical-looking text can be encoded differently (precomposed ö vs o plus a combining diacritic). Normalise with normalize('NFC') before comparing, or === surprises you with false. Sorting: ordering by Unicode code point is not alphabetical order — use localeCompare or a Collator. End with a practical stance: "Code written on an ASCII assumption breaks the moment it meets real user data — so for name, address and search fields I plan for normalisation and locale-aware comparison from the start."

Problem	Approach	Time	Space
Reverse	Two pointers (start and end), or convert to a char array and reverse	O(n)	O(n) — a new buffer is needed since strings are immutable
Palindrome check	Two pointers moving toward the centre; no copy needed	O(n)	O(1)
Anagram check	Compare character frequencies (a map or a 26-slot array)	O(n)	O(k) — alphabet size
Anagram — the simple way	Sort both and compare	O(n log n)	O(n)
Character counting	Accumulate frequencies in a hash map in one pass	O(n)	O(k)
Longest substring without repeats	Sliding window + a `Set`/`Map`	O(n)	O(k)

Strings and immutability

📚 Sources and documentation