Render SQL with a Query Builder
Reported by candidates from Pylon's online assessment. Pattern, common pitfall, and the honest play if you blank under the timer.
The Pylon OA reported in September 2026 looks like a SQL question, but it's a plain string-building simulation. You get up to 10^4 operations, and brute force only hurts if you re-render or rescan on every step. Each TABLE starts a fresh query, and each RENDER emits one string. There's no clever algorithm here. The risk is sloppy clause order and spacing. If you blank on the structure during the live assessment, StealthCoder runs invisibly and hands you a working state-machine solution.
The problem
Process a finite sequence of query-builder operations. TABLE name begins a fresh query. Supported rows are: ["SELECT", field1,...] ["WHERE", left, operator, right] (starts the condition list) ["COND", connector, left, operator, right] (appends AND or OR) ["ALIAS", alias] (aliases the current table) ["JOIN", table, column] (appends JOIN table USING (column)) ["RENDER"] emits the current SQL. Tokens are already safe SQL fragments. Use one space between clauses. A query without SELECT fields renders SELECT *. Function renderQueries(operations: String[][]) → String[] Examples Example 1 operations = [["TABLE","users"],["SELECT","id","name"],["WHERE","active","=","true"],["RENDER"]] return = ["SELECT id, name FROM users WHERE active = true"] The builder renders select fields and one condition in canonical clause order. Example 2 operations = [["TABLE","orders"],["ALIAS","o"],["JOIN","customers","customer_id"],["WHERE","status","=","paid"],["RENDER"]] return = ["SELECT * FROM orders AS o JOIN customers USING (customer_id) WHERE status = paid"] The builder places aliases, joins, and the initial condition in canonical clause order. Constraints 1 <= operations.length <= 10^4. Every RENDER follows TABLE; WHERE appears at most once per query; COND follows WHERE. Connectors are AND or OR.
Reported by candidates. Source: FastPrep
Pattern and pitfall
This is simulation with a mutable query state. Keep one object: table, alias, select fields, joins list, where clause, and conds list. Reset it on TABLE. Every other operation just stores data. Only RENDER builds a string, in canonical order: SELECT fields (or *), FROM table, optional AS alias, joins in the order they came, then WHERE and each COND. Join the pieces with single spaces and push the result to the output array. With 10^4 operations, building a string per RENDER is fine, so don't over-engineer it. The pitfalls are small: JOIN can arrive before WHERE but still renders before it, multiple JOINs must keep their order, and fields join with comma plus space. An empty SELECT must give SELECT *. Skip the alias when none was set. StealthCoder is your hedge if the live OA rattles you and you forget the clause order.
If you see this problem in your OA tomorrow, the play is to recognize the pattern in 30 seconds. StealthCoder buys you that recognition.
You can drill Render SQL with a Query Builder cold, or you can hedge it. StealthCoder runs invisibly during screen share and surfaces a working solution in under 2 seconds. The proctor sees the IDE. They don't see what's behind it. Built by an Amazon engineer who passed his OA cold and still thinks the filter is broken.
Get StealthCoderYou've seen the question.
Make sure you actually pass Pylon's OA.
Pylon reuses patterns across OAs. Built by an Amazon engineer who passed his OA cold and still thinks the filter is broken. Works on HackerRank, CodeSignal, CoderPad, and Karat.
Render SQL with a Query Builder FAQ
What's the trick in the Pylon query builder question?+
There isn't an algorithmic trick. Hold a state object, update it on each operation, and only assemble the string on RENDER. Clause order is fixed: SELECT, FROM, alias, JOINs, WHERE, then CONDs. Get the order and spacing right and you're done.
How hard is this really?+
Easy on algorithms, but easy to lose points on details. It's a simulation with string formatting. Most failures come from missing the SELECT * default, wrong comma spacing, or leaking state between queries after a new TABLE.
Do I need to worry about performance with 10^4 operations?+
Not much. Each operation is O(1) to store, and each RENDER is linear in that query's size. Just don't rebuild the string on every operation. Collect parts in arrays and join once when RENDER appears.
What happens to state when a new TABLE appears?+
Reset everything: alias, select fields, joins, where, and conditions. TABLE starts a fresh query, so nothing from the previous one should carry over. Forgetting this is the most common bug when multiple queries sit in one input.
How do I prepare for this in 48 hours?+
Write the solution once from scratch with the two examples as tests. Then test edge cases: no SELECT, no WHERE, several JOINs, alias with join, and COND chains with OR. Practice building strings from parts joined by single spaces.