Microsoft Software Engineer (Mid-Level) Interview Preparation Guide 2026

Correlating a frontend performance complaint with backend traces requires the frontend's own timing data to be joined with backend spans through a shared identifier, not just guessed at from backend metrics alone.

The method

1. Real User Monitoring (RUM) in the browser captures actual page-load and interaction timing for real users (not synthetic tests), including navigation timing, resource timing, and any custom spans around the slow interaction.
2. Propagate a correlation ID from the frontend request through to the backend (as a header on the API call the slow page makes), so a specific user's slow page load can be joined to the exact backend trace that served it. Concretely: the frontend attaches a header like traceparent: 00-8f2b1c7d4e...-01 to the API call the slow page makes; the backend reads that same header and logs it as the trace ID on its own span, so a frontend span named pageload.dashboard stitches directly to a backend span named GET /api/dashboard sharing that identifier.
3. Consistent span naming conventions across frontend and backend spans (matching operation names/prefixes) let a single trace view stitch a "page load" frontend span to the backend spans it triggered, rather than requiring manual correlation by timestamp guessing.
4. Sampling strategy: full RUM capture for a sampled percentage of real users, escalated to full detail specifically for sessions that already look slow (a threshold-triggered upgrade in fidelity: a cheap, low-overhead signal runs always-on for every session, and only once a session already looks anomalous does the system escalate to full, expensive-to-collect detail, since capturing full detail for every user by default would be too costly at scale, while waiting until a complaint arrives before capturing anything loses the very data needed to diagnose it).

A related worked instance

A load-balancer misconfiguration causing 502/503s for a subset of users is diagnosed the same way in reverse: correlate the client-visible symptom (which users, which requests) against infra-layer logs/metrics (LB health-check status, backend pool membership) using the same request-level correlation ID, rather than assuming the cause is in application code just because that's where the symptom is visible.

Trade-offs and pitfalls

RUM data can be noisy (real user devices/networks vary far more than a controlled synthetic test), so a single slow session is weak evidence on its own; the technique's value is in aggregating across many correlated frontend-to-backend traces to find a consistent pattern (a specific endpoint, a specific backend service) rather than chasing one anomalous session.

Approach: Do binary search at block granularity. Treat disk as sequence of fixed-size blocks (B bytes / records). Each probe reads one block containing the midpoint record; compute mid index, map to block number floor(mid / records_per_block), read that block (aligned), inspect record, and adjust low/high. Use an LRU block cache of small capacity C blocks and asynchronous prefetch of neighboring blocks when a probe jumps near them to amortize seeks.

Pseudocode (Python-like):

# Assume: N records, R = records_per_block, B = block size in bytes
def external_binary_search(target):
    low, high = 0, N - 1
    cache = LRUCache(capacity=C)           # holds blocks
    while low <= high:
        mid = (low + high) // 2
        block_id = mid // R
        block = read_block(block_id, cache)   # aligned read
        rec = block[mid % R]
        if rec == target: return True
        if rec < target: low = mid + 1
        else: high = mid - 1
        # Proactive prefetch: when jump distance > 1 block, prefetch neighbor
        prefetch_candidates = prefetch_plan(low, high, R)
        for b in prefetch_candidates:
            async_prefetch(b, cache)
    return False

def read_block(id, cache):
    if cache.contains(id): return cache.get(id)
    data = disk_read_block_aligned(id)   # single seek + read
    cache.put(id, data)
    return data

Key points:

• Align probes: compute block_id = floor(index / R); always read full block to avoid extra seeks.
• Minimize seeks: binary search touches O(log(N/R)) distinct block IDs (not log N), since many index steps stay within same block.
• Prefetching: when probe moves toward a range, async prefetch adjacent block(s) in that direction (1–2 blocks) to overlap seek time.
• Caching: small LRU or CLOCK cache of C blocks; keep recently accessed blocks (midpoints) — choose C = O(log(N/R)) to retain previously probed blocks.
  I/O complexity:
• Block reads = O(log(N/R)) worst-case block reads.
• Disk seeks ≈ O(log(N/R)) seeks; prefetching can convert some seeks into sequential reads if accesses are to contiguous blocks, but random midpoints still require seeks.
  Trade-offs:
• Larger R reduces number of probes but increases wasted bandwidth per read.
• Prefetch too aggressively wastes I/O; tune prefetch depth by observed access pattern.

Direct answer. A shape-mismatch error tells you two tensors disagreed in dimension somewhere in the forward pass, but the traceback often points at the operation that FAILED, not the operation that introduced the wrong shape several layers earlier, so the debugging process is really about walking the shape forward from the input until it diverges from what you expect.

Step-by-step approach.

1. Print the input shape first, and compare it against what the first layer actually expects. A surprising number of shape bugs are simply "the input isn't shaped the way I assumed," not a bug in the model at all.
2. Use a model summary tool (or manually print .shape after each layer in a quick forward pass) to see the shape at every stage in one pass, rather than binary-searching by commenting out layers one at a time.
3. Add explicit shape assertions inside custom layers, at the point where a specific shape is assumed (assert x.shape[-1] == self.expected_dim, f"got {x.shape}"). This turns a downstream, confusing shape error into an immediate, precisely-located one the next time the bug is triggered, which pays for itself the first time someone else hits a variant of the same bug.
4. Write a small unit test with a known, fixed input shape that exercises just the suspect layer or block in isolation, rather than the whole model, so you can iterate on the fix without paying the cost of a full forward pass through everything else.

A concrete example of why step 1 matters. A very common real case: a model expects batch-first input (batch, seq_len, features) but receives (seq_len, batch, features) from a data loader or a different framework's convention. The shapes are individually valid tensors, nothing crashes until several layers in when a dimension that "coincidentally" matched for a while finally doesn't, at which point the error message points at a layer far from the true cause (the data loader).

The unit test that prevents recurrence. Something as small as:

def test_encoder_output_shape():
    x = torch.randn(4, 10, 32)  # (batch=4, seq_len=10, features=32), the CONTRACT this layer expects
    out = encoder(x)
    assert out.shape == (4, 10, 64), f"expected (4, 10, 64), got {out.shape}"

run in CI on every change to the layer or anything upstream of it, catches this class of bug the moment a shape contract is violated, rather than three deploys later when someone finally notices predictions look wrong.

Direct answer

Compare them on three axes, cost, operations, and reliability, and expect labor cost to dominate the comparison more than raw infrastructure price: a managed service usually costs more per instance-hour but removes most of the patching, backup, and failover work that a self-managed cluster needs a dedicated person to own, which is often the bigger number.

Structured elaboration

Comparison table

When each is the right call

Managed fits when the team has limited dedicated database or site-reliability engineering headcount, when the online transaction processing (OLTP) workload needs a strict, well-tested availability target quickly, or when the provider's built-in scaling features fit the workload's actual bottleneck. Self-managed is justified when the workload needs an engine feature or extension the managed offering doesn't expose, when the scale is large enough that infrastructure plus automation genuinely beats managed pricing, or when a regulatory requirement demands direct control over maintenance windows, key handling, or backup policy that a managed service won't let you set yourself.

Worked example: where the real cost difference comes from

Assume a 3-node OLTP cluster (one primary, two replicas), illustrative rates: self-managed compute at $0.40 per instance-hour, managed-service compute at $0.55 per instance-hour (a 37.5% premium for the service), storage and backup roughly equal at $200/month either way, 730 hours/month.

Now add labor. Assume self-managed needs 0.3 full-time-equivalent (FTE) of database or site-reliability time for patching, backup verification, and failover testing, at a fully-loaded cost of $150,000/year, or $12,500/month per FTE:

Managed needs only an assumed 0.05 FTE for configuration and monitoring:

Total monthly cost:

At this illustrative scale, the managed option is actually cheaper overall despite its higher unit price, because labor dominates the total. That inverts once the cluster is large enough that the managed premium's absolute dollar gap exceeds what 0.3 FTE of labor costs, which is the "very large scale" condition under which self-managed becomes justified on cost.

Trade-offs & pitfalls

• Pitfall: comparing only instance-hour pricing and concluding self-managed is always cheaper; labor is the number that most often flips the comparison.
• Migration complexity (schema quirks, extension dependencies, connection-handling differences) is a real, often underestimated cost on either side of a switch.
• Hidden managed-service costs to watch for: input/output charges, cross-region data transfer, and support-tier pricing that isn't in the sticker instance price.
• Enterprise support contracts and published service-level agreements (SLAs) on either side change the reliability comparison; a self-managed cluster's reliability is only as good as the runbooks and testing actually behind it.

Direct answer. Interface Segregation: don't force a client to depend on methods it doesn't use. Split one large interface into several smaller, role-specific ones so each implementer/consumer only needs to know about the subset that's actually relevant to it.

The problem

A public SDK exposes one large interface:

interface DataStore {
    void read(String key);
    void write(String key, byte[] value);
    void delete(String key);
    void backup();
    void restore();
    void migrateSchema();
}

A client that only ever needs to READ data is still forced to implement (or mock, in tests) write, delete, backup, restore, and migrateSchema -- either as no-ops that silently do nothing (dangerous if accidentally called) or as a large surface a test double has to fully satisfy just to compile.

Splitting the interface

interface DataReader { void read(String key); }
interface DataWriter { void write(String key, byte[] value); void delete(String key); }
interface DataStoreAdmin { void backup(); void restore(); void migrateSchema(); }

class FullDataStore implements DataReader, DataWriter, DataStoreAdmin { /* full implementation */ }

A read-only client now depends on DataReader alone -- its code, its test doubles, and its compile-time contract all shrink to exactly what it uses, and it becomes IMPOSSIBLE (not just unlikely) for that client to accidentally call migrateSchema.

How to decide where the split lines go

Group methods by CONSUMER ROLE, not by implementation convenience: ask 'which distinct kinds of caller need which distinct subset of this surface?' Methods that are always needed TOGETHER by the same callers stay together; methods needed by only a subset of callers split out. Here, ordinary application code needs read/write; only an ops/admin tool needs backup/restore/schema migration -- that's the natural seam.

Trade-offs and pitfalls

• Splitting too finely (one interface per method) recreates the parameter-list problem in a different shape: now callers who genuinely need several related operations have to implement/depend on many tiny interfaces instead of one cohesive one. The goal is role-shaped interfaces, not maximally-fragmented ones.
• A single concrete class can (and often should) implement several of the smaller interfaces at once -- ISP is about how CONSUMERS depend on the surface, not about forcing a 1:1 mapping between interfaces and implementing classes.
• Retrofitting ISP onto an existing large interface used by many callers requires a migration path (extract the smaller interfaces, have the existing large interface EXTEND all of them for backward compatibility, then migrate callers to the smaller ones over time) rather than a breaking change in one release.

Direct answer
A JUnit 5 suite for fib(n) needs at least six categories: both base cases (n=0, n=1), a typical small value, a negative-input rejection, a duplicate/repeated-call determinism check, and the exact boundary where the result stops fitting a 32-bit signed integer. The overflow boundary is fib(46) (fits) and fib(47) (does not), the implementation should document and enforce which it does on overflow, either an explicit exception or a widened/BigInteger return type, rather than silently wrapping.

Structured elaboration

Choosing n=46/n=47 specifically (rather than "a large n") is what makes case 5 and 6 real boundary tests: fib(46) = 1836311903 <= Integer.MAX_VALUE, and fib(47) = 2971215073 > Integer.MAX_VALUE, so these two inputs are the exact pair that separates "correct" from "must not silently corrupt."

JUnit 5 examples (3 of the 6, executed against a real implementation)

import org.junit.jupiter.api.Test;
import static org.junit.jupiter.api.Assertions.*;

class FibonacciTest {
 @Test
 void baseCaseZero() {
 assertEquals(0, Fibonacci.fib(0));
 }

 @Test
 void negativeInputThrows() {
 assertThrows(IllegalArgumentException.class, () -> Fibonacci.fib(-5));
 }

 @Test
 void overflowAtFortySeven() {
 assertThrows(ArithmeticException.class, () -> Fibonacci.fib(47));
 }
}

Implementation, plus the driver that actually invokes it (a JUnit runner was not available in this sandbox, so this is the reproducible equivalent of the three @Test methods above, executed against a real Java JVM):

public class Driver {
 static int fib(int n) {
 if (n < 0) throw new IllegalArgumentException("n must be non-negative");
 if (n == 0) return 0;
 if (n == 1) return 1;
 int a = 0, b = 1;
 for (int i = 2; i <= n; i++) {
 int next = Math.addExact(a, b);
 a = b;
 b = next;
 }
 return b;
 }
 public static void main(String[] args) {
 System.out.println("fib(0) = " + fib(0));
 System.out.println("fib(1) = " + fib(1));
 System.out.println("fib(10) = " + fib(10));
 System.out.println("fib(46) = " + fib(46));
 try { fib(-5); } catch (IllegalArgumentException e) { System.out.println("fib(-5) threw IllegalArgumentException: " + e.getMessage()); }
 try { fib(47); } catch (ArithmeticException e) { System.out.println("fib(47) threw ArithmeticException: " + e.getMessage()); }
 }
}

fib(0) = 0
fib(1) = 1
fib(10) = 55
fib(46) = 1836311903
fib(-5) threw IllegalArgumentException: n must be non-negative
fib(47) threw ArithmeticException: integer overflow

(Cross-checked independently in Python against an exact big-integer reference: fib(46) == 1836311903 and fib(47) == 2971215073, confirming the Java implementation's boundary values are correct, not an artifact of the Java implementation itself.)

Expected overflow behavior
The best practice for an SDET reviewing this API is to insist on explicit, documented overflow behavior rather than "whatever the language happens to do": Math.addExact throwing ArithmeticException is one valid contract; returning long or BigInteger instead of int is another (it moves the boundary far out rather than eliminating it); silently wrapping past Integer.MAX_VALUE is the one behavior that should never ship, since it produces a wrong-looking-right number (fib(47) computed with plain unchecked int addition wraps to a negative value, which at least looks obviously wrong, but a later overflow could wrap back into positive, plausible-looking-but-wrong territory).

Complexity and edge cases
The iterative fib shown is O(n) time and O(1) space (two running variables, no recursion stack); a naive recursive implementation without memoization is O(2^n) time and O(n) stack depth, which is its own distinct edge case (see below). Edge cases: n=0 and n=1 (base cases), a typical small value, n=-5 (negative, must reject), n=46 (last value fitting signed int32), n=47 (first value overflowing it), and repeated calls with the same n (determinism).

Trade-offs & pitfalls
A naive recursive (non-memoized) implementation has its own distinct failure mode, unrelated to integer overflow: stack overflow from recursion depth at moderately large n, well before n=47, so testing "large n" for a recursive implementation actually needs a StackOverflowError test in addition to (not instead of) the arithmetic-overflow tests above. A common mistake is testing only n=50 or another arbitrary "big" value instead of the precise n=46/n=47 pair, which either doesn't reach the boundary at all or overshoots it, missing the exact transition the test is supposed to pin down.

Situation: When I hit a tricky bug that blocks progress or could recur, I treat it as both a technical problem and an opportunity to spread knowledge.

Preparation (before asking):

• Reproduce reliably and capture steps, logs, stack traces, environment, and timeline.
• Narrow the blast radius: isolate a minimal repro or a focused testcase.
• Form a clear hypothesis list (most to least likely) and what I’ve already tried.
• Prepare a short summary (one-pager/slack thread) with links to repro, logs, and branches so peers can review quickly.

Structuring the debugging session:

• Choose format based on scope:
  • Pair debugging (one-on-one) for focused code-level fixes.
  • Mob debugging for cross-cutting issues (infra, APIs, or ambiguous ownership).
  • Show-and-tell for knowledge-sharing after the fix.
• Set agenda and timebox (15–60 minutes): goal, hypothesis, actions, next steps.
• Assign roles: driver (controls IDE), navigator (asks questions/hypothesis), scribe (notes decisions).
• Walk through minimal repro, run experiments live, validate or rule out hypotheses, and agree on an action (patch, revert, rollout plan).

Knowledge transfer and follow-up:

• Open a concise postmortem or incident note with root cause, timeline, and decision rationale.
• Raise a PR with detailed description and link to the session notes; include tests and comments in code.
• Record the session or do a short demo during standup or tech sync.
• Pair the person who will own the code for next-week follow-up and add automated checks to prevent regression.

This approach respects peers’ time, leverages senior experience when needed, and leaves the codebase and team wiser.

Direct answer: Optimal scheduling of dependent tasks across N workers to minimize makespan (total completion time) is NP-hard in general (it's a generalization of job-shop scheduling / multiprocessor scheduling, both classically NP-hard), so exact optimal solutions become computationally infeasible past a small number of tasks. In practice, a greedy heuristic like longest-processing-time-first (LPT) or critical-path-first, combined with respecting the dependency DAG via a topological-order constraint, gives a solution computable in polynomial time (typically O(n log n) for sorting plus O(n + edges) for the scheduling pass) that is provably within a bounded factor of optimal (LPT is within 4/3 of optimal for the classic multiprocessor scheduling problem without dependencies).

Structured elaboration

• Why it's NP-hard: even without any dependencies, minimizing makespan across N identical machines (partitioning tasks into N groups to minimize the maximum group sum) is the classic "multiprocessor scheduling" problem, a well-known NP-hard problem (closely related to the partition/subset-sum problem). Adding a dependency DAG (some tasks must finish before others start) only makes the search space more constrained, not easier - exact solutions require exploring an exponential number of valid orderings/assignments in the worst case.
• Longest-processing-time-first (LPT): sort tasks by duration descending, then greedily assign each task (in that order) to whichever currently-least-loaded worker is idle and dependency-eligible (all its prerequisite tasks are already scheduled/complete). Sorting is O(n log n); the assignment pass is O(n log W) if worker loads are tracked in a heap (W = number of workers), or O(n * W) with a naive scan - either way polynomial, a world apart from exponential exact search.
• Critical-path-first: prioritize tasks that sit on the longest dependency chain (the "critical path" through the DAG) first, since delaying a critical-path task directly delays the whole schedule; tasks off the critical path have more scheduling slack. Computing the critical path is a single O(V+E) pass over the DAG (longest path in a DAG, computable via topological sort plus dynamic programming), making this heuristic's overall cost also polynomial.

Worked example

LPT's classical approximation guarantee (Graham's bound, 1969, for the dependency-free case): the makespan produced by LPT is never worse than $\frac{4}{3} - \frac{1}{3W}$ times the optimal makespan, where W is the number of workers - meaning for a 2-worker case, LPT is guaranteed within roughly 17% of optimal, and this guarantee HOLDS regardless of the specific task durations, without ever needing to compute the true optimal for comparison. Adding dependency constraints breaks this exact bound (LPT with dependencies loses the clean approximation guarantee since a critical-path task might get delayed behind an unrelated long task), but it remains a widely-used, empirically strong heuristic in practice for exactly this reason: polynomial-time and consistently close-to-optimal on realistic task-duration distributions, even without a formal bound in the dependency-constrained case.

Trade-offs & pitfalls

• Recognizing "this is NP-hard" is itself valuable interview signal - it tells you and your team that chasing an exact optimal solution at scale is the wrong investment, and that evaluating heuristics against their approximation guarantees (or empirically, against realistic workloads) is the right frame.
• The dependency DAG constraint means a heuristic must ALSO respect topological ordering, not just balance load - a heuristic that ignores dependencies (like naive LPT without the eligibility check) can produce an invalid or badly-delayed schedule.
• For genuinely small task counts (say under 20-30), exact approaches (integer linear programming, or exhaustive branch-and-bound with pruning) become tractable again and can be worth using when the problem size allows it - "NP-hard" is a worst-case-scaling statement, not a blanket ban on exact methods at small scale.

To improve cache locality for large matrix multiplication C = A × B, use blocked (tiled) matrix multiplication: split matrices into smaller submatrices (tiles) that fit into caches so inner computation reuses data while it's hot.

Approach:

• Choose block size B such that 3BB*sizeof(double) <= cache_size * occupancy_factor (e.g., 50–75%).
• For L1 (32KB) and doubles (8 bytes): B ≈ floor(sqrt( (32KB0.6) / (38) )) ≈ 16. For L2 (256KB) you can pick larger (e.g., 64).
• Outer loops iterate over tiles, inner loops multiply tiles with classical i-j-k order for each tile to maximize reuse of loaded tile rows/cols.

C++ pseudocode:

// A: MxK, B: KxN, C: MxN
const int B = 64; // choose based on cache (e.g., 16 for L1, 64 for L2)
for (int ii = 0; ii < M; ii += B) {
  for (int kk = 0; kk < K; kk += B) {
    for (int jj = 0; jj < N; jj += B) {
      int iMax = min(ii+B, M);
      int kMax = min(kk+B, K);
      int jMax = min(jj+B, N);
      for (int i = ii; i < iMax; ++i) {
        for (int k = kk; k < kMax; ++k) {
          double a = A[i][k];               // loaded once per inner j-loop
          for (int j = jj; j < jMax; ++j) {
            C[i][j] += a * Bmat[k][j];
          }
        }
      }
    }
  }
}

Why this helps:

• Each tile fits in cache so rows of A and blocks of B are reused across inner j-loop, reducing compulsory and capacity misses.
• Compared to naive triple loop, tiling reduces memory traffic from O(MKN) element accesses to fewer loads per element (amortized), often improving runtime by orders depending on problem and cache (typical 2–10x).
• Complexity remains O(MKN) arithmetic; memory bandwidth and cache miss count decrease substantially.

Practical notes:

• Tune B per target CPU and data type; consider alignment and using packed tile buffers, loop unrolling, and SIMD for further gains.
• Handle small remainder tiles with min(...) as shown.

Direct answer

Decide refactor versus rewrite using three concrete criteria: the blast radius of a full rewrite, how well-understood the correct end-state behavior actually is, and how much dedicated runway you realistically have. Then commit to a staged, reversible migration path regardless of which you pick, so you're never one bad deploy away from an unrecoverable outage.

Structured elaboration

• Evaluation criteria: blast radius, how many callers and integration points a rewrite would touch and how coupled they are to the current implementation's quirks; certainty of correct behavior, whether you can write tests that capture what "correct" means today, or whether even the current behavior is partly undocumented and disputed; and available runway, whether the business genuinely has room for a multi-month freeze or there's an urgent need a full rewrite can't meet in time.
• Cost and benefit: a full rewrite typically costs more calendar time and risks quietly reintroducing behavior no one remembered was load-bearing; an incremental refactor is cheaper and safer per step but can leave some debt in place longer. Weigh these against how urgent the blocking issue actually is.
• Staged migration and validation strategy: write characterization tests capturing current behavior first, so any change can be checked against a known baseline; migrate one path at a time behind a feature flag (a toggle that turns the new path on or off without a new deployment) rather than cutting over everything at once; where possible, run the old and new logic in parallel on real traffic, shadow mode, and compare outputs before fully switching.
• Risk mitigation and rollback: keep the old path intact, flagged off but ready, for a defined monitoring window after cutover, so any newly-discovered issue can be reverted instantly rather than requiring an emergency fix under pressure.

Worked example

A billing calculation service has duplicated pricing logic in two places, no test coverage, and is now blocking a needed pricing change. A full rewrite is estimated at 3 months with a feature freeze on pricing changes; the business needs the specific pricing change live within a month. Given the tight runway and that the current, buggy-but-known behavior is well understood, we choose an incremental refactor. First, characterization tests capture today's actual pricing output across a representative set of real accounts. Second, only the one code path on the critical path for the new pricing change is migrated behind a feature flag. Third, the old and new paths run in shadow mode in parallel on production traffic for 2 weeks; the new path matches the old path's output on over 99 percent of transactions, with every mismatch explained as an intentional fix to a known bug rather than a new one. We cut over, and keep the old path available behind the flag, monitored, for 2 more weeks before deleting it. The broader rewrite of the rest of the duplicated logic is proposed separately as a funded, dedicated initiative once the urgent pricing change is out.

Trade-offs and pitfalls

The most common mistake is picking "rewrite" because the existing code is embarrassing rather than because the evaluation criteria actually favor it; a rewrite chosen for morale reasons under time pressure often ends up worse than the debt it replaced. Another failure is skipping the characterization-tests step because "we know what it should do," when in inherited systems the actual behavior and the assumed behavior have usually already diverged. Watch also for deleting the old path immediately after cutover instead of keeping a monitored rollback window; the failures that matter tend to show up under load or on an edge case a day or two in, not in the first hour.