Hall of Shifting Tiles
Reported by candidates from Adobe's online assessment. Pattern, common pitfall, and the honest play if you blank under the timer.
A naive simulation passes both examples in the Adobe "Hall of Shifting Tiles" OA and then dies on the large cases. That's the trap. Candidates reported it in August 2026, and it looks like a flip-and-bounce corridor problem where every tile reverses after you step on it. n goes up to 2000 and costs go up to 10^9, so the totals are big and the walks can get long. If you blank on the structure during the live assessment, StealthCoder is the safety net. It sits invisibly on your screen and gives you a working solution in real time. Know the shape of the problem first, though.
The problem
A linear corridor contains n tiles numbered from 1 to n. Tile i has an initial direction directions[i], either < or >, and a nonnegative hardness cost costs[i]. For one run, place an orb on a chosen starting tile. Repeat the following steps while the orb remains inside the corridor: Add the hardness cost of the current tile to the total time. Flip the current tile's direction: < becomes >, and > becomes <. Move the orb one tile in the direction that the current tile had before it was flipped. The run ends when the orb moves to position 0 or n + 1. Run this process independently from every starting tile. Before each run, restore every direction to its original value. Return an array answer of length n, where answer[i] is the total time accumulated when the orb starts on tile i + 1. Function totalEscapeTimes(directions: String, costs: int[]) → long[] Examples Example 1 directions = "><" costs = [3, 5] return = [11, 13] Starting on tile 1 visits tiles 1, 2, 1, so the total is 3 + 5 + 3 = 11. Starting on tile 2 visits tiles 2, 1, 2, so the total is 5 + 3 + 5 = 13. Example 2 directions = ">><<" costs = [1, 2, 3, 4] return = [9, 23, 27, 16] For example, the run from tile 2 visits 2, 3, 2, 1, 2, 3, 4, 3, 2, 1. The corresponding costs sum to 23. Every other result is computed from an independent reset of the same initial corridor. Constraints 1 <= directions.length == costs.length <= 2000 directions[i] is either < or >. 0 <= costs[i] <= 10^9 All returned totals fit in a signed 64-bit integer.
Reported by candidates. Source: FastPrep
Pattern and pitfall
Don't simulate step by step. Each tile flips when you leave it, so the orb acts like it's hitting mirrors. Starting at tile i, it runs in one direction until it hits a tile pointing back at it. That tile flips and sends the orb the other way. The orb then passes through the tiles it already flipped and keeps going until it meets the next opposing tile on the far side. Each reversal widens the swept range. The answer for a start is a sum of cost times visit count. Visit counts follow from where the reversals happen, and prefix sums of costs give each swept segment's cost in O(1). With n at 2000, O(n^2) is fine. The pitfall is stepping one tile at a time, because the walk length can blow up, and overflowing 32-bit ints on the sums. Use 64-bit. If the bounce logic slips away mid-assessment, StealthCoder is your hedge for the live OA.
If you see this problem in your OA tomorrow, the play is to recognize the pattern in 30 seconds. StealthCoder buys you that recognition.
You can drill Hall of Shifting Tiles 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. Built by an Amazon engineer who passed his OA cold and still thinks the filter is broken.
Get StealthCoderRelated leaked OAs
You've seen the question.
Make sure you actually pass Adobe's OA.
Adobe reuses patterns across OAs. Built by an Amazon engineer who passed his OA cold and still thinks the filter is broken. Works on HackerRank, CodeSignal, CoderPad, and Karat.
Hall of Shifting Tiles FAQ
How hard is Hall of Shifting Tiles really?+
It's medium to hard, mostly because the brute force looks right. The examples pass with plain simulation. The difficulty is seeing that each start follows a bounce structure you can compute with segment sums instead of walking every step. Once you see that, the code is short.
What's the trick to avoid timing out?+
Stop walking tile by tile. Work out where the orb reverses, then add the cost of whole swept segments using prefix sums. Each reversal widens the range the orb covers, so you can jump from reversal to reversal. With n up to 2000, an O(n^2) approach over all starts is enough.
Why do I need 64-bit integers here?+
Costs reach 10^9 and a tile can be visited many times in one run. The statement says totals fit in a signed 64-bit integer, which means they can exceed 32-bit range. Use long in Java, long long in C++. Python handles it on its own.
Which edge cases should I test before submitting?+
Test n = 1 with both directions, since the orb exits right away. Test all tiles pointing the same way, where the orb leaves without bouncing. Test zero costs, and test alternating directions like the two examples. Also check that each start resets the corridor. Leaking flipped state between starts is a common bug.
How do I prepare for this in 48 hours?+
Hand-trace example 2 from tile 2 until you can predict the bounce points without simulating. Write the brute force first as a checker, then the segment-sum version, and compare them on random small inputs. That one habit catches most off-by-one errors in the reversal logic.