Implement an in-memory SQL-like table

Quick Overview

This question evaluates implementation-level skills for in-memory data structures and basic query processing, including projection, filtering, ordering, API design, input validation, and algorithmic efficiency.

Implement an in-memory SQL-like table

Company: Valon

Role: Software Engineer

Category: Coding & Algorithms

Difficulty: hard

Interview Round: Technical Screen

Implement a simplified in-memory SQL-like database for a single table. You should support the following operations on a table with a fixed schema (a list of column names). Each row is a mapping from column name to value (you may assume values are strings or integers and can be compared). Requirements: 1. **INSERT**: Insert a row providing a value for each column. 2. **SELECT with projection**: Return rows while selecting only a specified subset of column names (e.g., `SELECT colA, colC`). 3. **Filtering**: Support a `WHERE` clause that filters rows by a condition on a column (at minimum, equality like `colX = value`; if you choose, you may support additional comparisons). 4. **Ordering**: Support `ORDER BY <column>` (ascending; optionally support descending). Clarify/handle: - Invalid column names in SELECT/WHERE/ORDER BY. - Rows with missing columns (if disallowed, validate on insert). - Output format: a list of projected rows in the final order. Design an API (e.g., `insert(row)`, `select(columns, where_clause, order_by)` or parse SQL strings if preferred) and implement the functionality efficiently for typical interview constraints (up to tens or hundreds of thousands of rows).

Overview: This question evaluates implementation-level skills for in-memory data structures and basic query processing, including projection, filtering, ordering, API design, input validation, and algorithmic efficiency.

Valon logo
Valon
Feb 17, 2026
hardSoftware EngineerTechnical ScreenCoding & Algorithms
22
0

Implement a simplified in-memory SQL-like database for a single table.

You should support the following operations on a table with a fixed schema (a list of column names). Each row is a mapping from column name to value (you may assume values are strings or integers and can be compared).

Requirements:

  1. INSERT : Insert a row providing a value for each column.
  2. SELECT with projection : Return rows while selecting only a specified subset of column names (e.g., SELECT colA, colC ).
  3. Filtering : Support a WHERE clause that filters rows by a condition on a column (at minimum, equality like colX = value ; if you choose, you may support additional comparisons).
  4. Ordering : Support ORDER BY <column> (ascending; optionally support descending).

Clarify/handle:

  • Invalid column names in SELECT/WHERE/ORDER BY.
  • Rows with missing columns (if disallowed, validate on insert).
  • Output format: a list of projected rows in the final order.

Design an API (e.g., insert(row), select(columns, where_clause, order_by) or parse SQL strings if preferred) and implement the functionality efficiently for typical interview constraints (up to tens or hundreds of thousands of rows).