valon·Software Engineer·Technical Phone Screen·Intermediate

Intermediate

May 2026

Summary

Second part of a coding round at Valon for a software engineer role, focused on extending a SQL-like parser to handle IN clauses.

Questions Asked (1)

You've built a basic SQL SELECT parser. Now extend it to support IN clauses, like SELECT name IN xxx.

Algorithms & Data StructuresTechnical Trade-offs

Author's notes

This was a follow-up to whatever part one was, so I came in mid-flow.

Create a free account to read the full note

AI HintsAI Generated

Suggested Approach

Clarify the exact syntax and semantics of the IN clause (e.g., IN (value1, value2) or IN subquery) and discuss how it fits into the existing parser architecture. Then outline a step-by-step plan to extend the lexer, parser, and AST, emphasizing testing and edge cases.

Pro tip: Mention that you would first check if the existing parser uses a recursive descent or Pratt approach, as that determines how easily you can add IN as a postfix operator. Also, proactively discuss handling empty IN lists and NULL semantics, which shows depth.

1. Clarify requirements and syntax

Ask the interviewer to confirm the exact IN syntax (e.g., IN (1,2,3) vs IN subquery) and whether it can appear in WHERE, SELECT, or both. This avoids building the wrong feature.

2. Review existing parser architecture

Explain how the current parser is structured (lexer, parser, AST) and identify where IN fits—likely as a postfix operator after an expression. Discuss whether to extend the grammar or add a new node type.

3. Design the parsing logic

Describe how to parse the IN keyword, followed by a parenthesized list of expressions or a subquery. Handle comma-separated values and ensure proper precedence relative to other operators.

4. Implement AST and evaluation

Add an InExpression node to the AST that holds the left expression and a list of right expressions (or subquery). Explain how it would be evaluated (e.g., checking membership) and any optimizations.

5. Test and handle edge cases

Outline tests for valid and invalid syntax, empty lists, nested IN, and interaction with other clauses. Mention error handling for missing parentheses or trailing commas.

Key Points to Mention

Grammar extension: adding IN as a postfix operator with appropriate precedence
Lexer changes: tokenizing the IN keyword and handling parentheses and commas
AST design: creating a dedicated node for IN expressions to keep the tree clean
Evaluation strategy: short-circuit evaluation and handling NULLs (three-valued logic)
Edge cases: empty IN list, nested IN, IN with subquery, and error recovery
Testing: unit tests for parsing and evaluation, plus integration with existing queries

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