250+ Python questions focused on data manipulation, ETL logic, and file parsing. Your code actually runs with pandas, numpy, and the full standard library. AI grading evaluates correctness, code quality, edge case handling, and Pythonic patterns.
If you've been grinding LeetCode to prepare for a data engineering Python round, you're studying the wrong material. DE Python interviews don't test binary search, dynamic programming, or graph traversal. They test whether you can clean a messy CSV, call a paginated API, and write an ETL function that handles errors without crashing. The skillset overlap between LeetCode and DE Python interviews is roughly 15%.
SWE interviews give you clean, well-defined inputs. DE interviews give you a JSON file where some records are missing fields, some dates are in ISO format and others are in US format, and one value is the string 'null' instead of actual null. The test isn't whether you can write the algorithm. The test is whether you can handle the mess. DataDriven's Python questions replicate this messiness with intentionally dirty test data.
In a SWE interview, you might mention error handling and move on. In a DE interview, the interviewer asks: what happens when this API returns a 500? What happens when the file is empty? What happens when a field is missing? You're expected to write the try/except blocks, implement retry logic, and log the error with enough context to debug at 3am. DataDriven's grader explicitly checks for error handling in every Python question.
DataDriven executes your Python code in a real environment with pandas, numpy, and the full standard library. This matters because it means your imports work, your file I/O works, and your code runs the same way it would in a real pipeline environment. Platforms that simulate Python execution or restrict imports don't prepare you for the actual tools you'll use.
| Dimension | Data Engineering | Software Engineering |
|---|---|---|
| Problem type | Data transformation, ETL, file processing, API extraction | Algorithms, data structures, system design |
| Core skill tested | Handling messy data, edge cases, idempotency, resilience | Time/space complexity, algorithm selection, OOP design |
| Code evaluation | Does it produce correct output from messy input? Is it maintainable? | Does it pass all test cases? What's the Big O? |
| Libraries expected | pandas, json, csv, requests, datetime, os, re | Standard library only (no external packages) |
| Error handling emphasis | Critical. Pipelines run unattended. Errors must be caught and logged. | Moderate. Focus is on correctness, not operational resilience. |
| Typical question | Parse a log file, extract timestamps, find sessions with gaps > 30min | Find the shortest path in a weighted graph using Dijkstra's |
The breakdown below comes from analyzing Python interview questions reported at 275+ companies. Data manipulation dominates because it's the daily reality of the role.
Transforming, cleaning, reshaping, and validating data. This is the core of what data engineers do with Python, and it's the core of what interviewers test. Questions involve parsing messy inputs, handling missing values, deduplication, type conversion, and restructuring nested data into flat formats.
Data manipulation is 40% of questions because it's 80% of the actual job. Every pipeline starts with messy input data. Interviewers want to see that you can handle the mess without breaking, and that your code is readable enough for the next engineer to maintain.
Building extract-transform-load workflows in Python. Questions test your ability to design a pipeline that reads from a source, applies transformations in the correct order, handles errors gracefully, and writes to a destination. The focus is on correctness and resilience, not speed.
ETL questions separate data engineers from Python developers. A Python developer writes code that works once. A data engineer writes code that works at 3am when the source system sends a file with a new column, a missing header, and timestamps in a different timezone.
Reading and processing CSV, JSON, Parquet, XML, and log files. These questions test your knowledge of Python's I/O libraries, encoding handling, and your ability to deal with malformed input. Real-world data files are never clean, and interviewers know this.
File parsing is a litmus test for production experience. Candidates who've only worked with clean DataFrames struggle with encoding issues, malformed rows, and memory constraints. Interviewers use file parsing questions to find engineers who've debugged real pipelines.
Extracting data from REST APIs with pagination, rate limiting, authentication, and error handling. These questions combine HTTP knowledge with data engineering patterns like incremental extraction and checkpoint management.
APIs are the extraction layer of most modern pipelines. Interviewers test whether you can write reliable extraction code that doesn't crash when the API returns unexpected responses, and that doesn't get your company's API key revoked by ignoring rate limits.
DataFrame operations: merge, groupby, pivot, melt, apply, and vectorized operations. Pandas questions test whether you can write efficient tabular transformations without falling back to row-by-row iteration.
Pandas is a polarizing topic. Some DE teams use it heavily; others prefer pure Python or PySpark. When it does appear, interviewers specifically test vectorized thinking. Writing a for loop over DataFrame rows is a red flag that tells the interviewer you don't understand how pandas actually works under the hood.
Your code runs against test inputs that include happy path data and edge cases: empty inputs, single-element lists, None values, mixed types, and extremely large inputs. Results are compared against expected output, and you see exactly which cases passed and which failed.
Does your code handle None/NaN values? What happens with an empty input file? What about malformed rows in a CSV? The grader checks whether your code fails gracefully or crashes. It also checks whether you handle edge cases by design (defensive coding) or by accident (getting lucky on the test data).
Variable naming, function decomposition, DRY principle, appropriate use of Python idioms. The grader flags long functions that should be split, repeated code blocks that could be loops, and non-descriptive variable names. This maps directly to the 'code quality' axis on interview rubrics.
List comprehensions vs verbose loops. Context managers for file handling. Generator expressions for memory efficiency. enumerate() instead of manual index tracking. The grader identifies places where idiomatic Python would improve your code and explains why.
O(n^2) loops from nested list operations. Unnecessary copies of large DataFrames. Reading entire files into memory when streaming would work. The grader evaluates your approach and flags solutions that would fail on production-scale data.
Before writing any code, explicitly define: What is the input type and shape? What is the expected output type and shape? What are the edge cases? Writing this as a docstring or comment before coding shows the interviewer you think before you type. It also prevents the most common mistake: writing 80% of the solution before realizing you misunderstood the output format.
Interviewers evaluate code organization. A single 60-line function that parses, transforms, validates, and writes data is hard to read and hard to grade. Break it into 4 functions of 15 lines each. Name them clearly: parse_input, transform_records, validate_output, write_results. This structure also makes it easier to test and debug during the interview.
A bare except: pass is worse than no error handling at all. It tells the interviewer you're hiding bugs. Instead, catch specific exceptions, log useful context (which file, which row, what the bad value was), and decide whether to skip the bad record or abort the pipeline. DataDriven's grader specifically checks for bare except blocks and awards points for targeted exception handling.
If the question mentions 'large file' or 'millions of records,' the interviewer is testing whether you'll load everything into memory. Use generators, process in chunks, or stream line by line. Saying 'I'd use a generator here because the file might not fit in memory' is worth points even if the test data is small.
Run your code mentally (or actually, on DataDriven) with: empty input, single record, None values, duplicate keys, and the largest input you can imagine. If your code handles all five, you've covered 90% of what the grader checks. This habit also impresses interviewers because it shows you think about failure modes proactively.
When you submit Python code on DataDriven, it doesn't run in a simulated environment or a restricted interpreter. It runs for real, the same way your production pipelines would execute. Each submission starts with a clean slate, so there's no state leakage between questions.
You have access to pandas, numpy, and the full Python standard library. You can use json, csv, re, datetime, collections, itertools, functools, os.path, io, and every other stdlib module. File I/O works: you can read input files and write output files. Test data is pre-loaded and ready for your code to process.
Execution has a generous timeout and memory allowance for interview questions, but infinite loops and memory bombs are caught. If your code exceeds a limit, you get a clear error message explaining what happened. This matches the constraints you'd face in a real interview environment.
The grader checks your code across a range of edge cases. If your code throws an exception, you see the full traceback so you can debug and resubmit. This is exactly the feedback loop you need to build interview-ready habits.
DE Python interviews focus on data transformation, ETL logic, file parsing, and API handling. SWE interviews focus on algorithms, data structures, and system design. The overlap is about 15%. Preparing with LeetCode alone leaves you unprepared for 85% of what DE interviewers actually test.
pandas, numpy, and the full standard library (json, csv, re, datetime, os, collections, itertools, functools, and more). Your imports work and file I/O works exactly as it would in a real pipeline environment.
Both. The grader checks correctness (including edge cases), then evaluates code quality: function decomposition, naming, Pythonic patterns, error handling, and performance. These dimensions map directly to the rubric categories used by interviewers at top tech companies.
Over 250, broken down by topic: data manipulation (40%), ETL logic (25%), file parsing (15%), API handling (10%), and pandas (10%). Each question includes test cases with intentionally messy data to simulate real interview conditions.
Yes. Knowing Python and performing well in a Python DE interview are different skills. Interview conditions add time pressure, and DE questions add data messiness. Most experienced Python developers underperform on their first few mock interviews because they haven't practiced writing error-resilient ETL code under a timer. After 10 to 15 mock sessions, performance stabilizes.
Real code execution, real edge case data, real AI feedback. Practice the Python questions data engineering interviewers actually ask.
The complete guide to mock interviews across all 5 data engineering domains.
400+ SQL questions with real code execution and AI grading.
Python interview questions with worked solutions and common mistakes.