Frontend Developer Interview Preparation Guide - Junior Level (1-2 Years Experience)

Approach (brief)
Compare nodes recursively; when types differ produce replace; when both text compare strings; otherwise generate update-props if props differ, then walk children pairwise producing insert/remove for surplus children. No keyed reordering; preserve order.

Code (ES6)

// Minimal virtual DOM diff
function diff(oldNode, newNode, path = []) {
  const ops = [];

  // helpers
  const isText = n => typeof n === 'string';
  const propsDiff = (a = {}, b = {}) => {
    const set = {};
    const remove = [];
    for (const k of new Set([...Object.keys(a), ...Object.keys(b)])) {
      if (a[k] !== b[k]) {
        if (b[k] === undefined) remove.push(k);
        else set[k] = b[k];
      }
    }
    return { set: Object.keys(set).length ? set : null, remove: remove.length ? remove : null };
  };

  // both text nodes
  if (isText(oldNode) || isText(newNode)) {
    if (oldNode !== newNode) ops.push({ op: 'replace', path, node: newNode });
    return ops;
  }

  // types differ -> replace
  if (!oldNode || oldNode.type !== newNode.type) {
    ops.push({ op: 'replace', path, node: newNode });
    return ops;
  }

  // props diff
  const pd = propsDiff(oldNode.props, newNode.props);
  if (pd.set || pd.remove) ops.push({ op: 'update-props', path, ...pd });

  // children diff (preserve order)
  const oldChildren = oldNode.children || [];
  const newChildren = newNode.children || [];
  const common = Math.min(oldChildren.length, newChildren.length);
  for (let i = 0; i < common; i++) {
    ops.push(...diff(oldChildren[i], newChildren[i], path.concat(i)));
  }
  // extra new children -> insert
  for (let i = common; i < newChildren.length; i++) {
    ops.push({ op: 'insert', path: path.concat(i), node: newChildren[i] });
  }
  // extra old children -> remove (remove from end to keep indices stable during apply)
  for (let i = oldChildren.length - 1; i >= common; i--) {
    ops.push({ op: 'remove', path: path.concat(i) });
  }

  return ops;
}

Key concepts & reasoning

• Use path (array of indices) to identify node locations for applying ops.
• Replace when node type or text changes because children/props semantics differ.
• Props diff separates sets and removes for minimal updates.
• Child comparison is linear pairwise; no key-based reordering.

Complexity

• Time: O(n) where n is total nodes in both trees (visits each node once, prop diffs cost proportional to prop count).
• Space: O(h) recursion stack + O(k) ops output, worst-case O(n).

Edge cases

• Null/undefined nodes, text vs element transitions, props with undefined values.

Direct answer

A retro after a release with repeated design-engineering friction should produce two things: an honest, specific account of where the handoff actually broke down, not a vague 'communication issues,' and a small number of concrete process changes, each with an owner and a way to tell in a quarter whether it worked. Running it well means separating fact-finding from diagnosis, and diagnosis from blame.

Structured elaboration

Design principles for the session

• Facts before diagnosis: start from a timeline of what actually happened (spec dates, handoff dates, bug counts, points where implementation and design diverged), not from opinions about who was at fault.
• Root cause, not the nearest symptom: 'engineering didn't follow the spec' is a symptom; the root cause might be that the spec didn't capture edge-case states, or that both sides were working from different versions of a shared design system mid-migration.
• Few, high-leverage commitments: two or three process changes people will actually do beat ten action items that quietly get dropped.
• Everyone leaves with the same understanding of what changed, not just what went wrong.

A workable structure

One illustrative shape, adaptable to a team's own rhythm:

What 'actually changes how the two teams work' looks like

The output isn't a list of intentions, it's a specific artifact or habit that exists after the meeting and didn't before: a shared checklist embedded in the handoff process, an automated check that catches a class of mismatch before it ships, or a standing short sync during implementation windows. Whatever it is, it needs a way to tell if it worked, not just that it happened.

Worked example

One team's root cause turned out to be that design tokens (colors, spacing values) were maintained in the design tool but hand-copied into code, so drift was inevitable and nobody could tell which side was 'correct' when they disagreed. The concrete fix was an automated export from the design tool into the codebase, checked by both a design reviewer and a frontend reviewer before merge, plus a short recurring sync during active implementation. A quarter later, the team had a real signal that it worked: noticeably fewer visual-mismatch comments on pull requests and less late-stage rework than the release that triggered the retro. The same root-cause pattern shows up in other domains as a hand-copied data contract or config value instead of a design token, so the same fix shape (automate the handoff, add a lightweight check, add a short sync during the risky window) generalizes well beyond design and engineering specifically.

Trade-offs and pitfalls

• A retro that produces ten action items usually produces zero completed ones; prioritizing ruthlessly matters more than being thorough.
• If the room jumps straight to solutions or blame instead of facts first, the real root cause, often structural or tooling-related rather than a person's failure, never surfaces.
• A retro that isn't revisited becomes theater. Put the check-in on the calendar before the room disperses, not as a vague intention afterward.
• Watch for a fix that only addresses this specific release's symptom (a one-off manual double-check) rather than the structural cause; it holds for one cycle and then quietly stops happening.

Direct answer

Treat it as an environment-specific bug: reduce to the smallest reproducible case, then check what's actually different (rendering engine, not brand) before assuming your own code is wrong. Safari runs WebKit while Chrome and Firefox run Blink and Gecko, so genuine spec-interpretation gaps are common.

Structured elaboration

• Shrink the page to the smallest markup/CSS/JS that still reproduces it; this also makes it searchable against WebKit's own bug tracker.
• Check whether the feature is a known trouble spot: flexbox/grid gap in overflow containers, position: sticky, lenient date parsing.
• Use Safari's own Web Inspector to check the actual computed DOM, since a JS feature-detection branch can differ just as easily as rendering.

Worked example

A real, documented case: Safari fails to parse "2026-07-24 10:00:00" (space separator, no offset) as Invalid Date, while Chrome parses it leniently as local time. Neither is required by spec for that exact format; the durable fix is always constructing dates from an unambiguous ISO 8601 string with a T and explicit offset.

Trade-offs and pitfalls

Confirm it's a genuine engine quirk, not your code relying on Chrome's more lenient behavior, before writing a Safari-specific branch; fixing the underlying assumption is more durable.

What the interviewer probes next

How you'd add this to automated cross-browser coverage, such as Playwright's WebKit target.

Direct answer
Recursion trades stack space and a per-call overhead for code that mirrors the problem's natural self-similar structure; iteration trades that clarity for constant stack usage and typically better raw performance. The concrete risk with recursion is a stack overflow on deep input, and the usual mitigating technique, tail-call optimization, is not guaranteed across mainstream languages (notably CPython does not do it).

Structured elaboration

• Readability: recursion often reads closer to the mathematical or structural definition of the problem (a tree, a fractal-like decomposition, n! = n * (n-1)!). Iteration usually needs an explicit accumulator or work-list and can obscure that structure, especially for tree/graph problems.
• Stack usage: each recursive call pushes a new stack frame (return address, local variables). A recursive call chain of depth n uses O(n) stack space, while a well-written iterative loop uses O(1) auxiliary stack space (the loop variables live in one frame).
• Stack overflow risk: if depth exceeds the runtime's limit, you get a hard failure (Python's RecursionError, a native segfault-style crash in some languages). This is a real production risk whenever recursion depth is driven by input size rather than a small fixed bound.
• Tail-call optimization (TCO): in a 'tail-recursive' function, the recursive call is the very last operation, nothing happens after it returns. A compiler or runtime that supports TCO can reuse the current stack frame for that call instead of pushing a new one, turning the recursion into a loop under the hood with O(1) stack usage. Languages like Scheme and (in the target-relevant case) Java's Scala guarantee this for self-tail-calls; CPython deliberately does NOT implement it (a language design choice, not a limitation of the trick) partly because it would make stack traces less informative for debugging.

Worked example

def factorial_recursive(n):
    if n <= 1:
        return 1
    return n * factorial_recursive(n - 1)      # NOT tail-recursive: multiply happens after the call returns

def factorial_tail_style(n, acc=1):
    if n <= 1:
        return acc
    return factorial_tail_style(n - 1, acc * n)  # tail-recursive IN FORM, but Python still doesn't optimize it

def factorial_iterative(n):
    result = 1
    for i in range(2, n + 1):
        result *= i
    return result

All three agree on small input (verified: factorial_recursive(10) == factorial_iterative(10) == factorial_tail_style(10) == 3628800). The difference shows up at depth: with CPython's default recursion limit of 1000, factorial_recursive(5000) raises RecursionError: maximum recursion depth exceeded (confirmed by running it), while factorial_iterative(5000) completes normally regardless of the tail-style rewrite, because CPython never collapses the recursive call chain into a loop. The same real-world shape shows up walking a deep hierarchical structure (a category tree, a nested comment thread): a recursive walker is elegant until the tree gets deep enough that the recursion limit, not the actual computation, is what fails.

Trade-offs & pitfalls
A correct senior answer does not claim 'just write tail-recursive code and it'll be fine' in a language like Python, that is a common and wrong mental shortcut. The real decision is: if depth is bounded and small (most tree structures in practice), recursion's readability usually wins; if depth scales with untrusted or unbounded input, convert to an explicit iterative version with your own stack (see the tree-traversal conversion question for a worked version of exactly that conversion) rather than relying on the language to save you.

Brief approach (whitelist + attribute filtering)

I’d parse the user HTML with DOMParser, walk the resulting nodes, and only recreate allowed tags (<b>, <i>, <a>, <u>, <strong>, <em>, text). For <a> I’ll validate href (only http(s) and mailto), strip javascript: and data: URIs, and enforce safe attributes: target="_blank" must add rel="noopener noreferrer".

Implementation (vanilla JS)

// Sanitize user HTML, returning a DocumentFragment safe to insert
function sanitizeHtml(input) {
  const ALLOWED_TAGS = new Set(['B','I','STRONG','EM','U','A']);
  const parser = new DOMParser();
  const doc = parser.parseFromString(input, 'text/html');
  const frag = document.createDocumentFragment();

  function safeHref(href) {
    try {
      const url = new URL(href, location.href);
      return (url.protocol === 'http:' || url.protocol === 'https:' || url.protocol === 'mailto:') ? url.href : null;
    } catch (e) { return null; }
  }

  function walk(node, target) {
    if (node.nodeType === Node.TEXT_NODE) {
      target.appendChild(document.createTextNode(node.textContent));
      return;
    }
    if (node.nodeType !== Node.ELEMENT_NODE) return;
    const tag = node.tagName;
    if (!ALLOWED_TAGS.has(tag)) {
      // recurse children but skip the element itself
      node.childNodes.forEach(child => walk(child, target));
      return;
    }
    const el = document.createElement(tag.toLowerCase());
    if (tag === 'A') {
      const href = node.getAttribute('href') || '';
      const safe = safeHref(href);
      if (safe) {
        el.setAttribute('href', safe);
        // preserve target only if _blank, but ensure rel is safe
        if (node.getAttribute('target') === '_blank') {
          el.setAttribute('target', '_blank');
          el.setAttribute('rel', 'noopener noreferrer');
        }
      }
    }
    node.childNodes.forEach(child => walk(child, el));
    target.appendChild(el);
  }

  doc.body.childNodes.forEach(n => walk(n, frag));
  return frag;
}

Why this works

• Whitelist ensures only known-safe tags appear.
• href validation blocks javascript: and other dangerous schemes.
• Enforcing rel noopener+noreferrer prevents tab-nabbing when opening new windows.

Remaining risks & trade-offs

• Not a full HTML sanitizer—edge cases include CSS in style attributes or SVG/MathML; we simply drop non-whitelisted elements but don't handle complex attributes (e.g., on* event handlers are removed by only copying allowed attrs).
• Parser differences across browsers are minor but acceptable.
• For production, prefer well-tested libraries (DOMPurify). This custom approach is fine for small controlled whitelists and low risk inputs.

Direct answer

Scaling a team from roughly 5 to 50 people while preserving candor and psychological safety means deliberately converting practices that worked informally at small scale (everyone just knew the norms) into explicit, documented structures before the informal version breaks down, rather than waiting until it already has.

Structured elaboration

1. Hiring criteria. Screen explicitly for candor and comfort with feedback, not just technical skill, since a small number of hires who are defensive about critique can quietly shift a team's norms faster than any process can counter. Include a structured interview stage that probes how a candidate has handled being wrong or challenged in the past.
2. Organizational structure. Split into smaller sub-teams (pods or chapters of 5 to 8) before the whole-group size makes candor feel risky, since psychological safety is much easier to sustain in a group where everyone knows everyone than in a room of 50. Keep a clear owner for culture within each pod, not just at the top.
3. Onboarding. Make the team's actual norms around candor and mistake-reporting an explicit part of onboarding, with real examples, rather than assuming new hires will absorb it by observation, since observation-only onboarding is exactly what breaks down as headcount grows and new hires increasingly onboard from peers who are also new.
4. Communication rituals. Preserve at least one regular, small-group forum (not just all-hands) where junior members interact directly with senior leadership, since large-group settings systematically suppress the same voices that a 5-person team never had to worry about.
5. Decision rights. Document who decides what as the team grows, since ambiguity about decision rights at scale creates exactly the kind of quiet frustration and unaddressed disagreement that erodes safety over time.
6. Propagation and drift detection. Run a lightweight, anonymous pulse check periodically, segmented by pod or tenure, specifically to catch drift early (newer joiners or a particular pod reporting lower safety) before it becomes a pattern across the whole organization.

Worked example

At 8 people, the team relies on a single weekly meeting where anyone can raise anything, and it works because everyone already trusts everyone. At 25 people, that same meeting has quietly become a forum where only the four most senior people speak, so the team splits into pods of 6, each running its own version of that ritual, with a monthly all-pod sync led by rotating hosts rather than always the most senior voice. At 50 people, a pulse survey shows one newer pod reporting noticeably lower safety scores than the others; investigating finds that pod's lead came from a much more hierarchical background and had not been through the same onboarding on the team's norms, which gets addressed directly rather than assumed away.

Trade-offs and pitfalls

The main pitfall is assuming that what worked informally at small scale will simply continue to work if you just keep doing the same things, without noticing that the same practice (one big meeting, one set of unwritten norms) has different, worse effects at 10x the headcount. A second pitfall is over-formalizing too early, turning a small, trusted team into a bureaucracy before it needs one, which can suppress the very candor it is trying to protect.

Direct answer

An array gives O(1) random access because an index maps directly to a memory address via arithmetic, but inserting or deleting anywhere except the very end requires shifting every following element, an O(n) operation. A singly linked list gives O(1) insert or delete once you already hold a reference to the relevant node, but finding that node in the first place (including "the middle") costs O(n), since there is no arithmetic shortcut, only following pointers one at a time.

Structured elaboration

• The "O(1) insert" caveat, worth stating explicitly. A linked-list insert or delete is only O(1) when you ALREADY have a reference to the right node, typically because you're iterating and acting as you go. If you're only given a numeric position (say, "insert at index 500,000"), you still have to walk there first, which costs O(n); claiming a flat "O(1) insert" without that condition is the single most common oversimplification of this comparison.
• Concrete scenario favoring the array. A lookup table mapping millions of user IDs to profile records, queried by index or key extremely frequently: O(1) random access is the whole point, and the data is rarely inserted into at arbitrary positions.
• Concrete scenario favoring the linked list. An eviction-order list for a cache, where an arbitrary, already-known node is frequently removed from the middle and a new node re-inserted at the front; both operations are O(1) once you hold the node reference, with no shifting cost regardless of list size.

Worked example

Consider inserting one new element at the FRONT of a collection holding 1,000,000 items. On an array, every one of the 1,000,000 existing elements must shift one position to make room, an O(n) cost that scales with however large the array has grown. On a singly linked list, the operation is exactly two pointer writes (the new node's next pointer, and the head pointer), regardless of whether the list holds 10 elements or 10,000,000: the cost does not grow with list size at all. This is the concrete shape of the O(n)-versus-O(1) difference in the table above, not just an abstract notation.

Trade-offs & pitfalls

• Memory overhead and cache locality. Each linked-list node carries at least one extra pointer (8 bytes on a 64-bit system) beyond its payload, and nodes are not stored contiguously in memory. For an iteration-heavy workload, an array is often noticeably faster IN PRACTICE despite both being asymptotically O(n), because sequential array access is cache-friendly while pointer-chasing a linked list typically is not; this is a constant-factor, hardware-driven effect, not a difference in asymptotic complexity.
• The most common oversimplification is stating "linked-list insert/delete is O(1)" without the caveat that this assumes the relevant node reference is already in hand; always confirm whether the scenario gives you the node or just a position.
• Singly linked lists only walk forward. Anything that needs "delete the node before this one" or other backward movement needs either a doubly linked list, or tracking a trailing pointer while iterating forward.
• Don't confuse this with dynamic-array append. A dynamic array (Python's list, Java's ArrayList) amortizes appending at the END to O(1) via geometric growth, which is a different operation from inserting at an ARBITRARY position; conflating the two is a common mistake when reasoning about array costs.

How media queries work
Media queries evaluate device/environment features (commonly width) and apply CSS when conditions match. Example: @media (min-width: 768px) { ... }.

min-width vs max-width

• min-width: mobile‑first — base styles for small screens, add styles as viewport grows. Easier to cascade and maintain.
• max-width: desktop‑first — start with large-screen styles and override for smaller screens; can lead to more specificity overrides.

Breakpoint strategies

• Device-based (375, 768): + predictable, aligns to device sizes; − can be arbitrary as devices vary.
• Content-based: + responsive to layout needs; − requires more testing per component.
• Hybrid: use standard device anchors but adjust where content breaks.

Examples

• 375px (small phones): ensures readable typography and stacked layout.
• 768px (tablets): switch from single-column to multi-column/grid.

Definition & contrast

• Reflow (layout): browser recalculates positions/sizes of elements after DOM/CSS changes. Affects geometry and can cascade through the layout tree.
• Repaint (paint): browser redraws pixels for elements whose appearance changed but whose geometry stayed the same (colors, visibility, shadows).

Concrete triggers

• Reflow examples: changing element dimensions (width/height), adding/removing elements from DOM, changing font-size, altering box-model properties (padding/margin), reading layout-triggering properties like offsetWidth/getComputedStyle that force layout.
• Repaint examples: changing background-color, color, visibility via opacity, box-shadow (if not affecting layout).

Why reflows cost more

• Reflow requires walking the DOM/CSSOM, computing styles, layout, and then painting. It can be O(n) or worse if many ancestors/layouts affected. Repaint only rasterizes pixels for affected layers—less computation.

Techniques to minimize reflows

• Batch DOM writes/reads (read layout values first, then write).
• Use document fragments or off-DOM updates (build subtree, then append).
• Use transform/opacity for animations (GPU-accelerated) instead of changing top/left/width.
• Use will-change and promote frequently-changing elements to their own compositing layer sparingly.
• Minimize layout thrashing (avoid interleaving reads and writes).
• Limit expensive selectors and reduce DOM depth/size.
• In frameworks: use virtual DOM updates, keying, and debounce/throttle frequent updates (resize/scroll).

Direct answer. Add a thin safety net first (characterization tests around the highest-risk paths), then make the smallest behavior-preserving changes that let you keep shipping features on top of a codebase that's incrementally getting safer -- never stop feature delivery to do a big-bang rewrite.

A pragmatic, incremental plan

1. Triage by risk, not by ugliness: use bug/incident history and traffic volume to find which parts of the codebase actually cause production pain, rather than starting with whatever looks messiest to the eye. That's where safety-net investment pays off fastest.
2. Characterization tests around the riskiest, most-touched code first: pin current behavior before changing anything there, so the very next change (a bug fix someone was going to make anyway) has a safety net.
3. Introduce seams for testability opportunistically: when you're already touching a function for a bug fix or small feature, take the extra step to extract its logic behind a seam (dependency injection, a wrapper around a hard-to-test dependency) rather than scheduling a separate 'add tests' project that competes with feature work indefinitely.
4. Establish a ratchet, not a rewrite: a simple rule like 'code you touch must leave with equal or better test coverage than it had' compounds over months without ever requiring a stop-the-world effort.
5. Fix bugs as they're found, but track root causes: if the same TYPE of bug (e.g., null handling) recurs, that's a signal for a small, targeted structural fix (a value type, a validation layer) rather than continuing to patch individual symptoms.
6. Communicate progress in business terms: incident rate trending down, cycle time on bug fixes shrinking -- so the ongoing investment stays visible and defensible against pressure to 'just ship features.'

Why NOT a big rewrite

A rewrite requires understanding the FULL current behavior (including undocumented edge cases relied on by real users) well enough to reproduce it exactly, which is precisely the thing 'frequent production bugs and no tests' tells you the team does NOT currently have -- the rewrite would be built on the same uncertain understanding that caused the bugs in the first place, at much higher risk and with a long period of zero feature delivery.

Trade-offs and pitfalls

• This plan trades a fast dramatic fix for a slower, compounding one; if leadership expects a visible turnaround in weeks rather than months, be explicit up front about that mismatch rather than overpromising a timeline the approach can't deliver.
• The 'ratchet' rule needs actual enforcement (a CI coverage-delta check, or review discipline) or it silently stops being followed the first time a deadline gets tight -- decide in advance whether it's a hard gate or a norm, and be honest that a norm alone often erodes under pressure.