Top 30 Migration Interview Questions and Answers
30 multiple-choice questions on Migration, drawn from 30 bites out of the 32 tagged Migration 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
Which migration step should teams prioritize first to reduce memory leaks when unifying Android reactive streams?
Show the answer
Answer: d · Replace unsafe lifecycle subscriptions with lifecycle-aware coroutine scopes like viewModelScope
The card identifies replacing unsafe lifecycle subscriptions with scopes such as viewModelScope as the top priority for high-leak surfaces. Mapping operators first does not fix the lifecycle mismatches that directly cause undisposed subscriptions and memory leaks.
Read the full bite: Unify Android EventBus and RxJava with Kotlin Flow
Question 2 of 30
An Angular app suffers from both excessive backend requests during username checks and bloated bundles from legacy ngIf/ngFor usage. Which paired approach best resolves both issues?
Show the answer
Answer: a · Debounce async validators in Signal Forms and migrate structural directives to Control Flow syntax
The correct paired approach is debouncing Signal Forms async validators to stop redundant backend calls and migrating legacy structural directives to Control Flow syntax for bundle and runtime gains. The most tempting distractor suggests using only synchronous validators and standalone components, but synchronous validators cannot check username availability against a backend, and standalone components do not replace legacy ngIf or ngFor directives.
Read the full bite: Angular 21.1 ships with Signal Forms debounce patterns
Question 3 of 30
What single element most reduces churn when documenting a breaking API change for developers?
Show the answer
Answer: d · Concrete before-and-after migration steps for each breaking change
Developers churn when they cannot see how to fix their code; explicit before-and-after migration steps give a direct, actionable path. A celebratory tone or hiding the old behavior leaves users stranded and increases frustration.
Read the full bite: Structuring release notes for breaking API changes
Question 4 of 30
When migrating a breaking change in a mature design system used by hundreds of teams, which strategy best balances system evolution with consumer impact?
Show the answer
Answer: a · Beta test the migration guide with representative consumers, release automated migration tooling alongside a phased deprecation timeline, and track adoption before hard removal.
The correct approach treats migration as a socio-technical contract by validating docs with beta testers, automating busywork, and using phased timelines with analytics. Option C is tempting because it appears to eliminate tech debt decisively, but an overnight swap violates the deprecation window and ignores real-world sprint constraints and validation needs.
Read the full bite: How do you migrate a breaking change in a mature design system?
Question 5 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 6 of 30
Which change is most essential when migrating a local-disk-dependent monolith to a horizontally scaled PaaS?
Show the answer
Answer: a · Externalizing state to backing services so processes become stateless and disposable
Twelve-Factor requires stateless, disposable processes with state moved to backing services so any instance is interchangeable. Vertical scaling, permanent sticky sessions, and a full rewrite miss or overshoot the core fix.
Question 7 of 30
What most improves the accuracy of a pre-release migration cost forecast?
Show the answer
Answer: c · Scanning consumer repos for affected usages and weighting by per-change complexity
Counting real affected usages and weighting by complexity grounds the forecast in the actual codebase. Treating every change as equal-cost ignores that a behavioral change is far pricier than a prop rename.
Read the full bite: Quantifying migration cost for a major release
Question 8 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 9 of 30
A developer is migrating an on-premises Oracle database to Amazon Aurora PostgreSQL. What crucial step must be completed before using AWS DMS for data transfer?
Show the answer
Answer: b · Use AWS Schema Conversion Tool (SCT) to convert the Oracle schema to PostgreSQL.
AWS DMS is a data migration tool, not a schema conversion tool for heterogeneous migrations. The card explicitly states that for migrations between different database engines, AWS Schema Conversion Tool (SCT) must be used first to convert the schema. Provisioning a replication instance (Option D) is a step within configuring DMS, but the schema conversion must precede it for heterogeneous migrations.
Question 10 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 11 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 12 of 30
Why is continuous change data capture (CDC) the key to a near-zero-downtime migration, versus a single export-and-import?
Show the answer
Answer: a · CDC keeps the target in sync with writes during the load, shrinking the cutover window
CDC replicates ongoing changes so source and target stay in sync, letting you cut over in minutes instead of taking a long outage to dump and restore. It does not handle schema conversion or remove the need for validation.
Read the full bite: Near-zero-downtime database migration to cloud
Question 13 of 30
When introducing a breaking change to a widely consumed component, why is an overlap period where both old and new APIs work valuable?
Show the answer
Answer: b · It lets consumers migrate gradually instead of all breaking at once
An overlap window decouples your release from every consumer's upgrade schedule, allowing gradual migration. It does not remove the need for a major bump or a migration guide, and it often temporarily increases bundle size, not decreases it.
Read the full bite: Rolling out a breaking change to a shared Button
Question 14 of 30
When does CodeGen run and what does the spec file represent?
Show the answer
Answer: d · CodeGen runs at build time; the spec is the typed interface contract
CodeGen parses the typed spec at build time to generate type-safe bindings, so the spec is the interface contract. It is neither runtime config nor the rendering implementation.
Read the full bite: What do the spec file and CodeGen do in migration?
Question 15 of 30
Why is counting package installs alone an insufficient measure of design system adoption?
Show the answer
Answer: a · A team can install the library yet still build most UI with bespoke code
Installing the package does not mean the team uses its components; static analysis of how much UI is built from system components and how many overrides exist gives a truer picture. Installs are trackable but only a weak proxy for real usage.
Read the full bite: Driving and measuring design system adoption
Question 16 of 30
A critical accessibility bug in a Modal needs a breaking API change to fully fix. What is the strongest first response?
Show the answer
Answer: a · Ship a non-breaking interim mitigation if possible, then plan the breaking fix as a major
An interim non-breaking mitigation protects users now while you stage the proper breaking change responsibly as a major with migration tooling. Hard-breaking immediately strands teams, delaying harms users, and a patch hides a breaking change dishonestly.
Read the full bite: Critical a11y fix requiring a breaking API change
Question 17 of 30
A team writes a flawless codemod for a breaking Button change but only posts a single changelog line. What is the main risk?
Show the answer
Answer: b · Many teams will miss the change and break on upgrade despite the tooling
Even excellent migration tooling fails if teams never learn about the change, so multi-channel, early communication is essential. A codemod does not replace communication, override semver, or remove the need for a deprecation window.
Read the full bite: Technical and comms plan for a Button break
Question 18 of 30
What role do lint rules play alongside codemods when migrating a legacy codebase to a design system?
Show the answer
Answer: b · They prevent new code from reintroducing legacy patterns after migration
Codemods convert existing code, but lint rules act as guardrails that stop new code from adding legacy patterns and undoing progress. The two are complementary; lint rules do not rewrite code or enable a big-bang switch.
Read the full bite: Gradual design system adoption in legacy code
Question 19 of 30
Before deprecating a feature used by only 2% of users that consumes 15% of capacity, what analysis matters most?
Show the answer
Answer: b · Segmenting who the 2% are, their revenue and strategic value, against the cost and the blocked migration
Usage alone can hide that the 2% are top-revenue accounts, so weighing who they are against cost and the unblocked migration drives a defensible decision. Immediate deletion ignores value, a broad poll is noise, and code size does not reflect business impact.
Read the full bite: Build the case to deprecate a legacy feature
Question 20 of 30
Why circulate an RFC before implementing a breaking change to a core component's props API?
Show the answer
Answer: c · It lets affected teams surface concerns and alternatives before code is committed
An RFC gathers consumer input early, catching better alternatives and reducing surprise before the change is built. It does not replace semver, migration guides, or codemods, which are still required to ship the change safely.
Read the full bite: End-to-end process for a Modal props API break
Question 21 of 30
Before finally shutting down a deprecated API that two products depend on, what condition should gate the decommission?
Show the answer
Answer: c · Telemetry confirms traffic from both consuming products has dropped to zero, after a migration path was provided
Gating the shutoff on observed zero traffic after offering a migration target ensures no live consumer breaks. A date alone, a gut feeling, or only the sunsetting product going quiet ignore whether the two dependents have actually migrated.
Read the full bite: Decommission a depended-on API gracefully
Question 22 of 30
Why is dropping the old address column in the same release that adds the new columns considered unsafe during a rolling deploy?
Show the answer
Answer: d · Old or rolled-back instances may still reference the dropped column and error
During a rolling deploy both code versions run at once, so an instance still expecting the old column will fail if it is already dropped. The lock claim is false; modern online DDL avoids long exclusive locks.
Read the full bite: Zero-downtime schema migration on a hot table
Question 23 of 30
What is the role of the facade or proxy in the Strangler Fig pattern?
Show the answer
Answer: d · It intercepts requests and routes each to either the legacy system or its new replacement
The facade is the interception point that gradually shifts traffic from old to new as features are replaced. It does not rewrite code, act as the data store, or freeze the legacy system.
Question 24 of 30
In a multi-cycle deprecation plan, when is it appropriate to actually remove the deprecated component from the package?
Show the answer
Answer: a · In a later major version after warnings, a codemod, and low remaining usage
Removal is a breaking change that belongs in a major version, after consumers have had warnings, a codemod, and time to migrate. Removing in a minor or patch violates semver and surprises consumers.
Read the full bite: Deprecating a widely used component gracefully
Question 25 of 30
Which scenario best illustrates a primary use case for AWS Database Migration Service (DMS)?
Show the answer
Answer: b · Migrating an on-premises Oracle database to Amazon Aurora PostgreSQL with continuous replication.
The correct answer (B) directly aligns with DMS's primary use cases, specifically heterogeneous migrations and continuous data replication, as detailed in the card's 'WHEN TO USE IT' section and canonical example. Option D describes an ETL task, which the card explicitly states DMS is not designed for, making it a tempting but incorrect distractor.
Read the full bite: AWS DMS: Your Managed Database Migration Engine
Question 26 of 30
In a serverless Strangler Fig migration, what role does an event bus like EventBridge play?
Show the answer
Answer: a · It decouples new services by fanning out domain events to consumers without direct calls from the monolith
The event bus enables event-driven decoupling, letting new Lambdas react to published events instead of being invoked directly by the monolith. API Gateway remains the request facade, the bus is not a database, and migration stays incremental rather than big-bang.
Read the full bite: Strangler Fig with serverless and an event bus
Question 27 of 30
When migrating hundreds of pages from fragmented sources into a docs-as-code system, which approach best reduces risk and preserves SEO?
Show the answer
Answer: b · Inventory sources for freshness and ownership, pick an SSG aligned with team skills, automate conversion, migrate by domain with redirects, and establish CODEOWNERS.
The correct strategy inventories content first, matches the SSG to team skills, automates conversion, rolls out gradually with page-level redirects, and enforces governance via CODEOWNERS. Distractor D is tempting because automation and popularity feel like safe engineering defaults, but skipping the freshness audit and performing a big-bang cutover risks migrating stale content and breaking inbound links.
Read the full bite: Propose a strategy to migrate fragmented docs into a unified docs-as-code system
Question 28 of 30
Beyond shipping a codemod, what keeps consumers from breaking the instant a renamed token is released?
Show the answer
Answer: a · Keeping the old token name as a deprecation alias to the new value temporarily
An alias mapping the old name to the new value lets existing code keep working during a transition window while teams run the codemod. Deleting it immediately or shipping in a patch just causes the breakage you are trying to avoid.
Read the full bite: Automating a breaking design token rename
Question 29 of 30
Which scenario best describes the primary application of Flutter Add-to-App?
Show the answer
Answer: b · Incrementally integrating new features or modules developed with Flutter into an existing native mobile app.
The card states Add-to-App is for "gradual adoption" and "phased migration" by adding "new features or modules" to an existing native app. Option C is incorrect because the card advises against using it for "greenfield projects".
Read the full bite: Flutter Add-to-App: Embedding Flutter in Native Apps
Question 30 of 30
A design system team must restructure a core component API consumed by dozens of product squads. What is the primary purpose of a migration guide here?
Show the answer
Answer: d · To coordinate an incremental rollout so product teams can keep shipping features
The card defines a migration guide as an operational playbook that turns disruptive breaking changes into controlled, incremental rollouts so development never freezes. Treating it as mere documentation, a one-time sprint, or just a rollback tool misses the coordinated, phased operational plan that prevents a permanent dual-system mess.
Read the full bite: Migration Guide: Operational Playbook for Design System Changes
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.