Top 30 Versioning Interview Questions and Answers
30 multiple-choice questions on Versioning, drawn from 30 bites out of the 53 tagged Versioning on Tezvyn. Answer them here or read straight down. Every question carries the correct option, why it is correct, and a link to the bite it came from.
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.
Question 1 of 30
A deployed fraud model degrades. Using immutable lineage best practices, what is the most reliable way to isolate data drift from a code bug?
Show the answer
Answer: a · Reproduce the exact training run by combining the manifest's commit SHA, dataset hash, and locked dependencies, then verify the metrics match production logs
Reproducing the full training context from the manifest proves the model still yields the same metrics, confirming that production degradation is due to data drift rather than a code bug. Option B is tempting because it uses the exact dataset, but swapping in the latest code introduces a new variable and breaks the lineage chain needed for a valid comparison.
Read the full bite: Why version code, data, and models in MLOps?
Question 2 of 30
Given a dependency written as ^1.4.2, which upgrade would npm refuse to install on its own?
Show the answer
Answer: b · 2.0.0, a major release
The caret allows updates below the next major, so anything under 2.0.0 is permitted, but 2.0.0 itself is excluded. The tilde would be the operator that also blocks 1.7.0.
Read the full bite: SemVer and the caret vs tilde range operators
Question 3 of 30
What is the primary reason to avoid using the "latest" tag for Docker images in production or CI/CD pipelines?
Show the answer
Answer: b · The image associated with the "latest" tag can be updated at any time, leading to non-reproducible builds and unexpected behavior.
The card explicitly states that the image 'latest' points to can change without warning, leading to unexpected failures or behavior drift, making builds non-reproducible. This mutability is the core issue, not that it's inherently unstable or automatically purged.
Read the full bite: Docker Image Tagging: Versioning for Containers
Question 4 of 30
Why is a service's advertised eleven-nines durability insufficient protection for critical object data?
Show the answer
Answer: c · It guards against hardware loss, not accidental deletion, corruption, or malicious removal
Eleven-nines durability addresses physical media failure, but a human or buggy process can still delete or overwrite objects. Versioning and object lock, not the durability number, protect against those threats.
Read the full bite: Protecting object storage from accidental loss
Question 5 of 30
A library updates from version 1.2.3 to 2.0.0. What does this change primarily signal to users?
Show the answer
Answer: b · Existing code using the library might break and require modifications.
A MAJOR version increment (from 1.x.x to 2.0.0) signals incompatible API changes, meaning existing code relying on the previous API may break. New backward-compatible features are MINOR changes, and bug fixes are PATCH changes.
Read the full bite: Semantic Versioning: A Contract for Your Code's Evolution
Question 6 of 30
To guarantee exact reproducibility of a historical training dataset after both schema and data have evolved in the feature store, what should a pipeline pin?
Show the answer
Answer: d · Both the schema version and the data timestamp or commit ID
Reproducibility requires pinning both the schema version and the data snapshot because schema evolution and data history are independent dimensions; pinning only the schema version would retrieve current data rather than the exact historical state used for training.
Read the full bite: How would you implement versioning for feature definitions in a feature store?
Question 7 of 30
What is the central risk of using one model's embedding as a feature for a downstream model?
Show the answer
Answer: c · Updating the upstream model shifts the feature space, degrading the downstream model unless versions are pinned and coordinated
The downstream model is tied to a specific embedding version's geometry, so an unpinned upstream change causes silent skew and degradation. Dimensionality and feature type are not the core problem.
Question 8 of 30
While developing on a feature branch, a team consumes an internal library that receives multiple daily updates. Which versioning strategy is most appropriate?
Show the answer
Answer: b · Use a SNAPSHOT version because it allows frequent updates without cutting formal releases
SNAPSHOT versions are mutable placeholders intended for feature branches and rapid iteration, allowing teams to share incremental builds without creating multiple immutable releases. Option A is tempting but wrong because RELEASE versions are immutable and never overwritten, so Maven does not re-download them to fetch changes.
Read the full bite: SNAPSHOT and RELEASE versions: differences and appropriate use
Question 9 of 30
In a hybrid Docker tagging strategy, what distinguishes the role of a Git SHA tag from a SemVer tag at production deployment time?
Show the answer
Answer: d · The Git SHA tag provides an immutable source-to-artifact mapping used in deployment manifests, while SemVer offers human-readable labels for promoted releases.
Git SHA tags are immutable pointers created on every build to provide exact source-to-artifact traceability in manifests, while SemVer tags are human-readable aliases added only to promoted releases. Distractor C reverses this workflow: SHA tags are generated automatically per build, and SemVer is reserved for promoted images.
Read the full bite: How do you version Docker images: Git SHA or SemVer?
Question 10 of 30
What is the fundamental distinction between a design system changelog and a raw git log?
Show the answer
Answer: b · A changelog translates technical changes into human-readable impact for consumers, unlike a raw git log.
The card states a changelog "translates code changes into human-readable impact" for consumers, serving as "release notes for your users." In contrast, a raw git log is for maintainers and contains raw technical details, not curated for consumer understanding.
Read the full bite: Design System Changelogs: For Humans, Not Machines
Question 11 of 30
A purely visual padding change to a Button is released as a new major version. Why does this not force existing consumers to upgrade?
Show the answer
Answer: d · Consumers' pinned or caret version ranges keep them on the prior major until they choose to bump
Semver lets consumers' dependency ranges hold them on the previous major; the new major coexists and is adopted only when a team updates its range. The other options describe mechanisms that do not exist in npm or Changesets.
Read the full bite: Releasing a breaking change without forcing upgrades
Question 12 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?
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.
Question 13 of 30
What is the fundamental structure of a Semantic Versioning number?
Show the answer
Answer: a · A three-part number: Major.Minor.Patch.
The card explicitly states that the core of Semantic Versioning is a three-part Major.Minor.Patch number. While some implementations may extend it to four parts, this is not its fundamental structure.
Read the full bite: Semantic Versioning: A Three-Part Numbering System
Question 14 of 30
Why might a button padding change that shifts consumer layouts be classified as a breaking change under SemVer?
Show the answer
Answer: a · The component's rendered visual output is part of its public contract with consumers
For a design system the rendered output is part of the contract, so a layout-shifting change breaks consumers and warrants a major bump or opt-in. Not every CSS change is breaking; a non-shifting tweak can be a patch.
Read the full bite: Classifying a visually breaking padding change
Question 15 of 30
In which release type is it appropriate to actually remove a deprecated component, per SemVer norms?
Show the answer
Answer: b · A major release, only after usage of the replacement is high
Removal is a breaking change, so it belongs in a major release and only after migration is largely complete. Patch and minor releases must not break consumers, so removing a component in either violates SemVer.
Read the full bite: Designing a component deprecation process
Question 16 of 30
Under which circumstance is a formal breaking change policy most essential for a software component?
Show the answer
Answer: b · When it is a shared asset consumed by multiple independent teams or applications.
A breaking change policy is crucial for shared assets with multiple consumers to manage dependency risk and ensure predictable evolution. It is explicitly stated as overkill for early-stage projects or those used by a single team, and it applies to internal shared assets as well as public APIs.
Read the full bite: Breaking Change Policy: Managing API Evolution
Question 17 of 30
When updating the design system's primary blue, why publish a new versioned package release rather than just rebuilding and pushing the CSS?
Show the answer
Answer: c · Semver lets consuming apps control when they adopt the change and test it
A versioned release lets each consuming app decide when to upgrade and run its own tests first. Pushing CSS without versioning forces the change on everyone instantly with no opt-in or rollback path.
Question 18 of 30
What is the main downside of versioning a design system as a single monolithic package?
Show the answer
Answer: c · Any change bumps the whole library, forcing consumers to absorb unrelated updates
With one version, even an isolated fix bumps the entire library, so consumers inherit unrelated and possibly breaking changes. Independent versioning addresses this but adds tooling and dependency complexity.
Question 19 of 30
A backward-compatible bug fix with no API change is released as which SemVer bump, and why?
Show the answer
Answer: d · Patch, because it corrects behavior without breaking existing usage
A patch covers backward-compatible bug fixes, signaling consumers can upgrade safely with no changes. A fix is not a new feature (minor) and is not breaking (major), so over-bumping would mislead consumers about upgrade risk.
Question 20 of 30
What is a primary risk of running two major versions of a component library in the same app at once?
Show the answer
Answer: d · Global tokens, CSS resets, and shared singletons from each version can collide
Isolation of global concerns is the hard part: unscoped tokens, resets, and shared context bleed between versions. Module resolution and TypeScript both handle multiple versions via aliasing, and browsers happily load multiple stylesheets.
Read the full bite: Coexisting major versions during migration
Question 21 of 30
A shared component library is most clearly worth its overhead when which condition holds?
Show the answer
Answer: c · Many products need the same component and a team will own and version it
Reuse pays off when several products share a stable need and someone owns the library's versioning; otherwise duplication is cheaper. A frequently changing, unowned, or product-divergent component makes the coordination tax exceed the savings.
Read the full bite: Shared component library versus per-product builds
Question 22 of 30
Which change to an API would most likely necessitate creating a new version?
Show the answer
Answer: d · Splitting a single 'address' field into 'street', 'city', and 'zipCode' fields.
The card states that 'breaking changes' alter data structures or endpoint behavior, citing splitting a 'fullName' field as an example. Splitting an 'address' field is analogous, requiring clients to adapt to new fields. Adding optional fields or new endpoints are non-breaking changes, and performance optimizations do not alter the API contract.
Read the full bite: API Versioning: Managing Change Without Breaking Clients
Question 23 of 30
Beyond transforming tokens, what does a complete multi-platform token pipeline also require?
Show the answer
Answer: a · Semantic versioning and per-platform package distribution so each ecosystem can pull updates
Consumers on different platforms need versioned packages published to their respective registries (npm, Maven, Swift Package) to consume updates safely. Manual copying and a universal package format are not viable, and dropping versioning removes change control.
Read the full bite: Versioning and distributing multi-platform tokens
Question 24 of 30
To reproduce a model six months later after the original data source was overwritten, what must the pipeline have captured at training time?
Show the answer
Answer: c · The Git commit hash, a content-addressable data version, and the exact container image digest
Full reproducibility requires immutable snapshots of code, data, and environment, so all three must be captured. Option B is tempting because versioned code and random seeds feel sufficient, but they cannot recover a dataset that has been overwritten or guarantee the same system environment.
Read the full bite: How would you design a reproducible ML training pipeline?
Question 25 of 30
A library at version 1.5.2 adds a new, backward-compatible feature and fixes a bug. What should the next version be?
Show the answer
Answer: b · 1.6.0
Adding a new, backward-compatible feature requires incrementing the MINOR version, and the PATCH version resets to 0. While a bug fix alone would increment the PATCH, the introduction of a new feature dictates the MINOR version increment and subsequent PATCH reset. Option D is incorrect because the PATCH version always resets to 0 when the MINOR version is incremented.
Read the full bite: Semantic Versioning: The MAJOR.MINOR.PATCH Contract
Question 26 of 30
What is the primary purpose of component feature flags within a design system?
Show the answer
Answer: a · To facilitate a gradual, controlled adoption of breaking changes before a major design system release.
The card explicitly states that component feature flags were created to "de-risk this process by allowing for a gradual, controlled rollout of breaking changes" before a major release. Option C is incorrect as the card warns against using flags as permanent configuration options.
Read the full bite: Component Feature Flags: Opt-in to Breaking Changes
Question 27 of 30
When would a design system team most likely opt for individual component versioning over whole library versioning?
Show the answer
Answer: c · When different product teams require maximum autonomy to update only the specific components they use.
Individual component versioning is favored when team autonomy is the highest priority, allowing teams to update specific components on their own schedule. Option D is incorrect because individual versioning can actually lead to dependency bloat and increased bundle size due to multiple versions of the same component.
Read the full bite: Design System Versioning: One Package or Many?
Question 28 of 30
What most often makes introducing a breaking change to a design system hard, beyond the code itself?
Show the answer
Answer: c · Many independent consumer teams upgrade on their own schedules, needing comms, guides, and migration tooling
The organizational reality is that you cannot force every team to upgrade at once, so early communication, migration guides, and codemods matter as much as code. Semver does signal breaks, and changelogs alone do not drive migration.
Read the full bite: Challenges of breaking changes in a design system
Question 29 of 30
A refactor removes a prop from the Button component. Under Semantic Versioning, how should this be released?
Show the answer
Answer: d · As a major release, with a changelog and migration guide
Removing a prop breaks the public API, which SemVer requires a major bump for, accompanied by migration artifacts. Patch and minor imply backward compatibility, which would silently break consumers on auto-update.
Read the full bite: Releasing a breaking Button change with SemVer
Question 30 of 30
A team renames a token and publishes it as a minor version bump, removing the old name. What is the core problem with this release?
Show the answer
Answer: a · A rename that removes the old name is breaking and requires a major bump
Removing or renaming a token breaks every consumer that references the old name, so it must be a major release. A minor bump signals backward-compatible additions, which misleads consumers into upgrading safely.
Read the full bite: Versioning and shipping design tokens via NPM
Could you explain these out loud?
That is what an interview actually tests. Tezvyn gives you questions like these with what the interviewer is really checking, the answer that lands, and the mistake that ends the conversation, in the four minutes before your next meeting.
The iPhone app is on the way
We are building it. Until it lands, nothing here is held back from you: every interview card, your saved cards, streaks and the job board all work in Safari, plus hundreds of free practice quizzes of thirty questions each. Sign in and it all carries over to the app the day it arrives.
Want it as an icon? Tap Share at the bottom of Safari, then Add to Home Screen. It opens full screen and the cards you have read stay available offline.