Are Encoding and Serialization Questions Still Asked in 2026?

As of 2026-10-26, TrueInterview's bank holds 38 candidate-reported encoding and serialization questions from 22 big-tech companies, and 36 of them were last reported within the previous 12 months. The topic is still asked. Our take: for experienced hires, the weight sits on durable-storage formats. The most-linked question in the topic is Durable Key-Value Store Serialization, and all 13 of its write-up links come from senior-or-above candidates. Prepare to defend a format's contract (its grammar, delimiter rule, version field and malformed-input policy) rather than only showing that a string survives a round trip.

Disclosure: TrueInterview is an interview-preparation product and publishes this article. Facts about other products come from their public pages on the dates listed under Sources.

Are encoding and serialization questions still asked in big tech interviews?

Yes, and mostly in phone screens. Phone-screen is the most reported round for these questions, ahead of onsite and the online assessment. If your calendar is tight, book at least one phone-screen practice block for encode-and-decode problems before any coding loop, because this is a live topic rather than a legacy one.

By company, the bank files 6 of these questions under Google, 4 each under OpenAI, Amazon, Databricks and Snowflake, 3 each under Stripe, Microsoft, Uber and Oracle, and 2 under Airbnb. Of the 38, 22 questions have a phone-screen report, 16 an onsite report and 5 an online-assessment report, and one question can appear in more than one round. By format, 30 are coding questions, 7 are object-oriented design and 1 is a multi-file repo task. Our take: the design share is the part generic prep lists miss, because a design question can grade a format you build as a class, which you cannot rehearse by memorising a traversal. These are candidate-reported questions reconstructed for practice, not any company's official question list.

What the most recent reports look like, month by month

The bank records when each question was last reported, not when it first appeared, so the table below is a recency view rather than a growth measure. These are recent dated examples, and durable-storage and tree formats sit alongside the string decoders.

Our take: string decoders appear across the whole period, so treat them as the floor. The rows that ask more of a senior candidate are the ones with structure that has to persist: an N-ary tree, an encoded tree you edit in place, and a key-value store written to disk. If you are senior, the onsite row from OpenAI is the one to plan around, and the phone-screen rows are the warm-up you should be able to finish with time to spare.

Which string encoders and compression questions open the loop?

Strings is the top algorithm tag across the 30 coding questions, with 12, followed by hashing with 5 and trees with 4. In the 20 coding questions reported for phone screens, strings still leads with 7, but trees (4) moves ahead of hashing (3). Start here, because these are the problems a phone screen is most likely to hand you, and each one teaches a framing rule you reuse later.

Encode and Decode Strings is the best single repetition in this group, because its length-prefix framing is the same idea a durable file format needs. Write each string as its length, a separator, then the raw characters, and the decoder never has to guess where a value ends, whatever characters the value contains.

String Compression rests on run-length encoding. Wikipedia's article describes runs being stored "as a single occurrence of that data value and a count of its consecutive occurrences". Wikipedia's article describes decoding as repeating each character the number of times its count gives. Wikipedia's article also warns that on input without runs, the encoding can make a file larger than the original. Before you code an OA compression question, ask whether the output must be shorter than the input and how counts above nine are written, since both rules change the loop.

Is Serialize and Deserialize Binary Tree still the serialization question to drill?

Not as your first pick. Serialize and Deserialize Binary Tree is filed under 6 companies in the bank, Apple, Amazon, ByteDance, Databricks, DoorDash and Microsoft, yet only 2 candidate write-ups link to it. Learn it as the base pattern in one evening, then spend the extra hours on the tree variants that recent reports name.

The variants are where the reports point. Uber's N-ary tree question, the October row in the table above, is the newest dated tree example we list. Pinterest's Tree-Encoded Subtree Deletion and Stable Compaction is linked from 3 write-ups, all by senior-or-above candidates. For the N-ary case, each node needs either a child count or an end-of-children marker, since a binary null marker no longer says where a child list stops. For the compaction question, the title pairs subtree deletion with stable compaction, so practise locating the token range a preorder subtree occupies in an encoding with null markers before you open it.

Whatever the tree, shape has to be explicit. PracHub's binary tree guide makes the point that "Values alone rarely preserve shape" because one preorder sequence can describe several trees. Our take: the classic still earns its evening because it trains null markers, but with 2 write-up links it trails both the Pinterest compaction question and the durable store, so a candidate who has only drilled it is under-prepared for the questions candidates link most.

Why does Durable Key-Value Store Serialization lead the senior reports?

It is the most-linked question in the topic, and it is filed under more companies than the binary tree classic: candidates from Airbnb, OpenAI and Databricks link it from 13 write-ups, and the bank files it under 9 companies. Those companies are OpenAI, Airbnb, Amazon, Databricks, Google, LinkedIn, Pinterest, Snapchat and Snowflake. If you are senior or above, practise it before the binary tree classic.

It was reported at an OpenAI onsite as an object-oriented design question, so prepare it as a design you defend rather than a traversal you recall. From its title, the task is to turn a key-value store into bytes that survive a restart. Prepare for follow-ups that test whether your format still works when the input is not the output of your own encoder.

The decisions to prepare before the round

Our take: two decisions are worth preparing most, as general engineering practice. The first is record framing: how a reader knows where a key or value ends. The second is evolution and damage: how a newer or older reader handles a file it did not write, and what happens to a record cut off by a crash.

PracHub's guide lists what a binary format has to pin down: "Binary formats need endianness, integer width, length bounds, and versioning." Protobuf's documentation is a useful reference point, since its wire format defines "how your message is sent on the wire and how much space it consumes on disk". Protobuf's documentation also puts variable-width integers at the core of that format, with a continuation bit in each byte saying whether the next byte belongs to the same number. Protobuf's documentation says its wire types let old parsers skip fields they do not understand, which is the property your version field should buy you.

Our take: pick a length prefix over escaping for this question. Escaping keeps the file readable, but every reader then has to scan byte by byte for the escape character, and binary values make the escape rules harder to state. A length prefix makes truncation easy to detect: if the declared length runs past the end of the file, the record is torn. Before you write code, say a one-paragraph spec aloud:

• a header with a format identifier and a version number;
• for each record, a fixed-width unsigned key length, the key bytes, a fixed-width value length and the value bytes, with the integer width and byte order stated;
• a maximum length per field, and the error you raise when a length exceeds it or runs past the end of the input;
• the rule for a torn last record: reject the file, or recover every complete record before it and say so.

Aim to name every branch before the interviewer asks, even if you only have time to code the main path.

Do ML engineers need the LLM decoding questions?

Only if your role is ML, AI or research. OpenAI's Compute the Distribution of LLM Decoding Stopping Time and Build a Strategy Against Adversaries is linked from 3 write-ups. That question and Debug a Transformer Implementation and Implement a KV Cache for Decoding are each linked by 3 machine-learning, AI, research or data-science candidates and by no software engineers.

Both items are also linked only by senior-or-above candidates, 3 each. Across the whole topic, most links come from software engineers: 52, against 8 from machine learning engineers, 3 from backend engineers, 1 from a research scientist and 1 from an AI engineer. Yet neither LLM decoding item has a single software-engineer link, which is the reason to leave them out of a software engineer's plan. If you are a software engineer, spend those hours on string encoders, tree encoders and durable serialization instead.

Our take: if you are an ML candidate, the KV-cache item is the one to rehearse in code. As general background inferred from the titles, not from the reports: during decoding, a KV cache stores each layer's past keys and values so a new token attends to them without recomputing the whole prefix, and the bugs worth checking for are a wrong position index, a missing causal mask and a cache that grows along the wrong axis. The stopping-time item is probability work: if a model ends a sequence at each step with some probability, the stopping step has a distribution you can compute step by step, and the adversary half of the title points to a game-style follow-up, so read the practice page before assuming its rules.

What do interviewers push on in a serialization answer?

Invertibility comes first. PracHub's guide puts it directly: "Binary tree serialization interview questions test whether your output is invertible." The encoders in the bank differ, but each is only correct if its decoder accepts exactly what the encoder can emit and rejects everything else, so build the same checks into each practice session.

The depth row is not theoretical. PracHub's guide notes that a very deep chain of nodes can exceed the language's recursion limit even when the serialization is valid. The same guide warns against claiming a format is more compact without comparing real encodings, and cites Python's documentation on pickle being unsafe for untrusted bytes.

Our take: malformed input is the test that separates candidates who finish with the same working encoder. A round trip on your own example is the minimum. Volunteer a truncated input, an empty string and a value containing the delimiter as well, because they are short to write and they show you planned for input you did not generate.

What changes at senior and staff level?

Senior-or-above candidates link these questions 38 times, against 27 links from junior, new-grad or intern candidates, based on the level each candidate reported. The questions linked only from senior-or-above write-ups are the design- and systems-flavoured ones: Durable Key-Value Store Serialization, Tree-Encoded Subtree Deletion and Stable Compaction, and both LLM decoding items.

The counts are small, but they point the same way. Decode String (k[encoded]) has no senior links, and Decode String splits evenly, so the bracket decoders are the warm-up layer at every level. The staff-plus links land on Encode And Decode, a Databricks onsite question, and on the Morse decoder, both of which reward stating a grammar before coding.

Our take: at senior level the interviewer is checking whether you treat the encoding as a persistent contract, with versioning, bounds and a malformed-input policy, and whether you can explain why each choice holds when the file outlives the process that wrote it. Flattening a tree correctly is assumed.

Where the level signal sits

Our take: the down-leveling risk is in the onsite design-flavoured question, not the phone screen. A clean Encode and Decode Strings solution shows you can code but not senior judgement. Answering Durable Key-Value Store Serialization as a puzzle, with a comma-joined string and no version field, risks reading as mid-level even when the code runs, so walk through the spec from the durable-storage section before you write code.

How we counted

Counts come from TrueInterview's question bank as of 2026-10-26 and cover candidate-reported questions reconstructed for practice, not any company's official list. A question can be filed under several companies and reported in more than one round, so company and round tallies overlap. Level and role splits count write-up links by the level and role each candidate reported, and a link count measures what candidates wrote up, not how often a company asks a question. The bank gives each question's last reported month rather than a monthly share of links, so the trend view above shows what recent reports contain, not a measured growth rate. Format rules and quotations come from PracHub's guide, Protobuf's documentation and Wikipedia's run-length encoding article.

FAQ

Which companies ask encoding and serialization questions?

Google, OpenAI, Amazon, Databricks and Snowflake lead the company counts above, and the list runs to 22 companies in all. Treat the table as a map of where candidates reported these questions, not as a forecast of your own loop. For a specific target, open that company's reports and check whether its questions are string decoders, tree encoders or the durable-storage design question, because each needs a different practice week.

What is the most common serialization interview question?

By write-up links, it is Durable Key-Value Store Serialization, well ahead of the binary tree classic. Our take: still learn Serialize and Deserialize Binary Tree as the base pattern, because it trains the null markers every tree encoder needs. If you only have time for one, choose by level: the binary tree problem for a junior phone screen, the durable store for a senior onsite.

Can you use pickle or Java serialization in an interview answer?

Avoid it as your answer, because the question is testing whether you can design the format yourself. PracHub's guide cites Python's pickle documentation warning that pickle is not secure for untrusted bytes, which is a good line to say aloud if the interviewer asks why. One author's Medium write-up on Java serialization interview questions describes an example where serializing a Serializable class that holds a non-Serializable field throws an exception at runtime. That is one write-up's example, so treat it as a reminder to name your format's limits.

Your practice plan

A three-week plan for someone working full time, at about an hour on weekdays and a longer session at weekends:

1. First week, weekdays: solve Encode and Decode Strings with a length prefix, then feed your decoder a value containing the separator, an empty string and a truncated input, and make it reject the malformed ones.
2. First week, weekend: solve Decode String, Decode String (k[encoded]) and String Compression, stating the grammar and the rule for multi-digit counts before each one.
3. Second week, weekdays: solve Serialize and Deserialize Binary Tree, then Serialize and Deserialize an N-ary Tree, adding a trailing-token check and an iterative version to each.
4. Second week, weekend: work through Tree-Encoded Subtree Deletion and Stable Compaction and Encode And Decode, writing the token-range rule or the format grammar on paper first.
5. Third week, weekdays: write the one-paragraph format spec from the durable-storage section, then code Durable Key-Value Store Serialization against it, including a torn last record and an over-length field.
6. Third week, weekend: if your role is ML, AI or research, add Debug a Transformer Implementation and Implement a KV Cache for Decoding and the LLM decoding stopping-time question. Otherwise, rerun the durable store timed and say each decision aloud. TrueInterview says its coding questions are judged on hidden tests that show the case you failed, so use the failures to find the malformed inputs you missed.

Sources

• TrueInterview question bank — encoding and serialization at big-tech companies — counted 2026-10-26
• Run-length encoding - Wikipedia — checked 2026-10-26
• Binary Tree Serialization Interview Questions: Null Markers, Parsing, and Validation | PracHub Knowledge Hub — checked 2026-10-26
• Encoding | Protocol Buffers Documentation — checked 2026-10-26
• Medium — checked 2026-10-26
• Interview prep compared: your application, end to end · TrueInterview — checked 2026-10-26

Last reviewed: 2026-10-26.