The Data Engineer Live Coding Interview

Employers rarely publish their rubric, but the ones that do describe the same things. The Databricks engineering interview guide says its coding interview "evaluates your ability to write production-quality code", with "clean code organization, comprehensive test coverage, and careful edge case handling", and an analysis of efficiency in Big-O notation. Correctness is 1 line of that list.

In practice the notes an interviewer writes fall into 4 groups. Framing: did you restate the problem, ask about the grain and the time zone, check for nulls and duplicates, and state your assumptions? Correctness: does the code return the right result on the stated input and on the edge cases you named? Verification: did you run it on a small sample and check the output against what you expected before calling it done? Communication: could the interviewer follow your reasoning without asking, and did you take a hint when it was offered?

The 4 groups explain why 2 candidates with the same final query can get different outcomes. The one who asked whether retries can repeat an event and planned a dedupe, then ran the query and checked 1 group by hand, showed 4 things. The one who typed the same query in silence showed 1, and left the interviewer guessing whether it was luck.

Silence is the failure interviewers mention most, because a silent candidate gives them nothing to write down. You do not need to narrate every keystroke. You need to keep the interviewer's picture of your plan current, so they know where you're and can steer you before you spend 10 minutes on a dead end.

Keep silences short, and name them when you need one: I'm going to think about the join for 20 seconds. The interviewer will wait. When you are stuck, describe the problem you're stuck on, not the fact that you're stuck: I need the latest row per user, and I am deciding between a window function and a self-join. That sentence invites a hint without asking for one, and a hint taken while you're clearly reasoning costs far less than one given after a long silence.

While you type, say what each block is for as you start it, not after: now I dedupe on event_id so retries count once. Practise this before the day. Talking while you code is its own skill. Record yourself solving 1 problem out loud, then play it back and note each gap longer than about 15 seconds.

The most common data engineering live round is SQL against a described schema, and correctness is rarely what decides it. Take a typical prompt: from play_events, count streams per country per day, along with distinct streamers. Each row has 4 columns: event_id, user_id, country and event_ts.

A strong answer starts with 3 questions. Can the same event arrive twice? Here yes: the client retries a failed send with the same event_id, so 11 rows arrive for 7 real streams. Is a streamer counted once per day even with several plays? Yes. Which time zone is a day? Say UTC and note it, because 2 of the 7 streams start within 15 minutes of midnight and would change day in another zone.

Then the query follows from the answers: COUNT(DISTINCT event_id) counts streams and COUNT(DISTINCT user_id) counts streamers, with the query grouped by country and DATE(event_ts). Check 1 group by hand before calling it done. Germany on the first day receives 4 rows, but they are 2 streams by 2 people; a COUNT(*) would have reported 4 streams and doubled the number. The United States on the same day shows why streams and streamers differ: 3 streams by 2 people, because 1 person played twice.

The weak answer to the same prompt jumps to COUNT(*) grouped by country, never asks about retries, and never runs a sample. It returns numbers, and they're wrong in a way the interviewer spotted before the query finished. Finish by naming what changes at scale: at billions of rows, pre-aggregate per day in the pipeline and partition the table by event date so the query reads 1 day at a time.

The Python half of a data engineering live round looks like the work. You parse lines of a log into records and dedupe them on a key, keeping the latest, before you group and count. Other prompts have you sessionize events by a gap in time or flatten nested JSON, and merging 2 sorted feeds comes up too. The input is a list of dictionaries or a few lines of text, and the expected answer uses the standard library. Ask whether pandas is available before you reach for it; many interviewers want to see the loop and the dictionary.

The traps are the ones production code has. itertools.groupby only groups consecutive items, and the Python documentation warns that the input generally needs to be sorted on the same key first, unlike SQL's GROUP BY. Timestamps arrive as strings in mixed formats. Records are missing keys, so dict.get with a default beats indexing. A generator that reads 1 line at a time answers the follow-up about a 50 GB file before it's asked.

Write a small function per step, name each after what it returns, and run each on 3 hand-made records before combining them. The Python interview questions cover the shapes these problems take, and the Python practice problems run them in a browser editor with the same constraints as a live pad.

The costliest mistake belongs to confident candidates: they start typing as soon as they hear the prompt and find out 10 minutes later that the approach can't work. The cure is the plan out loud, which takes a few minutes and lets the interviewer stop you early. Close behind it is skipping the restatement, which leads to solving a nearby problem: the latest order per user when the prompt asked for the latest order overall.

Candidates also declare victory without running a sample. The pad runs code, and a result you'ven't looked at is a result you cannot defend. Another common mistake is defending a wrong answer. When the interviewer asks whether your query handles a user with no orders, trace it out loud; if it does not, say so before you fix it. Interviewers write down how you take feedback, and the defensive version of a candidate is the one they remember.

If you realise mid-round that the approach is wrong, stop typing and say what breaks: the running total double counts retries, so I need to dedupe first. Propose the new plan, wait until the interviewer agrees to it, and rewrite from it. A clean restart with 15 minutes left can still pass. Patching a design that can't work, while the clock runs, rarely does.

Assume the AI assistant is off unless the recruiter or interviewer says otherwise. Interview platforms now ship one: CoderPad's AI Assist, for example, is a setting the interviewer switches on per pad, with modes that answer questions and draft plans as well as edit code, and its documentation states that every prompt and every AI response is saved for review in playback. Where an employer enables it, the assistant is part of what's scored, not a shortcut around it.

When the assistant is on, the round tests judgment instead of typing. Break the task down and prompt for 1 piece at a time, read every line it returns before running it, test the output on the edge cases you named during clarification, and say out loud which lines you accepted and why you changed the others. Accepting code you cannot explain reads the same in the transcript as it would in a code review. The AI coding interview questions cover how these rounds are run and scored.

When the assistant is off, remember what the pad records whatever its settings. CoderPad's playback keeps every keystroke and every run, and it flags pasting from an outside source and leaving the editor tab. A block of finished code that appears in 1 paste after 2 minutes of silence shows up in the playback, so the interviewer can see it afterwards even if they missed it live.

Databricks is 1 of the few employers that publishes how its engineering interviews run. Its engineering interview guide lists a 1 hour technical screen, then a full panel of 4 to 6 interviews of 1 hour each, and points candidates to the CoderPad sandbox to prepare, so the live coding happens in CoderPad. The guide says Databricks is language agnostic but expects fluency in the language you choose.

The coding interview is scored on production-quality code, meaning clean organisation and tests that cover the edge cases, and on a Big-O analysis of the solution. That favours candidates who write a small function, test it on the spot and name its complexity without being asked. Expect the Spark conversation elsewhere in the loop: the panel also covers architecture, drawn in CoderPad Draw, and a detailed walk through your own past work. The published guide covers software engineering roles, so ask your recruiter which of these interviews a data engineering loop includes. The Databricks interview questions cover the Spark and Delta Lake topics those conversations reach.

Split preparation into 2 tracks. The first is the patterns: window-function dedupes and gaps and islands, rolling windows and anti-joins, plus sessionizing and the parse-then-count task. Work through the SQL interview questions and the SQL practice problems until each pattern comes out without searching for syntax, and do the same for Python.

The second track is the format, and most candidates skip it. Take 1 problem a day under the live conditions: a 45 minute timer, a plain browser editor with autocomplete off, and your voice on. Restate and plan before you code, then test and discuss, in the same order every time, so the rhythm holds when nerves arrive. The in-browser coding interview practice sets up exactly that environment.

In the last 2 weeks, add sessions where someone watches. A colleague who has interviewed people works best; a data engineer mock interview with follow-up questions is the next best thing. If your loop leans on a take-home instead, the take-home assignment guide covers that format, and the data engineer interview prep guide places the live round among the others you'll sit.