LakeBench Review: Data Engineering Drills, Mock Rounds, and Free Access

LakeBench lets you inspect data-engineering problems and execute a public SQL drill before signing in. In our attempt, a wrong OR filter returned five rows, including a Sales employee; the corrected AND filter returned the four expected Engineering employees. Submitting either answer required sign-in. That makes the distinction between query execution and a saved correctness verdict central to this review.

Before opening another drill, try PracHub’s duplicate-key join question and write down what one output row represents. LakeBench can provide a workspace, but the grain of the business answer still needs your explanation.

Checked November 3, 2026: we separate official product claims, anonymous browser observations and original local SQL exercises. No account, paid pass or completed AI mock was used. Free allowances and feedback entitlements below are provider descriptions, not independently tested quotas. PracHub publishes interview-preparation content and is the publisher of this review.

What the public SQL task actually asked

We followed the public Studio entrance to problem lb-sql-01. The loaded task asked for Engineering employees whose salary exceeded 80,000. It required five columns—employee identifier, name, department, salary and hire date—and ordering by descending salary, then ascending employee identifier.

The workspace identified its SQL environment as DuckDB with ANSI SQL. The homepage’s animated example referred to a different paid-order scenario and a MySQL label. We reviewed the task that actually loaded rather than treating the homepage illustration as the executed environment.

Its six-row employee table made the filter error visible. Four Engineering employees met the threshold: Alice at 120,000, Dan at 110,000, and Bob and Eve at 95,000. Omar worked in Sales at 105,000. Max worked in Sales with a missing salary.

Replacing the required conjunction with OR admitted Omar. He satisfied the salary condition even though his department was wrong. The browser ran that query and displayed five rows. That is a useful negative control because the statement is valid SQL and the result looks plausible unless you check the department condition.

The corrected query was:

SELECT employee_id, name, department, salary, hire_date
FROM employees
WHERE department = 'Engineering'
  AND salary > 80000
ORDER BY salary DESC, employee_id ASC;

Run returned the four expected rows in identifier order 1,3,2,4. The tie between Bob and Eve made the secondary sort observable. The displayed expected table supported a manual comparison; we did not receive a completed accepted submission.

Run, expected output and Submit answer different questions

We clicked Submit with both the wrong and corrected queries. Each attempt opened a sign-in requirement explaining that an account was needed to submit the free problem and save the result. The page said the code would be kept through sign-in; we did not complete that transition or test its persistence claim.

A status reading “100%” appeared near the editor in both attempts. We did not identify its meaning and do not use it as a correctness score. A number that stays unchanged between an intentionally wrong query and a correction cannot, by itself, support an answer-quality claim.

Separate immediate execution from the saved history you want to review later. The public runner can help you test a hypothesis now. A saved submission history, enforced quota or generated debrief needs a separate account-side check. Do not treat the presence of those buttons as proof that you have evaluated the features behind them.

The next SQL mistake is often the join grain

A filter task is a reasonable first diagnostic, but data-engineering interviews also expose errors that produce reasonable totals from incorrect intermediate rows. The following exercise is ours, executed independently in local SQLite. It is not a LakeBench problem or a hidden-test reconstruction.

Assume one order worth 100, two shipment records for that order and two refund records worth 10 and 5. A raw join from orders to shipments and refunds produces four rows: each shipment pairs with each refund. Summing the order amount produces 400; summing refunds produces 30. Subtracting those totals produces 370, although the intended order-level net is 85.

The repair starts with the requirement: one output row per order, with all refunds subtracted once. Aggregate refunds by order before joining them to orders. If shipment existence is only a filter, use an existence check rather than multiplying the order by every shipment record.

WITH refund_totals AS (
  SELECT order_id, SUM(amount) AS refunded
  FROM refunds
  GROUP BY order_id
)
SELECT o.id,
       o.amount - COALESCE(r.refunded, 0) AS net_amount
FROM orders AS o
LEFT JOIN refund_totals AS r ON r.order_id = o.id;

Our independent fixture returned 85 for the single order. That local result checks the declared toy contract. It does not establish warehouse-scale performance, distributed execution or LakeBench’s judging behavior.

Explain missing values before choosing a shortcut

The employee task included a missing salary. SQL comparisons with a missing value do not behave like an ordinary known number comparison. The useful interview habit is to predict whether the row should survive the business rule, then check how the expression implements that policy.

In the order exercise, a missing refund aggregate has a different meaning. With no refund rows, the declared business contract treats the refund total as zero. That justifies COALESCE at the joined aggregate. It would not justify converting every missing monetary value in every source table to zero.

Suppose an order has a refund row whose amount is unknown. The absence of a refund and an unknown refund amount are different states. A production model may need a completeness flag or a separate exception queue. Collapsing both states to zero can hide the very record an analyst needs to investigate.

Add a new customer, a refund without an order, and a repeated source event to your local fixture. State whether each record is valid, excluded or an upstream quality failure. These are useful follow-ups because they connect query mechanics with data contracts and rerun behavior, rather than simply requiring more SQL syntax.

What LakeBench advertises beyond one drill

The homepage connects SQL, Pandas and PySpark practice with study material and mock interviews. The mock setup offered full interviews, concept drills and coding drills, with difficulty choices and topic areas including SQL warehouses, Python, PySpark, Airflow and Kafka.

The full-interview description presented seven connected questions taking about 45 minutes. Its free-access description included one timed round with AI feedback. Both are official claims about the product’s intended offering. We reached the sign-in boundary without recording a round, so we cannot assess follow-up quality, scoring consistency or whether a debrief diagnoses the actual cause of a mistake.

For a data engineer, the connected-question idea could be useful if the questions preserve a common scenario. A SQL answer might establish a business metric, a Python step might validate records, and a design discussion might explain retries. Whether LakeBench delivers that continuity well needs a completed-session review.

You can evaluate that promise with a narrow target: choose a scenario where one error has consequences across steps. For example, an order identifier used inconsistently in deduplication and revenue aggregation should trigger a follow-up about identity. Generic encouragement after both answers would provide weaker evidence of scenario-aware feedback.

Free access and paid passes require separate checks

The homepage pricing section described a free tier with unlimited Studio access, five AI hints per day, one mock, a notebook preview and saved-job limits. It also displayed 30-day and 90-day Pro passes, with discounted rupee prices and a one-time, nonrenewing presentation during our visit.

These are dated official descriptions. We did not buy a pass, exhaust hints or verify how “unlimited Studio” interacts with account-only submission. The public task showed that free access can still include a sign-in requirement for a particular action. Price and entitlement details should be rechecked on the selected plan before payment.

A useful purchase decision begins with an unmet need you can name. If you can already execute and manually verify SQL, a paid explanation feature would need to improve your reasoning or review process. If your weakness is speaking through a design failure, more browser queries may not address it. Match the entitlement to the missing practice loop.

Also ask what you can retain from the session. A saved answer, clear correction and follow-up prompt can support later revision. A total score without the offending row, incorrect assumption or changed requirement gives you less material to practice independently.

A practice flow that produces reviewable evidence

For your first drill, write the expected output before running anything. Include the output columns, row grain, sort order and treatment of missing values. Then make one intentional mistake whose effect you can predict. In our public attempt, replacing AND with OR created exactly that contrast.

After correcting the query, change the data. Equal salaries test tie ordering; duplicate dimension keys test multiplicity; a missing match tests join preservation. Use a small fixture where the answer can be calculated by hand. This gives you an oracle that remains useful even when the browser provides execution feedback alone.

When you move into Pandas or PySpark, preserve the same business contract. A different API should not quietly change which records count or whether duplicate keys multiply rows. Compare row identities before comparing totals. A matching grand total can conceal offsetting mistakes.

Finally, explain the limitation of your result. “This returns the expected four rows on the supplied table” is a defensible claim. “The pipeline is correct” requires evidence about source validity, repeated loads, late data and deployment behavior. Being precise about that boundary strengthens the answer rather than diminishing the work.

Access also varied during the review. Our native Studio and mock-setup visits worked, while later direct requests failed and a pricing-page navigation produced an SSL connection error. The homepage remained readable through a separate web reader. We retain the successful observations and these later failures; check that the practice route you need opens before planning a session around it.

Five PracHub questions to test transfer

These questions provide fresh join and data-contract problems outside LakeBench. They are independent practice destinations, with no claim of product integration or a guaranteed employer question set.

LakeBench’s public Studio was sufficient to demonstrate a filter mistake and its correction. To test whether that learning transfers, finish with the duplicate-key join prompt, predict the intermediate rows and defend the intended grain before executing the query. Evaluate mocks and saved judging only after you can observe those features directly.

Sources and further reading

• LakeBench: official practice and access descriptions
• LakeBench: public SQL Studio task
• LakeBench: mock formats and sign-in entrance