Introduction

The "read the last 100 bytes" interview question looks trivial until you clarify the constraints. The good answer is usually not about string slicing. It is about recognizing when random access is available, when the data may be streamed, and how to handle files smaller than the requested window.

The Simple Case: A Regular File

If the input is a normal file on disk and random access is allowed, the efficient solution is to seek near the end instead of reading the entire file.

1def last_n_bytes(path, n=100):
2    with open(path, "rb") as f:
3        f.seek(0, 2)
4        size = f.tell()
5        start = max(0, size - n)
6        f.seek(start)
7        return f.read()
8
9
10print(last_n_bytes("example.bin", 100))

This is usually the expected baseline answer. It runs in constant extra space and avoids scanning the whole file.

Why Interviewers Ask It

The question is often used to see whether you notice two things:

• the file may be much larger than memory,
• random access changes the solution completely.

If a candidate immediately says "read all bytes and slice the last 100," that works functionally but misses the efficiency point.

Handle Small Files Correctly

A real solution must work even when the file has fewer than 100 bytes. The max(0, size - n) calculation handles that case cleanly.

If the file is 37 bytes long, the correct answer is "return all 37 bytes," not "throw an error because there are not 100 bytes available."

Streams Are A Different Problem

If the source is not seekable, such as a network stream or stdin, you cannot jump backward from the end because there is no random access. In that scenario, the right answer is a fixed-size rolling buffer.

1from collections import deque
2
3
4def last_n_bytes_from_stream(stream, n=100, chunk_size=32):
5    buffer = deque(maxlen=n)
6
7    while True:
8        chunk = stream.read(chunk_size)
9        if not chunk:
10            break
11        buffer.extend(chunk)
12
13    return bytes(buffer)

This version stores only the last n bytes seen so far. It is the right approach when the stream is large or endless and you only learn the end when the producer closes it.

Ask Clarifying Questions

A strong interview answer usually starts with a few small clarifications:

• Is the input a regular file or a stream?
• May I use seek?
• Do we need bytes or decoded text?
• Can the file be larger than memory?
• What should happen if the file has fewer than 100 bytes?

This is not overthinking. It is how you avoid solving the wrong problem.

Bytes Versus Text Matters

Another subtle point is that the problem says bytes, not characters. If the file is UTF-8 text, the last 100 bytes may cut through a multi-byte character boundary.

If the requirement is truly bytes, that is acceptable. If the requirement is actually "last 100 characters," the implementation and edge cases are different.

That distinction is exactly the kind of thing an interviewer may want you to notice.

Complexity Discussion

For a seekable file:

• time complexity is proportional to the bytes read, not the full file size,
• extra space is proportional to the returned result.

For a non-seekable stream:

• time complexity is proportional to the whole input,
• extra space stays bounded by 100 bytes plus small overhead.

Talking through both versions shows that you understand the environment, not just one API call.

A More Complete Example

Here is a reusable function that handles seekable files and stream-like objects separately.

1def read_last_n(source, n=100):
2    if hasattr(source, "seek") and hasattr(source, "tell"):
3        current = source.tell()
4        source.seek(0, 2)
5        size = source.tell()
6        source.seek(max(0, size - n))
7        data = source.read()
8        source.seek(current)
9        return data
10
11    return last_n_bytes_from_stream(source, n=n)

That is more than most interviews require, but it demonstrates the design boundary clearly.

Common Pitfalls

• Reading the entire file when random access is available.
• Assuming the input is always seekable.
• Confusing bytes with characters in encoded text.
• Forgetting to handle files shorter than 100 bytes.
• Giving only code and never explaining the stream-versus-file tradeoff.

Summary

• For normal files, seek near the end and read only what you need.
• For streams, keep a fixed-size rolling buffer.
• Clarify whether the problem is about bytes or characters.
• Handle files shorter than the requested size without error.
• The best interview answer explains the constraints before jumping into code.