How do you handle environment variables in Node.js? | Interview Question

Q: How do you handle environment variables in Node.js?

**Target Audience:** Engineers preparing for Node.js phone screens — no prior configuration-management experience assumed. **Difficulty:** Easy > **How to read this doc:** Concepts are explained in plain language first, then tagged with 📌 Interview term: . The string-coercion behavior below was **actually verified** on Node v24.19.0, not assumed from how JavaScript "usually" handles types. ## 1. Why This Even Matters — A Story First A form field that only accepts typed text will still show "42" if someone types the digits 4 and 2 — even though a human reading it assumes it means the number forty-two. Nothing on the form itself distinguishes "the text that looks like a number" from "an actual number" until something explicitly parses it. `process.env` is exactly that field: everything on it is text, always, no matter what value conceptually "should" be there. ## 2. The Core Idea 📌 **Interview term: `process.env`** is a plain object exposing the process's environment

01

Understand the problem

Question presented to candidate: "Your app reads process.env.PORT and passes it straight to app.listen(). A teammate says this sometimes breaks in a subtle way. What is the bug, and how do you handle environment variables correctly?"

What a strong answer should cover:

process.env is a plain object exposing the process's environment variables — set by the shell, a .env loader, a container orchestrator, or the CI system — as the primary way Node.js applications receive runtime configuration (ports, secrets, feature flags, environment name).
📌 The precise, verifiable gotcha: every value on process.env is always a string, even if something elsewhere assigns it a number — process.env.NUM = 42 reads back as the string "42", typeof confirmed as "string", not the number 42. Comparisons like process.env.PORT === 3000 are always false; Number(process.env.PORT) or parseInt is required first.
Reading a variable that was never set returns undefined (not an error, not an empty string) — this is why config-validation code typically checks explicitly for undefined at startup rather than trusting a value silently exists.
Since Node 20.6, the native --env-file CLI flag can load a .env file straight into process.env with no external package required — covered in full, with its own verified execution, in the dedicated --env-file question; dotenv remains relevant for interpolated values or multi-file layering that the native flag does not do.
Values should be validated at startup, not read ad hoc throughout the codebase — failing fast with a clear error for a missing required variable is far preferable to a confusing runtime failure deep inside request handling.
Secrets specifically should never be committed in a .env file checked into version control — a good answer distinguishes "environment variables as a mechanism" from "how the actual secret values get to that environment safely" (a secrets manager, CI-injected variables, etc.), which is a separate, larger operational concern.

Clarifying questions expected:

"Is this config that varies by environment (dev/staging/prod), or an actual secret?" — secrets warrant more careful handling than plain config.
"Does the deployment platform already inject environment variables (a container orchestrator, a PaaS), or does the app need to load a .env file itself?" — decides whether --env-file/dotenv is even relevant here.

Code / implementation expected: Yes — demonstrating the string-coercion gotcha directly, and a small startup-validation pattern, is the concrete, convincing part of the answer.

environment variablesconfigurationsecurity

02

Attempt it yourself

Sketch your approach before reading the solution — that's what interviews test.

Nudge consolestandby

Stuck? Beam a request up — the console returns a conceptual nudge that guides your logic without spoiling the implementation.

03

Study the solution

Target Audience: Engineers preparing for Node.js phone screens — no prior configuration-management experience assumed. Difficulty: Easy

How to read this doc: Concepts are explained in plain language first, then tagged with 📌 Interview term:. The string-coercion behavior below was **actually

Solution ready — 2 min read

Classified // press E to declassify

04

Read the code

The string-coercion gotcha and a missing-variable startup-validation pattern, both actually run

process.env.NUM = 42;
console.log(typeof process.env.NUM, process.env.NUM);
// string 42   <- NOT the number 42

console.log(typeof process.env.MISSING_VAR);
// undefined   <- no throw

// Startup validation pattern:
const required = ["DATABASE_URL", "PORT"];
for (const key of required) {
  if (process.env[key] === undefined) {
    throw new Error(`Missing required environment variable: ${key}`);
  }
}
const port = Number(process.env.PORT); // parsed explicitly — comparing the raw string to a number is always false

05

Join the discussion

Discussion (0)

Sign in to join the discussion.

No responses yet. Be the first to share what you think.