Top 30 Modules Interview Questions and Answers

30 questions. Pick an answer, or open “Show the answer” to read it.

Answers are graded in your browser. Nothing is saved, and no XP or streak is earned here. The app keeps score.

1. Question 1 of 30

   What is the primary function of an __init__.py file in a Python directory?

   • aTo automatically import all sub-modules into the package's namespace.
   • bTo declare the package's version number and author information.
   • cTo explicitly designate the directory as a Python package.
   • dTo define the package's main entry point for script execution.
   Show the answer

   Answer: c · To explicitly designate the directory as a Python package.

   The card states that "Its mere presence turns a regular directory into an importable package," indicating its fundamental role is to mark a directory as a package. While it can contain code to import sub-modules (option A), this is an optional setup task, not its primary function of defining the package itself.

   Read the full bite: Python Packages: Grouping Modules with __init__.py

2. Question 2 of 30

   What does Node do first when it encounters require('fs')?

   • aMatches it against built-in core modules, which take precedence
   • bDownloads it from the npm registry on demand
   • cTreats it as a relative path from the current file
   • dSearches node_modules directories upward for an fs package
   Show the answer

   Answer: a · Matches it against built-in core modules, which take precedence

   Bare specifiers are checked against built-in core modules first; fs is compiled into the binary and resolves without touching node_modules. The package search only runs for non-core bare names.

   Read the full bite: Resolving core vs relative module specifiers

3. Question 3 of 30

   Which statement about using ES Modules instead of CommonJS in Node is accurate?

   • aCommonJS supports top-level await but ESM does not
   • bYou can require an ESM-only file directly from a CommonJS module
   • cimport is just an alias for require with identical semantics
   • dESM lacks __dirname by default and is enabled via type module or .mjs
   Show the answer

   Answer: d · ESM lacks __dirname by default and is enabled via type module or .mjs

   ESM omits __dirname and require, and is enabled by type module or the .mjs extension. import is not an alias for require, and only ESM supports top-level await.

   Read the full bite: Choosing between CommonJS and ES Modules

4. Question 4 of 30

   When module B requires module A in the middle of A's own loading, what does B receive?

   • aA freshly re-executed copy of A's exports
   • bAn error, since CommonJS forbids cycles
   • cA's exports object as populated so far, possibly incomplete
   • dAn empty object that updates synchronously when A finishes
   Show the answer

   Answer: c · A's exports object as populated so far, possibly incomplete

   CommonJS caches the exports object at load start and returns it as-is, so B gets whatever A has assigned up to that point. It is not re-executed, does not throw, and the reference is not retroactively backfilled.

   Read the full bite: Circular dependencies in CommonJS modules

5. Question 5 of 30

   According to the CommonJS mental model, what is the default state of variables and functions defined within a module file?

   • aThey are shared with other modules unless explicitly marked as private.
   • bThey are private to the module unless explicitly exported.
   • cThey are only accessible after being imported by another module.
   • dThey are globally accessible unless explicitly marked as private.
   Show the answer

   Answer: b · They are private to the module unless explicitly exported.

   The card states, "By default, all tools and materials (variables, functions) inside are private. To share a tool, you place it on a public shelf called exports." This means they are private unless explicitly exported. Options A and B describe the opposite of CommonJS's encapsulation, and D is incorrect because variables are accessible within their own module before any import.

   Read the full bite: CommonJS: Node.js's Original Module System

6. Question 6 of 30

   If module A requires B, and B subsequently requires A, what does Node.js provide to B for A's exports when A was the module initially loaded?

   • aAn empty object or a partially populated module.exports object from A.
   • bA null value, indicating that the dependency could not be resolved.
   • cA fully resolved module.exports object from A, as if A had finished executing.
   • dA runtime error, immediately halting execution due to the detected cycle.
   Show the answer

   Answer: a · An empty object or a partially populated module.exports object from A.

   To prevent an infinite loop, Node.js returns the module.exports object from A as it exists at that moment, which is often incomplete. It does not immediately crash or provide a fully resolved object, but rather an unfinished version that can lead to later TypeErrors.

   Read the full bite: Node.js Circular Dependencies: The Unfinished Export

7. Question 7 of 30

   In module example.com/shop, directory helpers/ contains files with package utils. What is the correct way to import and use ProcessOrder?

   • aImport example.com/shop/helpers and call helpers.ProcessOrder
   • bImport example.com/shop/helpers and call utils.ProcessOrder
   • cImport example.com/shop/utils and call utils.ProcessOrder
   • dChange the package clause to helpers, then import example.com/shop/helpers and call helpers.ProcessOrder
   Show the answer

   Answer: b · Import example.com/shop/helpers and call utils.ProcessOrder

   The import path is always the module path plus the subdirectory (helpers), while the package clause (utils) sets the qualifier used in code. Option A is wrong because it assumes the directory name becomes the code qualifier, a common beginner misconception.

   Read the full bite: Go package declaration, directory name, and import path relationship

8. Question 8 of 30

   For a public JavaScript library, what is the most critical reason to dual-publish both ESM and CJS formats?

   • aTo provide flexibility for developers who prefer dynamic module resolution over static declarations.
   • bTo ensure that projects using require() can successfully import the library's modules.
   • cTo allow consuming applications to choose between synchronous and asynchronous module loading.
   • dTo enable advanced tooling features like tree-shaking for all consumers, regardless of their module system.
   Show the answer

   Answer: b · To ensure that projects using require() can successfully import the library's modules.

   The card states that dual publishing provides maximum compatibility, ensuring code works for users with legacy systems reliant on CJS, as CJS cannot require() an ESM module. While ESM enables tree-shaking, dual publishing is not primarily for extending tree-shaking benefits to CJS consumers; it's for CJS compatibility itself.

   Read the full bite: ESM vs. CJS: Navigating JavaScript's Module Divide

9. Question 9 of 30

   You move a helper package into an internal directory to restrict its use to your module. Which statement about the effects is true?

   • aExternal modules are blocked from importing it by the compiler, while sibling packages in the same module can still import it freely
   • bIt provides the same module-level privacy as using lowercase unexported identifiers in the helper package
   • cIt hides the package from all other packages, including those within the same module
   • dIt is a naming convention without compiler enforcement, relying only on team discipline
   Show the answer

   Answer: a · External modules are blocked from importing it by the compiler, while sibling packages in the same module can still import it freely

   The Go compiler rejects imports of internal packages from outside the module, yet packages inside the same module may import them normally. Option B is tempting because unexported identifiers also limit visibility, but they only restrict access within a single package, not across packages in a module.

   Read the full bite: What is the purpose of the internal directory in Go?

10. Question 10 of 30

    When building a multi-file Rust crate, what is the key difference between mod and use?

    • ause is mandatory for accessing public items in another module, while mod determines whether the declared submodule is public or private.
    • bBoth mod and use insert new modules into the crate tree, but mod declares submodules while use re-exports them.
    • cmod declares external dependencies listed in Cargo.toml, while use brings those dependencies into the current scope.
    • dmod adds a module to the crate tree and tells the compiler where to find its source, whereas use merely creates a local shortcut to a path already in the tree.
    Show the answer

    Answer: d · mod adds a module to the crate tree and tells the compiler where to find its source, whereas use merely creates a local shortcut to a path already in the tree.

    mod tells the compiler to include a new module in the crate tree and locate its source file, while use only creates a local shortcut to an item already in that tree. Distractor A is wrong because use never inserts modules into the crate tree or declares anything new; calling both keywords imports is a common misconception.

    Read the full bite: Explain the difference between mod and use in Rust

11. Question 11 of 30

    To create reusable functionality that can be easily shared across different Rust projects, where should the core logic primarily reside?

    • aInside a library crate, typically rooted at src/lib.rs.
    • bAs a standalone package, without being part of any crate.
    • cWithin the src/main.rs file of a binary crate, as it's the entry point.
    • dIn a separate src/bin directory, allowing it to be compiled as an independent executable.
    Show the answer

    Answer: a · Inside a library crate, typically rooted at src/lib.rs.

    The card explicitly states, "When you want to create shared, reusable functionality for other projects, you build a library crate." Option C is incorrect because `main.rs` is for the executable's entry point, not for shared logic, which the card advises against.

    Read the full bite: Rust Crates: Your Unit of Compilation

12. Question 12 of 30

    To make a struct defined within a submodule vegetables (located at src/garden/vegetables.rs) accessible from the crate root (src/main.rs), which visibility declaration is absolutely necessary?

    • aNo pub declarations are needed if the use keyword is employed in the crate root.
    • bOnly the garden module needs pub, as submodules inherit visibility from their parents.
    • cOnly the struct itself needs to be marked pub, as use statements handle module visibility.
    • dThe vegetables module, the garden module, and the struct must all be explicitly marked pub.
    Show the answer

    Answer: d · The vegetables module, the garden module, and the struct must all be explicitly marked pub.

    The card states that 'Every pub keyword here is essential; without them, the modules and the struct would be private and inaccessible from main.rs.' This means all modules and the item itself in the path must be public. The 'use' keyword only creates a shortcut to an item's path; it does not grant public visibility.

    Read the full bite: Rust Modules: Your Code's File System

13. Question 13 of 30

    To make a function `my_func` nested within `mod inner` (which is inside `mod outer`) accessible from the crate root, what visibility is required?

    • a`my_func` and `mod inner` must be marked `pub`.
    • b`my_func`, `mod inner`, and `mod outer` must all be marked `pub`.
    • cThe entire crate must be explicitly declared `pub`.
    • dOnly `my_func` needs to be marked `pub`.
    Show the answer

    Answer: b · `my_func`, `mod inner`, and `mod outer` must all be marked `pub`.

    The card states that for an item deep inside a module tree to be accessible from the outside, "it and all of its parent modules in the path must be marked pub." Therefore, all modules in the path to `my_func` must be public. Option A is a tempting distractor because it makes the immediate parent public, but misses the higher-level parent module.

    Read the full bite: Rust Item Visibility: Private by Default

14. Question 14 of 30

    A module resides in the cli subdirectory of a repository rooted at github.com/acme/tool. If the team releases major version 3, which module path must go.mod declare?

    • agithub.com/acme/tool/cli/v3
    • bgithub.com/acme/v3/tool/cli
    • cgithub.com/acme/tool/cli
    • dgithub.com/acme/tool/v3/cli
    Show the answer

    Answer: a · github.com/acme/tool/cli/v3

    The card states that a module path encodes the repository root plus any subdirectory, and for major versions 2+ must end with the version suffix. Option C omits the required /v3 suffix, while Option D incorrectly places the version before the subdirectory instead of at the end of the full module path.

    Read the full bite: go.mod: Root of Go Module Identity

15. Question 15 of 30

    Given `src/lib.rs` declares `mod utils;` and `src/utils.rs` declares `pub mod helpers;`, where does Rust expect `helpers`'s code?

    • asrc/utils_helpers.rs
    • bsrc/helpers.rs
    • csrc/lib/utils/helpers.rs
    • dsrc/utils/helpers.rs
    Show the answer

    Answer: d · src/utils/helpers.rs

    The module system maps recursively; `helpers` is a submodule of `utils`, so its file is expected within the `utils` directory relative to `src`. Option B is incorrect because `src/helpers.rs` would be the location if `mod helpers;` was declared directly within `src/lib.rs`, not nested within `utils`.

    Read the full bite: Rust's Module-to-Filesystem Mapping

16. Question 16 of 30

    What is the primary benefit of organizing Go packages within an 'internal' directory?

    • aIt allows the package to be freely refactored or modified without affecting external module users.
    • bIt automatically generates API documentation for internal helper functions, making them easier to manage.
    • cIt guarantees that the package's functions are optimized for performance by the Go compiler.
    • dIt restricts access to the package's contents, preventing any other package, even within the same module, from importing it.
    Show the answer

    Answer: a · It allows the package to be freely refactored or modified without affecting external module users.

    The 'internal' directory's main purpose is to create a visibility barrier, allowing code within it to be refactored or changed without creating breaking changes for external modules that cannot import it. It does not prevent other packages within the same module from importing it, nor does it relate to performance optimization or documentation generation.

    Read the full bite: Go's `internal` Directory: Private by Convention

17. Question 17 of 30

    You manually add a require directive to go.mod and skip go mod tidy. Your build passes locally, but a teammate with a fresh module cache sees a security error. What explains this discrepancy?

    • aTidy downloads all module source code into the vendor directory. Skipping it means the teammate's build cannot find the packages because they are not vendored.
    • bTidy upgrades all dependencies to their latest compatible versions, which updates go.sum. Skipping it leaves outdated checksums that no longer match the proxy's current versions.
    • cTidy computes the minimal build list via MVS and ensures go.sum contains checksums for every module in that list, including indirect dependencies. Without it, missing checksums cause verification failures on fresh caches.
    • dTidy resolves imports only for non-test packages. Skipping it causes test dependencies to be omitted from go.mod, triggering a security error when those tests run on the teammate's machine.
    Show the answer

    Answer: c · Tidy computes the minimal build list via MVS and ensures go.sum contains checksums for every module in that list, including indirect dependencies. Without it, missing checksums cause verification failures on fresh caches.

    go mod tidy computes the minimal build list using Minimal Version Selection and populates go.sum with checksums for every module, which fresh caches need for verification. Distractor A is tempting but incorrect because tidy does not upgrade dependencies to their latest versions; it only resolves the minimal versions actually imported by the code.

    Read the full bite: What does go mod tidy do beyond adding dependencies?

18. Question 18 of 30

    Why can unit tests call private functions while integration tests cannot?

    • aUnit tests are compiled with #[cfg(test)], which grants access to private functions that are hidden from integration tests
    • bPrivate items are only visible to code inside the src directory, not to files in the top-level tests directory
    • cIntegration tests do not include #[cfg(test)], so Cargo hides private implementation details from them
    • dUnit tests are child modules in the same crate and can access private ancestor items, but integration tests are external crates
    Show the answer

    Answer: d · Unit tests are child modules in the same crate and can access private ancestor items, but integration tests are external crates

    Unit tests are child modules within the same crate, so they can access private items in ancestor modules via super::, whereas integration tests are compiled as separate external crates and are restricted to the public API. #[cfg(test)] only controls conditional compilation, not visibility, so distractor A conflates the annotation with privacy rules.

    Read the full bite: How does Rust differentiate unit and integration tests?

19. Question 19 of 30

    What state strategy best supports many teams managing dev, staging, and prod with the same IaC codebase?

    • aStoring state locally on each engineer's laptop
    • bOne shared global state file for everything
    • cA separate hand-written copy of the code per environment
    • dState split per environment and component, with the same versioned modules promoted via variables
    Show the answer

    Answer: d · State split per environment and component, with the same versioned modules promoted via variables

    Splitting state per environment and component limits blast radius and locking contention while reusing versioned modules keeps environments consistent. Shared state risks fleet-wide breakage, copies drift, and local state cannot be shared safely.

    Read the full bite: Strategy for large multi-team IaC projects

20. Question 20 of 30

    When would a developer be unable to utilize Sass built-in modules in their project?

    • aWhen their project requires programmatic color adjustments for a design system.
    • bWhen the project's build process relies on an older Sass compiler like LibSass.
    • cWhen they need to prevent function name collisions with user-defined functions.
    • dWhen performing complex grid calculations or responsive typography.
    Show the answer

    Answer: b · When the project's build process relies on an older Sass compiler like LibSass.

    The card explicitly states that older compilers like LibSass do not support the @use rule required for built-in modules, making them unusable in such projects. Options A, B, and D describe scenarios where built-in modules are beneficial and intended for use.

    Read the full bite: Sass Built-in Modules: Namespaced Power Tools

21. Question 21 of 30

    What is the primary runtime effect of enabling esModuleInterop when default-importing a CommonJS module?

    • aIt emits a helper that checks for __esModule and wraps the required module in { default: module } if it is missing.
    • bIt sets an __esModule property on the imported CommonJS module so default imports resolve correctly.
    • cIt transpiles the required CommonJS module into an ES module during compilation.
    • dIt permits default imports during type checking without altering the emitted JavaScript.
    Show the answer

    Answer: a · It emits a helper that checks for __esModule and wraps the required module in { default: module } if it is missing.

    esModuleInterop emits the __importDefault helper, which checks the required module for __esModule and wraps it in { default: module } when absent, ensuring .default exists at runtime. The option claiming it only relaxes type checking without changing emitted JavaScript is wrong because that describes allowSyntheticDefaultImports alone.

    Read the full bite: What problem does esModuleInterop solve for CommonJS imports?

22. Question 22 of 30

    Which strategy best mitigates the dual-package hazard when distributing both ESM and CJS builds?

    • aSetting the module field to the ESM build so Node prefers a single copy
    • bOmitting the exports field and relying on main for deterministic resolution
    • cCompiling a single file with runtime format detection and conditional exports
    • dAvoiding mutable module-level state or using a wrapper to unify state
    Show the answer

    Answer: d · Avoiding mutable module-level state or using a wrapper to unify state

    The dual-package hazard occurs when Node loads separate ESM and CJS copies that diverge mutable state, so eliminating such state or wrapping shared state prevents breakage. Option A is tempting because the module field is common in bundler configs, but Node.js ignores it entirely, so it cannot stop duplicate loading.

    Read the full bite: How do you configure a dual ESM/CommonJS package?

23. Question 23 of 30

    When authoring a .d.ts file for a legacy CommonJS library that does module.exports = fn, why is export = preferred over export default?

    • aThe two are interchangeable whenever esModuleInterop is enabled
    • bexport default forces consumers to use import = require() for correct type inference
    • cexport = permits additional named exports alongside it, unlike export default
    • dexport = models the entire module.exports assignment, while export default implies a runtime property named default that the library does not create
    Show the answer

    Answer: d · export = models the entire module.exports assignment, while export default implies a runtime property named default that the library does not create

    export = represents the whole module.exports object, while export default asserts a property literally named default that the CommonJS code never creates. Option A is a common misconception: the two are never interchangeable in declaration files because they describe different runtime shapes, even if interop flags paper over the import syntax.

    Read the full bite: How does export = differ from export default in TypeScript declarations?

24. Question 24 of 30

    When typing a legacy UMD library so it works both as a script-tag global and via CommonJS require, which pattern should the main .d.ts entry point use?

    • aMaintain two separate .d.ts files, one for global usage and one for CommonJS resolution.
    • bNest everything inside declare module "my-lib" and use export = MyLib within it.
    • cWrap the API in declare global and use export default MyLib for module consumers.
    • dUse export as namespace MyLib for globals, export = MyLib for the module, and define the API inside declare namespace MyLib.
    Show the answer

    Answer: d · Use export as namespace MyLib for globals, export = MyLib for the module, and define the API inside declare namespace MyLib.

    Option D correctly pairs export as namespace for script-tag globals with export = for CommonJS while keeping shared types in a namespace. Option C is tempting but wrong because declare global and export default misalign CommonJS shapes and bypass TypeScript's purpose-built UMD directive.

    Read the full bite: Type a UMD library for script tags and CommonJS/ESM

25. Question 25 of 30

    What is a key characteristic of Rust's co-located unit tests, placed within a #[cfg(test)] module in the same file as the code?

    • aThey are always compiled into the final production binary, increasing code coverage.
    • bThey can directly access and test private functions and internal logic of the module.
    • cThey automatically generate test cases for all public functions, reducing boilerplate.
    • dThey are primarily designed for verifying interactions between different public APIs across multiple crates.
    Show the answer

    Answer: b · They can directly access and test private functions and internal logic of the module.

    Co-located unit tests are designed to test individual pieces of code in isolation, including private functions, by using 'use super::*' within the test module. They are conditionally compiled with #[cfg(test)] and are excluded from the production binary, making option A incorrect.

    Read the full bite: Rust Unit Tests: Co-locating Tests with Code

26. Question 26 of 30

    According to best practices for custom frameworks, what is the primary technical reason for adding a unique prefix to all global symbols?

    • aTo ensure the framework's symbols are correctly identified by the dynamic linker at runtime.
    • bTo prevent static link errors that arise from duplicate symbol definitions.
    • cTo optimize the framework's loading speed and reduce its memory footprint.
    • dTo facilitate easier debugging by clearly distinguishing framework-specific code.
    Show the answer

    Answer: b · To prevent static link errors that arise from duplicate symbol definitions.

    The card explicitly states that unique prefixes are necessary to prevent the static linker from finding duplicate definitions, which would cause a build failure. While prefixing can aid in symbol identification (Option A) or debugging (Option D), its critical technical purpose is to avoid these specific static link errors.

    Read the full bite: Custom Frameworks: Best Practices for Sharing Code

27. Question 27 of 30

    Which statement accurately describes the function of an NgModule's exports array?

    • aIt registers services for dependency injection within the module's scope.
    • bIt specifies other modules or standalone components that this module requires.
    • cIt makes specific items from this module available for use by other modules that import it.
    • dIt lists the components, directives, and pipes that are used exclusively within this module.
    Show the answer

    Answer: c · It makes specific items from this module available for use by other modules that import it.

    The 'exports' array is used to make components, directives, or pipes declared within the NgModule available for use by other NgModules that import it. The other options describe the functions of 'declarations', 'imports', and 'providers' respectively.

    Read the full bite: Angular NgModules: Organizing Legacy Code

28. Question 28 of 30

    For a modern Node.js project that utilizes ECMAScript Modules (ESM) and relies on packages with 'exports' fields, which moduleResolution strategy should be configured?

    • aclassic
    • bcommonjs
    • cnode
    • dnodenext
    Show the answer

    Answer: d · nodenext

    The 'nodenext' strategy is specifically designed for modern Node.js projects using ESM and understanding the 'exports' field in package.json. The 'node' strategy, while a default, only mimics classic CommonJS resolution and would lead to 'Cannot find module' errors in this scenario.

    Read the full bite: TypeScript's Module Resolution Strategy

29. Question 29 of 30

    What problem does `import type` primarily solve in TypeScript compilation, especially with tools like Babel?

    • aFacilitating automatic type inference for dynamically loaded modules.
    • bPreventing naming conflicts between type and value imports.
    • cEnsuring type-only imports are completely erased from the final JavaScript output.
    • dEnabling runtime type validation for imported data structures.
    Show the answer

    Answer: c · Ensuring type-only imports are completely erased from the final JavaScript output.

    The primary purpose of `import type` is to explicitly inform the compiler that an import is for type-checking only, guaranteeing its complete removal from the final JavaScript output, which is crucial for isolated compilation. Option B is not the main problem it solves; options C and D describe functionality unrelated to `import type`.

    Read the full bite: TypeScript: Type-Only Imports and Exports

30. Question 30 of 30

    What is the primary modern use case for triple-slash directives in TypeScript?

    • aTo replace ES module import statements for better performance in large applications.
    • bTo explicitly declare global type definitions for libraries that expose types globally.
    • cTo manage runtime dependencies between JavaScript files in a project.
    • dTo include external JavaScript files directly into the compiled output without type checking.
    Show the answer

    Answer: b · To explicitly declare global type definitions for libraries that expose types globally.

    The card states that the most common modern use is /// <reference types="..." /> to make ambient type declarations available globally, such as for Jest. They are compiler instructions, not for managing runtime dependencies or replacing ES module imports.

    Read the full bite: Triple-Slash Directives: Compiler Hints in Comments