The String Rotation Interview Problem Most Engineers Overcomplicate

May 25, 20264 min read
interview-prepdsaalgorithmsleetcode
The String Rotation Interview Problem Most Engineers Overcomplicate
TL;DR
  • String rotation has a 2-line solution: if s2 is a rotation of s1, then s2 is always a substring of s1 + s1.
  • Doubling the original string creates every possible rotation as a contiguous substring, turning the problem into a single in check.
  • O(n) time via built-in string search; O(n) space for the concatenated string, with a modular-indexing trade-off if space matters.
  • Over-engineering instinct fires when a keyword like "rotation" triggers generate-and-compare before you ask what rotation means structurally.
  • Problem reframing is the signal: instead of "which rotation matches?", ask "where does s2 appear if I write s1 twice?"
  • Narrating the trade-off out loud (space vs. time on the modular approach) is itself a scorable behavior, not just an afterthought.

Stop. Try this before reading another line. Thirty seconds, no hints.

Given two strings s1 and s2, determine whether s2 is a rotation of s1. Example: "erbottlewat" is a rotation of "waterbottle".

Write down your approach. This is a string rotation coding interview problem. The optimal solution is two lines.


What Your Brain Reaches For (And Why It Betrays You)

Most candidates start generating rotations.

for i in range(len(s1)): if s1[i:] + s1[:i] == s2: return True return False

This works. It's O(n²) once you account for string comparison inside the loop. It's also the kind of code that makes your interviewer scribble "brute force" in their notes while smiling politely at you.

Some candidates go further and reach for KMP, suffix arrays, or rolling hashes. These are genuinely excellent tools. You do not need any of them here.

A very patient interviewer watching a candidate spend 30 minutes on a "simple" problem

Your interviewer. Right now. While you debug your third nested loop.


The Two-Line String Rotation Solution

If s2 is a rotation of s1, then s2 will always appear as a substring of s1 + s1.

def is_rotation(s1: str, s2: str) -> bool: if len(s1) != len(s2): return False return s2 in s1 + s1

Two lines. Why does it work? Doubling s1 produces a string that contains every possible rotation as a contiguous substring. Concatenate "waterbottle" with itself and you get "waterbottlewaterbottle". Scan it and "erbottlewat" is right there. Every rotation is.

The in operator uses Python's built-in string search, O(n) average time. The length check handles differing lengths. Done.


Why You Missed It (Don't Worry, Everyone Does)

The word "rotation" fired a neuron. That neuron said "generate candidates." You opened your mental toolbox labeled STRINGS, grabbed the first thing that looked useful, and started looping. Pattern recognition is supposed to help you in interviews. Here it mugged you.

The step most candidates skip: ask what a rotated string looks like in relation to the original.

A rotation is a split and reattach. Not a shuffle. Not a transformation. Just cut it somewhere and tape the two halves back in the other order. Write two copies of the original back to back, and every possible split point appears as a substring. That's not a trick. That's just what the definition looks like if you draw it out.

When your approach requires a loop generating candidates to compare, pause. Ask: is there a transformation that makes the search trivial?

For rotation: instead of "which rotation of s1 matches s2?", ask "where does s2 appear if I write s1 twice?" One question leads to a loop. The other leads to a single substring check.

This reframe is the difference between the candidate who writes twenty lines and the one who writes two. Both might get the right answer. Only one signals efficient thinking.

If you catch that your approach is O(n²) mid-interview, say so out loud. Then ask whether a smarter observation exists before you start optimizing the brute force. That pause, narrated, is worth more than silently burning five minutes on an over-engineered loop. See why silence gets you rejected and how to avoid the most common interview traps.


The Follow-Up Questions (The Interviewer Isn't Done With You)

A good interviewer won't stop at the solution. Expect:

  • What is the time and space complexity? (O(n) time, O(n) space for the concatenated string)
  • Can you do it without allocating s1 + s1?
  • What changes if the strings contain Unicode?

The space question is worth thinking through before the interviewer asks. You can avoid the doubled string by simulating traversal across the conceptual s1 + s1 with modular indexing, keeping space at O(1), though that pushes worst-case time back to O(n²). Whether the trade-off makes sense depends on your constraints. Saying that out loud is the move.

The Unicode question is less about the algorithm and more about demonstrating that you know strings are not just ASCII. In Python 3 you're mostly covered. In C or C++ you're not. Knowing the difference, and mentioning it without being asked, is the kind of signal that sticks in a write-up.


The simplest-looking problems expose over-engineering instincts most cleanly. A hard problem forces you to think. An easy-looking one lets you rush. If you want to catch your own version of this before the interview does, SpaceComplexity runs voice-based mock interviews where you hear yourself explain your approach in real time, which is exactly when over-engineering becomes obvious.