Large Responses
Reported by candidates from Postman's online assessment. Pattern, common pitfall, and the honest play if you blank under the timer.
Postman's "Large Responses" OA, reported in September 2020, looks like a log parsing warm-up, and it is. You get up to 10^5 Apache-style log lines and need to count responses over 5000 bytes and sum their sizes. There's no clever algorithm here. The risk is sloppy parsing and a silly overflow. If you blank on the string handling during the live assessment, StealthCoder sits invisibly on your screen as a safety net and hands you the clean version. Read the trick below and you probably won't need it.
The problem
You are given Apache-style HTTP log records in records. Each non-empty record ends with a nonnegative integer giving the number of response bytes. A response is large when it contains more than 5000 bytes. Return a two-element array: the number of large responses; the total bytes sent by all large responses. The request portion may contain spaces and is enclosed in double quotes, so parse the byte count from the final whitespace-separated field. Function summarizeLargeResponses(records: String[]) → long[] Examples Example 1 records = ["unicom96.unicomp.net - - [01/Jul/1995:00:00:06 -0400] \"GET /shuttle/countdown/ HTTP/1.0\" 200 3985","unicom96.unicomp.net - - [01/Jul/1995:00:00:14 -0400] \"GET /shuttle/countdown/count.gif HTTP/1.0\" 200 40310","d104.aa.net - - [01/Jul/1995:00:00:15 -0400] \"GET /shuttle/countdown/count.gif HTTP/1.0\" 200 40310"] return = [2,80620] Two records have more than 5000 bytes. Their byte counts sum to 40310 + 40310 = 80620. Example 2 records = ["host - - [time] \"GET /a HTTP/1.0\" 200 5000","host - - [time] \"GET /b HTTP/1.0\" 200 5001"] return = [1,5001] A response of exactly 5000 bytes is not large; only the 5001-byte response qualifies. Constraints 2 ≤ records.length ≤ 10^5 Every non-empty record ends with a valid nonnegative byte count. The total bytes across all large responses does not exceed 10^14.
Reported by candidates. Source: FastPrep
Pattern and pitfall
The constraint that kills brute force thinking is 10^5 records, but the real answer is a single linear pass. For each record, skip the quoted request entirely. The byte count is the last whitespace-separated field, so find the last space with lastIndexOf and parse everything after it. Don't split the whole line on spaces, because the request portion contains spaces and the timestamp has brackets. Compare strictly greater than 5000, since exactly 5000 doesn't count (Example 2 tests this). Accumulate the total in a 64-bit long. The sum can reach 10^14, which overflows a 32-bit int. Also trim trailing whitespace and skip empty records before parsing. Return the count and the total as a two-element long array. That's O(total characters) time and O(1) extra space. If the live OA freezes your brain on edge cases, StealthCoder is the hedge, but this one is mostly careful typing.
Memorize the pattern. If you can't, run StealthCoder. The proctor sees the IDE. They don't see what's behind it.
You can drill Large Responses cold, or you can hedge it. StealthCoder runs invisibly during screen share and surfaces a working solution in under 2 seconds. The proctor sees the IDE. They don't see what's behind it. Made by an engineer who treats the OA as theater. If yours is tonight, you don't have time to grind. You have time to hedge.
Get StealthCoderRelated leaked OAs
You've seen the question.
Make sure you actually pass Postman's OA.
Postman reuses patterns across OAs. Made by an engineer who treats the OA as theater. If yours is tonight, you don't have time to grind. You have time to hedge. Works on HackerRank, CodeSignal, CoderPad, and Karat.
Large Responses FAQ
How hard is the Postman Large Responses OA really?+
Easy. It's a single pass over the records with string parsing and a threshold check. The difficulty is in details: parsing the last field correctly, using a strict greater-than, and using a long for the sum. Most candidates who fail it fail on overflow or splitting wrong.
What's the trick to parsing each record?+
Ignore the quoted request and the timestamp. Take the substring after the last whitespace in the line and parse it as a number. That field is always the byte count, no matter how many spaces appear in the request portion.
Why does the sum need a long?+
The total across large responses can hit 10^14, which is far past the 32-bit int limit of about 2.1 billion. Use a 64-bit integer for the accumulator. The return type is long[] for the same reason, so keep everything in long from the start.
What edge cases should I test before submitting?+
Test a response of exactly 5000 bytes, which must be excluded. Test 5001, which must be included. Test a record with extra spaces in the request, a zero-byte response, and empty strings in the array, which you should skip without crashing.
How do I prepare for this in 48 hours?+
Practice log-style string parsing in your language of choice: lastIndexOf, split limits, and integer parsing. Write this exact function once from scratch and run both examples. Then review other linear-scan-and-aggregate problems. Twenty minutes of focused repetition is enough.