Airbnb·Software Engineer·Technical Phone Screen·Senior

SeniorPrefer not to say

Apr 2026Remote

Summary

Airbnb technical screen where they asked me to build a mini in-memory SQL engine from scratch. Open-ended enough that I spent the first ten minutes just figuring out what to actually build, which probably cost me.

Questions Asked (1)

Design and implement an in-memory SQL-like database from scratch, supporting CREATE TABLE, INSERT, SELECT with WHERE predicates, DELETE, and UPDATE. You decide what subset of expressions and parsing logic to support.

System DesignAlgorithms & Data StructuresTechnical Trade-offs

Author's notes

The scope thing is what gets you.

Create a free account to read the full note

AI HintsAI Generated

Suggested Approach

Start by clarifying requirements and scoping the subset of SQL to support, then outline a modular architecture (parser, planner/executor, storage engine). Walk through the design of each component, emphasizing data structures and trade-offs, and finish with a simple implementation sketch or pseudocode for core operations.

Pro tip: Proactively discuss how you would test and validate the database (e.g., unit tests for parser, integration tests for queries) and mention potential extensions like indexes or transactions to show depth and foresight.

1. Clarify requirements and scope

Ask clarifying questions to determine the exact SQL subset, data types, and constraints (e.g., support for NULL, primary keys). Define what 'in-memory' means and whether persistence is needed.

2. Design the architecture

Outline the main components: SQL parser (using a simple grammar or library), query planner/executor, and storage engine (e.g., hash maps for tables and rows). Explain how they interact.

3. Detail data structures and algorithms

Describe how tables, rows, and indexes are represented (e.g., list of dicts, B-trees). Explain how WHERE predicates are evaluated (e.g., expression tree) and how operations like INSERT, DELETE, UPDATE are implemented.

4. Discuss trade-offs and optimizations

Compare design choices: e.g., row vs column storage, indexing strategies, parsing approaches (hand-written vs parser generator). Mention performance considerations for large datasets.

5. Sketch implementation and testing

Provide pseudocode or a high-level code structure for key operations. Outline a testing strategy (unit tests for parser, integration tests for queries) and potential extensions.

Key Points to Mention

Choice of parsing technique (e.g., recursive descent, Pratt parser) and how to handle SQL grammar.
Data structures for tables and rows (e.g., hash map for tables, list of dictionaries for rows).
Expression evaluation for WHERE clauses (e.g., abstract syntax tree, visitor pattern).
Indexing strategies (e.g., hash indexes for equality, B-trees for range queries) and their impact on performance.
Transactionality and concurrency (even if not required, mention how you would handle it).
Testing approach: unit tests for parser, integration tests for end-to-end queries, and edge cases.

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