Frontend Developer Mid-Level Interview Preparation Guide (FAANG Standards)

Direct answer

Array.prototype.forEach does not await its callback: it fires each async callback and moves on immediately, so console.log('done') runs before any of the await processor(item) calls have resolved. The fix is to replace forEach with a construct that actually waits, either a for...of loop with await inside it (sequential) or Promise.all over items.map(...) (concurrent).

Structured elaboration

forEach was designed before async/await existed and its callback's return value, including a Promise, is simply discarded. Passing an async function as the callback doesn't change this: each invocation still returns a Promise that forEach never looks at, so forEach itself completes synchronously (having merely started every item, not finished any of them) the instant it has called the callback once per array element. The console.log('done') line after the forEach call then runs immediately, while the async work is still in flight in the background.

Worked example

async function sleep(ms) { return new Promise(r => setTimeout(r, ms)); }

// Fixed, distinct per-item delays (not Math.random()) so the interleaving below
// is deterministic and reproduces identically on every run, not just illustrative.
const delays = { 1: 20, 2: 10, 3: 30 };

// BUGGY
async function processItemBuggy(x) { await sleep(delays[x]); console.log('  processed', x, '(buggy)'); }
async function processBuggy(items) {
  items.forEach(async item => { await processItemBuggy(item); });
  console.log('done (buggy)');
}

// FIXED: sequential
async function processItemFixed(x) { await sleep(delays[x]); console.log('  processed', x, '(fixed)'); }
async function processFixed(items) {
  for (const item of items) { await processItemFixed(item); }
  console.log('done (fixed)');
}

(async () => {
  console.log('--- buggy run ---');
  await processBuggy([1, 2, 3]);
  await sleep(100); // let the buggy run's background work finish before the next section starts
  console.log('--- fixed run (sequential for-of) ---');
  await processFixed([1, 2, 3]);
})();

Executed output (buggy items finish asynchronously in the background; with the fixed per-item delays above, item 2 always resolves first, then item 1, then item 3, after done has already printed):

--- buggy run ---
done (buggy)
  processed 2 (buggy)
  processed 1 (buggy)
  processed 3 (buggy)
--- fixed run (sequential for-of) ---
  processed 1 (fixed)
  processed 2 (fixed)
  processed 3 (fixed)
done (fixed)

done (buggy) prints immediately, before any processed line: forEach fired all three async callbacks and moved on without waiting for any of them. The processed (buggy) lines do eventually print, once their fixed delays resolve, in delay order (2, then 1, then 3, not the input order), rather than before done. The for...of version correctly prints all three processed lines, strictly in input order, before done.

Trade-offs and pitfalls

There are two valid fixes with different semantics, and picking the wrong one is itself a common mistake: a for...of loop processes items strictly one at a time (useful when order matters or you must not overwhelm a downstream dependency with concurrent calls), while await Promise.all(items.map(item => processor(item))) processes all items concurrently and finishes as soon as the slowest one does (faster, but only safe if the operations are independent and the downstream system can handle concurrent load). Silently reaching for forEach out of habit, rather than deliberately choosing sequential versus concurrent semantics, is exactly how this bug class gets reintroduced even by developers who already know the rule.

Direct answer

Don't position it as mentorship if the person resists that label. Frame the growth area as an opportunity tied to something they already care about, like impact or a problem worth solving, not as a personal deficiency to be corrected. Coach through modeling, shared ownership, and feedback on a specific concrete artifact, rather than direct instruction on their personality or style.

Coaching approach for a resistant, high-competence peer

Respect their self-image and drop the label if it's a trigger. People who resist being seen as needing a mentor often resist the framing more than the actual content. "Let's work on this together" as peers lands very differently than "I'm going to help you grow."

Attach the growth area to a real, concrete stake. Abstract feedback like "work on your communication" is easy to dismiss. A live initiative they're already invested in, where the gap visibly costs them something, like a proposal that keeps losing to weaker ideas because it doesn't land outside their own team, gives the coaching somewhere real to attach.

Coach indirectly: pairing, shadowing, and structured feedback on an artifact. Feedback on a specific document or pitch ("this framing lost the room in the first thirty seconds") is easier to accept than feedback on them as a person. Pairing them briefly with someone strong at the specific skill can model the behavior without you having to lecture it.

Give them ownership throughout. You scaffold (give graduated support that you withdraw as they gain competence); they drive. If it reads as your intervention rather than their initiative, you'll trigger the same resistance you were trying to avoid.

Fade support deliberately and watch for unprompted transfer. The real signal of progress is the specific pattern showing up again on a different initiative, without you being involved that time.

Worked example

A technically excellent peer keeps losing ground on ideas that are objectively strong, because their proposals don't land with people outside their immediate team. Naming this directly as a coaching need would likely trigger defensiveness, given how they see themselves. Instead, you invite them to co-own a cross-team initiative tied to a real problem they care about, briefly pair them with someone experienced at framing pitches for a broader audience, and give feedback specifically on the pitch document rather than on them. On the next initiative, without any involvement from you, they open with the same framing pattern you'd coached into the earlier pitch.

Trade-offs and pitfalls

Naming the growth area too directly with someone who resists the mentee label tends to trigger defensiveness and can shut down the relationship rather than open it.

Over-scaffolding, like writing the pitch for them yourself, solves the immediate case but doesn't build the underlying skill, and it reads as taking over rather than coaching.

This kind of indirect, peer-based coaching is slower and less controllable than direct instruction would be. You're deliberately trading speed for buy-in, and it's worth naming that trade-off rather than pretending it's free.

A real failure mode is mistaking short-term compliance, they did fine on the one pitch you were heavily involved in, for actual skill transfer, without ever testing whether the pattern shows up when you're not there.

Approach (brief)
Use Flexbox on the UL to lay out items in a row, center vertically via the NAV, allow wrapping with flex-wrap, and control per-item sizing with flex so items space evenly and wrap at a desired breakpoint. Use align-content to control spacing between wrapped rows.

CSS

/* container: center nav vertically */
.nav{
  display: flex;
  align-items: center; /* vertical centering of the UL inside the nav */
  padding: 0 16px;
  height: 64px; /* example height from design */
}

/* primary flex row */
.nav__list{
  display: flex;
  width: 100%;
  margin: 0;
  padding: 0;
  list-style: none;

  justify-content: space-between; /* distribute items across full width */
  flex-wrap: wrap;                /* allow items to wrap to new lines */
  align-content: center;          /* control vertical distribution of wrapped rows */
  gap: 12px;                      /* gap between items (optional, modern browsers) */
}

/* each nav item */
.nav__item{
  box-sizing: border-box;
  flex: 1 1 160px; /* grow, shrink, base width = 160px (controls when wrapping occurs) */
  text-align: center;
  padding: 12px 8px;
  white-space: nowrap; /* prevent internal wrapping of long labels */
}

Why this works / tips

• flex-wrap: wrap enables multi-line flow.
• flex: 1 1 160px gives each item equal share but lets them shrink; changing the base width adjusts when items wrap.
• justify-content controls spacing on each line; align-content controls spacing between lines when wrapped.
• If you need perfectly equal spacing including partial last row, consider using flex: 0 0 33.333% (fixed percents) or JavaScript to balance, but the flex approach is responsive and simple.
• Add accessibility/interaction styles (focus, hover) and test across browsers; include min-width or media-query tweaks for very small screens.

Direct answer

Decide by comparing the investment's expected payoff against its real cost, which is time and attention pulled from delivery, not just money, then bring your manager a specific, time-boxed ask paired with a coverage plan rather than an open-ended request.

Structured elaboration

• Name the investment type explicitly, since the shape of the ask differs: a certification (weigh its actual return on investment, or ROI, against the time and fee cost), a formal advanced degree (a far larger, multi-year time and money commitment for a credential), an internal on-the-job rotation (trades delivery time on your current team for exposure elsewhere), or simply protecting a fixed number of weekly hours split across growth domains.
• Compute the real cost honestly. If the ask is a fixed weekly-hours budget, name explicitly what shrinks to make room for it; a request that doesn't name its own trade-off reads as costless and gets challenged later.
• The negotiation lever that works is a bounded pilot: a defined number of weeks, a specific hours-per-week figure, a defined coverage plan for what you'd otherwise be doing, and a checkpoint partway through to reassess, rather than an open-ended protected-time request.
• If the ask involves protecting time against on-call or delivery pressure specifically, address it directly: name how coverage continues (pairing, documentation, swapping on-call windows) rather than letting the ask sound like a straight subtraction from the team's capacity.

Worked example

I wanted to protect a few hours a week for a structured certification relevant to where I wanted to grow, but I didn't just ask for the time. I brought my manager a specific ask: this many hours a week, for this many months, here's exactly what shrinks to make room for it, and here's how on-call coverage stays intact while I'm doing it. I framed it as a pilot with a checkpoint partway through: if my delivery velocity dropped noticeably, we'd pause and reassess rather than quietly abandoning either the study time or the delivery commitments. That framing made it an easy yes, because the cost was explicit and bounded instead of open-ended.

Trade-offs & pitfalls

• Asking for time without naming what shrinks to make room for it is the single biggest reason these requests get pushback.
• Treating a degree, a certification, an on-the-job rotation, and simply protected weekly hours as interchangeable asks misses that they carry very different costs and need different negotiations.
• Framing the investment purely as personal benefit rather than tying it to team or delivery value makes it harder to defend when priorities tighten.
• No checkpoint means no graceful way to pause if delivery genuinely suffers; always build in a reassessment point.

Approach overview
Short, reproducible DevTools trace + focused analysis to find JS heavy call stacks, then correlate with network/painting and apply targeted mitigations.

Record a performance trace

• Open Chrome DevTools → Performance.
• Check "Screenshots", enable "Memory" if needed. Set throttling to emulate target device (e.g., 4x CPU slowdown).
• Click Record, reproduce the interaction causing jank, Stop.
• Save trace for sharing.

Identify long tasks

• In the Performance panel’s Main thread flame chart, look for orange “Long Task” bars (>50 ms) and the Summary → "Main" -> "Self Time".
• Use the Experience Track (or Long Tasks track) to filter to only long tasks.

Inspect call stacks & JS execution

• Click a long task to expand the call stack at the bottom (Call Tree / Bottom-Up).
• Switch between "Call Tree" (logical order) and "Bottom-Up" (hot functions).
• Look for expensive functions: XHR/fetch handlers, framework reconciliation (React commit phase), heavy loops, large JSON.parse, synchronous layout/thrashing.

Correlate network / paint

• Inspect Network panel or Network section in the trace to see requests overlapping tasks.
• Use "Screenshots" and Paint/Composite layers in the trace to spot expensive style/layout/paint work.
• If long task follows a large script download/parse, focus on code-splitting. If paint-heavy, inspect expensive style recalc/layout calls.

Three+ strategies to reduce main-thread blocking

• Code-split & lazy-load: dynamic import routes/components; defer non-critical code so initial interactions avoid heavy parsing/compilation.
• Offload work: move CPU-heavy computation to Web Workers or WASM; use requestIdleCallback for non-urgent work.
• Break up long tasks: chunk loops with setTimeout/setImmediate/messageChannel or cooperative yielding (scheduler/yield points) to keep tasks <50ms.
• Reduce rendering cost: avoid layout trashing, use will-change carefully, virtualize long lists, minimize DOM nodes.
• Optimize third-party scripts: audit and defer/async or use placeholders.

Wrap-up
Iterate: reproduce after each change, re-record trace, verify long tasks removed and input latency improved.

Brief explanation

The children prop is React’s implicit way to pass nested JSX into a component. Use props.children for simple container components where consumers control markup inside (composition). Use render props or explicit slot props when the parent needs to supply specific regions or when the child needs data/callbacks from the component.

When to use which

• props.children: simple wrapper or layout (Card, Panel). Best when content is arbitrary and styling/structure is fixed.
• Render prop: when child needs component state or computed values (e.g., <DataLoader>{data => ...}</DataLoader>).
• Explicit slot props: when you want named regions (header, footer, actions) and clearer API.

Card example

// Card.jsx
export default function Card({ children, className = '' }) {
  return (
    <div className={`card ${className}`} role="group">
      {children}
    </div>
  );
}

Consumer usage:

<Card>
  <h3>Title</h3>
  <p>Body content...</p>
  <div className="actions"><button>OK</button></div>
</Card>

Notes

• For accessibility, preserve semantic elements inside children.
• If you need a structured API later, migrate to slot props: <Card header={} body={} footer={}>.

Direct answer

Propose a staged expansion built around one explicit decision rule: define, before the first user sees the change, exactly what "keep expanding" and "roll back" mean numerically. Expand only when the data clears that bar, starting from a cohort small enough (a canary slice) that a bad outcome is cheap to reverse. Staging beats a full launch here specifically because a large, diverse user base can hide a bad outcome for one segment inside a fine-looking average.

Structured elaboration

• Why staged: the average result can look fine while a specific segment is having a bad time; starting narrow surfaces segment-level effects before they're everyone's problem.
• Stage 1: 1-2% of users, broadly representative rather than just power users, run long enough for a stable read past any novelty effect (users reacting to a change simply because it's new, not because it's actually better, which can make early numbers look inflated).
• Stage 2, only if Stage 1 clears the bar: a meaningfully larger slice, roughly 10-20%, to catch effects that only show up at higher concurrency.
• Full rollout: only after Stage 2 holds; consider a small permanent holdout (a subset of users deliberately kept on the old version, so you always have a live comparison group) afterward to keep measuring true causal impact.
• What to monitor: the primary metric the change should improve, plus at least one guardrail (latency, error rate, a specific segment's experience) that could regress while the primary looks fine.
• Rollback criteria: a numeric trigger per guardrail, set before launch, so rollback is automatic, not a judgment call made under pressure.
• Stakeholder communication: a short update to stakeholders before each expansion on what the current stage showed, and if you roll back, communicate that fast and factually.

Worked example

A new ranking algorithm replaces the current one. Stage 1: 2% of users for 2 weeks, past the novelty bump that typically fades within days. Primary metric: click-through on the top 3 results. Guardrails: page load latency and complaint-ticket rate. Rollback trigger: complaints rising more than 25% above control, or latency up more than 100ms. At 2 weeks: click-through up 6%, latency unchanged, complaints up only 4%, well under the trigger, so you expand to 15% for 2 more weeks. Stage 2 holds the same gain with clean guardrails, so you proceed to full rollout, keeping a 1% holdout for one more month to confirm the gain persists once the algorithm is no longer new.

Trade-offs and pitfalls

A cohort so small or short you never get a stable read, declaring success on a 3-day, 0.1% sample, produces false confidence. Watching only the metric you want to improve and missing a guardrail regression is the other common failure. Treating the rollback bar as negotiable once you're invested in the launch undoes the point of setting it in advance.

Direct answer

Don't try to average everyone's position into a compromise nobody's happy with. Ground the negotiation in the shared outcome, make the trade-offs between options explicit with evidence, and force a real decision (with an owner and a documented rationale) within a fixed timeframe. A compromise sticks when people can see why it was chosen, not just that it split the difference.

Structured elaboration

1. Reframe around outcome, not position. Ask each stakeholder what success looks like for them, not what they want built. Two stakeholders who seem opposed on the "what" often agree on the "why," which is where the real compromise lives.
2. Bring evidence, not opinions. Gather whatever is available and relevant: usage data, cost/effort estimates, prior incidents, qualitative feedback. A room full of opinions negotiates forever; a room with a shared set of facts converges faster.
3. Make trade-offs visible. Lay out 2-3 real options with their costs and benefits side by side, instead of a single proposal to accept or reject. People compromise more easily when they're choosing between concrete alternatives than when they're being asked to give up a specific ask.
4. Use a structured negotiation move. Propose a balanced default option first, then invite each side to request a bounded concession from it, rather than starting from each side's maximal ask and negotiating down. Time-box the discussion so it doesn't drift into re-litigating the same points.
5. Document the decision and name an owner. Write down what was decided, why, who owns it, and when it will be revisited. If the group truly can't converge, escalate with a specific recommendation rather than an open question, so the escalation itself doesn't become another unresolved debate.
6. Build in a review point. Treat the agreement as provisional and testable, not permanent. A short follow-up (after the next milestone, or a fixed number of weeks) to check whether the compromise is actually working keeps people bought in because they know it isn't final and unappealable.

Worked example

Three stakeholders disagree on scope for a feature: one wants the full version shipped now, one wants it deferred a quarter, one wants a stripped-down version shipped immediately. Instead of negotiating "how much scope," the facilitator asks each what outcome they're protecting: the first is protecting a customer commitment, the second is protecting engineering capacity for other work, the third is protecting the team's ability to learn before over-investing. That reframing surfaces a real option none of them had proposed: ship a narrow version that satisfies the customer commitment, explicitly scoped as a first iteration, with the deferred work logged and re-prioritized at the next planning cycle. The decision, the scope boundary, and the re-prioritization date are written down and shared with all three stakeholders.

Trade-offs & pitfalls

• Pitfall: false compromise, where everyone gets a token piece of what they asked for and the result satisfies no one's actual underlying need.
• Pitfall: skipping documentation. An undocumented "agreement" gets re-argued the moment someone's memory of it differs.
• Pitfall: treating consensus as required. Some decisions need a single accountable owner to make the call after input, not unanimous agreement, especially under a deadline.
• Senior differentiator: designing the forcing function (a default option, a timebox, a named decision owner) instead of facilitating an open-ended discussion indefinitely. That's what turns "several people who each want something different" into an actual decision.

Direct answer

Advance one pointer (slow) one step at a time and another (fast) two steps at a time. If the list has no cycle, fast reaches the end first and you can report there is none. If it does have a cycle, fast eventually laps slow and the two meet somewhere inside it. Once they meet, restarting one pointer at the head and advancing both pointers one step at a time makes them meet again exactly at the cycle's start. All of this uses $O(1)$ extra space, no visited set required.

Structured elaboration

Why meeting implies a cycle, and why no meeting implies no cycle. With no cycle, fast strictly gains ground toward a null terminator every step and reaches it in at most n/2 steps; it can never occupy the same node as slow without a cycle to loop back through. Once both pointers are inside a cycle, fast closes the gap to slow by exactly one node per step, because fast gains two steps of distance while slow gains one, a net closing rate of one per step. Since the gap can never exceed the cycle's length, they are guaranteed to meet within one full lap of the cycle.

Why the meeting point locates the cycle's start. Let a be the distance from the head to the cycle's start, c be the cycle's length, and b be the distance from the cycle's start to the meeting point, with $0 \le b < c$. By the time they meet, slow has traveled a + b steps and fast has traveled exactly twice that, but fast has also gone around the cycle some whole number of extra laps $n \ge 1$:

So a and (c - b) differ by a whole number of cycle lengths, meaning a pointer walking one step at a time from the head, and a pointer walking one step at a time from the meeting point, land on the same node after exactly a steps: the cycle's start.

Related applications of the same fast/slow pattern. Removing the n-th node from the end of a list uses the same shape without any cycle involved: advance one pointer n steps first, then move both pointers together; when the front pointer reaches the end, the trailing pointer sits exactly at the node to remove. Finding a duplicate number hidden in an array reframes the array itself as an implicit linked list, where the value stored at each index tells you which index to visit next; a repeated value forces two different positions to point at the same next index, creating a cycle in that implicit list, which Floyd's tortoise-and-hare detects exactly the way it detects a cycle here.

Worked example

class Node:
    def __init__(self, val, next=None):
        self.val = val
        self.next = next


def detect_cycle_start(head):
    slow = fast = head
    while fast and fast.next:
        slow = slow.next
        fast = fast.next.next
        if slow is fast:
            ptr = head
            while ptr is not slow:
                ptr = ptr.next
                slow = slow.next
            return ptr
    return None


if __name__ == "__main__":
    nodes = [Node(i) for i in range(5)]  # values 0,1,2,3,4
    for i in range(4):
        nodes[i].next = nodes[i + 1]
    nodes[4].next = nodes[2]  # cycle back into node with value 2
    start = detect_cycle_start(nodes[0])
    print(start.val)

Running this prints 2. In the derivation's terms: a = 2 (two steps from the head, value 0, to the cycle's start, value 2), c = 3 (the cycle 2 to 3 to 4 back to 2 has three edges), and the two pointers first meet at the node with value 3, so b = 1 (one step from the cycle's start to that meeting point). Checking the identity: c - b = 3 - 1 = 2, which equals a, confirming the derivation against this concrete run.

Complexity

Time: $O(n)$. The pointers meet within one full lap of the cycle once both are inside it, and finding the cycle's start afterward takes at most another full lap; both phases are bounded by a constant multiple of the list's length n.
Space: $O(1)$, since only the slow and fast pointers (and later ptr) are held, with no visited set.

Edge cases

• Empty list (head is None): fast is None immediately, so the loop never runs and the function correctly returns no cycle.
• Single node with no self-link: fast.next is None on the first check, so the loop exits immediately with no cycle detected.
• Single node that cycles to itself: slow and fast both land back on that same node on the first iteration, correctly reporting it as the cycle's start.

Trade-offs & pitfalls

A common bug is comparing pointer values instead of pointer identity; when list values can repeat, slow.val == fast.val can be true without slow and fast being the same node, so the check must be slow is fast.

Direct answer

Three habits that compound because they're small enough to do daily and social enough to spread on their own: writing or updating a test alongside the code you're touching rather than as a separate later step, a weekly small-group code walkthrough where one person shares something interesting they wrote or found, and leaving code slightly better than you found it on every touch. Measure adoption with leading signals and success with a trailing signal a few months later, not a mandate announcement alone.

Structured elaboration

Habit one, daily: test alongside code. When touching a function, write or update its test in the same sitting, before moving on, instead of batching "add tests" as a separate task for later, which in practice usually means never. It's a small discipline per instance that compounds over months.

Habit two, weekly: a code walkthrough. A thirty-minute session where one person shows a piece of code they wrote or found interesting, a clever refactor, a tricky bug fix, a design decision they're unsure about, open discussion rather than a formal review. This spreads a tacit sense of what good looks like faster than a written standards document, and normalizes talking about code quality socially instead of only through review comments.

Habit three, on every touch: leave it better. A small, scoped improvement to whatever code you're touching, renaming an unclear variable, adding a missing test to an adjacent untested function, tightening an interface, bounded so it doesn't turn into unplanned scope creep on an unrelated ticket.

Measuring adoption and success: adoption is easiest to see as a leading signal, the share of merged pull requests that include a test change alongside the code change, walkthrough attendance and rotation of who presents, a count of small non-ticket cleanup commits. Success is a trailing signal reviewed monthly, the trend in review comments flagging a missing test, self-reported team confidence in the codebase from a short survey, and whether the same module keeps showing up in incident postmortems. Pair the adoption metrics with an occasional spot-check of quality, since presence alone can be gamed with a trivial test just to tick a box.

Worked example

A backend team of six adopts these three habits. In the first two weeks, the tech lead presents first at the weekly walkthrough to model the tone, informal rather than a performance review, then rotation cycles through the rest of the team. By the end of the first month, the share of merged pull requests including a test change rises noticeably from roughly half to nearly all, tracked from the pull request diff data rather than self-report. The leave-it-better habit shows up as a steady trickle of small cleanup commits alongside feature work, loosely tracked by a "cleanup" tag the team adopts as a commit-message convention. At the three-month mark, the team reviews together: review comments flagging missing tests have dropped noticeably, the walkthrough has surfaced two design issues early that would previously have only been caught in a later incident, and a quick anonymous survey shows most of the team feels more comfortable navigating the codebase than before, that combination, not any single number, is what the team uses to call the habits working.

Trade-offs and pitfalls

A daily habit that's too heavy, a full test-suite update on every touch, gets abandoned under deadline pressure, it has to be small enough to survive a genuinely busy week or it won't actually compound. The weekly walkthrough can slide into performance theater or quiet gatekeeping if the same senior person always presents and others feel judged, deliberately rotating presenters and keeping the tone informal matters as much as the format itself. The leave-it-better habit, left unbounded, turns into scope creep that annoys reviewers and slows down unrelated pull requests, it needs an explicit norm that the cleanup stays small and is mentioned in the pull request description rather than silently bundled in. And measuring only activity, walkthrough attendance, test-change percentage, without ever spot-checking quality risks celebrating habits that technically happened but didn't actually raise the bar.