DEV Community

Cover image for The Object Reference Trap That Tricks Many Developers
Ebenezer
Ebenezer

Posted on

The Object Reference Trap That Tricks Many Developers

JavaScript Interview Puzzle #5

Over the past few days in this JavaScript Interview Puzzle series, we explored several small pieces of code that behave in surprising ways.

We looked at:

• The this keyword trap
• Type coercion surprises
• The JavaScript event loop

Each puzzle showed that JavaScript isn’t random.
It simply follows rules that we sometimes overlook.
Today’s puzzle looks even simpler.
But it reveals something extremely important about how JavaScript stores objects in memory.
Let’s see if this one tricks you.


The Puzzle

Look at the code below.

Before scrolling further, try to guess the output.

let a = { value: 10 };
let b = a;

b.value = 20;

console.log(a.value);
Enter fullscreen mode Exit fullscreen mode

What do you think JavaScript will print?

Many beginners say:

10
Enter fullscreen mode Exit fullscreen mode

Because they think a and b are separate objects.

But that is not what happens.

The real output is:

20
Enter fullscreen mode Exit fullscreen mode

Wait.

Why did changing b also change a?

To understand this, we need to look at how JavaScript stores data in memory.


Let’s Pause for a Simple Story

Imagine you and your friend both have a map to a treasure chest.
You don’t each have your own chest.
You both have a map pointing to the same chest.
Now imagine your friend goes to the treasure chest and replaces the gold inside.
When you open the chest later…
You see the same change.
Why?
Because both maps pointed to the same location.
Objects in JavaScript behave exactly like that.


Understanding the Code

Let’s walk through the code step by step.

First we create an object.

let a = { value: 10 };
Enter fullscreen mode Exit fullscreen mode

Now a points to an object in memory.

You can imagine it like this:

a → { value: 10 }
Enter fullscreen mode Exit fullscreen mode

The Important Line

Now we write:

let b = a;
Enter fullscreen mode Exit fullscreen mode

Many beginners think this creates a copy.

But it doesn’t.

Instead, JavaScript simply creates another reference to the same object.

Now both variables point to the same place.

a ──┐
    ├──> { value: 10 }
b ──┘
Enter fullscreen mode Exit fullscreen mode

Changing the Object

Now we run this line.

b.value = 20;
Enter fullscreen mode Exit fullscreen mode

This means:

“Go to the object that b points to and change its value.”

But remember — a also points to that same object.

So the object becomes:

{ value: 20 }
Enter fullscreen mode Exit fullscreen mode

Now when we run:

console.log(a.value);
Enter fullscreen mode Exit fullscreen mode

JavaScript prints:

20
Enter fullscreen mode Exit fullscreen mode

Because a and b are both looking at the same object.


Primitive Values Work Differently

Numbers, strings, and booleans behave differently.

Example:

let x = 10;
let y = x;

y = 20;

console.log(x);
Enter fullscreen mode Exit fullscreen mode

Output:

10
Enter fullscreen mode Exit fullscreen mode

Why?

Because primitive values are copied, not referenced.

So x and y become completely separate.


Why Interviewers Love This Question

This puzzle tests whether you understand:

• JavaScript memory behavior
• Object references
• Primitive vs reference types

Many bugs in real applications happen because developers accidentally modify shared objects.

Understanding references helps prevent those mistakes.


A Slightly Trickier Variation

Try predicting the result of this code.

let user = { name: "Alex" };

let admin = user;

admin.name = "Sam";

console.log(user.name);
Enter fullscreen mode Exit fullscreen mode

What do you think it prints?

Think about the treasure map story before running the code.


Final Thought

JavaScript often surprises developers not because it is complicated…

But because it behaves differently than we expect.

Objects are not copied automatically.

Instead, variables often act like maps pointing to the same location in memory.

Once you understand this rule, puzzles like this become easy to predict.

And more importantly, it helps you avoid subtle bugs in real projects.


Your Turn

Without running the code:

What do you think the variation example prints?

Write your guess in the comments before testing it.

Wrapping Up the Series

This puzzle also brings us to the end of this 4-day JavaScript Interview Puzzle series.
Over the last few days we explored:

• this context
• Type coercion
• The event loop
• Object references

If these puzzles made you pause and think, then they did their job.
JavaScript becomes much easier when we start understanding why the language behaves the way it does.
Thanks for reading and thinking through these puzzles with me.
We’ll continue exploring more JavaScript stories and concepts in future posts.

Until then, happy coding — and see you in the next story🖖.

Top comments (0)