First compilerOptions to set after tsc --init

WHY THIS MATTERS A fresh tsconfig has many commented options, and the first few you set shape the project's safety and output for everyone after you. Interviewers want practical judgment, not a recital of the whole file.

A GOOD ANSWER COVERS strict comes first. It is an umbrella that turns on noImplicitAny, strictNullChecks, strictFunctionTypes, and more, which is where TypeScript earns its value by catching null and undefined bugs and untyped parameters. Keeping it on from day one avoids a painful retrofit later. target is next; it sets the JavaScript version TypeScript emits, so you pick one your runtime supports, for example a modern ES version for current Node or browsers, balancing new syntax against compatibility. module and moduleResolution align the output and resolution strategy with your environment, such as NodeNext for modern Node or a bundler setting when using Vite or esbuild. Many also set outDir and rootDir so compiled files land in a clean folder separate from source, plus esModuleInterop for smooth CommonJS imports.

COMMON WRONG ANSWERS Turning strict off to silence errors, which discards the main benefit. Listing options like skipLibCheck without explaining the trade-off. Setting an ancient target that strips useful syntax for no reason. Mismatching module with the runtime, causing import failures.

LIKELY FOLLOW-UPS What individual flags does strict enable? When would you use NodeNext versus a bundler resolution? Why might you enable noUncheckedIndexedAccess beyond strict? What does esModuleInterop fix?

ONE CONCRETE EXAMPLE For a Node service you set strict true to catch null bugs, target to a current ES version matching your Node runtime, and module plus moduleResolution to NodeNext so ESM imports resolve correctly. You add outDir dist and rootDir src so source and compiled output stay cleanly separated. The result is a config that fails fast on type errors and emits JavaScript your runtime can actually run.