Split Text into Minimum Suffixed SMS Messages
Reported by candidates from ZipRecruiter's online assessment. Pattern, common pitfall, and the honest play if you blank under the timer.
The detail that matters in this ZipRecruiter question, reported in November 2023, is that the suffix <x/y> counts toward the limit, and y depends on how many messages you end up with. That's a chicken-and-egg problem. You can't know the suffix length until you know the total, and you can't know the total until you know the suffix length. It's a string-splitting problem dressed up as a simulation. If you blank on the loop structure during the live OA, StealthCoder runs invisibly as a safety net. Otherwise, read on, because the trick is short.
The problem
Split every text character in order into the minimum number y of messages. Message x ends with suffix <x/y>, which counts toward limit. Every nonlast message must have total length exactly limit; the last may be shorter. Each message contains at least one text character. Return the first feasible split, or an empty array. Function splitSms(text: String, limit: int) → String[] Examples Example 1 text = "abcdefghij" limit = 7 return = ["ab<1/5>","cd<2/5>","ef<3/5>","gh<4/5>","ij<5/5>"] Five messages are the first total count with enough capacity. Example 2 text = "abc" limit = 10 return = ["abc<1/1>"] One message fits. Constraints 1 <= text.length <= 10000 1 <= limit <= 10000
Reported by candidates. Source: FastPrep
Pattern and pitfall
The trick: try each candidate total y from 1 upward. For a fixed y, message x has a suffix of length len(x) + len(y) + 3, covering the angle brackets and slash. Each text character costs one slot, so the capacity of message x is limit minus that suffix length. If that capacity is zero or negative for any message, y is infeasible. Sum the capacities across all y messages. The first y whose total capacity is at least text.length wins. Then build the messages greedily, remembering that every nonlast message must be filled exactly to limit and the last one can be shorter. The pitfall is the digit boundaries. Suffix length jumps at 10, 100, and 1000, so don't use a flat estimate. Another trap is a last message that ends up empty, which breaks the rule that each message needs a text character. Return an empty array when no y works. StealthCoder is your hedge if the loop logic slips under pressure.
Drill it cold or hedge it with StealthCoder. Either way, don't walk into the OA hoping you remember the trick.
You can drill Split Text into Minimum Suffixed SMS Messages 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 for the candidate who got the OA invite this morning and has 72 hours, not six months.
Get StealthCoderRelated leaked OAs
This OA pattern shows up on LeetCode as split message based on limit. If you have time before the OA, drill that.
You've seen the question.
Make sure you actually pass ZipRecruiter's OA.
ZipRecruiter reuses patterns across OAs. Made for the candidate who got the OA invite this morning and has 72 hours, not six months. Works on HackerRank, CodeSignal, CoderPad, and Karat.
Split Text into Minimum Suffixed SMS Messages FAQ
What's the core trick in the SMS splitting problem?+
Iterate over the total message count y starting at 1. For each y, compute the usable text capacity of every message given its suffix length, which depends on the digits of x and y. The first y with total capacity covering the text is your answer. Then build the messages.
Why does the suffix length make this tricky?+
The suffix <x/y> takes len(x) + len(y) + 3 characters, and x changes from 1 digit to 2 to 3 as it grows. So capacity per message isn't constant. You have to compute it per message, not assume one flat suffix size for all of them.
When is the answer an empty array?+
When no y can fit the text. If the suffix alone is as long as the limit or longer, a message has no room for a text character. That happens with small limits, and larger y makes it worse, so you can stop once suffix length alone exceeds the limit.
How big can y get, and does brute force work?+
Text length is up to 10000, so y is at most 10000, since each message holds at least one character. Trying every y with an O(y) capacity check is about 10^8 operations in the worst case. You can cut that by stopping early once the suffix can't fit.
How do I prepare for this in 48 hours?+
Write the capacity check by hand on a few cases like limit 7 with 10 characters. Test the digit boundaries around 9 to 10 and 99 to 100. Then code the outer loop over y and the greedy builder. Check that the last message is nonempty and that every other message is exactly limit long.