Changeis Software Engineer Interview Guide

The 60-second brief

Candidates describe Changeis work as cloud infrastructure and agile project delivery, with engineers acting as the link between client requirements and cloud-based implementations. The listings they mention are Cloud Engineer and Release Train Engineer. A Cloud Engineer designs and maintains cloud architecture, while a Release Train Engineer keeps delivery synchronised across several teams. Candidates also mention government and large enterprise contracts as relevant background, so expect project and client work rather than a single consumer product.

This guide is for engineers applying to Changeis as a Software Engineer, mainly through the Cloud Engineer and Release Train Engineer listings, which candidates describe as running from Junior Cloud Engineer up to Senior Principal Cloud Engineer. It covers the five reported rounds, the four reported questions (all about Agile teamwork and communication), the cloud topics candidates say come up, and how to write and speak your examples. It does not cover algorithm or coding-puzzle preparation, because candidates report none for this loop.

Candidates report five rounds over roughly four to six weeks: Initial Outreach, Screening Questionnaires, Written Responses, a Face-to-Face Conversation and a Final Evaluation. Much of the early process is described as email-based.

Focus areas

• Agile Development
• Cloud Engineering
• Cloud Architecture

Overview

The reported questions are all about how you work on a team: your experience on an Agile team, handling shifting priorities, your role in a typical sprint, and communicating between technical and non-technical stakeholders. None is a coding or algorithm question. The preparation is a small set of well-built stories and a clear description of your own part in a sprint, each backed by something measurable such as release frequency, carry-over between sprints or time to restore service.

The stack candidates mention is cloud-first. The requirements list AWS, Azure or GCP, with DevOps practices and automated testing as pluses, and the evaluation areas candidates describe include infrastructure-as-code, troubleshooting a failed deployment or a production performance problem, and scaling a service as demand grows. Prepare one real example for each, with the cause you found, the change you made and how you confirmed it worked. If you are aiming at the Release Train Engineer listing, prepare the delivery side as well: how you coordinate work across teams, track dependencies and keep a shared release cadence.

Writing counts more here than in most loops. Candidates report email outreach, screening questionnaires and written responses before any live conversation, and say the written answers are weighed alongside the interviews. Treat each written answer as a short, structured piece: lead with the answer, give one concrete example, finish with the result. Then check that your written claims match what you will say face to face, because the same stories will be heard again in the later rounds.

The Changeis interview process

The rounds below are what candidates report, not a published process. Candidates describe the early stages as mostly written and the later stages as conversations.

Initial Outreach

Candidates report that this stage is the first contact, and that it often arrives by email. Your reply is the first piece of writing the company sees from you, so it should be short, specific to the listing and easy to act on. Say which listing you are applying for (for example Cloud Engineer or Release Train Engineer), what level you are aiming at, and give a one-paragraph summary of the work you have done that matches it.

What to demonstrate

• How clearly and professionally you write in a short message
• Whether your background matches the listing and level you name

How to prepare

• Write a five-sentence summary of your Agile and cloud experience that you can paste into a reply
• Keep a short list of project summaries ready, each with the team size, your role and one measurable result
• Decide in advance which listing and seniority level you are applying for, so the reply names them

Screening Questionnaires

Candidates report focused screening questionnaires used to assess fit. The questions candidates attach to this loop are about Agile experience, shifting priorities, your sprint role and talking to non-technical stakeholders, so write the answers once in full and reuse the structure. Answer exactly what each question asks, in a few direct sentences with one concrete example.

What to demonstrate

• Direct answers that map to the question asked
• Working knowledge of Agile practice shown through your own examples
• Fit with the cloud or delivery listing you applied for

How to prepare

• Write a full answer to each of the four reported questions, then cut each to a version you could paste into a form
• List the cloud services and tools you have used in production, grouped by AWS, Azure or GCP
• Prepare one example of a priority change and one of explaining a technical constraint to a non-technical person

Written Responses

Candidates report written responses that are evaluated alongside the interviews. The requirements candidates describe name strong written communication for documentation and reporting, so write these as a work sample. A good response states the situation briefly, shows your decision and the reasoning behind it, and ends with a result you can quantify, such as a shorter deployment time or fewer failed releases.

What to demonstrate

• Written clarity and structure
• Whether your examples show your own decisions and measurable results
• Command of Agile and cloud terminology used correctly

How to prepare

• Write one example each for ceremony facilitation, backlog and technical-debt prioritisation, and working across functions
• Write one example of a failed deployment or production slowdown: symptom, cause, fix and what you changed afterwards
• Reread every answer for undefined acronyms and for claims you could not explain aloud

Face-to-Face Conversation

Candidates report a face-to-face conversation to assess fit further. This is where the stories from your written answers are told aloud, so practise delivering them without reading. Agile and cloud topics are the ones candidates report across the loop, so be ready to talk through your sprint role, how you handle changing priorities, and a cloud example covering infrastructure-as-code, troubleshooting or scaling.

What to demonstrate

• How well you explain your own work in conversation
• Consistency between what you wrote and what you say
• Technical depth behind the cloud or delivery experience you claim

How to prepare

• Say each prepared story aloud in under two minutes by your own clock and trim any part that does not carry the point
• Be ready to explain one infrastructure-as-code change end to end: what it provisioned, how it was reviewed and how it was rolled back
• Prepare two questions about how the team runs its sprints and releases

Final Evaluation

Candidates report a final evaluation that leads to the hiring decision. Nothing further is reported about its format, so prepare for the stage to revisit what came before: your examples, your level and your fit with the specific listing. Make sure the story you tell about your experience is the same one across the questionnaire, the written responses and the conversation.

What to demonstrate

• Overall fit with the listing and level
• Consistency of your account across the earlier rounds

How to prepare

• Reread everything you submitted and list any figure or claim you would need to be able to defend
• Be able to state in two sentences why this listing and this level fit your experience
• Have your questions ready about team structure, release cadence and how remote work is arranged for the listing

Where candidates lose points

Answering the Agile questions with framework definitions instead of what you did in the sprint

Open every answer with your role and one specific action, such as facilitating a retrospective or reordering the backlog. Keep the definitions to a clause. Prepare one story for each of the four reported questions.

Saying 'we' throughout so your own contribution to the delivery cannot be seen

For each story write down what you decided, built or changed personally, and say that first. Keep the team context to one sentence.

Treating the questionnaire and written responses as a formality before the real interviews

Candidates report these answers are evaluated alongside the interviews. Write them as short, structured work samples, answer exactly what is asked, and reread them for vague claims before sending.

Claiming cloud experience you cannot explain when asked for the details

For each provider and infrastructure-as-code tool on your résumé, prepare what you provisioned, how a change was reviewed and applied, and how you rolled one back. Remove anything you could not discuss.

Giving results with no numbers, or numbers with no method behind them

Attach one measure to each example, such as deployment time, failed-release count or time to restore, and know how it was collected. If you have no number, state the observable change instead.

Questions & practice

Archive a resource graph without breaking live references or recursing

Medium · graph traversal · topological order · tenant isolation

Resources reference other resources within a tenant; for the largest tenant the reference table holds up to 2,000,000 nodes and 8,000,000 edges. Archiving a resource must archive everything reachable from it that nothing outside the set still references, refuse when a live external referrer exists, and terminate when references form cycles, which they legitimately do. Produce the archive order and the refusal list, targeting O(V+E). Say what stops the traversal crossing a tenant boundary, and why recursion is the wrong control structure at this size.

Approach

1. Load the subgraph with the tenant predicate on both endpoints of the edge, not only on the side you started from. Scoping the left table alone is the classic cross-tenant leak: one mis-entered edge then pulls another tenant's resources into the traversal and, worse, into the archive.
2. Traverse iteratively with an explicit stack. A 2,000,000-node graph can hold a chain deep enough to exhaust a native stack in the low tens of thousands of frames, and that failure is a process crash rather than an error you can return.
3. Treat cycles as data rather than corruption: compute strongly connected components with Tarjan in O(V+E) using its own explicit stack, then condense. The condensation is a DAG, so a topological order over it gives the archive order, and every member of a component archives in one transaction because no order within a cycle is valid.
4. Decide refusals with reverse edges. A candidate is archivable only if every in-edge originates inside the candidate set, so build the transpose or count in-degrees restricted to the visited set, and emit each blocked resource with the id of the external referrer, which is the only part of the answer an operator can act on.

Follow-up

• The graph is read in one query and the archive writes a minute later. What can change in between, and how do you make the write safe?
• The candidate set is 400,000 resources. Is that one transaction, and if not, what does a half-finished archive look like to a reader?

Canonicalise a request body into a stable idempotency fingerprint

Medium · parsing · canonicalisation · hashing

idempotency_key.request_fingerprint is a SHA-256 over the method, path and canonicalised body, and a retry whose fingerprint differs must be rejected with 422 rather than served the stored response. Write the canonicaliser. Bodies are JSON up to 256 KB nested at most 32 levels; clients vary key order, whitespace and unicode escaping, and some send 64-bit ids as JSON numbers. Produce a deterministic byte string such that semantically identical bodies match and any semantic difference does not. State your complexity and name two normalisations you refuse to perform.

Approach

1. Parse once into a tree, then re-serialise under fixed rules: object keys sorted, array order preserved, one escaping convention, no insignificant whitespace. Parsing is O(n) and sorting keys is O(k log k) per object, so O(n log n) overall with O(depth) stack, and the 32-level cap is enforced during parsing because hostile nesting is how a canonicaliser becomes a stack overflow.
2. Sort keys by their UTF-8 bytes and say why the obvious implementation is wrong in some runtimes: a default string comparison that orders by UTF-16 code units places surrogate pairs, meaning code points from U+10000 up, below U+E000 to U+FFFF, which is not UTF-8 byte order, so two services written in different languages disagree on the same document.
3. Do not re-encode numbers through a double. IEEE-754 binary64 represents integers exactly only up to 2^53, so normalising a 19-digit id through a float changes it, and 1 against 1.0 cannot be reconciled without deciding whether they are the same value. Preserve the literal token, and require ids as strings at the API boundary if you want them comparable.
4. Reject duplicate keys rather than picking one. JSON permits them and parsers disagree, most keeping the last, so any choice you make ties the fingerprint to a parser detail that the code handling the request does not necessarily share.

Follow-up

• A client sends the same logical request with an extra field your API ignores. Same key, different fingerprint, so you return 422. Is that the right answer?
• Where does the fingerprint get computed relative to request decompression and the body-size limit?

Track a rolling failure rate per destination for circuit decisions

Easy · sliding window · ring buffer · circuit breaker

The egress service delivers about 1,500 webhooks per second across roughly 40,000 destinations, each call bounded by a 10 second timeout. Maintain, per destination, the failure rate over the trailing 60 seconds so a caller can ask before dispatch whether the circuit should open. Attempts arrive as (destination_id, finished_at_ms, outcome). Requirement: amortised O(1) per attempt, with total memory bounded by the destination count rather than by traffic. Give the structure, its exact memory, and the rule that stops a destination with three attempts from opening a circuit.

Approach

1. Name the exact-deque version and then reject it as the default. Holding timestamps and advancing a tail pointer past anything older than now minus 60 seconds is a correct two-pointer window at amortised O(1) per attempt, but its memory tracks in-window traffic, so one destination in a retry storm holds hundreds of thousands of entries while thousands of quiet destinations hold none.
2. Use a ring of 60 one-second buckets per destination, each bucket a pair of counters for attempts and failures. On an attempt, advance the ring by the elapsed whole seconds, zeroing at most min(elapsed, 60) buckets, then increment the head. That is amortised O(1) with a fixed footprint per destination.
3. State the footprint: 60 buckets times two 4-byte counters is 480 bytes of payload per destination, so 40,000 destinations is roughly 20 to 25 MB with per-entry overhead, bounded by the catalogue rather than by the rate. The cost is granularity, since the oldest bucket ages out in whole seconds, which is far tighter than the decision needs.
4. Require a minimum sample before the circuit may open. A destination with three attempts and three failures reads as 100 percent and is not evidence; a floor of roughly 20 attempts in the window makes the ratio meaningful, and below that floor use a run of consecutive failures as the trigger instead.

Follow-up

• The fleet is 30 instances and each sees roughly a thirtieth of a destination's traffic. Where does the rate actually live, and what does a per-instance answer get wrong?
• A destination answers in 9.5 seconds and succeeds. It is not failing but it is consuming your per-destination concurrency. What signal should open the circuit here?

Denormalise tenant onto revisions and backfill it live

Hard · denormalisation · online migration · backfill

resource_revision (revision_id, resource_id, version, actor_user_id, change_kind, patch, request_id, created_at) has 400M rows and no tenant column; tenant_id lives only on resource. Two reads need it: a tenant-scoped audit feed ordered by created_at DESC, and an offboarding purge. Both join back to resource today. Justify adding tenant_id to resource_revision against those two reads, name the anomaly the copy introduces and the constraint that prevents it, then give the ordered migration for a live table taking 1.2k writes/second — the lock each step takes, how the backfill is batched, and where each step stops being reversible. PostgreSQL 16.

Approach

1. Justify from the access path rather than from taste. Without the column, the audit feed either scans resource_revision by created_at and discards other tenants' rows, or resolves the tenant's resource_ids first and probes with them — both proportional to the tenant's whole history rather than to one page. With (tenant_id, created_at DESC, revision_id DESC) it is a seek that stops at 50 rows, and the purge becomes a ranged delete instead of a join.
2. Name the cost exactly: a second copy of a fact can disagree with the first. Make the disagreement unwritable rather than documented — add UNIQUE (resource_id, tenant_id) on resource so it can serve as a foreign-key target, then FOREIGN KEY (resource_id, tenant_id) REFERENCES resource (resource_id, tenant_id) on the revision table. A revision can then only ever carry its parent's tenant.
3. Step one, expand: ALTER TABLE resource_revision ADD COLUMN tenant_id BIGINT NULL, with no default, so it is a catalogue change and no rewrite. It still needs ACCESS EXCLUSIVE for an instant, and that instant queues behind the longest open transaction on the table while every later query queues behind it — set lock_timeout to 2s and retry rather than wait.
4. Step two, dual-write: deploy the writer that populates tenant_id on every new revision while reads still use the join. Reversible by redeploying the previous build, because nothing reads the column yet.

Follow-up

• The backfill is half finished and a rollback is required. What state is the table in, and what does the previous build do with a half-populated column?
• How do you verify the backfill actually finished, given rows are still being inserted while it runs?

Find version gaps and relay lag with window functions

Medium · window functions · event tables · frame semantics

outbox_event holds event_id, aggregate_type, aggregate_id, aggregate_version, event_type, payload, status ('pending','published','dead'), attempts, created_at, published_at. A projection is missing rows and you must decide whether the relay skipped events or the consumer dropped them. Write three queries over the last seven days: one listing every aggregate_id whose published aggregate_version sequence has a hole, one giving per-day counts with a running total, and one returning the newest published event per aggregate. For each, say where the window function is evaluated relative to WHERE and LIMIT. PostgreSQL 16.

Approach

1. Gaps: compute lead(aggregate_version) OVER (PARTITION BY aggregate_id ORDER BY aggregate_version) in a subquery, then filter next_version <> aggregate_version + 1 in the outer query. Window functions are evaluated after WHERE, GROUP BY and HAVING and before the outer ORDER BY and LIMIT, so the predicate cannot sit in the same WHERE clause and PostgreSQL 16 has no QUALIFY.
2. Say what the seven-day filter does to the answer: it truncates every partition, so the first row per aggregate has no predecessor inside the window and a hole spanning the boundary is invisible. Widen the window, or join to resource.version as the authority for the true maximum.
3. Running total: SELECT date_trunc('day', created_at) AS d, count() AS n, sum(count()) OVER (ORDER BY date_trunc('day', created_at) ROWS UNBOUNDED PRECEDING). An aggregate inside a window call is legal because grouping runs before windowing. The grouping key is unique per row here so ROWS and RANGE agree, but write the frame anyway — over ungrouped rows with tied timestamps the default RANGE frame pulls in every peer row and the total jumps.
4. Newest per aggregate: DISTINCT ON (aggregate_id) ... ORDER BY aggregate_id, aggregate_version DESC is the cheap PostgreSQL-only form when an index matches that order; row_number() OVER (PARTITION BY aggregate_id ORDER BY aggregate_version DESC) = 1 is the portable form and needs a subquery for the same evaluation-order reason as the gap query.

Follow-up

• Relay failover redelivers events. Does a duplicate break the gap query, and how would you detect one from this table alone?
• Turn the gap check into a continuous monitor rather than a query someone runs after an incident. What does it watch?

Can you describe your role in a typical Sprint cycle?

Medium · Agile Methodology and Team Dynamics

Approach

1. Walk the Scrum events in order and say what you personally did in each, not the textbook definition: sprint planning (pulling refined backlog items against a sprint goal and splitting them into tasks), daily stand-up, build and code review, mid-sprint backlog refinement, sprint review, retrospective.
2. Name your Definition of Done and how you held to it: unit and integration tests passing in CI, peer review, the change deployed to a staging environment, and for cloud work the infrastructure-as-code change reviewed and applied through the pipeline rather than by hand.
3. Anchor it in one real sprint with numbers: items committed versus finished, one story that grew mid-sprint, and what you did about it (raised it at stand-up, split it, moved the remainder back to the backlog instead of stretching the sprint).
4. If your team ran Kanban or SAFe instead, say so and map it accurately: Kanban has no fixed sprint and is managed by WIP limits and cycle time; in SAFe, team sprints sit inside a Program Increment that opens with PI Planning across the release train.
5. Show one retrospective action you owned and whether it stuck, e.g. a flaky test suite you fixed after it was named as the top blocker. Avoid treating velocity as a productivity score or comparing it across teams; it is a planning aid for one team.

Follow-up

• What happens to a story that is not finished when the sprint ends, and who decides?
• How did your team estimate, and what did you change when estimates kept missing?
• How did technical debt get a place in your sprints alongside feature work?

How do you ensure clear communication between technical and non-technical stakeholders?

Medium · Agile Methodology and Team Dynamics

Approach

1. Start from the decision the listener has to make (scope, date, cost or risk) and lead with it; give the technical reason one layer deep and keep the detail ready if they ask.
2. Translate mechanisms into outcomes with numbers: not 'move the database to multi-AZ' but 'if one data centre fails, the service stays up; it adds roughly X per month'. Quantify downtime, deployment time or cost where you can.
3. Name the artefacts you use: plain-language acceptance criteria written with the product owner, a two-level architecture diagram (one box-level view for the business side), short written status updates, and sprint review demos of working software instead of slides.
4. Close the loop: ask the stakeholder to restate the decision, record it in the ticket or a decision log, and raise risks early as options with trade-offs rather than a single yes or no.
5. Tell one specific story where a misunderstanding happened, what it cost, and the habit you changed afterwards. Answers that only say 'I avoid jargon' or that talk down to the non-technical side sink this question.

Follow-up

• How would you explain a failed production deployment and its impact to a non-technical client the same day?
• Tell me about a time a stakeholder asked for a date the team could not meet. How did you push back?
• How do you keep written documentation useful to both engineers and business readers?

Read latency spikes on a sixty-second sawtooth

Medium · cache stampede · single-flight · ttl

The cached listing read path serves about 14k reads/second at an 85% hit rate. p99 sits at 35 ms for 57 seconds, jumps to 900 ms for 3, and repeats. During each spike the primary shows several hundred identical listing queries starting within the same millisecond, all carrying one large tenant's id. Cache entries use a 60-second TTL. Give the mechanism, the ordered checks, the fix, and the correctness hazard your fix must not introduce.

Approach

1. Match the period to a configured number before theorising about load. A spike every 60 seconds against a 60-second TTL is an entry expiring, and you confirm it by correlating spike timestamps with the entry's write time rather than with the traffic curve. If the period had matched a cron or a GC interval instead, this is a different investigation.
2. Establish the concurrency of the miss. Several hundred identical queries in one millisecond means the miss path has no coalescing: every request that arrives between expiry and repopulation recomputes. The herd size is that key's arrival rate times its recompute time, so at 1.2k reads/second for the hot key and a 250 ms recompute you expect about 300 concurrent misses, which matches what is observed.
3. Add single-flight on the miss path so one caller per key recomputes under a short-lived lock while the rest wait for its result. Prefer stale-while-revalidate where the read tolerates it: return the expired value immediately and refresh asynchronously, which removes the latency spike rather than serialising it into a queue of waiters.
4. De-synchronise the keys. Write TTLs with jitter, for example 60 seconds plus or minus 10%, so a deploy or a mass invalidation does not align every key on the same second and turn a per-key herd into a fleet-wide one.

Follow-up

• The same sawtooth appears on a key that is invalidated on write rather than expired. Is that the same bug?
• How does your answer change if the recompute takes 4 seconds instead of 250 ms?

Suggested practice checklist

The plan follows the loop as candidates describe it: first the written stages, then the spoken ones. It builds the Agile stories, then the cloud examples, then rehearses both in writing and aloud.

Day 1 — Map the loop and your target listing

• Write the five reported rounds in order: Initial Outreach, Screening Questionnaires, Written Responses, Face-to-Face Conversation, Final Evaluation. Mark which are written and which are spoken.
• Pick the listing and level you are targeting (Cloud Engineer or Release Train Engineer) and list which of your projects best match it.
• Write the five-sentence summary of your Agile and cloud experience you would send in an email reply.

Deliverable: A one-page loop map, a chosen listing and level, and a five-sentence experience summary.

Day 2 — Agile experience and shifting priorities

• Write a full answer to the question about your experience on an Agile team: framework, team size, your role, one ceremony you improved, one measured result.
• Write a full answer to the question about handling shifting priorities, using a real mid-sprint change and showing the trade-off you took to the decision maker.
• Cut each answer to a short paragraph that would fit in a questionnaire field.

Deliverable: Two full written answers and two shortened versions, each with a number attached.

Day 3 — Sprint role and stakeholder communication

• Write a walkthrough of your role across one full sprint: planning, daily work, review and retrospective, with one thing you owned in each.
• Write an answer on communicating between technical and non-technical stakeholders, using one example where you turned a technical constraint into a decision someone else could make.
• Ask a colleague to read both and mark every sentence they cannot follow without technical background.

Deliverable: A sprint-role walkthrough and a stakeholder-communication answer, edited after the reader's marks.

Day 4 — Cloud engineering examples

• List the cloud services and infrastructure-as-code tools you have used in production, and for each write what you provisioned and how a change was applied and reversed.
• Write up one failed deployment or production performance problem: symptom, how you narrowed it down, cause, fix and the follow-up change.

Deliverable: A cloud inventory, one written incident or deployment-failure account, and a worked latency-spike exercise.

Day 5 — Scaling, backlog and delivery coordination

• Write how you would scale one service you have run as demand grows: what you would measure first, what you would change, and what you would watch afterwards.
• Write one example of balancing technical debt against new features in a backlog, with the criteria you used.
• If you are targeting Release Train Engineer, write how you track dependencies and keep several teams on one release cadence.

Deliverable: A scaling plan for a service you know, a backlog trade-off example, and a delivery coordination note if relevant.

Day 6 — Speak the stories and test the reversal story

• Say aloud your answers on Agile experience, shifting priorities, sprint role and stakeholder communication, without reading, and trim each to its strongest points.
• Record yourself once and note filler, long set-ups and missing results.

Deliverable: Four spoken answers trimmed to their key points and one written decision-reversal story.

Day 7 — Consistency check and questions to ask

• Compare every written answer against your spoken versions and fix any figure, date or claim that differs.
• Prepare the two-sentence reason this listing and level fit you, for the final stage.
• Write three questions for the team about sprint structure, release cadence and how remote work is arranged for the listing.

Deliverable: One consistent set of examples, a two-sentence fit statement and three questions to ask.

Agile teamwork and communication stories

The reported behavioral questions are about working inside an Agile team: your experience, changing priorities, your part in a sprint and talking to people outside engineering. Prepare stories where you made the decision, with a number or observable result, and be ready to give them both in writing and aloud.

1. Can you describe your role in a typical Sprint cycle?
2. How do you ensure clear communication between technical and non-technical stakeholders?
3. Describe a time you diagnosed a failed deployment or a production slowdown and what you changed afterwards.
4. Describe a technical decision you made and later reversed, and what the reversal cost.

What is your experience working on an Agile Team?

Medium · Agile Methodology and Team Dynamics

Approach

1. Name the setup first: the framework (scrum or kanban), your team size, and your own role in it. Then pick one concrete contribution, such as running retrospectives, refining the backlog or owning the release, rather than reciting the framework.
2. Tie the answer to ceremonies you took part in: stand-ups, sprint planning, review and retrospective. For each one you mention, say what you did there and one change it produced, such as a smaller story size or a working agreement that cut rework.
3. Give one measurable result from the team: fewer stories carried over each sprint, shorter lead time, fewer failed releases or faster restore after an incident. Say how you measured it, so the number holds up if asked.
4. Include one thing that went wrong, such as a sprint goal missed through poor estimation, and what you changed. Say what you personally changed, because a story told only as team activity hides your contribution.
5. Keep the written version to a short paragraph and the spoken version to a short story. The mistake that sinks this answer is a glossary of Agile terms with no example of your own.

Follow-up

• What did your team change after a retrospective, and how did you know it helped?
• How do you split a story that is too large for one sprint?
• When would you choose kanban over scrum for a team?

How do you handle shifting priorities within a fast-paced development cycle?

Medium · Agile Methodology and Team Dynamics

Approach

1. Pick one real change: new work arriving mid-sprint, a priority swap from a stakeholder, or a production incident. Open with what changed, who asked and what was already in progress, in two sentences, and spend the rest on your reasoning.
2. Show how you assessed the cost: what had to be dropped or delayed, what was half finished, which dependencies or other teams were affected, and whether the sprint goal was still reachable.
3. Show that you took the trade-off to the product owner or the person deciding, in terms they can act on, such as 'if I take this, that moves out and these two items slip'. Then say what was decided and how you recorded it for the team.
4. Cover the half-finished work: how you parked it safely, for example behind a feature flag or on a branch with notes, so it could be resumed without loss.
5. Close with the outcome and a lesson, such as agreeing a rule for urgent requests or reserving capacity. The mistake that sinks this answer is saying you simply work harder or say yes to everything, with no trade-off visible.

Follow-up

• What do you do when priorities change several times in the same sprint?
• How do you decide whether an urgent request justifies interrupting the sprint?
• How do you stop frequent changes from building up technical debt?

Reverse your own decision and price the reversal

Medium · reversibility · measurement · migrations

Describe a technical decision you made and later reversed. Pick one that cost something: a service you split and merged back, a cache you added and removed, an index you created that pushed the planner onto a worse plan, a projection you rebuilt from scratch. State what you believed when you decided, the measurement that changed your mind, how long the wrong version ran in production, and what the reversal cost in migrations, dual writes, and a deprecation window for callers you did not own.

Approach

1. State the original rationale without irony, in the version you would still defend given what was known then. If it is not defensible, the story is about carelessness rather than judgement, and a different example serves you better.
2. Give the measurement that moved with a before and after: the p99 that did not improve, the cache hit rate that sat at 40%, the plan that flipped to a sequential scan once the table passed a size you can name.
3. Cost the reversal in steps, not adjectives: expand-and-contract deploys, the dual-write window, the callers who had to be notified, the rows already written in the wrong shape that had to be backfilled or abandoned.
4. Distinguish reversal from rewrite by naming what you kept. Most good reversals preserve the schema or the interface and undo one decision inside it, which is also why they were affordable.

Follow-up

• What in that decision was irreversible, and did you know it was irreversible when you made it?
• How did you tell the people who had already built on top of the original decision?