Microsoft Frontend Developer (Mid-Level) Interview Preparation Guide

Approach summary
I’d create a pragmatic, developer-friendly API governance program that balances consistency with team autonomy, focused on frontend needs (predictable payloads, small responses, stable contracts).

Standards I’d set

• Schema: OpenAPI v3 required, strict request/response schemas, nullable rules, example payloads, pagination cursor patterns.
• Error formats: unified error envelope (code, message, details, traceId, userFacing boolean).
• Versioning: semantic versioning on major breaking changes; prefer non-breaking additive releases and deprecation headers (Sunset, Deprecation-Date).
• Performance: size limits, caching headers, and idempotency where applicable.
• Security/headers: auth schemes, CORS, rate-limit headers.

Enforcement

• CI checks: validate OpenAPI, contract tests, schema linting, payload size tests.
• Codegen & SDKs: generate TypeScript clients and typed models used by frontend repositories to ensure typesafety.
• Gateways: API gateway policy checks (headers, auth).
• Review process: lightweight API design review board for major changes.

Onboarding

• Starter repo with generated SDK, example React integration, and Storybook mocks.
• Workshops, docs portal, and Slack channel; template PRs and migration playbooks.

Metrics

• Adoption: % services with OpenAPI + generated SDK.
• Quality: contract test pass rate, production 4xx/5xx per integration, response size and latency percentiles.
• Stability: number of breaking changes per quarter and mean time to migrate.

This keeps frontend developer teams productive while ensuring reliable cross-team contracts.

Direct answer

I match the source to what I actually need: a quick conceptual grasp, a deep applied skill, and a decision-grade understanding each call for a different kind of source, and before committing real time I check the source's credibility, currency, and depth rather than assuming a polished one is automatically a good one.

Structured elaboration

Matching source to goal: an overview article is fine for a quick conceptual grasp, but a deep applied skill usually needs hands-on exercises with feedback, and a decision I have to get right needs the primary or authoritative source (the actual specification or documentation) over a summary of it, because summaries drift from what the thing actually does.

Judging credibility, currency, and depth upfront: checking when it was written or last updated, whether it matches the current version of whatever it's teaching, and whether it has exercises or just explanation, before investing real time.

When focused practice against feedback beats open-ended exploration, and when it doesn't: repeated, deliberate practice against concrete feedback is better once I know roughly what I'm aiming for; open-ended exploration is better earlier, when I don't yet know enough to know what to practice.

Sequencing reading and building: I interleave them rather than doing all of one before the other, since building surfaces exactly which parts of the reading I didn't actually understand.

Cost and time as real constraints: I weigh a resource's price and the time it demands against how urgent the need is, not just its reputation.

Early warning signs a source is wrong: it's too shallow for what I need, it's clearly outdated, it targets the wrong version or stack, or it has no exercises at all. Once I see one of those, I drop it rather than finishing it out of sunk-cost momentum. I also treat a knowledgeable colleague as a resource with its own selection criteria, specifically someone close to the actual system in question, not just the most senior person available.

Worked example

I started with a broad video course to get oriented on a tool, and within the first session realized it was built for an older version with several behaviors that had since changed. I cross-checked one specific claim it made against the current official documentation, and the documentation contradicted it. I dropped the course immediately rather than finishing it out of momentum, and switched to the current primary documentation paired with hands-on exercises for the applied depth I actually needed.

Trade-offs and pitfalls

The common failure here is over-investing in a resource because it's polished or well-produced, without checking whether it actually holds up against a quick spot-check on the primary source. The other is judging a resource purely by its reputation rather than by whether its specifics still match the current reality of what you're trying to learn.

Direct answer

Win this argument by translating "it's old and risky" into a number leadership already cares about, the cost or risk of doing nothing, then pair it with a phased plan that has a real fallback option, so the ask isn't all-or-nothing, and key performance indicators (KPIs, the specific measures used to judge success) that let leadership know later, objectively, whether the bet paid off.

Structured elaboration

• Quantify the cost of inaction: estimate current cost (maintenance hours, licensing, incident time) and risk exposure, as an honest range, not a falsely precise number.
• Phased plan: stages that each deliver something independently useful, so leadership sees value before everything is done.
• Milestones: a concrete checkpoint per phase with an explicit go/no-go decision.
• Staffing: name the team and time commitment, and where it comes from, since being unstaffed is the most common reason these efforts stall.
• Fallback: an explicit plan B if the full rebuild doesn't get funded or stalls partway.
• KPIs and handoff: two or three measurable success criteria plus a named owner once migrated, so "done" has a clear definition.

Worked example

A legacy reporting system costs the team an estimated 15 engineer-hours a week in firefighting, about 780 hours a year, and caused 4 data-accuracy incidents last year at roughly two days each to trace and fix. Cost of inaction: 780 hours a year in maintenance alone, before incident time or the risk of a fifth incident hitting an externally-reported number. Phased plan: Phase 1 (6 weeks) migrates the 3 highest-traffic reports as a parallel run, comparing output for parity; Phase 2 (8 weeks) migrates the remaining 12 once parity is proven; Phase 3 (2 weeks) decommissions the old system. Go/no-go at the end of Phase 1: pause if the new pipeline doesn't match within an agreed tolerance. Staffing: 1 dedicated engineer plus 20% of a second, for 16 weeks. Fallback: if the second engineer isn't funded, Phase 1 alone still cuts an estimated 60% of firefighting time, since those 3 reports account for most of it. KPIs: firefighting hours under 5 a week (from 15) and zero data-accuracy incidents in the following two quarters, reviewed at a 90-day check where ownership formally transfers.

Trade-offs and pitfalls

A suspiciously exact dollar figure instead of an honest range invites justified pushback. A phased plan with no independent value per phase means leadership sees nothing until it's all done, a hard sell. And no named owner after cutover lets the new system quietly become whoever built it's permanent side project.

Direct answer
A correct debounce utility needs to track not just a pending timer but how many calls occurred within the current window, because leading-edge and trailing-edge invocation interact: a single call in a leading+trailing window must fire once, not twice, while multiple calls in that same window correctly fire twice (once on the leading edge with the first call's arguments, once on the trailing edge with the last call's arguments). cancel() can only suppress a pending trailing call; it cannot undo a leading call that has already executed synchronously.

Structured elaboration

• Leading vs. trailing semantics: leading invokes immediately on the first call of a new window; trailing invokes once the window elapses with no further calls. Both can be enabled together, which is where most naive implementations get the single-call case wrong (see below).
• The double-invoke trap: a naive implementation that unconditionally fires the trailing call whenever trailing is true will invoke twice for a window containing exactly one call under {leading: true, trailing: true}, once from the leading edge and once from the trailing edge, for the same logical call. The fix is tracking a per-window call count and suppressing the trailing invocation specifically when the window had exactly one call AND that call already fired on the leading edge.
• Retaining this context: use a regular function expression for the returned debounced wrapper (not an arrow function) and call the wrapped function with fn.apply(thisArg, args), capturing this from the call site of the debounced wrapper itself, not from where debounce() was originally invoked.
• Cancel during a pending leading call: if leading: true and a call has already fired synchronously, the side effect has already happened, cancel cannot retroactively undo it. What cancel() legitimately does is clear the pending timer so the TRAILING call that would otherwise fire later never happens. This distinction (already-happened vs. still-pending) is the actual edge case named in the question, and a test must assert on it precisely: the leading call's effect persists after cancel, only the trailing call is suppressed.
• Return value: the debounced function should return whatever the underlying function returned on its most recent actual invocation, since a caller synchronously reading the return value on a leading call needs that value immediately, not after the debounce window closes.

Worked example (executed, ES6/ECMAScript 2015)

function debounce(fn, wait, { leading = false, trailing = true } = {}) {
  let timer = null, lastArgs = null, lastThis = null, result, callCountInWindow = 0;
  function invoke(args, thisArg) { result = fn.apply(thisArg, args); return result; }
  function debounced(...args) {
    const isNewWindow = timer === null;
    lastArgs = args; lastThis = this; callCountInWindow += 1;
    if (isNewWindow && leading) invoke(args, this);
    if (timer !== null) clearTimeout(timer);
    timer = setTimeout(() => {
      const shouldTrailingInvoke = trailing && !(leading && callCountInWindow === 1);
      if (shouldTrailingInvoke) invoke(lastArgs, lastThis);
      timer = null; callCountInWindow = 0;
    }, wait);
    return result;
  }
  debounced.cancel = function () {
    if (timer !== null) { clearTimeout(timer); timer = null; callCountInWindow = 0; }
  };
  return debounced;
}

Run against seven scenarios with real timers (30ms wait, real setTimeout, no mocked clock):

scenario1_trailing_only: ["c"]
scenario2_leading_and_trailing_multi_call: ["a","c"]
scenario3_leading_and_trailing_single_call: ["only"]
scenario4_this_context: fn ran without throwing, retained call succeeded
scenario5_leading_return_value: 10
scenario6_cancel_during_pending_leading: {"callsRightAfterLeadingEdge":["first"],"callsAfterCancelAndWait":["first"]}
scenario7_cancel_noop: no throw, safe

Scenario 2 confirms the multi-call case correctly fires twice (["a","c"], first and last), scenario 3 confirms the single-call case correctly fires exactly once (not ["only","only"]), and scenario 6 confirms the cancel-during-pending-leading-call edge case precisely: first is recorded once (the leading call already ran) and stays at exactly ["first"] after cancel and the wait elapses, meaning the trailing call for second was successfully suppressed and the already-fired leading call was correctly left alone.

Trade-offs and pitfalls
The most common wrong turn is the double-invoke bug described above, which passes any test that only checks "trailing mode alone" and "leading mode alone" separately and never tests the combination on a single-call window. A second pitfall is using an arrow function for the debounced wrapper, which permanently binds this to the enclosing lexical scope at definition time and silently breaks any usage as an object method. A third is assuming cancel() should reset callCountInWindow retroactively affect a leading call that already fired; it should not, and a test asserting the leading call's side effect persists after cancel is the one that actually catches an implementation that got this wrong.

Direct answer

Treat "legal needs three weeks but the team wants one week" as a scope problem, not a speed problem. Split the release into what can ship without new legal review and what genuinely needs sign-off, then give legal a narrow, well-defined ask for the second piece instead of asking them to review everything faster. The team ships on time, and the risky piece launches on its own review-driven schedule.

Structured elaboration

Find out what is actually blocking legal

"Legal sign-off" is rarely one undivided review. Ask legal directly which specific elements are new or unreviewed, and which are unchanged from something already approved. Most releases are a mix, and the review clock usually belongs to a small fraction of the surface area.

Split the release along that line

Everything that reuses already-approved language, patterns, or flows ships in the one-week window. Anything net-new that legal has not seen goes behind a feature flag (a toggle that keeps new code hidden from users until you're ready to turn it on) and ships later, once sign-off lands, decoupled from the original deadline.

Reduce legal's per-item cost, do not just ask for speed

A vague "please review this flow" invites a slow, open-ended read. A redlined diff (a side-by-side markup showing exactly which words changed from the last approved version, like tracked changes) against previously-approved language, with a one-paragraph explanation of what changed and why, is something legal can turn around fast because the review surface is small and explicit.

Keep everyone honest about the split

Do not quietly ship around legal's concern and call it done. Tell legal what you are shipping now, what is gated, and why you drew the line there, and let them confirm or push back on the boundary itself, not just react to a missed deadline.

Worked example

A signup redesign is due in one week. It includes a new consent checkbox asking users to opt into sharing data with a third-party analytics partner, and the copy for that checkbox has never been reviewed (legal quotes three weeks because it touches data-sharing language that needs a compliance read). Everything else in the redesign, the new layout and the reworked field order, is unchanged from an already-approved pattern used elsewhere in the product.

The split: ship the redesign now using the existing, already-approved consent copy and opt-in behavior unchanged. Put the new third-party-sharing consent language and checkbox behind a flag, off by default. Send legal a one-page diff: exactly the new sentence, what data it covers, and why it is being added, instead of the whole signup flow. The redesign ships in the one-week window. The new consent copy ships later, whenever legal actually signs off, on its own timeline, without ever having blocked the rest of the release.

Trade-offs and pitfalls

A flag-gated split adds real overhead: someone has to remember to remove the flag, and a half-shipped feature can linger longer than planned if nobody owns closing the loop. It also only works when the risky piece is genuinely separable. If the new element is load-bearing, meaning the whole flow depends on it, forcing a split creates a worse product than waiting.

The biggest pitfall is doing the split unilaterally and only telling legal afterward. That reads as shipping around the reviewer even when the intent was reasonable, and it burns the relationship needed for the next time this happens. The senior move is proposing the boundary and getting legal's explicit agreement on it before the ship date, not after.

Direct answer. Comment when the code can't express WHY (a business rule, a workaround, a non-obvious trade-off); refactor instead of commenting when the comment only restates WHAT the code already says -- a comment that duplicates the code is guaranteed to drift out of sync with it eventually.

The trivial case

# increment i by 1
i += 1

This comment is pure noise: it tells you nothing i += 1 doesn't already say faster to read. Delete it; if i needs a better name to convey intent (e.g., retry_count += 1), fix the name instead of commenting around it.

A comment that legitimately belongs (explains WHY)

# Stripe requires idempotency keys to be reused for retries within 24h,
# otherwise it treats a retry as a new charge. See INC-4021.
idempotency_key = order_id  # intentionally NOT time-based

No amount of renaming makes 'why we chose this specific value, tied to an external API's undocumented-until-we-got-burned behavior' obvious from the code alone -- this is exactly the kind of context a comment should preserve, ideally with a link to the incident/ticket for anyone who wants the full story.

A comment that's a smell (explains WHAT, redundant with the code)

# loop through all users
for user in users:

The code already says this as clearly as English could; the comment adds a second thing that has to be kept in sync every time the loop changes, for zero reader benefit.

A simple test to apply

Ask: 'if I deleted this comment, would a competent reader lose information, or just lose a restatement?' If deleting it loses nothing, delete it. If deleting it loses the REASON something non-obvious is true, keep it (and consider whether the reason belongs in a commit message / ticket link too, for permanence).

Trade-offs and pitfalls

• Comments that explain why are still at risk of going stale if the underlying reason changes (the external API behavior gets fixed) but nobody removes the now-obsolete comment -- treat comments as code that also needs maintenance, not a write-once artifact.
• Don't over-correct into a 'no comments ever' culture; some domains (financial regulations, security-sensitive code, deliberately non-obvious performance tricks) genuinely need WHY documented, and a codebase that bans comments entirely just pushes that knowledge into people's heads (or nowhere), which is worse.
• A comment that says 'TODO: fix this properly' with no ticket link or date is close to noise too -- if it's worth flagging, it's worth tracking somewhere more durable than an inline string that nobody searches for.

Direct answer

Treat each value in the array as a pointer: from index i, "follow" nums[i] to land on index nums[i]. Because there are n+1 values all in the range [1, n], at least two different indices must point to the same value (pigeonhole), which means this functional graph has a cycle, and the duplicate value is exactly the entry point of that cycle. Floyd's tortoise-and-hare cycle detection finds that entry point in O(n) time and O(1) extra space, without modifying the array at all, which is exactly what the question asks for.

Approach (Floyd's cycle detection)

1. Start both slow and fast at nums[0], i.e. one step into the implicit linked structure (index 0 always has an outgoing "pointer," but nothing points back to it, so it can't be part of the cycle itself, only the tail leading into it).
2. Advance slow one step (slow = nums[slow]) and fast two steps (fast = nums[nums[fast]]) each iteration until they meet; a meeting point is guaranteed to exist since the structure has a cycle (standard tortoise-and-hare argument).
3. Reset a second pointer to index 0, then advance it and slow one step at a time together; the index where they meet is the cycle's entry point, which is the duplicate value.

Complexity

Time: O(n) (each phase does at most O(n) steps). Space: O(1) extra; nums itself is never modified.

Edge cases

• Exactly one duplicate value, appearing exactly twice: this is the assumed input shape and the algorithm handles it directly.
• The duplicate value equal to n itself (the largest allowed value): handled the same way, since indexing is 0-based but values start at 1, so nums[i] is always a valid index regardless of which value 1..n is duplicated.

def find_duplicate_floyd(nums):
    slow = nums[0]
    fast = nums[nums[0]]
    while slow != fast:
        slow = nums[slow]
        fast = nums[nums[fast]]
    slow2 = 0
    while slow2 != slow:
        slow2 = nums[slow2]
        slow = nums[slow]
    return slow


data = [1, 3, 4, 2, 2]
original = list(data)
print(find_duplicate_floyd(data), data == original)

Output:

2 True

The duplicate is correctly identified as 2, and data == original confirms the array was never mutated during the search.

Alternative technique: index-marking

A second valid approach exploits the same "values are indices" fact differently: walk the array once, and for each value, negate the entry at the index that value points to (abs(value) - 1). If you ever land on an index whose entry is already negative, that index (converted back to 1-based) is the duplicate, because it means two different positions "pointed" to it. This is also O(n) time and O(1) additional space, but unlike Floyd's approach, it works by temporarily mutating nums in place (each visited value's target slot gets negated), so if the caller needs nums to remain externally unmodified while the function runs (not just restored by the time it returns), Floyd's version is the safer default.

def find_duplicate_marking(nums):
    duplicate = None
    for x in nums:
        idx = abs(x) - 1
        if nums[idx] < 0:
            duplicate = idx + 1
            break
        nums[idx] = -nums[idx]
    for i in range(len(nums)):
        nums[i] = abs(nums[i])
    return duplicate


data2 = [1, 3, 4, 2, 2]
print(find_duplicate_marking(data2), data2)

Output:

2 [1, 3, 4, 2, 2]

Both techniques agree on the duplicate (2), and the marking approach restores the array to its original values by the time it returns, even though it mutated it during the scan.

Trade-offs and pitfalls

• "Does not modify the array" has two readings, and the question's phrasing ("without modifying the array") most naturally means Floyd's guarantee: never mutated, at any point, including during execution. The marking approach only satisfies a weaker version ("unmodified once the function returns"), which is a meaningful difference if another thread could read nums concurrently while this function runs, or if the function could throw partway through and leave the array in its negated state.
• A frequent proof gap: candidates often reach for cycle detection without first establishing why a cycle must exist here. The argument is exactly pigeonhole: n+1 values drawn from a range of only n possible values guarantees at least one repeat, and because every value is a valid index (never 0, since the range is [1, n] not [0, n-1]), the "value points to index" structure is well-defined for every position, forcing at least one node in the sequence to be revisited, i.e. a cycle.
• A common bug in the marking approach: forgetting the final restoration pass, which silently corrupts the caller's array (still functionally finds the right duplicate, but violates the "don't modify the array" requirement in a way that's easy to overlook if you only test the return value).

Answer (Frontend Developer perspective)

When to use which

• event.preventDefault(): stops the browser’s default action (e.g., submitting a form, following a link). Use this when you want to cancel the default behavior of the element clicked.
• event.stopPropagation(): stops the event from bubbling up to ancestor elements. Use this when clicking should not trigger parent handlers (but default action may still occur unless prevented).

Goal: clicking the icon should NOT submit the form but other submit buttons should work normally — use preventDefault on the icon click. If form or parent has click handlers that you also want to avoid, add stopPropagation.

Example

// Icon inside form
const icon = document.querySelector('.no-submit-icon');

icon.addEventListener('click', function(event) {
  // prevent the browser from treating this click as a form submit
  event.preventDefault();

  // also stop bubbling if parent click handlers might submit
  event.stopPropagation();

  // perform icon-specific action
  console.log('Icon clicked: opened menu');
});

This prevents submission only when the icon is clicked; normal submit buttons remain unchanged.

Four things, at minimum: a machine-parsable error CODE (a stable string a client can branch logic on), a human-readable MESSAGE (for logging and debugging, never for client branching logic), a correlation or trace ID (so a developer can find this exact request in server-side logs), and a documented mapping from error codes to HTTP status codes so the status line and the body agree on what actually happened.

Why each field earns its place

Error code, not just a status code. HTTP status codes are coarse (a 400 covers many different validation failures); a specific, stable string like insufficient_inventory lets a client write real logic ("if this specific error, show the user a restock message and offer alternatives") instead of parsing a human-readable sentence, which is fragile and can change wording without warning.

A message meant for humans, not machines. The message field exists for logs, support tickets, and developer debugging; a client should never regex-match against it to decide behavior, because message wording is exactly the kind of thing that changes without being treated as a breaking change.

A correlation ID. When a client reports "I got an error," the correlation ID is what lets an engineer find the exact request in server-side logs in seconds instead of guessing based on approximate timestamps.

A stable status-code mapping. insufficient_inventory should map to the same HTTP status every time (409 Conflict is a reasonable choice here, since it reflects a state conflict rather than malformed input), documented so both server and client code agree on the mapping rather than each side guessing.

Worked example

{
  "error": {
    "code": "insufficient_inventory",
    "message": "Only 3 units of sku_1001 are available.",
    "correlation_id": "req_8f2c9a1e",
    "retryable": false
  }
}

This example is 145 bytes as compact JSON. A client parses this programmatically by checking error.code === "insufficient_inventory" (stable, documented) to decide its own behavior (offer the customer 3 units instead of the requested 5), logs error.correlation_id for later debugging if the customer files a support ticket, and displays a localized version of its OWN copy for that error code to the end user rather than showing error.message directly (which is written for a developer audience, in one language, and not meant for end-user display).

Trade-offs and pitfalls

The most common mistake is putting only a human-readable message in the error body and expecting clients to parse it for meaning; the moment that message's wording changes (even a small rewording meant purely to be clearer for humans), any client parsing it silently breaks. A second common mistake: reusing the SAME error code for conceptually different failures because they happen to produce the same HTTP status, which forces clients back to string-matching the message anyway to tell them apart, defeating the entire purpose of having a code field.

Overview — keyboard basics every interactive component must support

• Tab and Shift+Tab to move focus into and out of components
• Enter/Space to activate or toggle controls
• Arrow keys for list navigation where applicable
• Esc to close overlays/modals/dropdowns
• Home/End/PageUp/PageDown for long lists or grids

Examples

• Buttons: respond to Enter and Space; visible :focus state; pressing Space should trigger click behavior.
• Links: activate with Enter; open context menus with keyboard shortcuts if applicable.
• Custom dropdowns/comboboxes: Tab enters, ArrowDown/ArrowUp moves between options, Enter selects, Esc closes, Home/End jump to first/last option; manage aria-expanded/aria-activedescendant.
• Custom widgets (tabs/accordions): use Arrow keys for switching, Enter/Space to toggle, maintain roving tabindex for list-like navigation.

Why visible focus indicators matter

• They show which element receives keyboard input; without them keyboard-only users can’t orient or operate the UI. Always keep clear contrast and size for focus outlines or custom rings.

Why logical tab order matters

• Tab order should follow visual and reading order so users predictably arrive at controls. Avoid skipping interactive elements or trapping focus; implement focus management for overlays to return focus on close.

As a frontend developer I implement these behaviors with semantic HTML where possible, add appropriate ARIA only when necessary, and write keyboard handlers that mirror native control behavior.