← sesame Interview Insights

sesame·Software Engineer·Technical Phone Screen·Intermediate

Intermediate
May 2026

Summary

Sesame software engineering interview that went deep into low-level systems design pretty fast. The core problem was about an in-memory filesystem backed by fixed-size node arrays, and it escalated into a broader design conversation I wasn't fully ready for.

Questions Asked (3)

Q1

You have an in-memory filesystem stored as a list of fixed-size nodes, where each node is a fixed-size character array. Implement a print method that correctly traverses these nodes and outputs the full stored content.

Algorithms & Data StructuresSystem Design
Author's notes

The example they gave was two nodes like ['a','b','c','d','e','f','g','h'] and ['i','j','k','l','m','n','o','p'] so the output should be the full concatenated string.

Create a free account to read the full note

AI HintsAI Generated

Suggested Approach

First clarify the node structure and how content is stored (e.g., null-terminated strings, linked list, or array of nodes). Then design a traversal that iterates through each node, extracts the valid characters up to the null terminator or node boundary, and prints them in order. Consider edge cases like empty nodes, partial fills, and non-null-terminated nodes.

Pro tip: Demonstrate awareness of memory layout and performance: mention that you'd avoid unnecessary copying by printing directly from each node, and discuss how you'd handle nodes that are not null-terminated by tracking the valid length separately.

1. Clarify the data structure

Ask questions to understand how nodes are linked (array, linked list, etc.), whether each node is null-terminated, and if there is a separate length indicator. Confirm the expected output format.

2. Design the traversal

Plan an iteration over all nodes in order. For each node, determine the valid content: if null-terminated, print until null; otherwise, print the entire node or use a stored length.

3. Handle edge cases

Consider empty nodes, nodes with embedded nulls, non-null-terminated nodes, and the last node if partially filled. Decide how to avoid printing garbage characters.

4. Implement and test

Write the print method, ensuring it outputs the concatenated content correctly. Test with simple cases (single node, multiple nodes) and edge cases (empty, full, partial).

5. Discuss optimizations and trade-offs

Mention potential improvements like buffering output for fewer system calls, or using a single write if nodes are contiguous. Discuss time and space complexity.

Key Points to Mention

  • Node structure: fixed-size character array, possibly null-terminated or with separate length
  • Traversal order: sequential through nodes, likely linked list or array
  • Handling null terminators: stop at first null within a node, but continue to next node
  • Edge cases: empty nodes, non-null-terminated nodes, embedded nulls, last node partial fill
  • Performance: avoid unnecessary copying, consider buffering output
  • Testing: unit tests for various scenarios, including boundary conditions

AI-generated suggestions, not part of the candidate's original notes. May be inaccurate — verify before relying on them.

Q2

How do you handle file boundaries when files can start or end in the middle of a node, or span across multiple nodes?

System DesignTechnical Trade-offs
Author's notes

This is where it got tricky.

Create a free account to read the full note

AI HintsAI Generated

Suggested Approach

Start by clarifying the context—what system are we discussing (e.g., distributed file system, database, or log storage)? Then explain that file boundaries are handled by decoupling logical file boundaries from physical node boundaries, using metadata and indirection. Discuss trade-offs between approaches like chunking, replication, and indexing, and how to handle partial nodes and cross-node spans.

Pro tip: Mention that you would avoid splitting files across nodes unless necessary, and instead use a metadata layer to map logical offsets to physical locations—this simplifies recovery and consistency. Also, highlight that the choice depends on access patterns and consistency requirements.

1. Clarify the System and Constraints

Ask questions to understand the storage system, node architecture, and requirements (e.g., consistency, latency, throughput). This ensures your answer is tailored to the specific context.

2. Decouple Logical and Physical Boundaries

Explain that files are logical entities, while nodes are physical storage units. Use a metadata service to track which nodes hold which parts of a file, including partial nodes.

3. Handle Partial Nodes with Metadata and Indirection

For files starting or ending mid-node, store the exact byte range in metadata. Reads/writes use this metadata to locate the correct node and offset, possibly with a layer of indirection like a chunk map.

4. Manage Cross-Node Spans with Chunking and Replication

Split large files into fixed-size chunks (or blocks) that are distributed across nodes. Each chunk is stored on multiple nodes for fault tolerance, and a master node tracks chunk locations.

5. Discuss Trade-offs and Failure Handling

Compare approaches (e.g., chunking vs. whole-file storage) in terms of performance, complexity, and consistency. Explain how to handle node failures, rebalancing, and partial writes.

Key Points to Mention

  • Metadata management: central vs. distributed metadata, and how to keep it consistent.
  • Chunking/block storage: fixed-size vs. variable-size chunks, and their impact on performance.
  • Indirection layer: mapping logical file offsets to physical node locations.
  • Consistency and atomicity: ensuring reads/writes across nodes are consistent, especially during failures.
  • Fault tolerance: replication, erasure coding, and recovery from partial node failures.
  • Access patterns: how sequential vs. random access influences the design choice.

AI-generated suggestions, not part of the candidate's original notes. May be inaccurate — verify before relying on them.

Q3

How would you generalize this design to support read and write operations, not just printing?

System DesignTechnical Trade-offs
Author's notes

Honestly the part I felt weakest on.

Create a free account to read the full note

AI HintsAI Generated

Suggested Approach

First, clarify the current design and its limitations, then propose a generalized interface that abstracts read and write operations. Discuss how to extend the design while maintaining separation of concerns and handling trade-offs like consistency, concurrency, and performance.

Pro tip: Emphasize that generalization should not overcomplicate; start with a minimal viable abstraction and iterate based on requirements. Show awareness of real-world constraints like backward compatibility and incremental refactoring.

1. Clarify Current Design and Requirements

Ask questions to understand the existing design, its purpose, and what read/write operations entail. Identify specific use cases and non-functional requirements like latency, throughput, and consistency.

2. Define Generalized Interfaces

Propose abstract interfaces for read and write operations, such as Reader and Writer, with methods like read() and write(data). Ensure they are generic enough to support various data types and sources.

3. Address Key Trade-offs

Discuss trade-offs in generalization: e.g., simplicity vs. flexibility, performance overhead, error handling, and concurrency control. Explain how to balance these based on the context.

4. Outline Implementation Strategy

Describe how to refactor the existing design incrementally, perhaps using the Strategy pattern or dependency injection. Mention testing and validation to ensure correctness.

5. Summarize and Validate

Recap the proposed generalization, highlighting how it meets the requirements. Invite feedback and discuss potential extensions or edge cases.

Key Points to Mention

  • Abstraction of read/write operations into separate interfaces or classes
  • Use of design patterns like Strategy, Adapter, or Factory
  • Handling concurrency and thread safety for read/write operations
  • Error handling and fault tolerance in I/O operations
  • Performance considerations: buffering, batching, async I/O
  • Backward compatibility and incremental refactoring

AI-generated suggestions, not part of the candidate's original notes. May be inaccurate — verify before relying on them.