October 15, 2026·6 min read
Ask a candidate how they would migrate a system to the cloud and you will get a diagram. Boxes, arrows, a phased plan, a slide that says lift and shift first and optimise later. It looks like expertise and costs nothing to produce, which is precisely the problem: it is the most rehearsed answer in infrastructure interviewing.
Migrations do not fail at the diagram. They fail at the cutover, usually at 2am, when half the traffic is on the new platform, the old database is still accepting writes, and somebody has to decide in ten minutes whether to continue or go back.
So interview the cutover and the rollback. Those are the parts that cannot be drawn in advance and cannot be looked up during the interview.
The setup. A small system part-way through a move. Some traffic is on the new platform, the database is still on the old one, and the configuration shows both.
Ask: we are twenty minutes into the cutover and error rates have doubled. Take us back.
Strong looks like: they ask what has already been written to which side before they touch anything, because that determines whether going back is even possible. They order the steps: stop new writes, drain in flight work, revert traffic, and only then talk about data. They name the point of no return explicitly and say how far past it we are.
Weak looks like: reverting DNS and declaring the problem over, with no account of the writes that happened to the new side in the last twenty minutes.
Why it works: this is the real decision a migration lead makes, under time pressure, with incomplete information. It is also the question nobody prepares for, because every interview asks about the forward path.
The setup. The application works on the new platform until one path fails. The cause is something old and undocumented: a hardcoded IP address, a firewall rule that allowed the old subnet, a cron job on a server that is not part of the migration, a service that authenticates by source address.
Ask: the new environment is live and this one feature fails. Find out why.
Strong looks like: they compare rather than theorise. What is different between the two environments, in network terms, in identity, in configuration. They check from inside the new environment rather than reasoning from the diagram, and they ask what else might depend on the thing they just discovered, because there is usually more than one.
Weak looks like: opening the firewall wide to make it work and promising to tighten it later. That is how a migration quietly becomes a security finding.
Why it works: every migration meets something that was never written down. How somebody hunts for it is the most transferable skill in the exercise.
The setup. A database to move with a tolerance for a few minutes of downtime, or none at all. The candidate has to describe and then actually sequence the cutover: replication, verification, the switch, and what happens to writes in between.
Ask: plan the database cutover and tell me what the point of no return is.
Strong looks like: they verify before switching. Row counts, checksums, a sample of recent records, replication lag measured rather than assumed. They are explicit about which step is irreversible and what the recovery looks like on each side of it. If they propose dual writes, they also say how they would detect divergence, which is the part most people skip.
Weak looks like: a plan where verification happens after the switch. It is the most common cause of a migration that technically succeeded and lost a day of orders.
Why it works: the data is the only part of a migration that cannot be re-run. Judgment about irreversibility is the single clearest seniority signal here, and it is the same instinct we look for in the Terraform plan that will replace a database.
The setup. The move is complete and the application is measurably slower. The cause is architectural rather than a bug: a chatty service that used to be on the same host now crosses a network boundary, or storage that was local is now remote, so a hundred small calls that cost nothing before now cost a millisecond each.
Ask: everything is on the new platform and p95 has doubled. Where is the time going?
Strong looks like: they measure before guessing, and they look for a change in the number of round trips rather than in the speed of any single one. They can explain why the application was fine before and is not now, without blaming the new platform in general terms. Fixes they propose are specific: batch the calls, cache at the right layer, move the components back together, change the access pattern.
Weak looks like: bigger instances. It sometimes helps, hides the cause, and the invoice arrives every month afterwards. The cost side of that is a post of its own: cloud cost skills assessment.
Why it works: post-migration performance regressions are extremely common and almost always structural. Whether somebody can see the structure rather than the symptom decides how long the regression lasts.
Four rows, the same for every candidate:
None of those rows is "has used this cloud provider". Provider specifics are learnable in weeks. Cutover judgment is not.
These tasks need two environments that both exist, a database with data in it, a network boundary you can actually cross and a load generator. A whiteboard gives you the rehearsed answer, which is the thing you were trying to get past.
EasyEnv gives the candidate real boxes, an old environment and a new one, with the undocumented dependency already in place, replication already configured and the chatty call pattern already there. Every candidate gets the same recipe, so the cutover decision is identical and comparisons are fair. The boxes are disposable, so a candidate who breaks something has broken nothing. The session is recorded, so you can see whether they verified before switching.
The limits, plainly. Building the two-environment recipe is a day of work the first time, though it then runs forever. Reviewing needs an engineer who has led a cutover rather than attended one. And for a role that is purely greenfield with nothing to migrate from, this is the wrong hour to spend.
Stop asking for the migration plan. Put the candidate twenty minutes into a bad cutover, with an undocumented dependency, a database that has to be verified before switching, and a system that came out slower than it went in.
If you only run one, run the rollback. Whether somebody knows what has already been written, and what that makes impossible, is the difference between a migration and an incident.
Run live coding sessions and take-home challenges in real production environments. Watch sessions back, score consistently, and hire with confidence.
More posts you might like
Hiring someone to build with models is not the same as hiring someone who codes with one. Here are four tasks on a running LLM service, output that fails to parse, a change nobody can prove is an improvement, a context window that grows until it costs real money, and a provider having a bad afternoon.
You cannot ship an app in a 60 minute interview, so mobile hiring falls back on algorithm puzzles and a portfolio walkthrough. Here are four tasks inside a real project, a leak that survives the screen, state lost on rotation, a slow network, and a crash only on resume.
Read more
Give an analyst clean tables and a clear question and nearly everyone looks capable. Here are four tasks on a deliberately messy database, duplicated rows, nulls that mean two different things, a timezone that moves a month boundary, and a number that disagrees with finance.
Read more
