FDE Python Interview Questions: Practical Problems With Answers

Data wrangling and parsing questions

This is the heart of the FDE Python round. Expect a file or blob of imperfect data and a request to turn it into something clean and aggregated. Interviewers watch how you handle the edge cases, not whether you know a fancy library.

Parse a messy CSV of usage events and aggregate by customer

The classic. You are handed a CSV with inconsistent casing, blank fields, duplicate rows, and a mix of date formats. Read it with the csv module or a dict per row, normalize keys as you go, skip or flag malformed lines rather than crashing, then sum or count per customer with a dictionary (or collections.Counter / defaultdict). State your assumptions about bad rows out loud before you code.

Flatten a nested JSON API response into flat records

Given nested objects and arrays (say, orders with line items), produce one flat row per line item. Walk the structure explicitly, carry the parent keys down, and handle missing nested keys with .get() and defaults. Mention that you would validate the shape rather than assume every record has every field.

Reconcile two lists of records that should match but do not

A billing export and a usage log that are supposed to agree. Index one side by a key into a dictionary for O(1) lookups, then walk the other side classifying each record as matched, only-in-A, or only-in-B. This maps directly to real reconciliation work, so narrate the field-level comparison, not just the key match.

Deduplicate records, keeping the most recent per key

Group by an identity key, then within each group keep the row with the latest timestamp. A dict keyed by id, updated only when the incoming timestamp is newer, does it in one pass. Be explicit about your tiebreak rule when timestamps are equal.

Group and roll up time-series events into buckets

Bucket events into daily or hourly windows and aggregate per bucket. Truncate each timestamp to its bucket, use it as a dictionary key, and accumulate. The trap is timezone and off-by-one boundary handling, call it out even if you keep the implementation simple.

Small tools and algorithmic warm-ups

A subset of FDE rounds includes a lighter algorithmic problem or asks you to build a small self-contained tool. These reward the same practical instincts: reach for the right data structure, handle input defensively, and keep it readable.

Build a rate limiter or token bucket

Given a stream of requests with timestamps, decide which to allow under N-per-window. A sliding window with a deque of timestamps, or a token-bucket counter that refills over time, is the standard approach. Talk through what happens at the window boundary and what state you keep.

Write a tiny CLI that reads a file and prints a summary

Use argparse for arguments, read from a path or stdin, and print a clean report. The signal here is production hygiene: a clear usage message, a non-zero exit on bad input, and no crash on an empty file.

Two-pointer or sliding-window scan over a sequence

Find the longest run, a subarray summing to a target, or the first pair that satisfies a condition. Recognize when a nested loop collapses to a single pass with two indices or a running window, and say why the complexity drops from O(n squared) to O(n).

Count or find top-N with a hash map

Word frequencies, most active customers, duplicate detection. A dictionary or Counter turns most of these into one pass, and heapq.nlargest gives you top-N without a full sort. This is the single most reused pattern in the round.

Implement retry-with-backoff around a flaky call

Wrap a function that may fail in a loop that retries with exponential backoff and a cap on attempts. Note that you would only retry idempotent operations and would add jitter in production. This connects the coding round to real integration work.

How interviewers grade your Python

The rubric is consistent across FDE loops. Correctness on the edge cases comes first: empty input, malformed rows, duplicate keys, and missing fields. Readability comes next, clear names, small functions, and a structure a customer's team could maintain. Communication runs through all of it: state assumptions, start with something that works, then improve it, and never go silent for five minutes.

What loses points is over-engineering, solving a harder problem than the one asked, or reaching for a heavy dependency when a dictionary would do. Get something correct on screen quickly, then talk through how you would harden it.