Loading…

mediumStringsLC #271Sometimes asked

Encode and Decode Strings

Q: How do you solve Encode and Decode Strings using the Single-Character Delimiter Join (Naive — breaks on the data) approach?

When to use it: Bring it up to expose the core trap, then show a concrete input that breaks it before moving to length-prefixing. The instinctive first attempt is to glue the strings together with a separator, e.g. `",".join(strs)`, and `split(",")` to decode. **Why it feels right.** It's a one-liner, it's fast, and it works on every test case you'd naively write — `["neet","code"]` round-trips cleanly through `"neet,code"`. **Why it's fundamentally broken.** The decode step assumes the separator never appears inside a string. But the data may contain *any* of the 256 ASCII characters — including your separator. Encode `["a,b", "c"]` with a comma and you get `"a,b,c"`; decode splits into `["a", "b", "c"]` — three strings, not two. People reach for an 'exotic' delimiter like `\x00` or `"#:#"` to dodge this, but that only narrows the failure, it doesn't remove it: the prompt explicitly allows every character, so any chosen delimiter can occur in the payload. **Why escaping is the wrong fix.** You *can* escape the delimiter (e.g. replace `#` with `\#` and `\` with `\\`), but now you've signed up for careful, bidirectional escape/unescape logic that's easy to get subtly wrong. Length-prefix framing sidesteps escaping entirely: by recording how long each string is, decode never has to interpret the payload at all. Time complexity: encode O(total chars), decode O(total chars). Space complexity: O(total chars).

Q: How do you solve Encode and Decode Strings using the Length-Prefix (Chunked) Encoding — len#str (Optimal) approach?

When to use it: The answer they want. Phrase it as 'prefix each string with its length so decode knows exactly how many characters to read'. Frame each string with its length: write `len(s)`, a separator `#`, then `s` itself. The encoded form of `["neet","code"]` is `"4#neet4#code"`. **Why the length makes the payload safe.** The breakthrough is that decode never has to *interpret* the string content. It reads the digits before the first `#` to learn the length `L`, then blindly consumes the next `L` characters as the string — whatever they are. If one of those `L` characters is itself a `#`, it doesn't matter, because we're counting characters, not scanning for a separator. The `#` is special *only* in the length header, and there it can't be confused with a digit. This is what the comma-join could never do. **Why we need the `#` at all.** The length is a variable number of digits (`5`, `42`, `100`...), so we need to know where the digits stop and the payload begins. The `#` is that boundary. We can't be confused by a `#` in the data because by construction the parser is reading digits until the *first* `#`, and digits can't be `#`. **Why the cursor math must be exact.** After reading a chunk that started at index `i` with its `#` at index `j`, the payload is `s[j+1 : j+1+L]` and the next chunk starts at `j + 1 + L`. An off-by-one here — say starting the next chunk at `j + L` — shifts every subsequent string and corrupts the whole decode. Walk this pointer arithmetic carefully. **Why empty strings just work.** `""` has length 0, so it encodes as `"0#"` — a header with no payload. Decode reads `0`, consumes zero characters, and correctly produces `""`. No special case needed, which is a sign the design is right. Time complexity: encode O(total chars), decode O(total chars). Space complexity: O(total chars).

LCPractice

Arrays & Hashing · 6 of 83 · 8 min

Design an algorithm to encode a list of strings to a single string. The encoded string is then sent over the network and is decoded back to the original list of strings.

Implement the encode and decode methods:

string encode(List strs) encodes a list of strings to a single string.
List decode(string s) decodes a single string back to the original list of strings.

You are not allowed to solve the problem using any serialization library functions (such as eval).

In plain English

Serialize a list of strings into ONE string so it can be perfectly reconstructed. The catch: each string may contain ANY character, so there is no character you can safely reserve as a separator. The fix is to record each string's length up front, so decode knows exactly how many characters to read and never has to interpret the payload.

Examples

Example 1

Input: strs = ["neet", "code", "love", "you"]
Output: "4#neet4#code4#love3#you"
Note: Each string is prefixed by its length and a '#'. Decode reads 4 → "neet", 4 → "code", and so on.

Example 2

Input: strs = ["we", "say", ":", "yes"]
Output: "2#we3#say1#:3#yes"
Note: The ':' is just a 1-char string — "1#:". No character is special in the payload.

Example 3

Input: strs = ["#3", ""]
Output: "2##30#"
Note: First chunk: length 2, '#', then payload "#3" — the embedded '#' is read as data because we already know to take 2 chars. Second chunk "0#" is the empty string.

Constraints

1 ≤ strs.length ≤ 200
0 ≤ strs[i].length ≤ 200
strs[i] contains any possible characters out of 256 valid ASCII characters
encode(decode(s)) must return the original list exactly (round-trip lossless)

Clarifying questions4First question: Can the strings contain any character, including digits, '#', or newlines?Explore questions

Q1.Can the strings contain any character, including digits, '#', or newlines?
Yes — all 256 ASCII characters are fair game. That's precisely why a plain delimiter fails and length-prefixing is required.
Q2.Can the list contain empty strings?
Yes. Length-prefix handles it for free: "" encodes as "0#" with zero payload characters.
Q3.Can the list itself be empty?
Possibly — encode returns "" and decode of "" returns an empty list. Worth confirming, though constraints here say length ≥ 1.
Q4.Am I allowed to use built-in serialization like JSON or eval?
No — the prompt forbids serialization libraries. You must design the framing yourself, which is the whole point.

Quick interview revision

Understand

30-second explanation

Build the interview-ready mental model before comparing implementations.

Don't join with a delimiter — any delimiter can appear inside the data. Use length-prefix framing: encode each string as `len(s) + '#' + s`. To decode, read digits up to the next `#` to get the length, then take exactly that many characters as the string. Because the length tells you precisely how far to jump, the `#` inside the data is never mistaken for a separator.

Interview contextWhat is testedWhere candidates slipHow to stand outExplore interview context

What's being tested

Whether you recognise that any single-character (or even multi-character) delimiter is unsafe because the data can contain it, and reach for length-prefix framing instead. It's a serialization-correctness problem disguised as string manipulation.

Where candidates slip

Joining with a 'rare' delimiter like a comma or a non-printable char and assuming the input won't contain it — it can, and decode silently splits in the wrong place.

How to stand out

Name the length-prefix pattern, show it handles empty strings and embedded delimiters, decode by parsing the length then slicing exactly that many chars, and connect it to real protocols (HTTP Content-Length, netstrings).

Choose

Compare the available approaches

Use constraints and trade-offs to select the route you can defend in an interview.

Approaches at a glanceCompare before you dive in

#	Approach	Time	Space	When to mention	Jump
1	Single-Character Delimiter Join (Naive — breaks on the data)	`encode O(total chars), decode O(total chars)`	`O(total chars)`	Bring it up to expose the core trap, then show a concrete input that breaks it before moving to length-prefixing.	Read
2	Length-Prefix (Chunked) Encoding — len#str (Optimal)Optimal	`encode O(total chars), decode O(total chars)`	`O(total chars)`	The answer they want. Phrase it as 'prefix each string with its length so decode knows exactly how many characters to read'.	Read

Interactive decision treeInteractiveChoose the right approachFollow the branches and learn why each constraint changes the solution.First decision previewSerialize a list of arbitrary stringsCan data contain your delimiter?No / guaranteed safeYes (256 ASCII)Explore the full tree

Learn & trace

Build each solution step by step

Move from the core idea to a visual trace, implementation, proof, and edge cases.

03.1

Approach 1 of 2

Single-Character Delimiter Join (Naive — breaks on the data)

Timeencode O(total chars), decode O(total chars)SpaceO(total chars)

Bring it up to expose the core trap, then show a concrete input that breaks it before moving to length-prefixing.

Stuck? Progressive hintsReveal one at a time

1Hint 1Explore hint

The simplest idea: join the strings with some separator character and split on it during decode.

2Hint 2Explore hint

Pick any separator — comma, space, even a 'rare' non-printable char. Now ask: what if a string in the list actually contains that character?

3Hint 3Explore hint

If the data can contain your separator, decode splits in the wrong place. With all 256 ASCII characters allowed, NO single character is safe.

A · Core idea

The instinctive first attempt is to glue the strings together with a separator, e.g. ",".join(strs), and split(",") to decode.

Why it feels right. It's a one-liner, it's fast, and it works on every test case you'd naively write — ["neet","code"] round-trips cleanly through "neet,code".

Why it's fundamentally broken. The decode step assumes the separator never appears inside a string. But the data may contain any of the 256 ASCII characters — including your separator. Encode ["a,b", "c"] with a comma and you get "a,b,c"; decode splits into ["a", "b", "c"] — three strings, not two. People reach for an 'exotic' delimiter like \x00 or "#:#" to dodge this, but that only narrows the failure, it doesn't remove it: the prompt explicitly allows every character, so any chosen delimiter can occur in the payload.

Why escaping is the wrong fix. You can escape the delimiter (e.g. replace # with \# and \ with \\), but now you've signed up for careful, bidirectional escape/unescape logic that's easy to get subtly wrong. Length-prefix framing sidesteps escaping entirely: by recording how long each string is, decode never has to interpret the payload at all.

B · Visual dry run

Interactive dry run

Select a frame to connect the decision with its visual state.

strs = ["a,b", "c"], delimiter = ','

encode

join with ',' → "a,b" + "," + "c"

Stateencoded = "a,b,c"

Final result["a", "b", "c"] — WRONG (should be ["a,b", "c"])

C · Code with teaching comments

Reference implementation previewpublic class Codec { public String encode(List<String> strs) { return String.join(",", strs); // unsafe: ',' may appear in the data } Explore the full code

solution.javaJava

Single-Character Delimiter Join (Naive — breaks on the data) — reference

2 teaching notes

1
public class Codec {
2
    public String encode(List<String> strs) {
3
        // Glues with a comma — but a comma inside any string becomes indistinguishable
4
        // from a boundary.
5
        return String.join(",", strs); // unsafe: ',' may appear in the data
6
    }
7
 
8
    public List<String> decode(String s) {
9
        // split treats every comma as a separator, including the ones that were part of
10
        // the data.
11
        return Arrays.asList(s.split(",")); // mis-splits on embedded commas
12
    }
13
}

Yellow row = the algorithm's core logic. Amber `//` lines above it = what you'd say out loud.13 lines

D · Why it works and complexityencode O(total chars), decode O(total chars) timeO(total chars) spaceOpen the invariant and proofExplore the proof

A delimiter scheme is only correct if the delimiter can never appear in the data — an assumption you almost never actually have. The robust alternative is to stop relying on a 'special' character and instead store the boundary information (the length) out-of-band in a header.

Complexityencode O(total chars), decode O(total chars) time, O(total chars) space — Joining and splitting both touch every character once → O(total chars) time and space. The cost isn't the problem — correctness is.

E · Edge cases and pitfalls5strs = ["", ""] — Join gives "," and split also struggles with trailing/empty fields — empty strings are another failure mode of naive delimiters.Explore edge cases

Edge cases handled

strs = ["", ""]Join gives "," and split also struggles with trailing/empty fields — empty strings are another failure mode of naive delimiters.
strs = ["a#b"] with '#' delimiterDecodes to ["a", "b"] — proof that even a 'rare' delimiter fails when it appears in the payload.

Pitfalls

Believing a 'rare' or non-printable delimiter is safe — the spec allows all 256 ASCII chars, so none is.
Trailing-delimiter ambiguity: "a," could mean ["a", ""] or ["a"] depending on split semantics.
Reaching for escaping to patch it — correct but fiddly; length-prefix avoids the whole problem.

03.2

Approach 2 of 2 · Optimal

Length-Prefix (Chunked) Encoding — len#str (Optimal)

Timeencode O(total chars), decode O(total chars)SpaceO(total chars)

The answer they want. Phrase it as 'prefix each string with its length so decode knows exactly how many characters to read'.

Stuck? Progressive hintsReveal one at a time

1Hint 1Explore hint

The problem with delimiters is not knowing where a string ends. What if you wrote down the length first?

2Hint 2Explore hint

Encode each string as length + a marker + the string itself, e.g. "4#neet". The marker only separates the length digits from the payload.

3Hint 3Explore hint

Decode: read digits up to the first '#' to get the length, then take exactly that many characters as the string — the embedded characters (even '#') are read as data, never as boundaries.

A · Core idea

Frame each string with its length: write len(s), a separator #, then s itself. The encoded form of ["neet","code"] is "4#neet4#code".

Why the length makes the payload safe. The breakthrough is that decode never has to interpret the string content. It reads the digits before the first # to learn the length L, then blindly consumes the next L characters as the string — whatever they are. If one of those L characters is itself a #, it doesn't matter, because we're counting characters, not scanning for a separator. The # is special only in the length header, and there it can't be confused with a digit. This is what the comma-join could never do.

Why we need the `#` at all. The length is a variable number of digits (5, 42, 100...), so we need to know where the digits stop and the payload begins. The # is that boundary. We can't be confused by a # in the data because by construction the parser is reading digits until the first #, and digits can't be #.

Why the cursor math must be exact. After reading a chunk that started at index i with its # at index j, the payload is s[j+1 : j+1+L] and the next chunk starts at j + 1 + L. An off-by-one here — say starting the next chunk at j + L — shifts every subsequent string and corrupts the whole decode. Walk this pointer arithmetic carefully.

Why empty strings just work. "" has length 0, so it encodes as "0#" — a header with no payload. Decode reads 0, consumes zero characters, and correctly produces "". No special case needed, which is a sign the design is right.

B · Visual dry run

Interactive dry run

Select a frame to connect the decision with its visual state.

decode("4#neet4#code")

Array state

read length 4

digits before '#' → 4; payload = next 4 chars

i ↓

[0]

# ↓

[1]

[2]

[3]

[4]

[5]

[6]

[7]

[8]

[9]

[10]

[11]

Current pointerResolved stateNot processed

Final result["neet", "code"]

C · Code with teaching comments

solution.javaJava

Length-Prefix (Chunked) Encoding — len#str (Optimal) — optimal

5 teaching notes

1
public class Codec {
2
    public String encode(List<String> strs) {
3
        StringBuilder sb = new StringBuilder();
4
        for (String s : strs) {
5
            // Each chunk = length header + '#' separator + raw payload. The length is
6
            // what makes decode unambiguous.
7
            sb.append(s.length()).append('#').append(s);
8
        }
9
        return sb.toString();
10
    }
11
 
12
    public List<String> decode(String s) {
13
        List<String> result = new ArrayList<>();
14
        int i = 0;
15
        while (i < s.length()) {
16
            int j = i;
17
            // Scan digits until the first '#' — these digits are the length; a '#' in
18
            // the payload is never reached here.
19
            while (s.charAt(j) != '#') {
20
                j++;
21
            }
22
            // Parse the header digits into the exact number of payload characters to
23
            // read.
24
            int length = Integer.parseInt(s.substring(i, j));
25
            // Take exactly `length` characters after the '#' — embedded '#'/digits are
26
            // read as data.
27
            String word = s.substring(j + 1, j + 1 + length);
28
            result.add(word);
29
            // Advance past this chunk; off-by-one here corrupts every following string.
30
            i = j + 1 + length;
31
        }
32
        return result;
33
    }
34
}

Yellow row = the algorithm's core logic. Amber `//` lines above it = what you'd say out loud.34 lines

D · Why it works and complexityencode O(total chars), decode O(total chars) timeO(total chars) spaceOpen the invariant and proofExplore the proof

Storing the length turns an ambiguous 'where does this end?' scan into an unambiguous 'jump exactly this far' move. That's the essence of length-prefix framing — the same trick HTTP uses with Content-Length and that netstrings and TCP use to delimit messages. Whenever a delimiter could collide with the data, prefix the length instead.

Complexityencode O(total chars), decode O(total chars) time, O(total chars) space — Encode appends a length header plus each string once → O(total chars). Decode scans left to right, reading each length then jumping exactly that many characters, touching every character a constant number of times → O(total chars). Extra space is the encoded buffer / output list, O(total chars).

E · Edge cases and pitfalls5strs = ["#3", ""] — Encodes to "2##30#". Decode reads length 2 → payload "#3" (the inner '#' is data), then length 0 → "". Proves embedded separators and empty strings both work.Explore edge cases

Edge cases handled

strs = ["#3", ""]Encodes to "2##30#". Decode reads length 2 → payload "#3" (the inner '#' is data), then length 0 → "". Proves embedded separators and empty strings both work.
strs = [""]Encodes to "0#"; decode reads length 0, slices zero chars → [""]. Empty string handled with no special case.

Pitfalls

Off-by-one on the cursor (i = j + length instead of j + 1 + length) — shifts and corrupts all following chunks.
Searching for the length's end with anything other than 'first # after the cursor' — a later '#' in the payload must not be used.
Assuming the separator must be absent from the data — it can be present; only the header '#' is interpreted.

Practice

Try the solution yourself

Edit the optimal implementation, test another input, and observe the result.

Editable code previewpublic class Codec { public String encode(List<String> strs) { StringBuilder sb = new StringBuilder(); for (String s : strs) { sb.append(s.length()).append('#').append(s);Explore the playground

Try it — Java· run a complete program; method snippets need a driver

Avoid mistakes

Recognize the interview traps

Understand why common attempts fail before reviewing the corrected implementation.

Trusting a 'safe' delimiter

No single character is safe when the data may contain all 256 ASCII characters. Even an exotic separator can appear in the payload and break decode.

Explore the code comparison

Don't write this

def encode(self, strs):
    return "\x00".join(strs)  # \x00 can still appear in the data

def decode(self, s):
    return s.split("\x00")

Write this instead

def encode(self, strs):
    return "".join(f"{len(s)}#{s}" for s in strs)  # length, not a delimiter, marks boundaries

Off-by-one when advancing the cursor

After reading the '#' at index j and a payload of length L, the next chunk starts at j+1+L. Using j+L (or j+1) leaves a stray character or eats one, corrupting every following string.

Explore the code comparison

Don't write this

String word = s.substring(j + 1, j + 1 + length);
result.add(word);
i = j + length; // WRONG — drops/duplicates a character

Write this instead

String word = s.substring(j + 1, j + 1 + length);
result.add(word);
i = j + 1 + length; // start exactly at the next header

Scanning for the length's end incorrectly

The length ends at the FIRST '#' after the cursor. If you scan for some other occurrence (or split on all '#'), a '#' inside the payload gets mistaken for the header boundary.

Explore the code comparison

Don't write this

j = s.rfind('#')        # WRONG — finds the last '#', not this chunk's header
length = int(s[i:j])

Write this instead

j = s.index('#', i)     # first '#' at/after the cursor is this chunk's header
length = int(s[i:j])

Revise

Carry the pattern into the interview

Quick interview revision

Pattern to remember

Length-prefixed (chunked) encoding — `len#payload`

Code pattern to memorize

encode: ''.join(str(len(s)) + '#' + s for s in strs)
decode:
  i = 0
  while i < len(s):
      j = s.index('#', i)
      length = int(s[i:j])
      word = s[j+1 : j+1+length]
      i = j + 1 + length

Rules to remember

1Prefix each string with its length and a separator (len#) — the length, not the separator, decides where the string ends.
2On decode, read digits until the first `#` to get the length, then consume exactly that many characters.
3The separator # is only meaningful in the length header; inside the payload it's just data.
4Handle the empty string naturally: 0# encodes "" with no payload bytes.
5Advance the cursor to `j + 1 + length` after each chunk — off-by-one here corrupts every following string.

Use this pattern when

Serialize a list of arbitrary strings into one string and recover it exactly
Data may contain ANY character, including your would-be delimiter
Designing a wire/file format where chunk boundaries must be unambiguous
Any 'pack many fields into one buffer, then split losslessly' task

Choose another pattern when

Strings are guaranteed delimiter-free → a simple split on that char is fine
Fixed-width fields → pad to a known width instead of length-prefixing
Only one string → no framing needed at all
You control both ends with a typed format (JSON/protobuf) → use that library

Interview takeaway

Length-prefix framing is the bulletproof way to serialize variable-length data: by storing how long each chunk is, you never have to guess where it ends, so no character is ever 'special' in the payload. It's the same idea behind HTTP Content-Length, netstrings, and TCP framing — once you see it, every 'delimiter breaks on the data' bug disappears.

Continue

Transfer the pattern to another problem

Use a direct variation or pattern sibling to prove the idea is reusable.

Transferable patternCanonical length-prefix (chunked) framing. Recognise it whenever you must serialize variable-length data that could contain any character: store each chunk's length so boundaries are unambiguous. Same idea as HTTP Content-Length, netstrings, and binary-tree serialization with markers.

Practice queueDirect variations and pattern siblings

Direct follow-ups

Serialize and Deserialize Binary Tree
Coming soon
Same serialization mindset — pick an unambiguous framing (preorder + null markers) so decode is lossless.
Encode and Decode TinyURL
Coming soon
Encoding for retrieval rather than framing — map long URL to a short key and back via a hash map.
String Compression
Coming soon
Also packs counts next to characters (run-length); related length-aware encoding idea.
Count and Say
Coming soon
Builds strings as count+character runs — another length-prefix-flavoured construction.

Same pattern

←

Product of Array Except Self

Continue · Next problem

Longest Consecutive Sequence

mediumStringsLC #271Sometimes asked

Encode and Decode Strings

LCPractice

Arrays & Hashing · 6 of 83 · 8 min

Design an algorithm to encode a list of strings to a single string. The encoded string is then sent over the network and is decoded back to the original list of strings.

Implement the encode and decode methods:

string encode(List strs) encodes a list of strings to a single string.
List decode(string s) decodes a single string back to the original list of strings.

You are not allowed to solve the problem using any serialization library functions (such as eval).

In plain English

Examples

Example 1

Input: strs = ["neet", "code", "love", "you"]
Output: "4#neet4#code4#love3#you"
Note: Each string is prefixed by its length and a '#'. Decode reads 4 → "neet", 4 → "code", and so on.

Example 2

Input: strs = ["we", "say", ":", "yes"]
Output: "2#we3#say1#:3#yes"
Note: The ':' is just a 1-char string — "1#:". No character is special in the payload.

Example 3

Input: strs = ["#3", ""]
Output: "2##30#"
Note: First chunk: length 2, '#', then payload "#3" — the embedded '#' is read as data because we already know to take 2 chars. Second chunk "0#" is the empty string.

Constraints

1 ≤ strs.length ≤ 200
0 ≤ strs[i].length ≤ 200
strs[i] contains any possible characters out of 256 valid ASCII characters
encode(decode(s)) must return the original list exactly (round-trip lossless)

Clarifying questions4First question: Can the strings contain any character, including digits, '#', or newlines?Explore questions

Q1.Can the strings contain any character, including digits, '#', or newlines?
Yes — all 256 ASCII characters are fair game. That's precisely why a plain delimiter fails and length-prefixing is required.
Q2.Can the list contain empty strings?
Yes. Length-prefix handles it for free: "" encodes as "0#" with zero payload characters.
Q3.Can the list itself be empty?
Possibly — encode returns "" and decode of "" returns an empty list. Worth confirming, though constraints here say length ≥ 1.
Q4.Am I allowed to use built-in serialization like JSON or eval?
No — the prompt forbids serialization libraries. You must design the framing yourself, which is the whole point.

Quick interview revision

Understand

30-second explanation

Build the interview-ready mental model before comparing implementations.

Interview contextWhat is testedWhere candidates slipHow to stand outExplore interview context

What's being tested

Where candidates slip

Joining with a 'rare' delimiter like a comma or a non-printable char and assuming the input won't contain it — it can, and decode silently splits in the wrong place.

How to stand out

Choose

Compare the available approaches

Use constraints and trade-offs to select the route you can defend in an interview.

Approaches at a glanceCompare before you dive in

#	Approach	Time	Space	When to mention	Jump
1	Single-Character Delimiter Join (Naive — breaks on the data)	`encode O(total chars), decode O(total chars)`	`O(total chars)`	Bring it up to expose the core trap, then show a concrete input that breaks it before moving to length-prefixing.	Read
2	Length-Prefix (Chunked) Encoding — len#str (Optimal)Optimal	`encode O(total chars), decode O(total chars)`	`O(total chars)`	The answer they want. Phrase it as 'prefix each string with its length so decode knows exactly how many characters to read'.	Read

Learn & trace

Build each solution step by step

Move from the core idea to a visual trace, implementation, proof, and edge cases.

03.1

Approach 1 of 2

Single-Character Delimiter Join (Naive — breaks on the data)

Timeencode O(total chars), decode O(total chars)SpaceO(total chars)

Bring it up to expose the core trap, then show a concrete input that breaks it before moving to length-prefixing.

Stuck? Progressive hintsReveal one at a time

1Hint 1Explore hint

The simplest idea: join the strings with some separator character and split on it during decode.

2Hint 2Explore hint

Pick any separator — comma, space, even a 'rare' non-printable char. Now ask: what if a string in the list actually contains that character?

3Hint 3Explore hint

If the data can contain your separator, decode splits in the wrong place. With all 256 ASCII characters allowed, NO single character is safe.

A · Core idea

The instinctive first attempt is to glue the strings together with a separator, e.g. ",".join(strs), and split(",") to decode.

Why it feels right. It's a one-liner, it's fast, and it works on every test case you'd naively write — ["neet","code"] round-trips cleanly through "neet,code".

B · Visual dry run

Interactive dry run

Select a frame to connect the decision with its visual state.

strs = ["a,b", "c"], delimiter = ','

encode

join with ',' → "a,b" + "," + "c"

Stateencoded = "a,b,c"

Final result["a", "b", "c"] — WRONG (should be ["a,b", "c"])

C · Code with teaching comments

Reference implementation previewpublic class Codec { public String encode(List<String> strs) { return String.join(",", strs); // unsafe: ',' may appear in the data } Explore the full code

solution.javaJava

Single-Character Delimiter Join (Naive — breaks on the data) — reference

2 teaching notes

1
public class Codec {
2
    public String encode(List<String> strs) {
3
        // Glues with a comma — but a comma inside any string becomes indistinguishable
4
        // from a boundary.
5
        return String.join(",", strs); // unsafe: ',' may appear in the data
6
    }
7
 
8
    public List<String> decode(String s) {
9
        // split treats every comma as a separator, including the ones that were part of
10
        // the data.
11
        return Arrays.asList(s.split(",")); // mis-splits on embedded commas
12
    }
13
}

Yellow row = the algorithm's core logic. Amber `//` lines above it = what you'd say out loud.13 lines

D · Why it works and complexityencode O(total chars), decode O(total chars) timeO(total chars) spaceOpen the invariant and proofExplore the proof

E · Edge cases and pitfalls5strs = ["", ""] — Join gives "," and split also struggles with trailing/empty fields — empty strings are another failure mode of naive delimiters.Explore edge cases

Edge cases handled

strs = ["", ""]Join gives "," and split also struggles with trailing/empty fields — empty strings are another failure mode of naive delimiters.
strs = ["a#b"] with '#' delimiterDecodes to ["a", "b"] — proof that even a 'rare' delimiter fails when it appears in the payload.

Pitfalls

Believing a 'rare' or non-printable delimiter is safe — the spec allows all 256 ASCII chars, so none is.
Trailing-delimiter ambiguity: "a," could mean ["a", ""] or ["a"] depending on split semantics.
Reaching for escaping to patch it — correct but fiddly; length-prefix avoids the whole problem.

03.2

Approach 2 of 2 · Optimal

Length-Prefix (Chunked) Encoding — len#str (Optimal)

Timeencode O(total chars), decode O(total chars)SpaceO(total chars)

The answer they want. Phrase it as 'prefix each string with its length so decode knows exactly how many characters to read'.

Stuck? Progressive hintsReveal one at a time

1Hint 1Explore hint

The problem with delimiters is not knowing where a string ends. What if you wrote down the length first?

2Hint 2Explore hint

Encode each string as length + a marker + the string itself, e.g. "4#neet". The marker only separates the length digits from the payload.

3Hint 3Explore hint

Decode: read digits up to the first '#' to get the length, then take exactly that many characters as the string — the embedded characters (even '#') are read as data, never as boundaries.

A · Core idea

Frame each string with its length: write len(s), a separator #, then s itself. The encoded form of ["neet","code"] is "4#neet4#code".

B · Visual dry run

Interactive dry run

Select a frame to connect the decision with its visual state.

decode("4#neet4#code")

Array state

read length 4

digits before '#' → 4; payload = next 4 chars

i ↓

[0]

# ↓

[1]

[2]

[3]

[4]

[5]

[6]

[7]

[8]

[9]

[10]

[11]

Current pointerResolved stateNot processed

Final result["neet", "code"]

C · Code with teaching comments

solution.javaJava

Length-Prefix (Chunked) Encoding — len#str (Optimal) — optimal

5 teaching notes

1
public class Codec {
2
    public String encode(List<String> strs) {
3
        StringBuilder sb = new StringBuilder();
4
        for (String s : strs) {
5
            // Each chunk = length header + '#' separator + raw payload. The length is
6
            // what makes decode unambiguous.
7
            sb.append(s.length()).append('#').append(s);
8
        }
9
        return sb.toString();
10
    }
11
 
12
    public List<String> decode(String s) {
13
        List<String> result = new ArrayList<>();
14
        int i = 0;
15
        while (i < s.length()) {
16
            int j = i;
17
            // Scan digits until the first '#' — these digits are the length; a '#' in
18
            // the payload is never reached here.
19
            while (s.charAt(j) != '#') {
20
                j++;
21
            }
22
            // Parse the header digits into the exact number of payload characters to
23
            // read.
24
            int length = Integer.parseInt(s.substring(i, j));
25
            // Take exactly `length` characters after the '#' — embedded '#'/digits are
26
            // read as data.
27
            String word = s.substring(j + 1, j + 1 + length);
28
            result.add(word);
29
            // Advance past this chunk; off-by-one here corrupts every following string.
30
            i = j + 1 + length;
31
        }
32
        return result;
33
    }
34
}

Yellow row = the algorithm's core logic. Amber `//` lines above it = what you'd say out loud.34 lines

D · Why it works and complexityencode O(total chars), decode O(total chars) timeO(total chars) spaceOpen the invariant and proofExplore the proof

Edge cases handled

strs = ["#3", ""]Encodes to "2##30#". Decode reads length 2 → payload "#3" (the inner '#' is data), then length 0 → "". Proves embedded separators and empty strings both work.
strs = [""]Encodes to "0#"; decode reads length 0, slices zero chars → [""]. Empty string handled with no special case.

Pitfalls

Off-by-one on the cursor (i = j + length instead of j + 1 + length) — shifts and corrupts all following chunks.
Searching for the length's end with anything other than 'first # after the cursor' — a later '#' in the payload must not be used.
Assuming the separator must be absent from the data — it can be present; only the header '#' is interpreted.

Practice

Try the solution yourself

Edit the optimal implementation, test another input, and observe the result.

Try it — Java· run a complete program; method snippets need a driver

Avoid mistakes

Recognize the interview traps

Understand why common attempts fail before reviewing the corrected implementation.

Trusting a 'safe' delimiter

No single character is safe when the data may contain all 256 ASCII characters. Even an exotic separator can appear in the payload and break decode.

Explore the code comparison

Don't write this

def encode(self, strs):
    return "\x00".join(strs)  # \x00 can still appear in the data

def decode(self, s):
    return s.split("\x00")

Write this instead

def encode(self, strs):
    return "".join(f"{len(s)}#{s}" for s in strs)  # length, not a delimiter, marks boundaries

Off-by-one when advancing the cursor

After reading the '#' at index j and a payload of length L, the next chunk starts at j+1+L. Using j+L (or j+1) leaves a stray character or eats one, corrupting every following string.

Explore the code comparison

Don't write this

String word = s.substring(j + 1, j + 1 + length);
result.add(word);
i = j + length; // WRONG — drops/duplicates a character

Write this instead

String word = s.substring(j + 1, j + 1 + length);
result.add(word);
i = j + 1 + length; // start exactly at the next header

Scanning for the length's end incorrectly

The length ends at the FIRST '#' after the cursor. If you scan for some other occurrence (or split on all '#'), a '#' inside the payload gets mistaken for the header boundary.

Explore the code comparison

Don't write this

j = s.rfind('#')        # WRONG — finds the last '#', not this chunk's header
length = int(s[i:j])

Write this instead

j = s.index('#', i)     # first '#' at/after the cursor is this chunk's header
length = int(s[i:j])

Revise

Carry the pattern into the interview

Quick interview revision

Pattern to remember

Length-prefixed (chunked) encoding — `len#payload`

Code pattern to memorize

encode: ''.join(str(len(s)) + '#' + s for s in strs)
decode:
  i = 0
  while i < len(s):
      j = s.index('#', i)
      length = int(s[i:j])
      word = s[j+1 : j+1+length]
      i = j + 1 + length

Rules to remember

1Prefix each string with its length and a separator (len#) — the length, not the separator, decides where the string ends.
2On decode, read digits until the first `#` to get the length, then consume exactly that many characters.
3The separator # is only meaningful in the length header; inside the payload it's just data.
4Handle the empty string naturally: 0# encodes "" with no payload bytes.
5Advance the cursor to `j + 1 + length` after each chunk — off-by-one here corrupts every following string.

Use this pattern when

Serialize a list of arbitrary strings into one string and recover it exactly
Data may contain ANY character, including your would-be delimiter
Designing a wire/file format where chunk boundaries must be unambiguous
Any 'pack many fields into one buffer, then split losslessly' task

Choose another pattern when

Strings are guaranteed delimiter-free → a simple split on that char is fine
Fixed-width fields → pad to a known width instead of length-prefixing
Only one string → no framing needed at all
You control both ends with a typed format (JSON/protobuf) → use that library

Interview takeaway

Continue

Transfer the pattern to another problem

Use a direct variation or pattern sibling to prove the idea is reusable.

Practice queueDirect variations and pattern siblings

Direct follow-ups

Serialize and Deserialize Binary Tree
Coming soon
Same serialization mindset — pick an unambiguous framing (preorder + null markers) so decode is lossless.
Encode and Decode TinyURL
Coming soon
Encoding for retrieval rather than framing — map long URL to a short key and back via a hash map.
String Compression
Coming soon
Also packs counts next to characters (run-length); related length-aware encoding idea.
Count and Say
Coming soon
Builds strings as count+character runs — another length-prefix-flavoured construction.

Same pattern

←

Product of Array Except Self

Continue · Next problem

Longest Consecutive Sequence