Stop being a workhorse for nothing: how to refactor your current “shit‑mountain” project into the most useful interview prep before you get “optimized.”

The article’s core conclusion is straightforward: truly valuable shit‑mountain refactoring is not about making legacy code elegant, but about turning a high‑risk, uncontrollable grind into an engineering case that can protect you before layoffs and interviews—and be monetizable. For individuals, shit‑mountain projects are almost unavoidable, but they are not the same as meaningless tech‑debt cleanup; done right, refactoring them is the clearest way to demonstrate engineering judgment, risk awareness, and business understanding—prime interview material. The article stresses that before layoffs, the top priority in refactoring is not speed but safety and narratability: control risk first, isolate change second, then replace in small steps, making “nothing blew up in production” a verifiable outcome. The value of legacy refactoring also lies not in eliminating tech debt all at once, but in building test or logging safety nets, identifying untouchable core logic, documenting tacit tribal knowledge, and reducing risk via feature flags and shadow validation. The result is that you no longer just have “someone else’s shit‑mountain,” but a complete, reviewable, quantifiable set of practices that can answer refactoring interview questions: what cannot be changed, why, how to validate before changes, and how to monitor and roll back after. Even if the project is never fully refactored, this safety‑first, guide‑style approach is enough to prove you can clean tech debt and handle complex systems in real production. For engineers squeezed by AI refactoring tools, org optimizations, and uncertainty, the ability to turn shit‑mountain refactoring into the most useful interview material is often more important than shipping a few new projects.

Core Approach to Refactoring a “Spaghetti Codebase”: Control Risk First, Then Replace Gradually

When facing a legacy “spaghetti code” project, your first reaction should not be “I’ll rewrite a cleaner version.” The truly safe—and most interview-worthy—path is: contain the risks first, then reduce complexity through small, incremental replacements. The goal of refactoring is not to make the code look beautiful immediately, but to let the system gradually become understandable, verifiable, and reversible without breaking production.

When talking about refactoring a spaghetti codebase in interviews, the key is not showing off techniques, but proving that you have the engineering judgment to “protect production, identify boundaries, and deliver incrementally.”

The full process can be compressed into these five steps:

1. Map business and code dependencies
   First, understand the core flows, API calls, database tables, scheduled jobs, message queues, and external system dependencies. Many problems in legacy systems are not that the code is hard to change, but that no one knows “changing this line will affect which money flow, which state, or which downstream system.”
2. Identify high-risk modules and no-touch areas
   Mark in red anything involving funds, permissions, order state transitions, core transactions, past incident modules. Code that looks duplicated may actually carry implicit rules for different channels, regions, or historical versions; without evidence, do not merge these areas rashly.
3. Add minimum viable tests or logging for validation
   Don’t expect to build perfect unit tests from day one—legacy systems often make that unrealistic. A more practical approach is to add black-box API tests, key-path regression cases, snapshot comparisons, or critical log instrumentation to lock down “current behavior.” This “build a safety net first” mindset also aligns with common test protection practices in legacy system refactoring.
4. Isolate new implementations with feature flags or sidecar logic
   Don’t replace old logic directly. Instead, run the new logic in parallel: feed the same input to both old and new implementations, let the old logic produce the result, and have the new logic only compare and record differences. Once discrepancies converge, gradually roll out the new logic via feature flags by user, channel, or percentage.
5. Replace incrementally and monitor continuously
   Each time, replace only one clearly bounded capability—for example, one payment channel, one order state, or one billing rule. After deployment, watch error rates, latency, conversion rates, amount discrepancies, alert volume, and rollback records. If metrics go abnormal, turn off the switch immediately instead of continuing to “trust the new code.”

A typical scenario: in a payment module, hundreds of lines of if-else calculate fees based on payment method, membership level, coupons, region, and historical campaigns. The most dangerous approach is to abstract a “clean strategy pattern” and replace everything at once; a safer approach is to first map existing payment paths, mark fund calculation and refund flows as no-touch areas, add result comparisons for key order samples, and finally switch only one low-risk payment channel to the new implementation.

This approach aligns with the legacy system governance model of “protect–isolate–optimize”: protect existing behavior first, then isolate the scope of change, and only then talk about structural optimization. In other words, risk control always has a higher priority than code elegance. If you can explain this clearly, your “spaghetti code project” becomes not just overtime experience, but a solid engineering case you can win with in interviews.

Step 1: Draw the Real Business and Dependency Map

Many spaghetti-code projects are untouchable not because the code is “advanced,” but because the real rules don’t live in the code. Some are hidden in historical requirements, some in past production incidents, and others in verbal agreements with former colleagues. What you see are if-else blocks, temporary fields, and duplicated methods; what the system truly depends on are things like “which users must not go through the new flow,” “which states must never roll back,” and “which tables are scanned by downstream reports at 3 a.m.”

So, the cost of understanding is often far higher than the cost of changing. Modifying a single condition might take 5 minutes, but figuring out why that condition exists can mean digging through requirements from three years ago, checking production logs, and talking to product managers and QA. The first step of legacy system refactoring should be “drawing the map,” not “wielding the knife.” This aligns with common experience in large legacy refactors: first analyze existing business requirements and code design as thoroughly as possible, then add tests, then refactor in small steps. Jumping straight into code changes amplifies risk, especially in projects with severe context loss. InfoQ’s interviews on legacy refactoring also emphasize that the first step is to understand the original business requirements as much as possible, not just to look at code smells themselves: Legacy System Refactoring Process.

You can quickly build a system map in a very plain way; there’s no need to start with complex architecture diagrams:

1. API call chain: who calls me, and who do I call
   List entry APIs, scheduled jobs, message consumers, and external RPC/HTTP calls. Pay special attention to synchronous versus asynchronous paths, because async messages are often “invisible in the code but triggered in production” hidden dependencies.
2. Database table dependencies: which tables are read, written, or updated together
   Record core tables, status fields, unique indexes, soft-delete fields, and legacy compatibility fields. Pay particular attention to tables that are “write-only” or “read-only”; they may serve risk control, finance, BI, or manual operations backends.
3. Key business flows: draw normal paths, exception paths, and compensation paths separately
   Don’t draw only the happy path. What really tends to explode are edge flows like refunds, cancellations, timeout retries, duplicate callbacks, manual order补单, and state rollbacks.
4. Implicit rules: rules not in comments but assumed by the business
   For example: “old users cannot migrate to the new discount model,” “orders from certain channels cannot be auto-closed,” or “orders with amount 0 must not trigger the invoicing flow.” These rules may not be elegant, but they usually explain why the spaghetti grew the way it did.

A simple dependency list is often enough, for example:

Create Order API
├─ Validate user status: UserService / userstatus table
├─ Calculate price: PromotionService / couponrecord table / activityconfig table
├─ Lock inventory: InventoryService / stocklock table
├─ Create payment order: PaymentService / payorder table
├─ Send message: ordercreated_topic
└─ Downstream consumers: fulfillment, invoicing, risk control, operations reports

In real scenarios, the most common problem in order systems is this: a single createOrder() method stuffed with multi-conditional branches, continually extended based on user type, channel, promotion, payment method, inventory type, and whether it’s presale. Newcomers look at the code and think, “These branches are duplicated; we can extract them into a strategy pattern.” But once you ask the business, you find that two seemingly identical pieces of logic actually serve “standard coupons” and “platform-sponsored coupons” respectively; during refunds, the liable party differs, and the financial reconciliation rules differ as well. If you refactor purely based on code shape, you may merge two business rules that must not be merged.

When explaining this step in an interview, you can nail the point with one sentence:

I won’t rewrite core methods right away; I first draw the business flows, API call chains, and data dependencies to confirm which branches are truly duplicated and which ones carry historical business rules.

There are two common pitfalls:

• Pitfall one: rewriting directly.
  Rewriting looks fastest, but without a business map, you’re essentially recreating the system you think exists, not the one that actually runs in production.
• Pitfall two: only reading code, not walking the business paths.
  Reading code alone easily traps you in local details like method names, class responsibilities, or repeated conditions. The real dangers in spaghetti projects usually lie in cross-system calls, state transitions, and historical data compatibility. Code is only one layer of the map; production traffic, database states, and operational processes are the full terrain.

The output of the first step doesn’t need to be pretty, but it must answer three questions: Which business chain does this code serve? Which upstream and downstream systems does it depend on? Who is most likely to be affected if I change it? If you can answer these three questions, then adding tests, isolating risk, and incremental replacement in later steps will have a solid footing.

Step 2: Identify the Untouchable Core Logic and High-Risk Areas

In legacy “spaghetti” projects, the most dangerous code is often not the ugliest code, but the code closest to money, permissions, transaction state, and SLAs. What you see may be a pile of duplicated checks, hard-coded values, and historical branches; what the production system relies on may be implicit rules forged through years of incidents. So the second step is not to immediately abstract, merge, or delete branches, but to first tag the code by risk: what can be cleaned up, what can only be wrapped, and what absolutely must not be touched for now.

When talking about this step in an interview, the key is not to show how good you are at refactoring, but to show that you understand: the first goal of refactoring is not to blow up production.

You can start by classifying modules into three risk categories:

A common pitfall is this: two methods look 90% identical, so you merge them without thinking. For example, in an order system there might be two discount calculation branches:

• calculateNormalOrderDiscount()
• calculateChannelOrderDiscount()

A newcomer sees that both do “full reduction + coupons + membership discount” and extracts a common method. But a senior colleague tells you: channel orders cannot stack coupons with membership discounts because of a contractual constraint from two years ago; normal orders can stack them because it was promised in a marketing campaign. The code is indeed duplicated, but behind that duplication are different business rules. If you treat this purely as a code smell, it’s very easy to refactor “duplicate code” into a “unified incident”.

When identifying high-risk areas, don’t rely only on reading code. A more reliable approach is to pull information from three sources:

1. Check logs and monitoring
   Look for APIs with high error rates, frequent alerts, or high call volumes. Pay special attention to modules like payment callbacks, order state updates, permission interceptors, and scheduled compensation tasks—modules that are “quiet most of the time, but fatal when they fail”.
2. Review historical issues, incident postmortems, and release records
   If a class repeatedly appears in emergency fixes, production rollbacks, or data repair scripts, it’s very likely not just ordinary bad code but an incident hotspot. Record the reasons first; don’t rush to “optimize it while you’re there”.
3. Ask the people who have maintained it
   In many legacy systems, the real rules are not in comments, but in senior engineers’ heads. InfoQ’s practices on legacy system refactoring also mention that pair refactoring allows someone familiar with the business context to confirm decisions in real time, improving safety; at the same time, risk should be reduced through tests and small, incremental commits (see this interview on Orderly Code Refactoring).

In practice, you can label each module with a simple tag:

• P0: Untouchable Areas
  Funds, permissions, core transaction chains, historical incident modules. In the short term, only logs, tests, and side-channel validation are allowed; no direct changes to business logic.
• P1: Change-with-Caution Areas
  Modules with many dependencies but some testing or rollback mechanisms. Small-scale refactoring is allowed, but must include canary releases, monitoring, and rollback plans.
• P2: Priority Cleanup Areas
  Low traffic, low business impact, clearly bounded utility classes, presentation logic, and internal admin features. Suitable as the first batch of refactoring targets to build safety nets and team trust.

You can express it like this in an interview:

“I don’t start by fixing the messiest code. I start with the parts that have the lowest risk and verifiable returns. For core logic like payments, permissions, and order state machines, I first mark them as untouchable areas, confirm implicit rules through logs, historical incidents, monitoring, and business owners, and then decide whether to replace them via side channels or feature flags.”

The value of this statement is that you don’t promise that “refactoring will definitely be safe”; instead, you show that you know how to cage uncertainty. For legacy spaghetti projects, identifying what must not be touched is often more important than knowing how to start changing things.

Step 3: Add Minimal Tests or a Logging-Based Verification Mechanism

Don’t touch core logic directly in a “zero-test” pile of spaghetti code. You might think you’re just changing an if, but in reality you could be altering a hidden rule that only triggers for a major client, a historical order, or a specific canary city. A more realistic approach is not to immediately build a perfect testing system, but to first add a layer of minimal safety net: protect only the most critical, most failure-prone paths that best represent business value.

In an interview, you can express this step like this:

“Legacy systems are usually hard to add unit tests to immediately, so I first lock down current behavior in a black-box way—such as key-path regression scripts, API snapshot tests, or log comparisons. The goal isn’t coverage, but knowing which behaviors I must not accidentally change before refactoring.”

This idea aligns with common practices in legacy system refactoring: for heavily decayed systems, teams often start by covering medium-to-large integration tests or UI tests to guard core business logic, and only add finer-grained unit tests after the structure becomes clearer. InfoQ’s refactoring interviews also mention that many legacy systems have issues like tens of thousands of lines per class or huge methods, making unit testing very difficult. A more pragmatic strategy is to first use automated tests to protect major business scenarios, then refactor in small steps with frequent feedback, and gradually add smaller tests.

You can build the safety net with the following priority:

A simplest example: you want to refactor an old user profile API /api/user/profile. Don’t start by breaking up Services. First, fix several user samples: a normal user, a VIP user, a frozen user, and a historically migrated user. Then write an API snapshot check to at least ensure that key fields of the old API aren’t accidentally removed.

cases = [
  { userId: 1001, type: "normal" },
  { userId: 2001, type: "vip" },
  { userId: 3001, type: "frozen" }
]

for case in cases:
    response = GET("/api/user/profile?id=" + case.userId)

assert response.status == 200
    assert response.body contains ["userId", "name", "level", "status"]
    assert response.body.userId == case.userId
    assert response.body.status in ["ACTIVE", "FROZEN", "DELETED"]

saveSnapshot(case.type, normalize(response.body))

The normalize step is critical here: don’t hard-compare fields like timestamps, random IDs, or dynamic recommendation lists, or the test will fail every day. You should compare only stable fields and business-critical fields, such as user level, account status, permission flags, amounts, and order status. Snapshot tests are more like “scaffolding”: they lock down current external behavior rather than proving how elegant the internal design is. Similar views are common in legacy code refactoring discussions: before refactoring, establish baseline or snapshot tests to lock in the current behavior of “input A produces output B.” Even if the output contains historical issues, you should distinguish between “behavior locking” and “bug fixing” phases, avoiding mixing refactoring with business logic changes.

If even automated tests are hard to integrate, start with a log-based verification mechanism. For example, before refactoring order discount calculation, print structured logs at key exits of the old logic:

log.info("couponcalcresult", {
  orderId,
  userId,
  couponId,
  originAmount,
  discountAmount,
  finalAmount,
  ruleId,
  resultCode
})

After refactoring, log the same fields. Before release, run a batch of orders in a test environment or with canary traffic, and compare old vs. new logs: does the same order hit the same rule, is the discount amount the same, and are error codes consistent? It’s not as clean as tests, but it’s extremely practical in legacy systems—especially at the stage where “logic is scattered across multiple Services and no one dares to extract functions.”

A common pitfall is: trying to add all tests at once, causing the project to stall.
This happens easily in real teams: you just take over a spaghetti codebase, feel increasingly uneasy as you read it, and decide to add Controller tests, Service unit tests, DAO mocks, boundary cases, and exception branches. Two weeks later, business requirements haven’t moved, refactoring hasn’t started, and your boss only sees “zero progress.”

A more realistic standard is:

1. Cover the most profitable or most failure-prone paths first: payment, login, ordering, settlement, permissions.
2. Test external behavior before internal implementation: API inputs/outputs, state changes, and log results come first.
3. Preserve current behavior before fixing bugs: don’t disguise “refactoring” as “casually changing business logic.”
4. Add only the tests that support the next cut: if you’re breaking apart discount calculation, protect discount calculation first; if you’re changing the user state machine, protect state transitions first.

What interviewers really want to hear isn’t “I’ll raise test coverage to 90%,” but that you know how—under constraints of schedule, risk, and business pressure—to first build a safety net that’s good enough, so every subsequent refactor has feedback, evidence, and traceability.

Step 4: Gradually Replace Old Logic Using Isolation Strategies

With minimal tests and a logging safety net in place, don’t “wipe out everything in one go” when you start making real changes. What legacy systems fear most is not ugly code, but not knowing which ugly code carries historical incidents, operational exceptions, or gray-release patches. A safer approach is: isolate first, run in parallel, then replace. This aligns with the commonly cited legacy system governance mindset of “protect–isolate–optimize.” The core goal is to shrink the blast radius of changes, not to prove you can rewrite a module in one shot.

You can prioritize three types of isolation strategies:

For example, suppose you have a classic “ancestral if-else” that calculates prices based on user type, region, campaign, and channel:

// before: all business rules stitched into one method
Money calculatePrice(Order order) {
    if (order.userType == VIP && order.region == "CN") {
        // member price + domestic promotion
    } else if (order.userType == NEW && order.channel == "APP") {
        // new-user App discount
    } else if (order.hasCoupon()) {
        // coupon logic
    } else {
        // default price
    }

// inventory, risk control, logging, tracking are also mixed in below...
}

Don’t start by building a “perfect domain model.” A more realistic approach is to first extract a stable entry point so external callers don’t perceive internal changes:

// after: establish a unified entry point first, then migrate rules gradually
interface PriceStrategy {
    Money calculate(Order order);
}

class LegacyPriceStrategy implements PriceStrategy {
    Money calculate(Order order) {
        return legacyCalculatePrice(order); // wrap the original logic as-is
    }
}

class VipPriceStrategy implements PriceStrategy {
    Money calculate(Order order) {
        // new VIP pricing logic
    }
}

class PriceService {
    Money calculate(Order order) {
        if (FeatureFlag.enabled("newvipprice") && order.isVip()) {
            return new VipPriceStrategy().calculate(order);
        }
        return new LegacyPriceStrategy().calculate(order);
    }
}

The key point here is not that “using the Strategy pattern is sophisticated,” but that you’ve narrowed the risk boundary: the old logic still exists, and the new logic only takes over a clearly defined scenario, such as “VIP users + domestic orders.” If anomalies are found in production, you just need to disable newvipprice, and requests immediately return to the old path—no emergency rollback of the entire release required.

An even safer approach is to run Shadow Logic first. That is, production continues using the old result, while the backend quietly computes the new result and records the differences:

Money oldResult = legacyPrice.calculate(order);

if (FeatureFlag.enabled("shadownewprice")) {
    Money newResult = newPrice.calculate(order);
    logCompare(order.id, oldResult, newResult);
}

return oldResult; // users still receive the old result

This step is especially worth elaborating on in interviews because it demonstrates engineering judgment: you’re not “trusting the new code you wrote,” but validating it with real traffic. You can observe the difference rate, the distribution of difference amounts, and the affected business scenarios, then decide whether to expand from 1% canary to 10%, 50%, or 100%.

If the old module exposes very dirty data structures—for example, amounts as strings, mixed status codes, or field semantics that depend on historical channels—don’t let the new module consume this data directly. Add an Adapter / Anti-Corruption Layer:

class LegacyOrderAdapter {
    CleanOrder adapt(LegacyOrder legacy) {
        return new CleanOrder(
            parseMoney(legacy.amountText),
            normalizeStatus(legacy.status),
            mapChannel(legacy.source)
        );
    }
}

The benefit of this approach is that the chaos of the old world stays inside the Adapter, and the new logic only deals with relatively clean models. Similar anti-corruption layer ideas are commonly used to isolate dirty data when old and new systems coexist. Refactoring practices shared by the Tencent Cloud Developer Community also mention using adapters to transform raw legacy system data into standardized objects required by the new domain model, avoiding pollution of core logic (Anti-Corruption Layer Design).

In interviews, you can summarize this section in one sentence:

“I don’t delete old logic directly. I first use Feature Flags and Adapters to establish boundaries so new and old logic can run in parallel; then I gradually expand coverage through Shadow comparison and canary releases. This way, even if the new logic has issues, we can roll back quickly and use logs to prove whether the migration is safe.”

A common pitfall is turning “isolation” into “architectural洁癖”: introducing complex frameworks, splitting into a dozen modules, and designing a pile of abstract interfaces right away—only to have delivery pressure halt the project before the business logic is fully migrated. The correct scale is: design isolation layers only for the key paths you’re replacing right now. If today you’re migrating price calculation, don’t opportunistically refactor inventory, coupons, payments, or notifications. Replace one small piece at a time, and ensure each step has a switch, logs, and a rollback path. That’s what truly makes safe, practical refactoring possible in a spaghetti-code project.

Step 5: Go-Live Monitoring and Rollback Mechanisms

Many “spaghetti-code projects” don’t die during the coding phase of a refactor, but during the release phase: test environments have data that’s too clean, load testing traffic isn’t realistic, the gray release scope is chosen incorrectly, or no one watches the metrics after launch. No matter how beautifully you tidy up the code locally, as soon as some historical edge case in production is hit, what the business sees is not “the architecture is more elegant,” but “it worked yesterday and is broken today.”

So the final step of refactoring is not merging code, but designing an observable, loss-limiting release loop. Especially in interviews, you need to express one key mindset: a refactoring release is not about proving you wrote things correctly, but about quickly discovering what’s wrong and being able to safely roll back. InfoQ’s practices on legacy system refactoring also emphasize that small, incremental releases help with problem localization and rollback, and that the refactoring process must establish effective measurement and feedback mechanisms; otherwise, both value and risk are hard for the team to perceive.

Before going live, prepare at least the following categories of monitoring:

A real-world scenario: you refactor an old coupon calculation implemented with a pile of if-else statements into a strategy pattern, and roll it out to 5% of users. Error rates don’t rise noticeably, and API latency is stable, but business monitoring shows that the coupon usage rate for “enterprise customer renewal orders” suddenly drops. Further log analysis reveals that the old logic contained an undocumented edge rule: when enterprise customers renew at the end of the month, they can stack a certain class of historical whitelist coupons; the new strategy missed this branch.

At this point, what truly tests you is not “can you fix it immediately,” but whether you prepared an escape route in advance:

1. Use feature flags to disable the new logic first
   If the old and new logic coexist, switch traffic back to the old logic instead of hot-fixing core code on the spot.
2. Keep deployable packages or container images of the old version
   Don’t let “rollback” turn into re-packaging, re-approval, and re-guessing configurations. Before going live, confirm that the last stable version can be restored with one click.
3. Make database changes reversible or compatible
   The most dangerous situation is when code can roll back but data structures cannot. Field deletions, state enum changes, and data migration scripts must consider forward compatibility; when in doubt, add fields, dual-write, observe, and then clean up.
4. Logs must pinpoint users, requests, and strategy branches
   At a minimum, record requestId, user type, which old/new logic version was hit, summaries of key inputs, and result differences. Don’t just log a single line like “calculate failed”—that’s almost useless for incident recovery.
5. Agree on loss-limiting thresholds
   For example: a core API’s 5xx rate exceeds baseline for 5 consecutive minutes, P99 latency doubles, payment success rate drops significantly compared to the same period, or key business alerts fire continuously—then pause the gray release or roll back. Thresholds don’t need to be dramatic, but they must be written down in advance to avoid emotion-driven decisions during incidents.

In interviews, you can wrap up your answer like this:

“I wouldn’t treat a refactoring release as a one-off launch. I’d close the loop with gray release, monitoring, and rollback. First, control traffic via feature flags and only release to a small group of low-risk users; after going live, watch both technical and business metrics, especially error rates, P99 latency, core conversion rates, and differences between old and new results; if boundary business anomalies appear, switch back to the old logic to limit losses first, then locate the issue through logs. This way, even if the refactor doesn’t fully cover all historical rules in one go, it won’t escalate risk into a production incident.”

The point of this answer is not to make you sound like “someone who writes great code,” but to convince the interviewer that you know legacy systems hide landmines—and that you know how to contain the blast radius before they explode. Truly mature refactoring isn’t about having no incident risk, but about making risk observable, isolatable, and reversible.

Why Projects Gradually Turn into a “Shit Mountain”

Many “shit mountain” projects aren’t bad at the beginning—often quite the opposite. They are usually hero systems of a certain stage: they deliver, they go live, they support business growth. The real problem is that through repeated choices like “let’s do it this way for now,” “we’ll handle it in the next version,” or “this client is special,” layer after layer gets added. As some developers have summarized, a shit mountain doesn’t cause disaster immediately. Precisely because it can still run, it survives for a long time and continues to swell.

A common evolution story goes like this: at first, it’s just a simple order status check—three to five states, two or three entry points. The code is clear, and the owner understands what each branch means. Then a big client arrives and needs exclusive discounts; a marketing campaign needs to temporarily bypass inventory checks; the finance system requires compatibility with legacy fields; there’s an online incident, so another protective branch is added. Half a year later, the original “order processing module” has turned into something where everyone can understand a small part, but no one dares to claim they understand the whole picture.

Common sources of technical debt are usually not that a programmer “isn’t good enough,” but the accumulation of these real-world factors:

• Requirement pressure: Deadlines are close, the benefits of refactoring are hard to explain, and patch-style development is the easiest to get approved.
• Legacy compatibility logic: Old clients, old data, and old interfaces can’t be changed, so new logic can only be wrapped with yet another layer of conditions.
• Patch-style fixes: Production bugs require immediate bleeding control; root cause analysis and structural cleanup get pushed to “later.”
• Insufficient test coverage: Without automated tests as a safety net, the risk of changing core logic is amplified.
• Missing documentation: Rules exist only in chat histories, veteran employees’ memories, and comments that are already obsolete.
• Staff turnover: After people who understand the background leave, the business intent in the code becomes even more diluted.

Here is a key insight: the higher the cost of understanding, the more the team tends to keep adding patches; the more patches there are, the higher the cost of understanding becomes. This is the self-reinforcing mechanism of a shit mountain. For those preparing for interviews, what’s truly valuable is not simply complaining that “the code is terrible,” but being able to clearly explain why it became this way, where the risks are, and how you would gradually dismantle it without blowing up production.

Typical Spaghetti-Code Structure: The if-else Forest and Implicit Business Rules

The most common spaghetti-code projects are not necessarily those where “the code doesn’t run at all.” On the contrary, they often run for a long time, have supported many business traffic peaks, and may even have once been the team’s “hero system.” The problem is that with every requirement change, the structure was never altered—conditions were simply added to the existing flow. Over time, the code comes to look like an if-else forest, while the real business rules are scattered across branches, magic values, comments, and historical patches.

A typical core method might look like this:

public PriceResult calculatePrice(Order order, User user) {
    if (order.getType() == 1) {
        if (user.getLevel() >= 3) {
            if (order.getSource().equals("APP")) {
                // Special handling for legacy campaign users
                if (order.getCreateTime().before("2022-06-01")) {
                    return oldVipAppPrice(order);
                } else {
                    return newVipAppPrice(order);
                }
            } else if (order.getSource().equals("MINIPROGRAM")) {
                return miniProgramVipPrice(order);
            }
        } else {
            if (order.hasCoupon()) {
                if (couponService.isSpecialCoupon(order.getCouponId())) {
                    return specialCouponPrice(order);
                }
                return normalCouponPrice(order);
            }
        }
    } else if (order.getType() == 2) {
        // Customized logic for B-side clients, must not be removed
        if (order.getCustomerId().equals("C10087")) {
            return customCustomerPrice(order);
        }
        return enterprisePrice(order);
    }

return defaultPrice(order);
}

The scariest part of this code is not the nesting depth itself, but the fact that each branch may represent a real business commitment:

• order.getType() == 1: possibly an early consumer (C-end) order type;
• createTime before 2022-06-01: possibly compatibility logic left over from a pricing system migration;
• customerId == C_10087: possibly a special clause in a major client’s contract;
• source == MINI_PROGRAM: possibly a rule hastily added when the mini-program channel launched;
• specialCoupon: possibly a fallback patch after a marketing incident.

Therefore, an if-else forest is not merely “ugly code,” but rather the result of business evolution that was never modeled, only appended into control flow. When a team becomes accustomed to a delivery pattern of “new requirement → new branch, new scenario → new condition, new rule → new special case,” the spaghetti code enters a steady growth curve. This is also a pattern repeatedly mentioned when developers reflect on how spaghetti code forms: every requirement is additive.

It keeps expanding, usually for three technical reasons:

1. Overly centralized modification points
   All business logic is crammed into a single service, handler, or controller. When a new requirement arrives, the easiest place for developers to find is the old method, so they keep inserting branches into the middle of it.
2. Rules have no names
   The code only has if (status == 3 && type == 2), not a business expression like isRefundableEnterpriseOrder(). When rules are not named, they cannot be discussed, reused, or tested. The only way to understand them is to read the entire code block and guess the intent.
3. Lack of verifiable boundaries
   Without unit tests, contract tests, or regression cases, no one can be sure “which users will be affected if this branch is changed.” As a result, the safest approach is not to delete old logic, but to add an even narrower condition and route the new logic around it.

This is also why many spaghetti-code systems cannot be rewritten directly. You think you are rewriting code, but in reality you are rewriting a pile of business history that no one fully remembers. Why does an interface use POST in the old code when the documentation says the new code should use GET? Why does a page still have hidden backend entry points? Why do an empty string and null represent different states for a field? These may not be “garbage logic,” but implicit rules accumulated after years of production operation. In similar refactoring-failure cases, common problems include missing modules, inconsistent interface behavior, and one-shot releases causing issues to erupt all at once, ultimately forcing a rollback. These risks are typical in postmortems of refactoring spaghetti-code projects.

If you are asked in an interview, “What complex legacy projects have you encountered?”, don’t just say “There were a lot of if-else statements, and it was messy.” A better answer would be:

The problem with that module wasn’t simply poor code style, but that business rules had long been embedded as inline conditions in the main flow. My first step wasn’t to rewrite it immediately, but to identify which branches corresponded to real business rules, which were obsolete patches, and which needed test coverage, and then decide whether to abstract, isolate, or remove them.

When you can analyze “there are a lot of if-else statements” down to the level of “implicit business rules lack proper modeling,” your answer shifts from venting to technical judgment.

Organizational Factors: Requirement Pressure, Staff Turnover, and Tribal Knowledge

Many “spaghetti-code projects” are not messy because some developer wrote bad code, but because the organization has long tacitly accepted a collaboration model: business rules do not go into documentation, tests, or code semantics; they exist only in the minds of a few veteran employees. This is what is known as “tribal knowledge.”

Tribal knowledge: implicit rules on which a system’s normal operation depends, but which are not explicitly written into requirement documents, interface contracts, test cases, or code comments, and are instead passed along orally by senior staff.

For example, there might be an order status field status = 7, with code that only says:

if (status == 7 && source == 3) {
    // Special handling
    return manualReview(order);
}

A newcomer seeing this logic only knows that it is “special,” but not why it is special. After asking around, they eventually learn that three years ago, orders from a certain major client’s channel had to bypass automatic review due to reconciliation system delays. Later, the client’s contract ended, but no one dared to delete the logic because no one knew whether other channels had reused it. As a result, this if statement evolved from a temporary patch into an inherited rule.

Staff turnover further exacerbates the problem. When senior employees leave, handover documents usually say things like “the order module handles creation, payment, and refund flows,” but they rarely spell out in full:

• Which pieces of logic are historical patches;
• Which fields must not be modified casually;
• Which interfaces appear deprecated but are still called by back-office entry points;
• Which exceptional paths are triggered only at month-end, during holidays, or in major client campaigns;
• Which production incidents have occurred before, and why they were fixed that way at the time.

As a result, for someone new taking over a system that is “running stably in production,” the most rational choice is often not refactoring, but avoiding the core logic they cannot understand and continuing to add patches around the edges. This is a recurring theme in many developers’ stories: systems with no complete architecture diagrams or requirement documents, where core logic is passed down orally; there are segments of code no one dares to touch, and no one can clearly explain their purpose. Projects like this often already exhibit typical spaghetti-code index characteristics.

A very common scenario looks like this:

I’ve seen similar situations: a newcomer takes over a membership benefits module and needs to add a “Black Gold Member exclusive coupon.” The code already has four sets of checks for regular members, corporate members, channel members, and trial members. The cleanest approach would be to sort out the benefits model, but the schedule allows only three days, and no one can confirm whether old membership levels are still referenced by certain marketing campaigns. In the end, the solution becomes adding an if (vipType == BLACK_GOLD) after line 260 of the original method. It works fine in production—but when another “co-branded card member” comes along, the method keeps growing.

The most dangerous aspect of this kind of problem is that each patch is the safest choice at the moment, but in the long run it continuously raises the cost of understanding. The higher the understanding cost, the more hesitant future maintainers become about refactoring; the more hesitant they are, the more they lean toward patch-based development. After a few cycles, the system no longer depends on documentation or models, but on “who still remembers what happened back then.”

So, if you plan to turn this spaghetti-code experience into interview material, don’t just say “the project code was a mess.” A more valuable way to present it is:

• What tribal knowledge you identified;
• How you reconstructed business rules from senior staff, tickets, logs, historical PRs, and production incident records;
• How you distilled oral rules into documentation, test cases, state machine diagrams, or interface contracts;
• How you reduced the onboarding cost for newcomers without impacting delivery.

What interviewers really want to hear is usually not how you complain about predecessors, but whether you have the ability to turn risks that are “known only by a single person” into assets that “the whole team can understand and verify.”

Can AI Refactoring Tools Save a Codebase from Hell? Real Capabilities and Limits

Let’s start with the conclusion: AI can help you understand a codebase from hell faster, locate code smells, and generate small-step refactoring plans, but it cannot replace your understanding of the business. Especially in interviews, don’t frame your answer as “I used AI to refactor legacy code with one click.” A more credible explanation is: you use AI for structural analysis and low-risk changes, and rely on tests, canary releases, and business validation as safeguards.

The value of AI in refactoring is closer to an “accelerator” than to “autopilot.” For example, IBM’s introduction to AI-driven code refactoring also emphasizes that AI suggestions still need developer review and test validation to ensure affected functionality works correctly. Some practical articles further point out that AI refactoring is highly context-dependent: without clear intent, it often can only handle basic operations like renaming or method extraction, rather than reliably making complex architectural decisions. You can refer to this analysis on how AI-assisted refactoring depends on effective context.

A common failure scenario is this: AI sees a piece of logic that is “never called by the new version of the client” and suggests deleting it. But in reality, a major customer may still be using an old client from three years ago, and the server must retain this compatibility branch. Or in payment risk control, an if that looks redundant may actually be a patch added after a financial loss incident. AI can see the code, but it doesn’t necessarily know incident postmortems, customer contracts, operations console configurations, or historical canary rules.

So the right question is not “Can AI save a codebase from hell?” but putting it in the right place: let AI handle scanning, summarizing, and generating candidate solutions; let humans handle business semantics, risk prioritization, and final decisions. In practice, it’s best to break tasks into small chunks—have AI produce diffs within 50–200 lines, then review them manually and run tests. This boundary of “humans do the planning, AI does the execution” is repeatedly mentioned in AI coding practices, such as this experience summary on planning to humans, execution to AI. That way, what you present in interviews is not tool worship, but a controllable, verifiable, and practical engineering methodology.

Three Types of Refactoring Tasks AI Is Best Suited For

AI is best positioned as a “refactoring co-pilot,” helping you first organize mechanical, repetitive, and structured information; but the steering wheel should always stay in your hands. Especially when preparing for interviews, you can turn AI output into three types of explainable materials: what problems were discovered, how risks were broken down, and how you verified that the business was not broken. IBM’s summary on AI-driven code refactoring also points out that AI is better at improving consistency, accelerating analysis, and assisting with low-level refactoring, but developers still need to review suggestions and run tests to validate results—blindly merging is not an option.

Type One: Duplicate code detection—turning “copy-pasted everywhere” into a quantifiable problem.
In messy legacy projects, the most common issue isn’t an ugly function, but the same logic scattered across 8 entry points, 12 services, and 20 pages. You can have AI help scan for similar code blocks and categorize them by “duplicate logic type,” rather than asking it to modify code right away.

Example prompt:

Please analyze the following three order price calculation functions and identify duplicated logic, differences, and potentially abstractable common parts.
Do not rewrite the code directly. Only output:
1. A list of duplicated logic
2. Whether each difference could be a business difference
3. Parts that are recommended to be merged with priority

In interviews, this kind of work can be described as: “I first used tools to help identify duplicate branches and found three recurring types of logic: promotion calculation, membership discounts, and shipping fallbacks. Then I confirmed with product and QA which differences were business-related, and finally merged only the parts that were confirmed to be consistent.” This sounds far more credible than simply saying “I used AI to optimize the code.”

Type Two: Function decomposition suggestions—breaking a 500-line function into testable units.
AI is usually quite helpful with local refactorings such as “extracting pure functions,” “isolating side effects,” and “improving naming.” For example, a frontend submitOrder function might simultaneously handle form validation, price calculation, tracking, API requests, and error popups. You can first ask AI to annotate responsibility boundaries, then split things step by step. In similar practices, developers often use AI to first separate pure logic like form validation and price calculation, while keeping the original function responsible for orchestration—an approach commonly seen in refactoring cases.

A practical way to split is:

1. First ask AI to mark pure logic and side effects within the function;
2. Only ask it to extract pure functions, such as validateOrder() and calculateTotalPrice();
3. Add unit tests for these pure functions;
4. Finally, clean up the original flow function so it only coordinates calls.

Example prompt:

Please only analyze the responsibility boundaries of this submitOrder function.
Classify the code into three categories:
1. Logic that can be extracted into pure functions
2. Side effects that must remain in the flow
3. High-risk logic that is not recommended to change for now
Do not modify the code.

The key here is “classify first, then cut.” Don’t let AI rewrite the entire large function in one go; otherwise, it’s very likely to change exception handling, compatibility branches, and tracking timing all at once. A safer approach is to produce small diffs each time. Experienced developers also emphasize that breaking tasks into 5–15 minute iterations with manual review each round is much safer than handing both planning and execution entirely to AI.

Type Three: Dependency analysis—draw the map first, then decide where to start.
In many messy legacy projects, the real difficulty isn’t code length but tangled dependencies: an order service is called by payment, inventory, invoicing, and after-sales at the same time; change one line in a common utility class and a dozen modules break. AI can help you preliminarily organize call chains, module boundaries, and high-risk dependencies, but you still need to cross-check with your IDE, static analysis, logs, and test results.

Example prompt:

Based on the following files and call relationships, please organize a dependency map for orderService:
1. Which modules call it
2. Which external services or utility classes it depends on
3. Which methods are high-risk modification points
4. Where it is suitable to add tests before refactoring

You can organize the AI output into a simple table:

In a real interview, you can put it this way: “I didn’t modify the core service directly. Instead, I first mapped out dependencies to identify methods with the most references, lacking tests, and with large incident impact. I added regression cases for those points first, then did small-step refactoring.” This lets interviewers hear your risk awareness, not just your ability to use tools.

Finally, remember one principle: AI output should only be considered candidate solutions, not final conclusions. Before adopting any AI suggestion, do at least three things: read the diff, run tests, and check business scenarios. Where there are no tests, add characterization tests first; for uncertain rules, ask senior colleagues, check requirement documents, or review incident records. Being able to treat AI as an analyzer and execution assistant—rather than an “automatic refactoring button”—is the real capability worth talking about in interviews.

Three Things AI Struggles to Understand: Business Semantics, Historical Incidents, and Implicit Rules

When AI looks at code, it sees “the structure in the current text”; when humans look at a legacy spaghetti project, they see “why it ended up like this.” The difference is huge. Many dangerous refactoring accidents don’t happen because AI can’t extract functions or rename variables, but because it doesn’t know that behind some ugly code there may be business compromises, production incidents, or team conventions.

So in interviews, when talking about AI refactoring, a safer way to phrase it is not “I used AI to refactor the project,” but:

AI helps me improve code understanding and the efficiency of local changes; key business decisions, risk identification, and release boundaries are controlled by me.

This also aligns with more realistic engineering experience: AI refactoring depends on effective context; when context is missing, its suggestions may be inaccurate; developers still need to review, test, and validate AI output. Similar views are repeatedly mentioned in discussions like AI-assisted software engineering practices and IBM’s take on AI code refactoring: AI can boost efficiency, but it cannot replace an engineer’s judgment.

First, AI has a hard time understanding business semantics.

For example, in a payment system there may be logic that looks strange at first glance:

if (user.isNew && order.amount > 500) {
  riskLevel = 'HIGH'
}

if (channel === 'partner_x' && order.amount > 300) {
  riskLevel = 'HIGH'
}

AI might suggest abstracting them into a unified rule:

if (order.amount > threshold) {
  riskLevel = 'HIGH'
}

From a code cleanliness perspective, this suggestion is fine; but from a business perspective, “large payments by new users” and “payments through a specific channel” may correspond to two completely different risk-control strategies: the former prevents fraud, the latter prevents channel arbitrage. They just “look similar,” not “mean the same thing.”

In interviews, you can put it like this:

I don’t let AI directly merge similar conditions. Instead, I first classify rules by business semantics: user dimension, order dimension, channel dimension, device dimension. Only after confirming that trigger conditions, risk levels, and follow-up actions are identical will I extract a common function; otherwise, at most I extract a more clearly named private method and keep the business boundary intact.

Second, AI has a hard time knowing historical incidents.

Legacy projects often contain code like this:

// Do not delete, for historical reasons
if (request.getClientVersion() < 231) {
    return oldResponseFormat(data);
}

Or worse, with no comments at all:

if ("0".equals(user.getStatus())) {
    return defaultProfile();
}

AI cannot see the production incident from three years ago: an old version of the app couldn’t parse new fields, causing large-scale white screens; nor does it know that a partner API has been sending the wrong status value for years, but the contract hasn’t expired, so the system must remain compatible. So it may conclude: “This is obsolete logic,” “This is a dead branch,” “It can be deleted.”

These spots are ideal to turn into interview highlights, because they demonstrate engineering maturity rather than just coding skill:

1. Verify first: check Git blame, commit messages, incident postmortems, monitoring alerts, and support tickets.
2. Isolate next: wrap historical compatibility logic into clearly named methods, such as handleLegacyClientResponse().
3. Add tests: add regression cases for old versions, abnormal states, and boundary inputs.
4. Set exit criteria: if the business allows, add metrics to track call volume and re-evaluate deletion only after it stays below a threshold for several releases.

Explaining it this way is far more credible than simply saying “I deleted useless code.”

Third, AI has a hard time identifying implicit rules.

Implicit rules aren’t impossible to express in code; rather, no one has fully written them into code, documentation, or comments. For example:

• An API cannot be called concurrently because the downstream inventory service is not idempotent;
• A field cannot be renamed because BI reports directly depend on the JSON key;
• A sleep(200ms) looks stupid, but it actually works around eventual consistency delays of a third-party API;
• Certain order statuses cannot be merged because finance, customer service, and warehouse systems interpret them differently.

AI may treat these as “code smells,” but humans need to judge whether they are technical debt or business constraints. If it’s temporarily unclear, the safer approach is not to refactor immediately, but to first do “three small things”:

• Name the rule: replace magic conditions with intention-revealing functions or constants, such as isLegacyPartnerSettlementCase().
• Add guardrails: add unit tests and integration tests to at least cover current behavior.
• Find the owner: determine whether it belongs to product rules, operational rules, financial rules, or pure technical legacy.

When using AI in practice, you can make boundaries more explicit:

Please only analyze possible implicit business rules in this code, and do not directly suggest deletion or merging.
Please output in the format: “possible business meaning / risk of deletion / who to confirm with / suggested tests to add.”

The goal of this kind of prompt is not to let AI make the final call, but to have it help you organize a risk checklist. The real judgment still belongs to humans: do you understand the business flow, know the incident history, and can you design a validation path?

If you include this experience in your résumé or interview answers, you can emphasize one sentence:

My principle in using AI is “let it expand my perspective, but not take responsibility for me.” For high-risk logic such as payments, risk control, permissions, accounting, and compatibility, I establish tests and monitoring first, then refactor in small steps, rather than applying a large AI-generated overhaul in one shot.

How to Present Legacy Code Refactoring Experience as a High-Quality Interview Story

Many engineers have clearly wrestled with the toughest legacy systems, yet in interviews they only describe it as “I optimized some code,” “split a few modules,” or “added tests.” The problem isn’t that the experience isn’t solid enough; it’s that maintenance work hasn’t been translated into engineering capabilities that interviewers can evaluate: how complex the system was, what risks refactoring failure would bring, why you chose that approach, and what impact it ultimately had on delivery or stability.

When talking about refactoring a “messy codebase,” you shouldn’t present it as a “technical activity log,” but organize it around Problem — Action — Result. If it’s a behavioral interview, you can also apply STAR, but embed the technical details:

1. Problem scale: codebase size, number of modules, call-chain complexity, testing coverage gaps, release frequency, and production impact scope.
2. Risk assessment: which logic couldn’t be touched lightly? Did it involve core paths such as payments, login, orders, permissions, or billing?
3. Concrete decisions: did you first add characterization tests/snapshot tests, or start with anti-corruption layers, facades, module decomposition, dependency inversion? Why not rewrite directly?
4. Execution approach: how you made small incremental commits, used canary releases, rollback mechanisms, monitoring, code reviews, and aligned release windows with business stakeholders.
5. Result validation: express value with verifiable metrics, such as build time, defect rate, number of regression issues, release duration, delivery cycle time, cyclomatic complexity, or code duplication rate.

The key point is: refactoring is not “I made the code look nicer,” but “I reduced system risk and future delivery cost without interrupting the business.” In legacy systems, ugly-looking if-else blocks often carry historical incidents and edge cases, so interviews should convey a sense of caution: modifying core logic rashly without a safety net is essentially amplifying production risk. On this point, common advice for legacy system refactoring emphasizes establishing a testing safety net first, then gradually touching core logic, rather than tearing everything down and starting over. You can refer to this article on a systematic approach to taming messy code.

A simple but sufficient structure you can prepare looks like this:

Background: We had a legacy order module where core flows were concentrated in a few large classes; adding new promotion rules often affected payments, inventory, and coupon logic.
Problem: Slow requirement delivery, wide regression scope, testing mainly reliant on manual verification, and the team was afraid to touch the core branch.
Action: I didn’t rewrite it directly. I first added black-box/characterization tests and snapshot tests for the core paths to lock in existing behavior; then isolated external dependencies through interface abstraction and an anti-corruption layer; finally, I split methods and modules by business capabilities, ensuring each commit addressed only one clear change.
Result: Subsequent rule additions had a more controlled change scope, faster regression localization, and clearer module boundaries. If data is available, add before-and-after comparisons of build time, defect counts, release duration, or development cycle time.

If you have real metrics, be sure to organize them in advance. If you don’t, don’t fabricate numbers—describe “observable changes” instead: for example, “previously a requirement required changes in five files; now changes are mostly confined to the strategy module,” or “we used to rely solely on full regression; now core paths are covered by automated tests.” InfoQ’s discussion on the value of refactoring also notes that results can be made explicit through metrics like cyclomatic complexity, function length, duplication rate, build speed, and release efficiency. These metrics are very suitable for conveying engineering value in interview stories; see this interview on implementing code refactoring in a methodical way.

The next preparation focus comes down to two things: first, break down the interviewers’ most frequent follow-up questions in advance to avoid resorting to “it depends” on the spot; second, package your technical debt story into an engineering case with complexity, trade-offs, and business impact, rather than a routine code cleanup.

The Most Common “Spaghetti Code Refactoring” Interview Questions

When interviewers ask about “spaghetti code refactoring,” they’re usually not interested in hearing you rant about how bad the previous code was. They’re evaluating whether you have risk control, business judgment, and incremental transformation skills. Don’t rush to say “I’ll split modules, adopt DDD, and add unit tests.” First, frame the problem: what business the system currently supports, where the biggest risks are, and how you prove that changes won’t break production behavior. The key to refactoring legacy systems is often to first establish a testing safety net, then do isolation and optimization. This point is repeatedly emphasized in discussions about legacy code refactoring strategies.

You can focus on preparing answers to these questions:

• How would you refactor a legacy system with no documentation and no tests?
  Answer approach: Don’t change the core logic right away. First, reconstruct the business map through logs, call chains, production monitoring, database table relationships, and interviews with long-tenured employees. Then prioritize adding “characterization tests” or black-box tests to lock in current inputs and outputs, and start refactoring in small steps from modules with clear boundaries and obvious benefits.
• When facing a pile of spaghetti code in a core path, where do you make the first cut?
  Answer approach: Don’t say “rewrite the worst part first.” Instead, say “start with an entry point that has high change frequency, high incident rate, and a controllable blast radius.” For core paths like login, payment, or orders, the first cut is usually not changing internal implementations, but adding monitoring, tests, interfaces, and isolation layers.
• How do you reduce production risk during refactoring?
  Answer approach: Emphasize small commits, canary releases, feature flags, rollback plans, automated testing, and core metric monitoring. You can add that refactoring commits should be separated from business logic fixes; otherwise, when something goes wrong, it’s impossible to tell whether the regression came from structural changes or from the business fix itself.
• If the code is terrible but the business timeline is very tight, would you still refactor?
  Answer approach: Avoid extremes. Say that you distinguish between blocking technical debt that must be addressed to deliver safely, and general technical debt that can be improved gradually alongside feature development. For the former, you should persuade the team using risk and delivery cost, not by arguing that the code is “inelegant.”
• How do you convince product managers, leaders, or the team to give you time for refactoring?
  Answer approach: Translate technical language into business language: what risks the current structure creates, such as regression bugs, longer testing cycles, inability to roll back releases, or increasingly slow feature delivery. A more persuasive approach is to present a comparison: delivery risk without refactoring vs. the benefits gained after investing a small amount of time in isolation and testing.
• How do you judge whether a refactoring effort is successful?
  Answer approach: Don’t just say “the code is cleaner.” Answer using engineering metrics, such as reduced cyclomatic complexity, less duplicated code, shorter average function length, improved build or release efficiency, and faster defect localization. InfoQ interviews on refactoring practices also mention making refactoring value visible through code health and engineering efficiency metrics.
• If you discover bugs in the original logic during refactoring, do you fix them along the way?
  Answer approach: Answer cautiously. A safer approach is to first capture current behavior with tests, complete the structural refactoring, and then fix bugs in separate commits. This clearly distinguishes “behavior-preserving refactoring” from “intentional behavior-changing fixes.”
• If someone on the team opposes refactoring, how do you handle it?
  Answer approach: First clarify whether their concern is about schedule pressure, risk, unclear returns, or past incident trauma. Then reduce resistance with low-risk pilots: choose a non-core but frequently changed module, define observable metrics, and after completion, let results drive the discussion rather than arguments.
• Would you choose a rewrite or incremental refactoring?
  Answer approach: Default to incremental refactoring unless the old system can no longer support key business needs, maintenance costs far exceed migration costs, and there is a clear plan for dual writes, migration, canary releases, and rollback. Saying “just rewrite it” in an interview is risky, as it usually signals underestimation of hidden business rules and production stability requirements.
• How do you deal with implicit business rules buried in spaghetti code?
  Answer approach: Don’t just look at the surface of the code. Reconstruct rule origins through production data, historical requirements, customer support or operations feedback, exception branches, old tickets, and monitoring alerts. Those seemingly strange if-else blocks may be patches from past production incidents, and must be validated before removal to ensure the protected scenarios no longer exist.
• If performance degrades after refactoring, how do you investigate?
  Answer approach: First check whether you had baseline data before refactoring; without a baseline, it’s hard to prove the source of the problem. Start by examining API latency, database queries, cache hit rates, thread pools, and changes in call counts. If necessary, roll back to the previous small version rather than blindly debugging within a large commit.
• You wrote “led a refactoring effort” on your résumé—what exactly did you lead?
  Answer approach: Be prepared to clearly explain your scope of responsibility: identifying problems, designing solutions, driving reviews, breaking down tasks, writing core code, adding tests, or handling release and postmortems. Don’t just say “participated in refactoring.” Specify which module you influenced, what pain points you solved, and how you validated the results.

Turn Technical Debt Stories into “Valuable Engineering Cases”

In interviews, when you say “I refactored a pile of spaghetti code,” the biggest risk is sounding like code hygiene for its own sake: you spent a lot of time extracting methods, splitting classes, and changing design patterns, but the interviewer can’t tell why it mattered. A better approach is to package it as an engineering case, structured around three dimensions: complexity, decisions, and impact.

One-sentence framework: Where the system I took over was complex, what trade-offs I made in my technical decisions, and what impact those decisions had on delivery efficiency, stability, or collaboration cost.

You can prepare it in the following order:

Here’s an example you can expand on in an interview:

A typical answer:

“The order module was really messy before, so I split a huge Service into several classes and introduced the strategy pattern, which improved code readability.”

The problem with this answer is that it only describes technical actions, not engineering value. It’s hard for the interviewer to judge the scale of your contribution or whether you handled real risks.

A better answer:

“When I took over the order promotion module, the core Service mixed parameter validation, inventory checks, coupon redemption, and price calculation. Every change to promotion rules required reading the entire call chain, and there were no stable unit tests, so QA usually had to do extensive regression testing.

Instead of rewriting it outright, I first identified high-frequency change points and the core transaction path, and locked down the main behaviors with interface tests. Then I split price calculation, coupon validation, and inventory reservation into independent components, while keeping the original calling interface unchanged through a facade layer to avoid impacting upstream systems. After that, new promotion rules only required extending the corresponding strategies without modifying the main flow.

In terms of results, we could demonstrate value with at least three metrics: whether development time for similar requirements decreased, whether regression issues on the core path were reduced, and whether build or test feedback for the related modules became faster. If the company has historical data, use real numbers; if not, clearly explain which observable signals you used, such as reduced PR diff size, smaller regression scope, or fewer blocking issues before release.”

The key point here isn’t “which patterns were used,” but that you proved: this refactor reduced the cost of future change.

When quantifying results, don’t fabricate numbers. You can look for evidence in these areas first:

• Development efficiency: cycle time from estimation to release for similar requirements, number of PR review rounds, number of modified files, merge conflict frequency;
• Quality risk: production rollbacks, P0/P1 defects, number of regression test issues, monitoring alert counts;
• Engineering feedback speed: build time, test execution time, length of local debugging chains;
• Code health: cyclomatic complexity, duplication rate, average function length, convergence of module dependency directions.

These metrics aren’t interview trivia. InfoQ has also pointed out in discussions on refactoring metrics that for small to medium refactors, code health indicators like cyclomatic complexity, average function length, and class size can be observed; for large-scale refactors, engineering efficiency indicators such as build speed and release efficiency make the value of refactoring more visible. You can refer to this interview on implementing code refactoring in an orderly way, which mentions that in large legacy system refactors, the measurement and feedback mechanism itself is a critical part of making refactoring land successfully.

Finally, avoid a common mistake: talking only about technical details and not about business impact.

Don’t stop your answer at:

• “I used DDD.”
• “I added an anti-corruption layer.”
• “I replaced if-else with the strategy pattern.”
• “I split one large class into a dozen smaller ones.”

These are all fine to mention, but they are just means. You also need to add:

• Why couldn’t you keep piling on code at that point?
• Why did you choose incremental refactoring instead of a rewrite?
• How did you ensure business iteration wasn’t impacted during the refactor?
• Who benefited after the refactor: business stakeholders, QA, backend, frontend, ops, or new team members?
• If you did it again, which decisions would you keep or adjust?

What interviewers really want to judge is whether you can make controllable, valuable, and executable engineering improvements in a legacy system. Turning “I cleaned up a pile of spaghetti code” into “I reduced the change risk and delivery cost of a core business module” is what makes an interview answer truly competitive.

A Real, Reusable Case Structure for Refactoring a Spaghetti-Code System

When talking about “refactoring a spaghetti-code project” in interviews, there are two taboos. One is focusing only on complaining about historical baggage, which sounds like shifting blame. The other is overselling the results as “10× performance improvement, zero production incidents,” while being unable to present the process or evidence. A more solid approach is to organize it into a reusable case structure: Background → Problems → Risks → Solution → Results.

Your goal is not to prove that you “changed a lot of code,” but to prove that you can identify key problems in high-risk legacy systems, control release risks, and turn technical debt into business-understandable value.

Below is a typical order module refactoring example to organize interview material. The order module is especially suitable because it usually involves inventory, coupons, payment, risk control, refunds, notifications, and other chains, giving it inherent complexity. At the same time, it cannot simply be taken offline and rewritten, which demonstrates your understanding of risk control. The same structure can also be applied to permission modules, user centers, settlement systems, or approval workflow systems.

You can first compress the story clearly using a “case card”:

When describing the solution, it is not recommended to start by saying “we adopted DDD / microservices / platformization.” A more credible statement is: first identify the most frequently changing and highest-risk business points, then use minimal structural adjustments to support them. For example, extract validation, inventory, promotions, and amount calculation logic that were previously piled into OrderService, so that the order entity, pricing service, coupon strategy, and external system adapter layer each take on clear responsibilities. A case from the Tencent Cloud Developer Community’s order system also mentions a similar direction: before refactoring, a common problem was a single Service mixing大量 validation, inventory, and promotion logic; after refactoring, clearer domain models and service decomposition were used to carry business rules, preventing all logic from continuing to pile into a single method (see: Order System Refactoring Case).

But note this: the highlight of the case is not “which advanced patterns were used,” but the key decisions. For example:

• Instead of a full rewrite, regression test cases were first built around the core order placement flow;
• Instead of immediately splitting into many microservices, package structure and dependency direction were first governed within the monolith;
• Compatibility layers were retained for old data, old interfaces, and historical abnormal orders, rather than assuming the data was clean;
• Only one business branch was migrated at a time, such as migrating coupon calculation first, then inventory locking;
• Gray releases, switches, log comparisons, or dual-write verification were used to reduce go-live risks.

This kind of expression is far more persuasive than “I was responsible for refactoring the order system and improved maintainability.” Because what the interviewer hears is that you know legacy systems cannot be pushed through by courage alone; they must rely on test protection, small-step commits, rollback-capable design, and metric feedback. InfoQ interviews on legacy system refactoring also emphasize that refactoring usually requires first understanding business requirements and the original design, then adding characterization tests, performing small and safe refactoring steps, and measuring results through metrics such as cyclomatic complexity, function length, duplication rate, and build efficiency (see: Six-Step Method for Legacy System Refactoring).

Subsequent cases can be expanded on two levels: first, describe the structure, risks, and technical debt before refactoring to make the problems feel real; then describe the architectural changes after refactoring, the practical results, and retrospective insights. Organized this way, a “spaghetti-code project” is no longer just hard labor on your résumé, but a high-value interview case that demonstrates system design, engineering governance, risk control, and collaboration skills.

Before Refactoring: Problems, Risks, and Technical Debt

Don’t rush to say, “I refactored a pile of spaghetti code.” What interviewers really want to hear is not how bad the code was, but whether you could accurately identify where the complexity lay, where the risk boundaries were, and why it was worth touching. A reusable way to describe it is: this was a typical order module that was quickly built early on using Controller -> Service -> DAO. Over time, coupons, inventory, payments, risk control, and after-sales were continuously integrated, and eventually all the rules sank into one massive OrderService.

This structure is very common in many legacy systems: layers exist on the surface, but in reality business rules are concentrated in the Service layer, while domain objects are merely DTOs/POJOs. An order system refactoring case on the Tencent Cloud Developer Community mentioned similar issues: before refactoring, OrderService mixed validation, inventory calculation, coupon redemption, and other logic; only after refactoring were concepts like orders, coupons, and amount calculation made explicit as domain models (see this order system refactoring example).

Before refactoring, the code roughly looked like this:

@Transactional
public Order createOrder(OrderDTO dto) {
    // 1. Parameter validation: user, address, items, campaign, channel
    if (dto.getUserId() == null || dto.getItems().isEmpty()) {
        throw new BizException("invalid order");
    }

// 2. Query inventory and deduct
    for (OrderItemDTO item : dto.getItems()) {
        Stock stock = stockDao.query(item.getSkuId());
        if (stock.getAvailable() < item.getQuantity()) {
            throw new BizException("stock not enough");
        }
        stockDao.decrease(item.getSkuId(), item.getQuantity());
    }

// 3. Coupon logic mixed with promotion rules
    BigDecimal total = calculateTotal(dto);
    if (dto.getCouponId() != null) {
        Coupon coupon = couponDao.query(dto.getCouponId());
        if (coupon != null && coupon.getExpireTime().after(new Date())) {
            total = total.subtract(coupon.getDiscount());
            couponDao.markUsed(dto.getCouponId());
        }
    }

// 4. Branch by payment method
    if ("BALANCE".equals(dto.getPayType())) {
        walletService.freeze(dto.getUserId(), total);
    } else if ("ONLINE".equals(dto.getPayType())) {
        paymentService.createPrepay(dto.getUserId(), total);
    }

// 5. Persist, send message, write logs
    Order order = buildOrder(dto, total);
    orderDao.insert(order);
    mq.send("order_created", order.getId());
    return order;
}

The problem with this code is not just that “the method is too long,” but that business invariants have no clear ownership: where is order amount consistency guaranteed? When is a coupon considered reserved versus redeemed? How is compensation handled if inventory deduction fails? What if payment callbacks arrive repeatedly? These rules are scattered among if-else blocks, DAO calls, and external service invocations, so even a small requirement change can trigger chain reactions.

You can categorize the pre-refactoring issues into several types; explaining them this way is much clearer in interviews:

The development pain points were also very concrete: when a newcomer picked up a requirement like “add a corporate customer discount,” on day one they searched the codebase for discount, coupon, and price. On day two they discovered that the order confirmation page, order creation API, pre-payment validation, and after-sales refunds each calculated the price once. The most dangerous part was that no one dared to delete old logic, because it might be a patch for some historical channel, a major client, or a past production incident.

Here is an expression that scores highly in interviews:

At the time, I judged that this module wasn’t just suffering from “poor code style,” but was already impacting delivery certainty: requirement estimation took longer, regression scope was uncontrollable, and production issue diagnosis depended on the memory of senior engineers. So before refactoring, I broke the problems down into complexity, coupling, test gaps, and business risks, instead of directly opening a new branch and rewriting everything.

If you have real data, you can make this more convincing, for example:

• In the past three months, how many production incidents in the order module were related to amounts, inventory, or state transitions;
• How many days on average a normal order requirement took from development to integration;
• Lines of code, cyclomatic complexity, and duplicate code ratio of OrderService;
• Whether core flows had API tests, unit tests, or regression cases;
• Whether failed releases could be rolled back quickly or required manual data fixes.

If you don’t have data, don’t fabricate it. You can say: “At the time we didn’t have complete metrics, but we made an initial judgment based on defect records, release rollback logs, and code scanning results.” InfoQ’s discussions on legacy system refactoring also emphasize analyzing business requirements and code smells before refactoring, and making problems explicit with metrics like cyclomatic complexity, method length, and duplication rate (see this legacy system refactoring practice).

Finally, before refactoring, the most important thing to explain clearly is the risk boundaries: which parts must not be touched lightly, which parts require tests first, and which logic must be confirmed with product managers or senior colleagues. For example, in an order system, amount calculation, inventory deduction, payment state transitions, and refund compensation are usually high-risk areas; backend list fields, log formats, and internal query conditions may be low-risk. If you can clearly articulate these boundaries, the subsequent “how to refactor” will sound credible, rather than like an impulsive bout of technical perfectionism.

After Refactoring: Architectural Changes and Practical Results

The core of refactoring is not “making the code more elegant,” but breaking the business rules that were originally mixed together in a single OrderService into locatable, testable, and replaceable modules. In interviews, don’t just say “I used DDD / the Strategy pattern / the Chain of Responsibility”; explain clearly: why you split it, where you split it, and how you ensured it wouldn’t blow up.

This order module ultimately adopted a structure of “lightweight domain model + application service orchestration + strategy extension points”:

Before
order
├── OrderController
├── OrderService          # Order placement, inventory, promotions, pre-payment validation, notifications all here
├── OrderMapper
└── dto / entity / util

After
order
├── application
│   └── OrderAppService   # Orchestrates the flow: create order, lock inventory, calculate amount, submit payment
├── domain
│   ├── Order             # Aggregate root: order status, items, invariants
│   ├── OrderItem
│   ├── OrderCalculator   # Domain service for amount calculation
│   └── promotion
│       ├── PromotionPolicy
│       ├── CouponPolicy
│       └── FullReductionPolicy
├── infrastructure
│   ├── OrderRepository
│   └── LegacyCouponAdapter
└── api
    └── OrderFacade

There were three key decisions during the split.

First, separate “process orchestration” from “business rules.” OrderAppService is only responsible for call order and no longer contains hundreds of lines of if else. Amount calculation, promotion validation, and order state transitions are pushed down into domain objects or domain services. Similar practices—splitting an anemic Service in an order system into explicit domain models—can also be seen in the order system refactoring case on the Tencent Cloud Developer Community: coupon validation is placed in Order.applyCoupon(), and amount calculation in OrderCalculator, so rules are no longer scattered across procedural flow code.

Second, turn high-frequency change points into strategy interfaces. Promotion rules change most often, so you can’t modify the main order placement flow every time there’s a campaign:

public interface PromotionPolicy {
    boolean supports(PromotionContext context);
    Money discount(Order order, PromotionContext context);
}

public class CouponPolicy implements PromotionPolicy {
    public Money discount(Order order, PromotionContext context) {
        // Only handles coupon rules, not concerned with the order flow
    }
}

When the interviewer asks, “Where do you change things to add a new full-reduction campaign?”, you can answer very concretely: add a FullReductionPolicy, write the corresponding unit tests, register the strategy in PromotionPolicyFactory, and leave the main flow untouched. This answer is far more credible than simply saying “I used the Strategy pattern to reduce coupling.”

Third, add an anti-corruption layer when old and new systems coexist, instead of polluting the new model directly. The legacy promotion API might return a Map<String, Object>, and the fields may even contain historical dirty data. Don’t let the new domain model depend on it directly; instead, use a LegacyCouponAdapter for conversion and fallback handling:

public class LegacyCouponAdapter {
    public Coupon toDomainCoupon(LegacyCouponDTO dto) {
        // Field cleanup, default values, exception code conversion
        return new Coupon(dto.getCouponId(), Money.of(dto.getAmount()));
    }
}

This kind of anti-corruption layer is especially worth emphasizing in interviews, because it shows you’re not “doing architecture for architecture’s sake,” but dealing with the real boundaries of legacy systems: dirty data, old interfaces, and inconsistent exception semantics.

When talking about actual results, be restrained but verifiable. Don’t say things like “performance improved by 10x” without evidence; instead, you can present it like this:

If you have real data, you can supplement with metrics such as “average function length, cyclomatic complexity, duplication rate, build time, defect count”; if not, explain how you would measure them. InfoQ also emphasizes in interviews on legacy system refactoring that refactoring value needs to be made explicit through metrics like complexity, class/method length, duplication rate, build and release efficiency, rather than relying solely on subjective feelings.

Finally, the key takeaway from this case for interviews can be distilled into one sentence:

I didn’t choose a one-shot rewrite; instead, I first identified high-frequency change points, added tests to the core flow, and then isolated risk with the Strategy pattern and anti-corruption layers. The benefit of refactoring wasn’t “prettier code,” but the ability to make small changes, run small tests, and release in small increments for subsequent requirements.

This summary is crucial. Many “legacy codebase refactoring” failures aren’t because the patterns were wrong, but because refactoring was turned into a big-bang release. In real projects, the most valuable engineering judgment is often: what must be split now, what can stay unchanged for the moment, and where tests and monitoring should be used as safeguards.