Q141: Strict Mode and Safer JavaScript Semantics

What Interviewers Want To Evaluate

This question checks whether you understand how JavaScript tightened unsafe historical behavior. Interviewers want "use strict", accidental globals, this binding differences, assignment errors, duplicate parameters, modules being strict by default, and why strict mode still matters in legacy code.

Senior answers should connect strict mode to safer runtime behavior, debugging, and migration.

Short Interview Answer

Strict mode is a JavaScript mode that turns some silent failures into errors and removes or restricts unsafe language behavior. It prevents accidental globals, changes unbound this in functions from the global object to undefined, rejects duplicate parameter names, and makes assignments to non-writable properties throw. ES modules and classes are strict by default, so modern code often uses strict semantics automatically.

Detailed Interview Answer

Strict mode can be enabled in a script or function with:

"use strict";

Modern ES modules are strict automatically.

export function run() {
  // strict semantics already apply
}

This means many modern apps are already using strict mode even if the directive is not visible.

Accidental Globals

Without strict mode, assigning to an undeclared variable can create a global variable in sloppy scripts.

function save() {
  userName = "Asha";
}

Strict mode throws instead.

"use strict";

function save() {
  userName = "Asha"; // ReferenceError
}

This catches a class of painful bugs.

this Binding

In sloppy mode, a plain function call can bind this to the global object.

function showThis() {
  return this;
}

showThis();

In strict mode, this remains undefined for an unbound function call.

This is safer because accidental global access becomes obvious.

Assignment Failures

Strict mode makes certain failed assignments throw.

"use strict";

const user = {};

Object.defineProperty(user, "id", {
  value: "u1",
  writable: false,
});

user.id = "u2"; // TypeError

Without strict mode, this kind of assignment may fail silently.

Duplicate Parameters

Strict mode rejects duplicate parameter names.

"use strict";

function createUser(id, id) {}

This avoids confusing argument binding.

delete Restrictions

Strict mode rejects deleting plain identifiers.

"use strict";

let count = 1;
delete count; // SyntaxError

Deleting object properties is still allowed when property descriptors permit it.

eval and with

Strict mode restricts some dynamic features. The with statement is not allowed.

"use strict";

with (object) {}

with makes scope resolution ambiguous and blocks optimization.

Modules and Classes

ES modules and class bodies run in strict mode automatically.

This is one reason strict mode feels less visible in modern codebases.

class User {
  method() {
    // strict semantics
  }
}

Legacy Code Migration

Strict mode can expose hidden bugs in old scripts.

Migration should be tested because behavior changes may surface:

implicit globals
sloppy this binding
silent assignment failures
duplicate params
use of with
arguments quirks

This is good, but it can require cleanup.

Common Mistakes

A common mistake is thinking strict mode is only old trivia. It still explains module behavior, this, and legacy bugs.

Another mistake is assuming strict mode fixes all unsafe JavaScript behavior. It improves semantics, but it is not a security sandbox.

Senior Trade-Offs

Modern projects should use modules, TypeScript, linting, and tests alongside strict semantics.

Strict mode catches runtime hazards. TypeScript catches many static contract issues. Linters catch style and risky patterns. They complement each other.

Code or Design Example

function runPlugin(plugin) {
  "use strict";

  return plugin.execute();
}

For modern systems, plugin code still needs isolation and validation. Strict mode alone is not enough.

Debugging Workflow

When strict mode changes behavior:

check whether file is a module
check implicit global assignment
check unbound this
check non-writable property assignment
check duplicate parameters
check legacy with or eval patterns
add tests around changed behavior

Interview Framing

Explain strict mode as safer semantics that turn silent problems into errors. Then mention modules/classes are strict by default.

Revision Notes

Strict mode removes unsafe historical behavior and makes many mistakes fail loudly.

Key Takeaways

Strict mode is part of why modern JavaScript is safer than old script-style JavaScript, but it is only one layer.

Follow-Up Questions

1. How do you enable strict mode?
2. Are ES modules strict by default?
3. What happens to accidental globals?
4. How does strict mode affect this?
5. What assignment failures become errors?
6. Why are duplicate parameters rejected?
7. Why is with forbidden?
8. Does strict mode sandbox code?
9. How does strict mode relate to TypeScript?
10. What can break during legacy migration?

How I Would Answer This In A Real Interview

I would say strict mode makes JavaScript safer by turning silent mistakes into errors and removing confusing behavior. I would mention accidental globals, unbound this, failed assignments, modules being strict by default, and legacy migration concerns.