The Interview Question That Was Never Really About Code
During my time at Reason, there was this one technical interview exercise that consistently threw candidates off, not because it was difficult, but because the motive behind it wasn’t immediately obvious.
I’ve never been a fan of coding tests, and to be honest, I still aren’t. In the real world, between modern IDEs and agentic development, we’re surrounded by helpful guardrails. Syntax hints. Autocomplete. Linting. It’s practically impossible to write bad code quickly. Yet there we were, asking people to solve a tiny coding problem anyway, not to check their fluency in JavaScript syntax, but to hear how they thought out loud. How they unpacked the problem statement. How they navigated toward the end goal with clarity (or at least, with a sense of direction).
We’d stand them in front of a whiteboard and say, using JavaScript notation: "How would you reverse an array without using array.reverse?" Same spirit in other languages. Then we’d talk through it together.
Most people got a little flustered, it was an interview, after all, so any syntax hiccups didn’t matter. We weren’t looking for perfectly written code. We were looking for the thinking.
...And that’s when things always got interesting.
Candidates would usually start with in-place solutions, but we knew what was coming, as the example array always had an odd number of elements (or one element would be added or removed). Cue the classic off-by-one issue. When we asked then to step though [n] itterations, people would catch it, or not, or fall into the familiar loop of “Wait… hang on… why is this not lining up?” That’s when placeholder arrays started appearing on the whiteboard, and we’d discuss the trade-offs of that extra overhead.
In all my time running that exercise, only a couple of people never arrived at a working solution. And honestly, that wasn’t the part I found most telling. What stood out was how people handled the moment, because everyone know interviews are just pressure masquerading as friendly chats.
Some candidates were wonderfully open, narrating their thoughts as they moved through the logic. Others were quiet, methodical, almost meditative in how they approached each step. And then there were those who powered ahead with total confidence in a completely wrong solution or treating the exercise like a race they simply had to win, dismissing the whole thing as beneath them.
To many, it looked like a weird detour in an otherwise normal interview. But this tiny pop quiz revealed a lot: how someone collaborates, communicates, and breaks down a problem. How they make sense of ambiguity. How they reach for clarity.
Was it a good interview question? Would I use it again? Honestly… I’m still undecided. Tech evolves, tools evolve, expectations evolve, but the need to articulate your thinking clearly? That part never goes out of style.
Whilst my story ends, the technical detail follows below
To keep things fair, I made sure I'd solved this question in multiple ways myself. If I'm going to ask someone to do something, the least I can do is show up having done the homework too.
The Classic
function oldSchool(arr){
// using a temp array
let tempArr = [];
for (var i = arr.length; i > 0; i--) {
tempArr.push(arr[i - 1]);
};
return tempArr;
}This one shows a solid understanding and is usually the first step towards the answer, but when asked how you would do it without creating another array, people would pause. It's clean, readable, and gets the job done, just not in place.
The In-Place Swap (For Loop)
function oldSchoolSwap(arr){
// for half the array
for (var i = 0; i < arr.length / 2; i++) {
// set temp existing value, and the inverse position
let tmp = arr[i], negIndex = arr.length - i - 1;
// swap inverse value
arr[i] = arr[negIndex]
// replace existing value
arr[negIndex] = tmp
};
return arr;
}This is where things get interesting. Swapping in place by only iterating through half the array—elegant and efficient. This is usually where candidates would hit that off-by-one issue with odd length arrays, but once they got it, you could see the lightbulb moment.
The In-Place Swap (While Loop)
function oldSchoolSwapWithWhile(arr){
let start = 0;
let end = arr.length - 1;
let temp;
while (start < end) {
temp = arr[end];
arr[end] = arr[start];
arr[start] = temp;
start++;
end--;
}
return arr;
}Same concept as the for loop version, but using a while loop with two pointers.
The Push-Pop Approach
function pushPop(arr){
let newArray = [];
while (arr.length) {
newArray.push(arr.pop());
}
return newArray;
}Use pop() to pull from the end while building a new array. It's destructive to the original array, which some candidates didn't realize until we pointed it out. A good teaching moment about side effects.
The Push-Then-Slice Trick
function oldSchoolPush(arr){
// push to end of array
for (var i = arr.length; i > 0; i--) {
arr.push(arr[i - 1]);
};
// return second half of array
return arr.slice(arr.length/2);
}This one made me smile the first time I saw someone do it as I had thought about it myself before too. Push everything to the end, then slice off the second half. It works, but it's a bit of a roundabout way to get there. Creative problem-solving, though.
🤔 Below are some of the other ways I had thought to do the exercise. Unfortunately, looking back now I can't remember if these ones had been tried by candidates.
The Shift-Splice Method
function shiftReverseInPlace(arr){
let i = arr.length;
// till we run out of array
while (i--) {
// remove the last element from the array and splice to
// insert it in the new location
arr.splice(i, 0, arr.shift());
}
return arr;
}This one is… interesting. Using shift() and splice() together feels like using a sledgehammer to crack a nut, but it does work. Not the most performant approach I explored, but it was fun to think through.
The ES6 Destructuring Swap
function notationSwitchInPlace(arr){
// use es6 notation to swap values in place
for(let i = 0, j = arr.length-1; i < j; i++, j--){
[arr[i], arr[j]] = [arr[j], arr[i]];
}
return arr;
}Modern JavaScript at its finest. The destructuring assignment makes the swap beautifully concise. This was one I was particularly proud of when I first worked it out, but if you're using shorthand please make sure you add comments as it's not quite skim readable.
The Reduce with Concat
function reduceConcat(arr){
// b is the reduced value and defaults to []
// a is the current item
return arr.reduce((a, b) => [b].concat(a), [])
}Building the array backwards by concatenating each new element to the front. It works, but the array creation on each iteration isn't the most efficient. Still, I liked the elegance of it.
The Reduce with Spread
function reduceSpread(arr){
// same as reduceConcat, but we use spread ... to do the concat
return arr.reduce((a, b) => [b, ...a], [])
}Same idea as the concat version, but using the spread operator. More modern, arguably more readable. Both are fine solutions if you're okay with creating a new array.
The Reduce with Unshift
function reduceUnshift(arr){
// as part of our reduce, push the value to the start of the array
return arr.reduce((a,b) => {
a.unshift(b);
return a;
}, []);
}Using unshift() to build the reversed array. Simple and straightforward, though unshift() can be less performant than push() for large arrays.
The ReduceRight Approach
function reduceRight(arr){
// reduceRight accumulates an array (from right-to-left)
return arr.reduceRight((a, b)=>{
a.push(b);
return a;
}, []);
}This one is elegant. reduceRight naturally processes from the end, so you just push each element as you go. It's almost cheating, but it's not array.reverse(), so it counts.
🚫The Sort Hack
function sortHack(arr){
// sort lower every time
// only works for arrays smaller than 10 items due to native algorithms
return arr.sort(()=>1)
}The cheeky solution. Using sort() with a comparator that always returns 1, which should reverse the array. But here's the catch: it only works reliably for arrays smaller than 10 items due to how JavaScript's native sort algorithm works. Clever, but not reliable. I included it more as a curiosity than a real solution.
The Code Golf
function codeGolfTony(arr){
// [...arr] clones the array, .map(arr.pop, arr) pops the array
// and push it to a 'new' array, which results in a reversed array.
return [...arr].map(arr.pop, arr)
}This is the kind of solution that makes you pause and think "wait, does that actually work?" It does, but it's destructive and relies on some JavaScript quirks. Impressive for its brevity, but probably not something you'd want in production code. I'm not sure where I first saw this one, but it stuck with me.