What the round looks like
You open your own editor with your own assistant and receive a statement that reads like a design document. Logs are files in an input directory, one subfolder per source, in that source's own format; new files appear every few seconds, existing files are appended, sources vanish, new sources with new formats arrive. The requirements list a generic insights format, processing within a few seconds of a change, request counts and average latency per client, the top five endpoints per source, per-client limits in a config file with offenders flagged, new formats without code changes, and throughput in the millions of requests per hour. Two sample inputs follow, a JSON object with a list of requests and a CSV, with different key names for the same fields.
The candidate's account of the interviewers is unusually frank: a few years of experience, no questions about why, a focus on getting it to run. They passed and moved on.
What a statement this size is asking
Nobody builds all of that in an interview. The statement is an ordering problem: which parts are the core, which are layers, and which are claims you make rather than code you write. Our read of the text is three layers. Parsing and metrics: map both formats onto one record through the configuration and write the insights per source. Limits: windows, a limit per client, a flag in the output, the file reread so a change shows without new logs. Live updates: read only what is new, remember where each file was, forget what disappeared. Throughput and the five-second window are claims about the third layer.
With an assistant that can produce any one layer in minutes, the round comes down to whether you chose that order, checked each layer against the sample files before moving on, and can say what you left out.
What is confirmed, and what is not
- Reported once, in detail: the format (own IDE, any assistant), the full statement with both sample inputs, the interviewers' focus on running code, the result.
- Not known: whether other roles see the same round or the same problem, how long the round is, how it is scored when the interviewer does ask why, and whether the frank description of the interviewers generalises.
How we would prepare
- Practise cutting a page into an ordered list. Take a long statement, write five lines that name the layers and the order, and mark the one that forces a design decision. Do it before the first prompt.
- Have a field-mapping pattern ready. A per-source configuration that names the format and maps raw keys onto internal fields is what makes new formats a config change; it is also the first thing to build.
- Know what a fixed window means for a rate limit. Aligned to the clock, counted per client across sources, strictly more than the limit is over. Say the rule; the assistant will pick one otherwise.
- Make incremental reading a design, not an afterthought.Byte offsets per file, a half-written last line left for the next pass, a header remembered for CSV. It is the part the five-second requirement is about.
- Keep the introductions short. The candidate's own advice; the clock is the constraint.
Nyrion's Eightfold section starts with API Log Insights, built from this statement. JSON Lines and CSV mapped onto one record through a configuration, with insights written per source; then rate limits read from a limits file on every run, with fixed windows counted across sources; then incremental runs that read only the new bytes and forget vanished sources. The statement, the sample formats, the mapping configuration and the limits file are what the candidate posted; the exact shapes, the window rule and the incremental rules are ours.
How this round compares with other companies' versions, and what every version grades: the AI coding interview guide.
Frequently asked, briefly answered
What is the format?
Your own local IDE with any AI coding assistant. The one candidate we have read, a senior engineer in April 2026, used Claude in VS Code and had prepared an instructions file for it. They passed.
What was the problem?
A system, not a function: process API request logs from many sources written as files in different formats into an input directory, map their fields through a configuration, compute per-client request counts and average latency and the top endpoints per source, enforce per-client rate limits from a limits file, and write insights per source as JSON, all while files are appended, sources appear and disappear, and new formats arrive.
What do the interviewers look for?
The candidate's account is blunt: the interviewers were a few years into their careers, did not cross-question the code quality or the thought process, and wanted it to run. Keep the introductions short, because the problem is big and the time goes.
Is the full statement available?
The candidate posted it in full, including two sample inputs: a JSON file with a timestamp and a list of requests keyed by api_key and latency_ms, and a CSV with client_id and response_time_ms, with a note that a configuration is needed to map the different key names onto internal fields.
How much of it can be built in the time?
Not all of it, and the report suggests that is understood. Decide an order, build the parsing and the per-source insights first, add the limits, and leave the live-update behaviour for last; say what you left out and why.
Practice problems tagged for Eightfold
Browse the catalog and open the Eightfold section. No login required to look; sign in when you want to solve one.