A customer reports that some requests to your API fail, and you have logs and nothing else. Walk through your first hour.

The prompt is vague on purpose. Show order: who is affected and how badly, what the failures have in common, and whether the customer hears from you while you work. One candidate reported on Glassdoor, in August 2026, that their interview for Cohere’s Forward Deployed Engineer role included a problem-solving round on debugging a system. The reviewer did not say what the system was. This prompt is our version of that kind of round, not the question they were asked. Employers do set this task. Ethyca’s published take-home for its Forward Deployed Privacy Engineer role has you connect to its API, reproduce and diagnose a customer’s API error, and then write the reply to that customer. Here you get logs. If you get an architecture diagram instead, do the same steps as questions: trace one request from the client to the data store, name what you’d query at each hop, and ask the interviewer for that result. They are your logs. Say the plan before you start. Scope, pattern, mitigation, with updates to the customer throughout. Turn the report into search terms. Ask for failing request IDs, timestamps with time zone, the endpoint, the exact error the client saw and when it started. Acknowledge it with a time for the next update. Check the failures reached you. A failure the client sees can leave no error in your logs: rejected at the load balancer or during the TLS handshake, or a client timeout while your server returns HTTP 200 late. Missing request IDs are evidence too. Scope the impact. Their error rate over time, failures divided by requests, then everyone else’s. One customer or all? One endpoint or all? Sudden or gradual? That sets severity and who else to tell. Find the pattern. Group failures by status code first; the status code classes in RFC 9110 tell you whether to look at the request or at your side. Then slice by endpoint, client version, host and payload size, and line the start up against deploys, config changes and key rotations. Test one hypothesis at a time. “Only requests above the body size limit fail” predicts something a single query can confirm or kill. Mitigate before you fully understand. Roll back, pull a bad host, or hand the customer a workaround, and tell them what is safe to retry. Close the hour in writing. What you know, what you don’t, what changed, and the next update time.

Debug failing API requests | Cohere FDE interview question

Where it comes from

Reported at CohereSource 1Cohere Forward Deployed Engineer Interview QuestionsPublisherGlassdoor (anonymous interview review)Source typecandidate’s personal write-up More Cohere questions

How to answer

The prompt is vague on purpose. Show order: who is affected and how badly, what the failures have in common, and whether the customer hears from you while you work.

One candidate reported on Glassdoor, in August 2026, that their interview for Cohere’s role included a problem-solving round on debugging a system. Source 1Cohere Forward Deployed Engineer Interview QuestionsPublisherGlassdoor (anonymous interview review)Source typecandidate’s personal write-up The reviewer did not say what the system was. This prompt is our version of that kind of round, not the question they were asked.

Employers do set this task. Ethyca’s published take-home for its Forward Deployed Privacy Engineer role has you connect to its API, reproduce and diagnose a customer’s API error, and then write the reply to that customer. Source 2Ethyca Technical Challenge -- Forward Deployed Privacy Engineer (FDPE)PublisherEthyca (GitHub)Source typecompany website Here you get logs. If you get an architecture diagram instead, do the same steps as questions: trace one request from the client to the data store, name what you’d query at each hop, and ask the interviewer for that result. They are your logs.

Say the plan before you start. Scope, pattern, mitigation, with updates to the customer throughout.
Turn the report into search terms. Ask for failing request IDs, timestamps with time zone, the endpoint, the exact error the client saw and when it started. Acknowledge it with a time for the next update.
Check the failures reached you. A failure the client sees can leave no error in your logs: rejected at the load balancer or during the TLS handshake, or a client timeout while your server returns HTTP 200 late. Missing request IDs are evidence too.
Scope the impact. Their error rate over time, failures divided by requests, then everyone else’s. One customer or all? One endpoint or all? Sudden or gradual? That sets severity and who else to tell.
Find the pattern. Group failures by status code first; the status code classes in RFC 9110 tell you whether to look at the request or at your side. Then slice by endpoint, client version, host and payload size, and line the start up against deploys, config changes and key rotations.
Test one hypothesis at a time. “Only requests above the body size limit fail” predicts something a single query can confirm or kill.
Mitigate before you fully understand. Roll back, pull a bad host, or hand the customer a workaround, and tell them what is safe to retry.
Close the hour in writing. What you know, what you don’t, what changed, and the next update time.

Follow-ups

What the interviewer may ask next, once your first answer is on the table.

The failing request IDs aren’t in your logs at all. What now?
The failures are gateway timeouts on a POST. What do you tell the customer about retrying?
It’s one customer only, and nothing changed on our side. Where do you look?

Where answers go wrong

Debugs the first stack trace for the hour and never counts the failures.
Counts errors without comparing them to total requests.
Goes quiet on the customer until the cause is known.

Answer this in two minutes

Write the answer you would say out loud. The clock starts with your first word.

Compare with the model answer

Model answer

“My plan is scope, pattern, mitigation, with the customer updated throughout.

T+0 to T+10: make the report searchable. I reply to the customer right away: we’re on it, next update within the hour. I ask for a few failing request IDs or timestamps with time zone, the endpoint, the error body their client got, and when they first noticed. While they answer, I start from what I already have, their tenant ID. When their request IDs arrive, the first check is whether those requests reached us at all. If they’re missing, I look at the edge and load balancer logs. If they’re there with HTTP 200 and a long duration, their client timed out before we answered, and error counts will never show it.

T+10 to T+25: scope. Assuming JSON logs with ts, tenant, route, status, host and duration_ms:

# Their failures by status and route
jq -r 'select(.tenant=="acme" and .status>=400) | [.status, .route] | @tsv' logs/api-*.jsonl \
  | sort | uniq -c | sort -rn | head -20

# Their requests, failures and error rate per minute
jq -r 'select(.tenant=="acme") | [.ts[0:16], (if .status>=400 then 1 else 0 end)] | @tsv' logs/api-*.jsonl \
  | awk -F'\t' '{n[$1]++; e[$1]+=$2} END {for (m in n) printf "%s %d %d %.1f%%\n", m, n[m], e[m], 100*e[m]/n[m]}' | sort

# Everyone else: requests, failures and error rate per host
jq -r 'select(.tenant!="acme") | [.host, (if .status>=400 then 1 else 0 end)] | @tsv' logs/api-*.jsonl \
  | awk -F'\t' '{n[$1]++; e[$1]+=$2} END {for (h in n) printf "%s %d %d %.1f%%\n", h, n[h], e[h], 100*e[h]/n[h]}' | sort -k4 -rn

The rate matters because a rise in failures can simply be a rise in traffic. The comparison with everyone else is the query that matters most. If only this customer fails, the cause is probably in what they send or how their account is set up. If everyone fails on one host, it’s ours and it’s an incident, so I’d page on-call before going further.

T+25 to T+45: pattern and hypothesis. The status code steers me. HTTP 401 or HTTP 403 starting at one moment suggests a rotated or revoked key. HTTP 413, or HTTP 400 on one route, suggests payload size or a schema change on their side, so I compare request sizes of failures against successes. HTTP 429 means a rate limiter refused them (RFC 6585), so I check which layer sent it and plot their request rate against their limit. HTTP 502 or HTTP 504 clustered on one host, or on slow requests, points at an upstream timeout or a bad instance. I line the start time up against our deploy log and config changes. Each hypothesis becomes one query that could prove it wrong.

If it’s an LLM API, the same codes mean more. An HTTP 429 can come from a tokens-per-minute limit while the request count looks normal, so I plot their tokens per minute, not only requests. HTTP 400 errors for exceeding the context length grow as their prompts grow, for example when they start adding chat history or retrieved documents, so I bucket failures by input tokens, not bytes. A streamed response cut off by a proxy or load balancer idle timeout shows up as an HTTP 200 with a truncated body, or an HTTP 504 at the edge, and the durations pile up at one round number. A provider can also send an error event mid-stream, after the HTTP 200, so a stream counts as a success only when its final event arrives. Overload at an upstream model provider shows as HTTP 503, or a provider’s own code, such as the HTTP 529 that Anthropic’s API documentation lists for overload. The queries for the streaming and context-window cases, assuming the logs carry input_tokens:

# Their requests by 5-second duration bucket and status: a pile at one bucket is a timeout
jq -r 'select(.tenant=="acme") | [(.duration_ms/5000 | floor) * 5, .status] | @tsv' logs/api-*.jsonl \
  | sort | uniq -c | sort -k2,2n -k3,3n

# Their error rate by input-token bucket: failures only above a size point at the context window
jq -r 'select(.tenant=="acme") | [(.input_tokens/10000 | floor) * 10000, (if .status>=400 then 1 else 0 end)] | @tsv' logs/api-*.jsonl \
  | awk -F'\t' '{n[$1]++; e[$1]+=$2} END {for (b in n) printf "%s %d %d %.1f%%\n", b, n[b], e[b], 100*e[b]/n[b]}' | sort -n

By T+45: mitigate. If a deploy lines up, roll it back. If one host is bad, pull it from rotation. If it’s their payloads, send the limit and a workaround now and raise the product question separately.

T+60: a written update. For example:

Since 09:40 UTC, about 6% of your POST /v1/orders requests have failed with HTTP 504. They all went through one of our hosts, which we removed at 10:31; failures stopped at 10:32. A gateway timeout means we stopped waiting, not that the order failed, so some of these orders may exist. The attached list shows which of them were created; please check it before you retry, or send an Idempotency-Key header so a retry can’t create a duplicate. We are finding out why that host degraded and will send the cause and the fix by 17:00 UTC today.

It says the impact, the cause as far as we know it, what changed, and when they’ll hear next. The retry line is there because a gateway timeout says nothing about whether the upstream finished (RFC 9110, section 15.6.5), and POST is not idempotent (RFC 9110, section 9.2.2), so a blind retry can create a second order.

If it’s one customer and nothing changed on our side, something changed on theirs: a new SDK version, a new region or network path, a proxy in front of them, or bigger payloads. I slice their requests by user and source IP around the start time, and I ask them what they deployed that morning.

What I avoid is opening the first stack trace and debugging it for the hour. Until I’ve counted the failures by type, I don’t know whether that trace is the problem or a background error that’s always been there.

If the interviewer hands me a diagram instead of logs, I run the same hour as questions: I trace one request hop by hop from client to data store, say what I’d query at each hop, and ask for the result.”