Free lesson · JavaScript Basic to Advance

Interview Lens: Control Flow Patterns

Easy5 min read

The Question

Control flow rarely shows up as a single question in interviews. Instead, it shows up everywhere — in every coding problem, in every solution you write, in every "can you walk me through your approach" moment. The question isn't always "explain control flow." The question is "do you write code that uses control flow well?"

That said, three specific control-flow questions come up often enough to prepare for:

"Write FizzBuzz." (The classic warm-up.)

"Given this array, find [some specific element / pattern / value]. Walk me through your approach."

"What's the difference between forEach and map?" (Often paired with filter and reduce.)

Arun here. Two years out of Anna University, currently at Apple iOS Frameworks. Before Apple, I had 14 rejections. Most of them ended on control flow in some form — not because the question was "explain a for loop," but because the iteration choices I made during a coding problem signaled what level of JavaScript I was at.

Why They Ask It

Control flow questions are about code judgment, not syntax memorization. An interviewer assumes you know how loops work. What they're testing:

Signal 1: Do you reach for modern idioms or stay stuck in 2010? A candidate who writes for (let i = 0; i < arr.length; i++) for every iteration is a candidate who learned JavaScript years ago and never updated. A candidate who reaches for filter, map, reduce, find, some is current. Both candidates may know the same language, but one reads like a senior developer and the other doesn't.

Signal 2: Do you choose the right tool for the situation? Some problems genuinely need a classic for loop — two-pointer techniques, manual index manipulation, optimization-sensitive inner loops. Some problems are cleaner with map or filter. A candidate who only knows one tool reaches for it everywhere. A candidate who knows several picks the right one.

Signal 3: Can you reason about edge cases? Empty arrays, single-element arrays, very large arrays, duplicates, negatives — your loop should handle all of them correctly. Interviewers will throw edge cases at you and watch how you adapt.

I'll be honest: the first time someone asked me to solve a problem on a whiteboard, I wrote a triple-nested for loop because that's what I'd practiced on Codeforces. The interviewer's silence after I finished told me everything. The solution was correct. The style was not what they were looking for.

The Wrong Answers

Warning: The control-flow mistakes interviewers see most often.

Using a classic for loop for everything. When the problem is "transform this array into a new array," map is clearer than a for loop with manual push calls. Writing for (let i = 0; i < arr.length; i++) { result.push(...) } instead of arr.map(...) signals you haven't fully internalized modern JavaScript.

Trying to break out of forEach. A candidate who writes a forEach and tries to "exit early" with return doesn't realize forEach ignores the return. The interview ends up with the interviewer pointing out the bug, which is not how you want to spend interview time. If you might need to stop early, use for...of with break, or use find / some.

Off-by-one errors under pressure. Loops with i <= length instead of i < length. Loops that start at 1 instead of 0. These mistakes don't mean a candidate doesn't know loops — they mean the candidate didn't double-check the boundaries before claiming the solution was done. Always test with empty array, single element, and a small array to catch off-by-one errors.

The Right Answer

When an interviewer asks about iteration choices, three layers depending on depth.

The 30-Second Answer

"For most array iterations, I reach for the appropriate array method. map when I'm transforming into a new array of the same length. filter when I'm keeping a subset. reduce when I'm combining into a single value. forEach when I'm just visiting each element for side effects. I use for...of when I might need to break out early, and a classic for loop when I need explicit index control — usually for two-pointer or sliding-window patterns."

That's enough for a quick conceptual check.

The 2-Minute Answer

Build on the above:

"The reason modern array methods are preferred is that they describe what you're doing instead of how you're doing it. numbers.filter(n => n > 0).map(n => n * 2) reads as 'positives, doubled.' The equivalent classic loop with manual pushing reads as a mechanical sequence — readers have to trace the logic to understand the intent.

That said, the array methods aren't always right. forEach can't break early, so if you might need to stop iteration before the end, you need for...of. If you're doing something with explicit index relationships — like comparing arr[i] and arr[i+1] in a sliding window — a classic for loop is clearer than trying to fit that pattern into reduce. And there are performance considerations in tight inner loops where the function-call overhead of forEach matters, though for most code this difference is negligible.

The skill is matching the tool to the problem. A solution that uses for loops everywhere is rigid. A solution that uses array methods everywhere is sometimes forcing the wrong shape. Reading code well means recognizing which one the situation calls for."

This is what a senior interview wants to hear.

The Deep Dive

For senior or staff interviews where the conversation goes deeper:

"At the engine level, there's a difference between the methods. forEach, map, filter, and reduce all invoke a callback function per element, which adds function-call overhead — though modern engines like V8 inline these aggressively when the callback is simple. Classic for loops have no callback overhead at all.

For most code this is irrelevant — the overhead is measured in nanoseconds per call. But in performance-sensitive code — large arrays processed in tight loops, hot paths in rendering or simulation — the choice can matter. Profile before optimizing. Don't preemptively choose for loops everywhere for performance reasons that don't apply to your code.

The other consideration is immutability. map and filter return new arrays without modifying the original. This is desirable in functional-style code and in React-style state management, where mutating arrays in place causes subtle bugs. Classic for loops with push or in-place mutation can introduce bugs that array methods naturally avoid.

For interviews at the senior level, the conversation is often about why a particular choice was made, not just what was chosen. Being able to articulate the tradeoffs — readability, performance, immutability — signals you're not just using the tools but understanding them."

The FizzBuzz Trap

FizzBuzz is the most famous warm-up problem in technical interviews. The naive version isn't hard:

for (let i = 1; i <= 15; i++) {
  if (i % 15 === 0) {
    console.log("FizzBuzz");
  } else if (i % 3 === 0) {
    console.log("Fizz");
  } else if (i % 5 === 0) {
    console.log("Buzz");
  } else {
    console.log(i);
  }
}

What interviewers actually watch when you solve it:

Do you check 15 first, or 3 first? Checking 3 first means you'd print "Fizz" for 15 and never reach the "FizzBuzz" branch. Some candidates get this wrong. The fix is either checking 15 first, or building the output by concatenation: let output = ""; if (i % 3 === 0) output += "Fizz"; if (i % 5 === 0) output += "Buzz"; console.log(output || i);. The second approach is more elegant and easier to extend if the problem grows (FizzBuzzBazz on multiples of 7?).

Do you hand-roll modulus logic, or do you reach for it cleanly? Some candidates try to track multiples manually instead of using %. That's a code smell.

Do you parameterize the function? A senior candidate might write function fizzBuzz(start, end) instead of hardcoding 1 to 15. This signals they think in functions, not in scripts.

FizzBuzz is a five-minute warm-up that interviewers use to calibrate their next question. Get it right, get it cleanly, and they move on to harder material.

The Follow-Ups

Interview: What the interviewer asks next after you've answered well.

"What's the difference between forEach and map?" forEach runs a function for side effects and returns undefined. map transforms each element and returns a new array. Functionally, the difference is whether you care about the return value.

"What's the difference between filter and find?" filter returns an array of all matching elements. find returns just the first match (or undefined if none). Use find when you know you only need one.

"Can you use await inside forEach?" Trick question. Technically yes, but forEach doesn't wait for promises. The async functions all run in parallel and the loop completes before any of them finish. Use for...of with await for sequential async iteration. We cover this in Module 9.

"What about performance? When is a classic for loop faster than map or forEach?" In tight inner loops over very large arrays, the function-call overhead of array methods can matter. But always profile before optimizing — the difference is rarely meaningful in real code.

"How would you iterate over an object's keys?" Object.keys(obj) gives you an array of keys. Then use forEach, map, or for...of on it. We cover this in Module 7.

The Founder Moment

One interview that taught me a lot was at a startup in Bangalore — I think interview number nine of my fourteen-reject streak. The problem was "given an array of user objects, find the youngest one named 'Olena.'" I wrote a triple-nested approach: filter for the name, sort by age, take the first.

The interviewer asked me to walk through it. While walking through, I realized I was doing two passes over the array when one would do. I corrected mid-explanation to a reduce that tracked the youngest match in a single pass.

The interviewer didn't say anything during the correction. After the interview ended, I assumed I'd failed. But the rejection email I got two days later actually said the opposite — the interviewer's note was that my correction showed self-awareness and willingness to refactor under pressure. The reason for the rejection was a different question (system design) that I'd bombed.

What I took from that: interviewers aren't grading your first solution. They're grading the conversation around it. Writing perfect code in silence is worse than writing decent code and improving it out loud. Show your thinking. Catch your own bugs. Course-correct visibly. That's what control flow questions are actually testing, and it's the meta-skill that carried me through to Apple.

Back to JavaScript Basic to Advance