Interview answer drill

Use this JavaScript interview question to rehearse a quick answer, common mistake, follow-up, and production pitfall.

Practice interview questions Follow JavaScript mastery study plan Practice more JavaScript interview questions

What does 'use strict' do in JavaScript?Frontend interview answer

HighIntermediateJavascript

By FrontendAtlas Team · Updated Apr 10, 2026

Interview focus

This JavaScript interview question tests whether you can explain JavaScript 'use strict': migration bugs, module defaults, and eval restrictions, connect it to production trade-offs, and handle common follow-up questions.

JavaScript 'use strict': migration bugs, module defaults, and eval restrictions explanation without falling back to memorized docs wording
Strict Mode and Use Strict reasoning, edge cases, and production failure modes
How you would answer the most likely JavaScript interview follow-up

Practice more JavaScript interview questions

Interview quick answer

'use strict' is mainly a migration and debugging tool: it turns sloppy-mode footguns into explicit errors. Strong answers compare accidental globals, silent failures, bare-function this, eval restrictions, and modern ES module defaults.

Full interview answer

The core idea

'use strict' turns on strict mode, a safer JavaScript execution mode that converts many silent bugs into explicit errors. The real value is migration and debugging: old code that used to limp along with accidental globals or sloppy this assumptions starts failing loudly.

In interviews, a strong answer is: strict mode reduces ambiguity, catches risky patterns early, and makes code behavior more predictable across runtimes.

JAVASCRIPT

// Sloppy mode
function sloppyShow() {
  leakedTotal = 10; // accidental global
  return this;      // window in browsers
}

const cfg = {};
Object.defineProperty(cfg, 'version', {
  value: 1,
  writable: false
});

function sloppyWrite() {
  cfg.version = 2;  // may fail silently
}

// Strict mode
function strictShow() {
  'use strict';
  leakedTotal = 10; // ReferenceError
  return this;      // undefined
}

function strictWrite() {
  'use strict';
  cfg.version = 2;  // TypeError
}

Behavior	Sloppy mode	Strict mode
Assigning undeclared variable	Creates accidental global	Throws `ReferenceError`
Plain function call `this`	Global object in browser (`window`)	`undefined`
Duplicate function parameters	Often allowed	SyntaxError
`with` statement	Allowed (discouraged)	SyntaxError
Some silent write failures	May fail silently	Throws `TypeError`

Strict mode intentionally removes legacy footguns.

Where to apply it

You can enable strict mode at file scope or function scope:

File-level: affects the entire script file.

Function-level: affects only that function body.

Also important: ES modules and class bodies are strict by default, even without writing 'use strict'.

JAVASCRIPT

// File-level strict mode
'use strict';

function a() {
  return this; // undefined in strict mode
}

// Function-level strict mode
function b() {
  'use strict';
  return this; // undefined here, even if outer file is non-strict
}

this behavior that surprises people

In strict mode, calling a function without an owning object keeps this as undefined. That prevents accidental writes to global scope and exposes binding bugs earlier.

JAVASCRIPT

function show() {
  console.log(this);
}

// Non-strict in browser: Window
// Strict: undefined
show();

Common breakpoints during migration

Implicit globals from missing let/const.

Legacy code using with.

Duplicate parameter names in old utility functions.

Code that expects sloppy-mode this fallback to global object.

Mutations that used to fail silently (readonly/non-extensible targets).

JAVASCRIPT

'use strict';

const cfg = {};
Object.defineProperty(cfg, 'version', {
  value: 1,
  writable: false
});

// cfg.version = 2;
// TypeError in strict mode (instead of silent failure in sloppy mode for many cases)

Interview-ready trade-off

Advantages: strict mode catches accidental globals, unsafe this assumptions, and silent write failures earlier. Cost: old script files may break during migration because they relied on sloppy-mode behavior. In modern ES module code you often get strict mode automatically, so the literal mostly matters in legacy scripts or function-scoped opt-ins.

Goal	Recommended practice	Why it helps
Prevent accidental globals	Use strict mode + `let`/`const`	Turns hidden runtime leaks into immediate errors.
Safer modern codebase	Prefer ES modules	Modules are strict by default and have clearer dependency boundaries.
Lower migration risk	Enable strict mode per file and run tests	Isolates failures and makes fixes incremental.

Strict mode is most effective when paired with linting and tests.

Follow-up: eval and modern code

Strict mode also changes some eval behavior and blocks older syntax like with. In ES modules and class bodies you already have strict semantics, so adding the literal there is usually redundant rather than harmful.

Interview one-liner

'use strict' opts JavaScript into a safer mode that rejects legacy error-prone behaviors, making bugs surface earlier and execution semantics more predictable.

Practical scenario
A checkout script accidentally assigns totalAmount = ... without declaration inside a helper. In non-strict mode this leaks a global and causes flaky cross-page behavior; in strict mode it throws immediately so the bug is fixed early.

Common pitfalls

Adding strict mode and only testing happy paths.
Assuming old callback code still has global this.
Mixing legacy scripts and modules without checking runtime boundaries.

Trade-off or test tip
Roll out strict mode incrementally by file, and add tests for scope errors, this binding, and readonly mutation paths.

Still so complicated?

Think of strict mode like turning on compiler warnings-as-errors for runtime behavior: less permissive at first, but much safer for long-term code quality.