Write SQL queries against a real database, execute Python code, and write PySpark transformations. All in the browser. No local setup. AI grading gives line-by-line feedback on every submission, not a generic "correct/incorrect" verdict.
SQL database
Python execution
PySpark engine
Execution time
Most data engineering interview prep platforms work the same way. You read a question. You think about it. You click "Show Solution." You read the solution, nod, and move to the next question. Two weeks later, you sit in a real interview, and you can't write the query from scratch because you never actually wrote it.
Reading solutions is passive learning. Writing code is active learning. The difference matters enormously for interview performance. Research on skill acquisition consistently shows that active recall (writing code from memory) produces 2 to 3 times better retention than passive review (reading solutions). Your brain encodes the skill differently when your fingers are on the keyboard.
The second problem with "show solution" platforms is that they hide your mistakes. When you read a solution, you assume you would have gotten it right. But in practice, you would have forgotten the PARTITION BY clause, or used RANK instead of ROW_NUMBER, or missed the edge case where the previous month's revenue is zero. Running your code against a real database exposes every one of these gaps.
DataDriven takes the opposite approach. You write code. You run it. You see whether it works. The AI grader tells you exactly what you got wrong and why. This is how real interviews work: you write code on a shared screen, and the interviewer watches you debug in real time.
SQL is the most tested skill in data engineering interviews. 41% of all interview questions are SQL. When you practice on DataDriven, your queries run against a real database with actual data loaded into the tables. This is not pattern matching or string comparison. It is real query execution.
Why does this matter? Because keyword-based "grading" cannot tell the difference between a correct query and an incorrect one that happens to contain the right syntax. Consider this example:
Question: Find the top 3 products by revenue in each category
Common mistake (looks correct, produces wrong results):
SELECT category, product, revenue,
RANK() OVER (PARTITION BY category ORDER BY revenue DESC) AS rnk
FROM products
WHERE rnk <= 3; -- ERROR: can't reference window alias in WHERECorrect solution:
WITH ranked AS (
SELECT category, product, revenue,
DENSE_RANK() OVER (PARTITION BY category ORDER BY revenue DESC) AS rnk
FROM products
)
SELECT category, product, revenue
FROM ranked
WHERE rnk <= 3;A keyword-based grader might accept the first query because it contains RANK, OVER, PARTITION BY, and WHERE. But a real database rejects it because you can't reference a window function alias in the WHERE clause. You need a CTE or subquery. And RANK vs DENSE_RANK produces different results when there are ties. A real database catches both issues. A keyword grader catches neither.
On DataDriven, every SQL problem runs your query against a real database. The grader checks correctness across a range of edge cases: NULLs, duplicates, empty groups, and boundary values. If your query handles the simple case but mishandles NULLs, the grader flags it and explains exactly what went wrong.
The SQL editor includes syntax highlighting, auto-completion for table and column names, and keyboard shortcuts for running queries (Cmd+Enter or Ctrl+Enter). The schema panel on the left shows all tables, columns, and data types for the current problem. You can query any table to inspect the data before writing your solution. This mirrors the real interview experience, where you typically get access to the schema before the timer starts.
Python questions account for 35% of data engineering interviews. DataDriven runs your Python code in an isolated environment. Each run starts clean: no state from previous submissions, no lingering variables, no side effects. This isolation matters because it mimics the real interview environment, where you start from scratch.
The environment includes the libraries you would expect in a DE interview: pandas, numpy, collections, itertools, heapq, json, csv, re, datetime, and typing. You don't need to import standard library modules (they are available by default), but you can import them explicitly if you prefer.
Example: flatten nested JSON with approach feedback
def flatten_dict(d, parent_key="", sep="."):
items = []
for k, v in d.items():
new_key = f"{parent_key}{sep}{k}" if parent_key else k
if isinstance(v, dict):
items.extend(flatten_dict(v, new_key, sep).items())
else:
items.append((new_key, v))
return dict(items)AI Feedback
Correct for basic nesting. Two edge cases to address: (1) empty dicts should produce no keys, but your function handles this correctly because the for loop does not iterate. (2) What happens when a value is a list? Currently, lists are treated as leaf values and stored as-is. The interviewer may ask you to explode lists into separate rows or index-based keys (e.g., "tags.0", "tags.1"). Consider adding an isinstance(v, list) branch.
The Python grader does not just check whether your output matches the expected answer. It reviews your code for style, efficiency, and common pitfalls. If you write a nested loop where a dictionary lookup would be O(n) instead of O(n^2), the grader points it out. If you catch a bare Exception instead of a specific exception type, the grader flags it. These are the details that interviewers notice and that separate passing candidates from borderline ones.
Execution happens within 2 seconds for most problems. The 30-second timeout matches what you would encounter in a real coding interview. If your code times out, it usually means your solution has an algorithmic issue (e.g., O(n^2) when O(n) is possible), not that the system is slow. The grader provides specific feedback about why the timeout occurred and what optimization to consider.
Spark questions appear in senior DE roles and Spark-specific positions. Reading about Spark is not the same as writing Spark code and seeing how it behaves. The difference between repartition and coalesce is obvious in a textbook. But when you actually run both on a skewed dataset and observe the task distribution in the Spark UI, the lesson sticks.
DataDriven runs a real PySpark environment. The SparkSession is pre-configured. You write your transformation logic, run it, and see the output DataFrame. The environment supports DataFrame API operations, Spark SQL, window functions, UDFs, and Structured Streaming.
Example: sessionize clickstream data with PySpark
from pyspark.sql import functions as F
from pyspark.sql.window import Window
w = Window.partitionBy("user_id").orderBy("timestamp")
sessionized = (
events
.withColumn("prev_ts", F.lag("timestamp").over(w))
.withColumn(
"new_session",
F.when(
(F.col("timestamp").cast("long") - F.col("prev_ts").cast("long")) > 1800,
1
).otherwise(0)
)
.withColumn("session_id", F.sum("new_session").over(w))
)The Spark grader evaluates not just correctness but also approach quality. If you use a UDF where a built-in function would work (and be 10x faster), the grader calls it out. If you collect() a 10-million-row DataFrame to the driver when you should keep it distributed, the grader explains why that would fail in production. These performance-aware evaluations matter because Spark interviews specifically test your understanding of distributed processing trade-offs.
Generic "correct" or "incorrect" verdicts don't help you improve. You need to know what you got wrong and why. The DataDriven AI grader gives you detailed feedback on every submission.
Correctness. Your code runs for real. The grader checks whether your solution produces the right output across a range of edge cases. For SQL, you see exactly which cases passed and which failed. For Python, the grader validates your function's behavior across normal and edge case inputs.
Code review. The grader reads your code line by line. It identifies common mistakes: using GROUP BY without handling NULLs, writing a correlated subquery where a JOIN would be clearer, catching bare exceptions, using mutable default arguments, or missing edge cases in conditional logic. Each annotation references the specific line number and explains both the issue and the fix.
Interview assessment. Beyond correctness and code quality, the grader evaluates how your solution would land in a real interview. Did you choose the right approach for the problem? Did you handle edge cases proactively? Would an interviewer be able to follow your logic? Is your code production-quality or interview-sketch quality? This maps to the rubric that FAANG interviewers actually use: problem solving, coding quality, communication, and edge case awareness.
Example AI grader output for a SQL submission
Most interview prep platforms fall into three categories when it comes to code execution. Understanding the differences helps you choose where to invest your practice time.
Category 1: No execution at all. Many popular SQL interview sites show you a question and a "Reveal Solution" button. You read the solution, compare it to what you would have written, and move on. This is reading, not practicing. You would never prepare for a piano recital by reading sheet music without touching the keys. The same logic applies to coding interviews.
Category 2: Keyword-based grading. Some platforms let you write code, but they grade it by checking for the presence of specific keywords. If your query contains "ROW_NUMBER" and "PARTITION BY," it passes. This approach has a fundamental flaw: it cannot distinguish between a correct query and an incorrect one that uses the right syntax. A query that partitions by the wrong column, uses the wrong ordering, or misses a filter condition will pass keyword grading while producing completely wrong results.
Category 3: Real execution with basic test cases. A few platforms run your code against a single test case. If the output matches, you pass. This is better than keyword grading, but it misses edge cases. One test case won't catch NULL handling bugs, won't reveal off-by-one errors in window frames, and won't expose incorrect behavior when the input data has duplicates or empty groups.
DataDriven sits in a fourth category: real execution with multiple test cases, edge case data, and AI-powered code review. Your code runs against carefully designed test data that includes NULLs, duplicates, ties, empty groups, and boundary values. The AI grader reviews your code beyond just correctness. This combination means that when you pass a problem on DataDriven, you actually understand it. Not just at the surface level, but at the level of someone who could solve a variation of it in a real interview.
Interview performance is a skill, not knowledge. You can know what ROW_NUMBER does, know the syntax for window functions, and know the difference between RANK and DENSE_RANK. But if you haven't written these patterns dozens of times, you will be slow under pressure. Slow candidates fail interviews even when they know the material.
Running your code builds three types of muscle memory that reading solutions cannot.
Syntax fluency. After writing 40 window functions, you stop thinking about the syntax. PARTITION BY, ORDER BY, ROWS BETWEEN: these flow from your fingers automatically. In the interview, you spend your cognitive energy on the logic, not on remembering whether it's "OVER (PARTITION BY x ORDER BY y)" or "OVER (ORDER BY y PARTITION BY x)."
Debugging instinct. When your query returns 47 rows instead of 50, you develop an instinct for where to look. Is it a JOIN that dropped rows? A WHERE filter that excluded NULLs? A window function that produced duplicates? This debugging instinct only develops through practice. You can't build it by reading solutions.
Edge case awareness. After getting burned by NULLs in a GROUP BY three times, you start checking for NULLs proactively. After losing 10 minutes to a RANK vs ROW_NUMBER bug, you ask the interviewer about tie-handling before writing a single line. These habits come from making mistakes and fixing them. They don't come from reading about other people's mistakes.
This is why DataDriven's in-browser execution exists. Not because it's a nice feature. Because it is the difference between studying for an interview and training for one.
ROW_NUMBER, RANK, DENSE_RANK, LAG, LEAD, running totals, moving averages. 150+ problems.
Self-joins, anti-joins, recursive CTEs, multi-level CTEs with intermediate debugging. 120+ problems.
JSON parsing, file processing, pandas transformations, generators, decorators. 80+ problems.
Retry logic, rate limiting, schema validation, change detection, sessionization. 60+ problems.
DataFrame API, Spark SQL, window functions, UDFs, join strategies. 50+ problems.
Repartitioning, broadcast joins, skew handling, caching strategies. 30+ problems.
Real SQL. Real Python. Real Spark. AI grading that reviews your code like a senior engineer would. Every problem. Every submission.