USA | Airtable Phone Screen
Summary
I recently completed a technical phone screen with Airtable in USA, where I was tasked with implementing robust undo/redo functionality for a custom Table class, which involved handling cell updates and extending to other structural operations.
Full Experience
I completed a technical phone screen for Airtable and wanted to share my experience. The interview kicked off with quick introductions, followed by a demo of a feature within an Airtable app. What truly stood out to me was the interviewer's approach to problem presentation; they provided essential product context before diving into the actual exercise, which I believe signifies a strong value for product thinking among their engineers.
The core of the exercise revolved around a Table class. This class was described as being internally represented as a '2D dict' (e.g., {row1: {col1: value1, col2: value2, ...}, row2: ....}) and came with row_ids and column_ids arrays. It also had several straightforward, pre-implemented functions like add_column, remove_column, add_row, remove_row, set_cell, get_cell, get_row_ids(), and get_column_ids(). My primary task was to implement undo() and redo() functions.
For the first iteration, I focused on implementing undo() and redo() specifically for the set_cell operation. A key constraint was that I couldn't add function parameters to undo() and redo(), which guided my design based on the product context. After discussing a couple of ideas with the interviewer, we aligned on using a diff history-like approach to optimize space complexity. I also wrote several test cases to verify the correctness of my implementation.
The second iteration was to extend undo() and redo() to cover other operations such as add_row, remove_row, add_column, and remove_column. Although I didn't get to fully implement this part, I was able to discuss my high-level thought process with the interviewer. I'm hopeful that my performance was enough to move forward.
Interview Questions (2)
You are provided with a Table class that manages spreadsheet-like grid components. The table is internally represented as a '2D dict' (e.g., {row1: {col1: value1, col2: value2, ...}, row2: ....}) and includes row_ids and column_ids arrays. The class has existing, functional methods:
add_columnremove_columnadd_row(row_id)remove_row(row_id)set_cell(row, col, value)get_cell(row, col)get_row_ids()get_column_ids()
Your task is to implement undo() and redo() functions. For this first iteration, these functions should specifically support the set_cell operation. You are not allowed to add function parameters to undo() and redo().
Example Test Case:
table = Table()
table.add_row("test_row")
table.add_column("test_col")
# Set initial value
table.set_cell("test_row", "test_col", "initial_value")
assert table.get_cell("test_row", "test_col") == "initial_value"
table.set_cell("test_row", "test_col", "changed_value")
assert table.get_cell("test_row", "test_col") == "changed_value"
table.undo()
assert table.get_cell("test_row", "test_col") == "initial_value", "Undo should revert to previous value"
table.redo()
assert table.get_cell("test_row", "test_col") == "changed_value", "Redo should restore the undone change"
Building upon the previous iteration, extend the undo() and redo() functionality to cover other table operations, including add_row, remove_row, add_column, and remove_column.
Preparation Tips
Before the interview, I consulted interview question databases to understand typical questions for Airtable phone screens, noting that some involved complex problems like 'implement connection pool with timeout'. Thankfully, my actual problem was more product-facing.
During the interview, I found these practices particularly helpful:
- Consistent Communication: Maintaining a clear and consistent channel of communication with the interviewer was crucial for staying on the same page.
- Confirming Requirements: I always made an effort to paraphrase the interviewer's requirements in my own words to ensure a shared understanding.
- Leveraging Existing Code: I focused on using as much of the provided existing code as possible, keeping my changes minimal to facilitate easier debugging. The interviewer specifically appreciated my approach of utilizing existing pieces rather than reinventing the wheel. Since the provided code was confirmed to work, my efforts were primarily directed towards the
undo()andredo()functions.