Senior Frontend Developer Interview Preparation Guide - FAANG Standards

Direct answer

Without formal authority, influence has to come entirely from credibility and voluntary buy-in instead of any ability to assign work or shape a review. That changes the approach toward explicit opt-in, keeping every session clearly worth their time, and respecting that they can walk away at any point without consequence.

What actually changes

• No mandate over cadence or topics. You can't schedule a recurring 1:1 and assume it happens, each session has to earn its place on their calendar.
• No visibility into their formal goals. You're advising without the context a manager has, so advice has to stay conditional ("here's what I'd consider, given what I know") rather than directive.
• No enforcement of follow-through. They can take or leave anything you suggest with no consequence, which is a feature, not a problem, but it means you can't measure success the way you would with a direct report.
• A boundary with their actual manager. Advice that touches their team's norms, priorities, or performance is their manager's territory. Staying in a peer-advisor lane means flagging that explicitly rather than quietly overriding it.
• No natural checkpoint. A direct-report relationship gets reviewed on a cycle; an informal one only continues as long as both sides keep choosing it, so it's worth periodically checking whether it's still useful rather than assuming it is.

Worked example

A colleague on a different team reached out about a specific hard decision they were facing. The first move was an explicit, opt-in question rather than assuming continued access: whether they wanted a recurring conversation or just help with this one thing. Advice stayed framed as "here's what I'd weigh" rather than a recommendation to just do X, and anything that touched their team's priorities or their manager's likely call was flagged as outside this lane, with a suggestion to raise it with their manager directly instead. A few sessions in, a light check-in confirmed it was still useful before continuing.

Trade-offs and pitfalls

A common mistake is treating an informal mentee like a direct report: being directive, assuming continued access, and not checking whether it's still wanted. The more durable version treats it as an ongoing, consent-based relationship, and requires being comfortable that some advice will simply be ignored with no way to enforce it, which is normal here, not a sign of failure. The other real pitfall is overstepping into another manager's territory, giving performance-adjacent feedback that should go through the person's actual chain instead.

Direct answer

In forty-eight hours I am not trying to understand the technology, I am trying to deliver one narrow, correctly-working slice of it and be honest about everything I did not verify. I spend the first couple of hours scoping exactly what "real" has to mean for the deliverable, deliberately decide what to fake, stub, or hard-code outside that slice, and I protect the work by verifying the riskiest part by hand rather than trusting untested intuition, then naming the residual risk explicitly to whoever receives the work.

Structured elaboration

• Scope ruthlessly from the actual deliverable backward: what is the smallest real thing that satisfies the ask, and what can be stubbed, mocked, hard-coded, or simply omitted for now.
• Name out loud what is being skipped and why: edge cases, error handling for paths not exercised, configuration options, anything the tool offers that this specific window does not need.
• For the part that has to be real, verify by hand what you cannot yet trust your own understanding to catch: manually walk a request through, check a response against documentation line by line, rather than relying on "it looked right" for the piece that matters most.
• Where existing knowledge partly maps from something familiar, be explicit with yourself about which parts of that intuition are actually being verified and which are just being trusted, since a partial map is exactly where false confidence creeps in.
• Flag residual risk explicitly to whoever receives the work: what was not verified, what could break outside the narrow case tested, and what should be checked next if this needs to become durable.

Worked example

With about forty-eight hours' notice, I was asked to integrate a third-party payment provider's webhook into a live service for a stakeholder demo the next day, having never touched that provider's interface before. I scoped the real slice tightly: handle exactly one webhook event type correctly, with real signature verification, since faking that would be dangerous even in a demo, and hard-coded a canned response for every other event type in the provider's catalog rather than trying to handle all of them. I verified the signature-verification code by hand against the provider's documented example payload and hash, byte by byte, rather than trusting that it compiled and ran without error, since that was exactly the part I could not yet trust my own instincts on. I left retry and duplicate-delivery handling explicitly out of scope, wrote that down in the change description, and told the person receiving the work directly that a duplicate webhook delivery would currently be processed twice, so it was not safe to treat as production-ready before that gap closed.

Trade-offs and pitfalls

• The biggest failure mode under this kind of compression is quietly treating "it ran once without an error" as proof of correctness; hand-verifying the riskiest slice is exactly what prevents that.
• Skipping too aggressively can produce a demo that looks complete and creates false confidence that the hard part is done, when the hard part was actually the part left out; naming what was skipped, out loud, is what prevents that.
• Leaning on knowledge that only partly maps from a familiar tool is efficient but dangerous if the transferable parts are not separated from the parts that merely look similar.

CSS rule (exact)

html { 
  font-size: clamp(
    16px,
    calc(16px + 4 * ((100vw - 320px) / 880)),
    20px
  );
}

Explanation — parts

• min (16px): the lower bound. Font will never shrink below 16px at very small viewports (accessibility/readability).
• preferred (calc(...)): the fluid value that scales linearly between the breakpoints.
  • 100vw is the current viewport width.
  • (100vw - 320px) shifts the scale to start at 320px.
  • Dividing by 880 (1200 - 320) normalizes the progress from 0 → 1 across the range.
  • Multiplying by 4 gives the incremental growth (20px − 16px = 4px).
  • Adding 16px yields a value that moves from 16px → 20px as viewport goes 320px → 1200px.
• max (20px): the upper bound. Font caps at 20px on large viewports so it doesn't grow excessively.

Why this prevents extremes

• clamp() enforces hard min/max, so even if calc() extrapolates outside the intended viewport range (or on odd zoom/UA behavior), the font-size stays between 16px and 20px.
• The calc() expression produces a smooth linear interpolation across the target range, avoiding sudden jumps at breakpoints while keeping typography accessible and consistent.

Approach (brief)
For unit tests, mock the browser APIs at the Jest setup level or per-test to control callbacks and assert behavior. For E2E, prefer real browser behavior but provide polyfills or graceful fallbacks in the app so tests run across environments.

Jest mocks — examples

IntersectionObserver (setupTests.js):

// setupTests.js
class MockIntersectionObserver {
  constructor(cb) { this.cb = cb; }
  observe() { /* no-op */ }
  unobserve() { /* no-op */ }
  disconnect() { /* no-op */ }
  // helper to simulate entries:
  trigger(entries) { this.cb(entries, this); }
}
global.IntersectionObserver = MockIntersectionObserver;

window.matchMedia (per-test or setup):

// setupTests.js
Object.defineProperty(window, 'matchMedia', {
  writable: true,
  value: (query) => ({
    matches: false,
    media: query,
    addListener: () => {},
    removeListener: () => {},
    addEventListener: () => {},
    removeEventListener: () => {},
    dispatchEvent: () => false,
  }),
});

ResizeObserver (simple mock):

global.ResizeObserver = class {
  constructor(cb) { this.cb = cb; }
  observe() {}
  unobserve() {}
  disconnect() {}
  // test helper:
  trigger(entries) { this.cb(entries); }
};

How to use in tests

• Import your component, call mock.trigger([...]) to simulate intersection/resize events and assert side effects.
• Keep mocks minimal and deterministic; reset them between tests.

E2E strategies & graceful degradation

• Detect feature availability at runtime:
  • Use feature detection (if ('IntersectionObserver' in window) { use it } else { fallback })
  • Expose fallbacks (throttled scroll listeners) so app behavior remains testable.
• For E2E in CI:
  • Use real browsers (Playwright/Puppeteer) that support APIs.
  • Inject polyfills before app loads if target browser lacks API (serve polyfill bundle or set browser flags).
  • Optionally add a test hook: window.__TEST_FORCE_NO_IO = true to exercise fallback code paths.
• Document and test both primary and fallback paths.

Why this works

• Unit mocks give deterministic, fast tests focused on component logic.
• Graceful degradation and E2E in real browsers ensure production parity and catch integration issues.

Code coverage is useful, but it only tells you that code was executed, not that it was meaningfully verified.

A high number can be misleading when tests:

• execute lines without asserting important outcomes,
• miss edge cases and error paths,
• rely on mocks so heavily that nothing real is exercised,
• or leave critical user flows untested while chasing percentage points.

Meaningful coverage asks, "Are we protecting the product?" I look at:

• branch and path coverage on risky logic,
• tests around recent bug fixes and churn-heavy code,
• mutation testing or at least hand-checking assertion strength,
• escaped defects and flaky-test trends,
• and whether critical user journeys have at least one solid test at the right layer.

For example, a screen can have 95% line coverage and still fail on a null API field or a background/foreground transition. I’d rather have slightly lower coverage with strong assertions on the risky paths than a high percentage that gives false confidence.

For a RESTful web application (React SPA, Node.js REST API, PostgreSQL, external payment gateway), each pyramid tier should own a different, non-overlapping slice of confidence, and the tests below make that concrete.

Unit tier (four examples)

1. Discount/price calculator: a pure function calculateDiscount(price, tier); verifies core business math, e.g. Jest for the frontend or a plain test runner on the backend.
2. React component render logic: does the checkout form component render a validation error when the card field is empty; React Testing Library.
3. Request validator: does the order-creation handler reject a negative price before touching the database; a plain Jest unit test with mocked input, no HTTP or DB involved.
4. Payment-gateway response parser: given a sample JSON response from the gateway, does your parser extract the correct transaction ID and status; a pure-function Jest unit test with a hard-coded fixture, no real network call.

Each of these verifies one piece of logic in isolation and depends on nothing external, which is why they can run in milliseconds.

Integration tier (four examples)

1. API-to-database write path: POST an order to the real Node API running against a real (test) PostgreSQL instance, then query the database directly to confirm the row and its computed total are correct; Supertest plus a real Postgres test container.
2. Repository layer against Postgres: an ORM query (e.g., a Prisma or TypeORM query) that joins orders and customers, run against a seeded test database via Testcontainers, to catch a wrong join or a migration mismatch a mocked-DB unit test would miss.
3. Payment-gateway client against the gateway's sandbox: using an HTTP client library such as Axios (or the gateway's official Node.js SDK if one is provided), call the gateway's real sandbox endpoint (not your parser in isolation) to confirm your client sends a well-formed request and correctly handles the sandbox's real success and decline responses.
4. React SPA against a mocked API layer: render the checkout page and confirm it calls the real API client code (not the component logic alone) and correctly updates state on a real HTTP response, using a tool like MSW (Mock Service Worker) to intercept only the network boundary, not the application code.

Each of these proves two real components agree on a contract (route shape, SQL schema, gateway request format) that a unit test, by construction, cannot check because it never invokes the second component for real.

End-to-end tier (four examples)

1. Full checkout journey: drive the real React SPA in a real browser through add-to-cart, checkout form, and payment, against the real (or sandboxed) full stack, using Playwright or Cypress, to prove the whole assembled system delivers a working checkout.
2. Payment failure path end-to-end: using Playwright or Cypress, submit a card the gateway's sandbox is configured to decline, and confirm the SPA shows the correct user-facing error, proving the failure path is wired correctly all the way through, not just handled by the parser in isolation.
3. Session and auth flow: using Playwright or Cypress, log in, add an item, refresh the page, and confirm the cart persists, exercising the real session/cookie mechanism no lower-level test touches.
4. Order confirmation and receipt: using Playwright or Cypress to complete the purchase, combined with a test email-capture tool such as Mailhog or Mailtrap, confirm a confirmation email or receipt page reflects the correct final total, proving the pricing logic, the database write, and the presentation layer all agree once wired together for real.

Why each test belongs where it does

The dividing line is what would have to be REAL for the test to fail the way it's meant to: the unit tests fail only if the pure logic is wrong; the integration tests fail only if two real components disagree, even when each one's internal logic is correct in isolation; the end-to-end tests fail only if something in the full assembly, including things no lower test can see (routing, session state, real gateway behavior), is broken.

Trade-offs and pitfalls

The most common mistake with this stack specifically is testing the payment-gateway integration primarily at the end-to-end level because "it's the riskiest part": that inflates the slowest, flakiest tier with coverage that a much cheaper integration test against the gateway's sandbox could provide almost as well. Reserve end-to-end for the few journeys where the VALUE is specifically in proving the pieces are wired together, and push everything else down a tier.

Approach (brief)

Represent each user action as a Command object containing do() and undo() functions plus any metadata (ids, indexes, payload). Maintain two stacks: undoStack and redoStack. Commands operate on a model (array of item objects) and a DOM renderer — perform DOM patching via stable element ids to preserve event listeners.

Code (core example)

// Simple model and helper
const model = []; // array of { id, text }
const getEl = id => document.querySelector(`[data-id="${id}"]`);

class Command {
  constructor(doFn, undoFn, meta={}) {
    this.do = doFn;
    this.undo = undoFn;
    this.meta = meta;
  }
}

const undoStack = [], redoStack = [];

function execute(cmd) {
  cmd.do();
  undoStack.push(cmd);
  redoStack.length = 0;
}

// Example actions
function addItem(item, index = model.length) {
  const doFn = () => {
    model.splice(index, 0, item);
    renderInsert(item, index);
  };
  const undoFn = () => {
    const el = getEl(item.id);
    if (el) el.remove();
    model.splice(model.findIndex(i=>i.id===item.id),1);
  };
  execute(new Command(doFn, undoFn, { type:'add', id:item.id, index }));
}

function removeItem(id) {
  const oldIndex = model.findIndex(i=>i.id===id);
  const oldItem = model[oldIndex];
  const doFn = () => {
    const el = getEl(id);
    if (el) el.remove();
    model.splice(oldIndex,1);
  };
  const undoFn = () => {
    model.splice(oldIndex,0,oldItem);
    renderInsert(oldItem, oldIndex);
  };
  execute(new Command(doFn, undoFn, { type:'remove', id }));
}

function undo() {
  const cmd = undoStack.pop();
  if (!cmd) return;
  cmd.undo();
  redoStack.push(cmd);
}

function redo() {
  const cmd = redoStack.pop();
  if (!cmd) return;
  cmd.do();
  undoStack.push(cmd);
}

// Rendering helpers preserve event listeners by recreating elements only when needed
function renderInsert(item,index){
  const ul = document.getElementById('list');
  const li = document.createElement('li');
  li.dataset.id = item.id;
  li.textContent = item.text;
  // attach listeners here (consistent factory)
  li.querySelector?.remove; // placeholder
  if (index >= ul.children.length) ul.appendChild(li);
  else ul.insertBefore(li, ul.children[index]);
}

Key concepts & reasoning

• Command pattern encapsulates operation and inverse so complex ops (reorder: two removes/inserts) are single commands.
• Keep canonical model array separate from DOM; commands modify model then DOM renderer to ensure state consistency.
• Use stable data-id attributes so event delegation can be used (preferred) or reattach listeners in a single place when nodes are recreated.
• For edits, store previous value in command meta so undo can restore it.

Edge cases & robustness

• Reorder operations should record source/destination indexes and use splice+insert on model.
• If DOM node identities must persist (e.g., for attached element state), reuse existing node instead of replacing; otherwise use event delegation to avoid lost listeners.
• Persist undo history (optional) by serializing command metas (avoid functions) and rehydrate on reload.

Complexity

• Most commands are O(n) in worst case for array splices; typically O(1) for end insert/remove. Re-rendering only the affected nodes keeps UI responsive.

This design ensures predictable undo/redo, keeps model and DOM in sync, and avoids lost event listeners via delegation or controlled reattachment.

Direct answer
Reduce filler words by replacing the urge to fill silence with a deliberate pause, by slowing down at the start of an answer, and by preparing your first sentence in advance so you're not composing it live while also speaking it.

Structured elaboration

• Replace filler with silence. A half-second pause where "um" used to go feels awkward to the speaker but is barely noticeable to a listener, and it reads as more confident than a filler sound. Practice: the next time you feel a filler word coming, close your mouth instead.
• Slow down your opening sentence. Most filler happens in the first few seconds of an answer, while you're still figuring out what to say. Preparing (even mentally, for two seconds) how you'll start, before you start talking, removes most of the pressure that produces filler.
• Chunk your answer into a structure you can hold in your head (for example, "there are two things here: first... second..."), so you're not searching for what comes next mid-sentence.
• Record yourself and count filler words in a short answer. Most people are surprised by the number until they've heard it; the awareness alone reduces the habit over the next few attempts.
• Slow your overall pace, not just remove filler. Filler words often show up when speaking too fast for the thought to keep up; a slightly slower baseline pace gives your thinking time to catch up to your mouth.

Worked example
Before: "So, um, I think the, uh, main reason is like, you know, we didn't really have enough test coverage, if that makes sense."

After (pause instead of filler, front-loaded structure): "The main reason [pause] was insufficient test coverage."

Both convey the identical fact. The second version uses a brief pause where filler used to sit and states the point directly instead of hedging around it.

Trade-offs and pitfalls

• Eliminating filler entirely in the moment, under real pressure, is unrealistic; the realistic goal is a noticeable reduction, not zero.
• Overcorrecting into a rigid, over-rehearsed cadence can read as stiff; the goal is fewer filler words, not a scripted delivery.
• Practicing alone (recording yourself) tends to work faster than trying to notice it live, because live self-monitoring competes with the cognitive effort of actually answering the question.

Direct answer. Drag-and-drop interactions are inherently mouse/touch-centric, so an accessible implementation needs a full keyboard-equivalent path: focus an item, enter a "grab" mode with a key press, move it with arrow keys, and confirm the drop with another key press, all announced through ARIA live-region messages since there's no visual drag cursor for a screen reader user to follow.

Keyboard interactions for grab and move.

• Tab to an item, press Space or Enter to "pick it up" (announce "Grabbed. Use arrow keys to move, Space to drop, Escape to cancel").
• Arrow keys move the item one position at a time within its list, or across columns for a board-style layout (e.g. Kanban): Left/Right could move it between columns, Up/Down within a column.
• Space or Enter again drops it in the new position; Escape cancels and returns it to its original position.

ARIA roles/properties. Each draggable item gets aria-roledescription="draggable item" (since there's no native "draggable" role) and grabbed/dropped status (conceptually what aria-grabbed used to represent) communicated as plain live-region text rather than by applying the deprecated aria-grabbed/aria-dropeffect attributes themselves (marked deprecated in ARIA 1.1 for having poor and inconsistent AT support, though never formally removed from the spec); a live region (aria-live="assertive", since drag-state changes are time-critical) announces "Moved to position 2 of 5" or "Moved to In Progress column" after each arrow-key move. role="application" is a separate, unrelated pattern that switches a screen reader out of its normal browse mode (the screen reader's default mode for reading page content with arrow/letter keys, rather than passing keystrokes straight through to the app) entirely and is generally discouraged; it doesn't announce anything on its own and isn't needed here, since the live region alone handles the announcement.

Worked example, one continuous grab-move-drop-cancel cycle. Take a Kanban board with columns To Do, In Progress, and Done, and a card titled "Fix login bug" sitting second in the To Do column. Tab to the card and press Space: the live region announces "Grabbed Fix login bug. Use arrow keys to move, Space to drop, Escape to cancel." Press Right arrow once: the card moves to the In Progress column and the live region announces "Moved Fix login bug to In Progress, position 1 of 2." Press Down arrow once within In Progress: the card moves below the existing card there and the live region announces "Moved Fix login bug to position 2 of 2." Press Space to drop: the live region announces "Dropped Fix login bug in In Progress, position 2 of 2," and focus stays on the card in its new location. If Escape is pressed at any point during the grab instead, the card returns to To Do, position 2, and the live region announces "Cancelled. Fix login bug returned to To Do, position 2 of 3," so the user hears the exact recovery state rather than being left to guess whether the cancel actually worked.

Screen reader messaging and touch fallback. For touch users, provide an explicit alternative to gesture-based dragging, e.g. a visible "Move" button per item that opens a simple "move to position..." menu, since touch drag gestures are difficult for users with motor impairments to perform precisely regardless of screen reader use.

Trade-offs and pitfalls. The most common real gap is implementing the visual drag interaction fully (mouse and touch) and treating keyboard support as an afterthought bolted on later, which usually produces a keyboard path that moves items but never announces the result, leaving a screen reader user unsure whether their action succeeded. A second common gap: forgetting Escape-to-cancel, which strands a keyboard user mid-operation with no way back to the original state.

Testing plan for edge cases and AT compatibility. Test the full grab, move, drop, and cancel cycle with a real screen reader (NVDA+Chrome and VoiceOver+Safari at minimum), not just visually: confirm the live-region announcement fires on every move, not only the first; confirm Escape restores the original position and announces the cancellation; test dropping into a full or invalid target and confirm a failure is announced rather than failing silently; test with touch screen readers (VoiceOver on iOS, TalkBack on Android), since their gesture-based navigation can conflict with a custom touch handler; and test at 200% zoom to confirm the grabbed-item visual indicator, not just the ARIA state, stays visible.

Direct answer

First diagnose why the meeting is stalling: usually it's because status-sharing and decision-making are mixed together, and no one is clearly accountable for closing a decision when people disagree. The fix separates the two (status moves async, meeting time is reserved for decisions), names a decision owner per topic, and tracks decisions in writing so they don't get relitigated the next week.

How to redesign it

Step 1: diagnose before redesigning. Ask whether people are status-updating instead of deciding, whether it's unclear whose call something is, or whether decisions do get made but aren't tracked so they resurface. Each cause has a different fix.

Step 2: separate status from decisions.

Step 3: track decisions so they don't restall. Keep a lightweight decision log: what was decided, who owns it, and the date. If an item can't close live, name a follow-up owner and a deadline instead of letting it silently carry over.

Step 4: reconsider the cadence. If most items now resolve async, a lower-frequency decision meeting paired with a written weekly status may serve the group better than a fixed weekly sync for everything.

Worked example

Situation: a cross-functional project with design, engineering, and data has a standing 60-minute weekly sync. Status updates take up 45 minutes, decisions surface in the last 15, and things 'decided' in the room get revisited the following week.
Action: introduced a pre-read posted 24 hours ahead covering status and any open decisions that need a live call; restructured the meeting to skip status entirely and spend the full time on flagged decisions, each with a named owner; started a shared decision log so a closed decision has a record to point back to.
Result: the meeting shortened from 60 to 30 minutes because status moved out of the room, and decisions stopped resurfacing because there was now a written record of what was actually agreed and by whom.

Trade-offs and pitfalls

• Cutting the meeting without giving people another outlet just moves the stalling into chat threads. Live time is still needed for genuine disagreement, don't eliminate it entirely.
• Naming a decision owner can feel like taking authority away from the group. Frame it as who is accountable if the call turns out wrong, not as a power grab.
• Async pre-reads fail without a light enforcement habit. If nobody protects the norm, it quietly reverts to status-in-the-room within a few weeks.
• Adding a decision log and a template is itself process. If it isn't paired with removing something (like the status round-robin), it just adds overhead on top of the original problem.