Rotate an Array in Java: From Brute Force to the Optimal Reverse Algorithm

The first time array rotation showed up in an interview, I solved it in about four minutes and felt pretty good about myself. Then the interviewer asked one follow-up question — "what if the array has ten million elements and you need to rotate it fifty thousand times?" — and the solution I was proud of fell apart almost instantly. That's the whole point of this problem. It isn't hard. It's designed to catch people who stop at the first thing that works.

What rotating an array actually means

The first time array rotation showed up in an interview, I solved it in about four minutes and felt pretty good about myself. Then the interviewer asked one follow-up question — "what if the array has ten million elements and you need to rotate it fifty thousand times?" — and the solution I was proud of fell apart almost instantly. That's the whole point of this problem. It isn't hard. It's designed to catch people who stop at the first thing that works.

Rotation itself is simple to picture. Take an array like this one:

[1, 2, 3, 4, 5]

Rotate it left by one position, and the first element walks around to the back while everyone else shifts one seat to the left:

Before: 1 2 3 4 5
After:  2 3 4 5 1

Rotate it right by one instead, and it's the last element that walks around to the front:

Before: 1 2 3 4 5
After:  5 1 2 3 4

Same five numbers, same idea, opposite direction. Everything else in this post is really just answering one question: how do you do that efficiently, for any number of positions, without doing more work than the problem actually requires?

The brute-force instinct — and why it's worth starting there

Almost everyone reaches for the same first idea, and it's a good one to reach for. To rotate left by one position, you don't need anything clever. You just need three steps.

First, save the element that's about to get displaced:

int temp = arr[0];

Then slide everything else one seat to the left:

Before shifting: 1 2 3 4 5
After shifting:  2 3 4 5 _

And finally, drop the value you saved into the gap that's left behind:

2 3 4 5 1

That's a full left rotation by one position, and it's genuinely the right way to think about the problem before you optimize anything. You can't skip a step to a shortcut you haven't earned an understanding of yet.

Why repeating that K times gets expensive

Once you can rotate by one position, rotating by K looks trivial: just do the same three steps K times in a row. It works. It's also the part of the solution that quietly turns into a performance problem the moment the numbers get realistic.

Each single rotation touches every element in the array once, which is O(N) work. Do that K times and the total cost is:

O(K × N)

That looks abstract until you put real numbers in it. Say you're working with an array of 100,000 elements and you need to rotate it 50,000 times:

n = 100000
k = 50000

You are now sliding elements one step at a time, five billion times over, to accomplish something that — as you're about to see — doesn't need repetition at all.

The shortcut hiding inside K: k % n

Here's the observation that breaks the problem open. Rotate an array exactly N times, where N is its length, and you get the original array back:

Array:        1 2 3 4 5
Rotate by 2:  3 4 5 1 2
Rotate by 3:  4 5 1 2 3
Rotate by 4:  5 1 2 3 4
Rotate by 5:  1 2 3 4 5   ← back to the start

Once you notice that, the rest follows immediately. Rotating six times is identical to rotating once. Rotating seven times is identical to rotating twice. Every full lap around the array is wasted motion — it lands you exactly where you started, so it never needed to happen. The only part of K that actually changes anything is the remainder after you divide out every complete lap:

k = k % n;

Seventeen rotations on an array of five elements is the same as two rotations:

k = 17
n = 5
17 % 5 = 2

One line of arithmetic just deleted every unnecessary rotation before you've written a single line of the actual algorithm.

What negative K actually means

K isn't always positive. Sometimes a problem hands you a negative rotation count, and it's less mysterious than it looks: a negative rotation just means rotate the other direction.

Take k = -1 on an array of five elements. Rotating right by one and rotating left by four land you in exactly the same place:

Right rotate by 1  ==  Left rotate by 4

because

-1 + 5 = 4

So the fix is one conditional, applied once, before anything else runs:

if (k < 0) k += n;

After that line, K is always a positive number pointing in a consistent direction, and every rule you already worked out — including k % n — applies without a single exception.

Doing it in one pass: the reverse algorithm

Repeating the single-rotation trick K times is easy to write and easy to justify, right up until K and N are both large. If n = 100,000 and k = 50,000, the brute-force approach is doing roughly five billion units of work for a result that a smarter approach reaches in three passes over the array.

The smarter approach doesn't shift anything at all. It reverses.

Take an array of ten values and rotate it left by four:

Array:  10 20 30 40 50 60 70 80 90
k = 4
Expected: 50 60 70 80 90 10 20 30 40

Three reversals get you there. First, split the array at position k and reverse the first block on its own:

10 20 30 40 | 50 60 70 80 90
40 30 20 10 | 50 60 70 80 90

Then reverse the second block on its own:

40 30 20 10 | 90 80 70 60 50

And finally, reverse the entire array, both blocks together:

50 60 70 80 90 10 20 30 40

That's the answer. No shifting, no temp variable passed around K times, no loop that runs longer the bigger K gets. Just three reversals, applied in order.

Why the reversal trick actually works

It looks like a magic trick the first time you see it, but the mechanism is simple once you look at what each reversal is undoing.

Reversing the first block flips its internal order. Reversing the second block flips its internal order too. Both blocks are now backwards relative to how they started — and that's exactly the state you want, because the final step, reversing the entire array, flips everything backwards one more time. Flip something twice and it lands back in its original order, except now the two blocks have also swapped positions with each other, which is precisely what a rotation is: two blocks trading places while keeping their own internal order intact.

It's a small piece of reasoning, but it's worth sitting with, because it's the kind of pattern — do a smaller, controlled version of an operation on two pieces, then apply the same operation to the whole — that shows up again in other places once you know to look for it.

Comparing the two approaches

Put side by side, the difference isn't subtle.

Three reversals, each one a single O(N) pass, add up to O(3N) — and since constants don't change how an algorithm scales, that simplifies to O(N). For an array of 100,000 elements rotated 50,000 times, that's the difference between roughly five billion operations and about three hundred thousand.

What this problem is really teaching you

Rotate Array shows up in interviews so often not because rotating an array is a useful skill on its own, but because the problem is a small, contained rehearsal of a habit that matters everywhere in engineering: getting something working is the beginning of the work, not the end of it.

The brute-force approach isn't wrong. It's necessary — it's how you build the intuition that makes the optimization make sense in the first place. But stopping there means missing the two ideas sitting quietly underneath the problem: that k % n deletes an entire category of wasted work before you write a single line of algorithm, and that a sequence of small reversals can replace a much larger amount of shifting because of how the operations compose.

The habit worth taking with you isn't the reverse algorithm specifically. It's the question to ask after any solution that works: is there a mathematical observation hiding in here, is there a pattern replacing repeated work, and is there a smaller operation I could compose differently to get the same result for less. Rotate Array is a small problem. That question isn't.

Working through DSA problems like this one? The archive has free PDF notes on data structures, algorithms, and computer science fundamentals — no account needed.