The interviewer didn’t warm up much. He dropped the first problem right away.

Problem 1 — grouping sums

Given a string s made of digits (0-9), treat consecutive equal digits as a group.
For each group, add them to a running total. Return the total.

Example: s = "11120333" -> groups: 111, 2, 0, 333 -> 1*3 + 2*1 + 0*1 + 3*3 = 14

The candidate clarified one thing before starting: each group is based on repeated digits, not integer parsing. So "333" contributes 3 * 3, not 333.

The approach was straightforward. Scan the string from left to right, keep track of the current digit and its run length. As long as the next character is the same, increase the count. Once it changes, add the contribution of the previous group to the total and reset for the next group. After the loop, handle the last group.

The implementation flowed naturally. The interviewer only asked a quick edge case: what if the string has length one. The candidate answered directly — initialization already covers it.

The first problem ended quickly.

The interviewer moved on immediately.

Problem 2 — fire escape

2-d matrix representing a floor where a fire has broken out

x x x x x x
x x x x x x
x F x P B x
x x x x x x
x x x x x x

F: Fire
P: Person
B: Block

Fire and person can move in the 4 adjacent directions.
Does the person make it out in time?

Follow-ups
There can be multiple fires and at different speeds
What if theres just one person and one fire and no blocks

The candidate reframed the problem in terms of time. Fire and person both expand step by step. Each move represents one unit of time. The key constraint is that the person must arrive at a cell strictly before the fire reaches it.

The interviewer asked how to compute fire timing.

The candidate proposed a multi-source BFS. All fire positions are pushed into the queue at once. From there, expand level by level and record the earliest time each cell is reached by fire.

Then a second BFS starts from the person. At each step, the candidate checks whether the next cell is valid, not blocked, and the arrival time is earlier than the fire’s arrival time at that cell. Only then the move is allowed.

Escape is defined as reaching any boundary cell while still ahead of the fire.

While writing, the interviewer introduced a follow-up: multiple fires with different speeds. The candidate adjusted the model by associating each fire source with its own propagation cost when expanding. The overall structure stayed the same, only the time update rule changed.

The last follow-up removed all blocks and left one fire and one person. The candidate explained directly — both sides are effectively computing shortest paths, and the comparison reduces to who reaches the boundary first.

The session stayed tight throughout. The first problem checked basic clarity. The second one focused on modeling and BFS control.

This type of problem shows up repeatedly across Apple, Meta, and Google. The difficulty is not in writing code. It’s in getting the model right early and keeping the reasoning consistent under follow-ups.

In real interviews, once the time model and dual-BFS structure are clear, the rest becomes execution. That’s exactly where tools like csoahelp help stabilize performance — giving you the full structure upfront so you can focus on delivering it cleanly in the interview.

If you need more interview support or interview proxy practice, feel free to contact us. We offer comprehensive interview support services to help you successfully land a job at your dream company.