Junior Fullstack Developer Interview Preparation Guide - FAANG Standard

Direct answer

The second explanation almost never wins by being louder or more detailed than the first. It wins by changing the format, meaning I switch from telling to showing, and by rooting the explanation in a decision the person actually needs to make rather than in the mechanics of the tool itself. To avoid condescension, I treat the first miss as information about my explanation, not about their ability.

Structured elaboration

When a first explanation does not land, I go through a specific adjustment process rather than just repeating myself more slowly:

1. Diagnose what actually did not land, by asking a targeted question rather than re-explaining immediately. Usually the gap is one of three things: the vocabulary I used, the lack of a concrete example, or the fact that I explained the mechanism instead of the decision it enables.
2. Change the format, not just the pace. If the first pass was verbal, the second pass gets a visual or a live walkthrough. If the first pass was abstract, the second pass starts from a specific, real example the person already cares about.
3. Anchor the explanation in a decision they need to make, not in how the underlying system works. People retain "here is what you do when you see X" far better than "here is how X is calculated."
4. Check understanding by having them use it themselves, not by asking if it makes sense. Watching someone operate the thing and narrate their reasoning out loud surfaces exactly where the model in their head diverges from reality.

To avoid condescension, I frame the second attempt as "let me show you a different way to look at this" rather than "let me try explaining this more simply," and I never reference the fact that this is a repeat explanation in front of other people.

Worked example

I owned a dashboard that tracked monthly customer churn, acquisition channel, and cohort value for Product and Customer Success managers, most of whom were not technical. After my first walkthrough, several of them still could not use it to decide which customers to prioritize for retention outreach; they nodded along in the room but did not use it afterward.

For the second attempt, I changed three things. First, storytelling: instead of walking through the chart types, I opened with a real scenario, "we're seeing a spike in churn from one acquisition channel this quarter, here is what that costs us and how we'd catch it," and used the dashboard to answer that story as it unfolded. Second, guided filters: rather than describing the filters, I handed them the dashboard and had each person isolate a cohort and change the date range themselves while I coached, so the tool's behavior stopped being something I described and became something they had just done. Third, annotated visuals: I added in-dashboard annotations next to each chart naming the business question it answers, so the connection between a chart and a decision was visible without me being in the room. Afterward, I gave each person a short realistic scenario and had them talk through, using the dashboard, what they would do, which told me directly whether the explanation had landed rather than relying on their saying it made sense.

Trade-offs and pitfalls

• Switching format on the second attempt costs more preparation time than repeating yourself; it is worth it specifically because a second identical explanation rarely succeeds where the first one failed for the same underlying reason.
• Anchoring purely in decisions can under-explain the tool for a stakeholder who later needs to use it in a situation you did not walk through. If the audience needs durable independence, not just one correct decision, the mechanism has to come back in briefly, just after the decision framing rather than before it.
• The biggest condescension risk is not tone, it is implying the person should have understood the first time. Framing the second pass as offering a different angle, rather than a simpler one, avoids that without softening the actual content.
• Hands-on practice only works if you can tolerate the person making a visible mistake in front of you or others; rushing to correct every misstep undercuts the exact learning-by-doing effect you are relying on.

What I would change before shipping
For production, I would remove recursion from any traversal or path algorithm that could see a deep tree. An explicit stack is safer than trying to raise Python's recursion limit, because sys.setrecursionlimit only hides the risk and can still crash the process on very deep inputs.

Concrete changes

• Replace recursive traversals with iterative versions.
• Use explicit stacks for inorder, postorder, and path-sum checks.
• Add tests for degenerate trees, such as a single chain of 20,000 nodes.
• Decide what to do on missing nodes or empty trees, and return that consistently.
• Add observability, such as logging maximum depth seen in production.

Example
If a customer uploads a tree shaped like a linked list, a recursive path-sum solution may fail even though the logic is correct. An iterative DFS with (node, state) pairs avoids that failure mode.

Production rule
My default is: if input depth is unbounded, do not rely on recursion. Use iterative code and make memory use predictable.

Direct answer

A hash map alone gives $O(1)$ key lookup but has no notion of access order, so evicting the least-recently-used (LRU) entry would mean scanning every entry to find it, which is $O(n)$. Pairing the hash map with a doubly linked list solves this: the hash map maps each key directly to its node in the list, and the list keeps nodes ordered by recency, most-recently-used at the head and least-recently-used at the tail, so a lookup, a reorder-on-access, and an eviction (pop the tail) are all $O(1)$.

Approach

• Maintain a doubly linked list of nodes (key, value), ordered by recency, with dummy head and tail sentinels so inserting or removing at either end never has to special-case an empty list.
• Maintain a hash map from key to the node holding that key, so you never search the list by value; you always jump straight to the node.
• get(key): if the key isn't in the map, return the miss sentinel. Otherwise move that node to the front (most-recently-used position) and return its value.
• put(key, value): if the key exists, update its value and move it to the front. Otherwise create a new node, add it to the front, and if that pushes the map over capacity, remove the node just before the tail sentinel (the actual least-recently-used entry) and delete it from the map too.

class Node:
    __slots__ = ("key", "value", "prev", "next")

    def __init__(self, key=None, value=None):
        self.key = key
        self.value = value
        self.prev = None
        self.next = None


class LRUCache:
    def __init__(self, capacity: int):
        self.capacity = capacity
        self.map: dict[int, Node] = {}
        self.head = Node()
        self.tail = Node()
        self.head.next = self.tail
        self.tail.prev = self.head

    def _remove(self, node: Node) -> None:
        node.prev.next = node.next
        node.next.prev = node.prev

    def _add_to_front(self, node: Node) -> None:
        node.next = self.head.next
        node.prev = self.head
        self.head.next.prev = node
        self.head.next = node

    def get(self, key: int) -> int:
        if key not in self.map:
            return -1
        node = self.map[key]
        self._remove(node)
        self._add_to_front(node)
        return node.value

    def put(self, key: int, value: int) -> None:
        if self.capacity <= 0:
            return
        if key in self.map:
            node = self.map[key]
            node.value = value
            self._remove(node)
            self._add_to_front(node)
            return
        node = Node(key, value)
        self.map[key] = node
        self._add_to_front(node)
        if len(self.map) > self.capacity:
            lru = self.tail.prev
            self._remove(lru)
            del self.map[lru.key]


if __name__ == "__main__":
    cache = LRUCache(2)
    cache.put(1, 1)
    cache.put(2, 2)
    print(cache.get(1))   # 1 (1 is now most recent)
    cache.put(3, 3)       # capacity 2: evicts key 2 (least recently used)
    print(cache.get(2))   # -1
    cache.put(4, 4)       # evicts key 1
    print(cache.get(1))   # -1
    print(cache.get(3))   # 3
    print(cache.get(4))   # 4

Running this prints, in order: 1, -1, -1, 3, 4, which matches the standard LRU trace (put 1, put 2, get 1 promotes key 1, put 3 evicts key 2 since it's now the least recent, put 4 evicts key 1 since 3 was inserted more recently).

Key points

• Every present key has exactly one node in the map and exactly one node in the list; those two structures are kept in lockstep on every operation.
• The head and tail sentinels remove every edge-case branch for "the list is empty" or "the list has one element" from _remove and _add_to_front.
• Deterministic cache keys: the map key must be a stable, complete representation of the thing being cached. If two logically identical requests can hash to different keys, for example because a key is built from an unordered dict or kwargs whose iteration order isn't fixed, or because it omits a parameter that actually affects the result, you get both a spurious cache miss and duplicate storage for what should have been one entry. Build cache keys from a canonical, fully-ordered encoding of every input that affects the output.
• LRU vs. LFU: this design evicts by recency. A least-frequently-used (LFU) policy instead evicts the entry with the smallest access count, which needs a frequency counter per entry plus a way to find the minimum count in $O(1)$ (typically a doubly linked list of frequency buckets, each bucket holding the keys at that frequency). LFU is worth reaching for when recency is a noisy signal, for example a periodic bulk scan that touches every key once would evict your actual hot set under plain LRU even though those keys are still frequently used elsewhere.

Complexity

Time: $O(1)$ for get and put. Space: $O(n)$ for $n$ cached entries (one hash map entry plus one list node per key).

Edge cases

• capacity <= 0: put is a no-op and get always misses.
• Updating an existing key on put must still move it to the front; forgetting that is the most common bug in this design.
• Capacity of exactly 1: every new put after the first immediately evicts the previous entry.
• A workload dominated by a one-time bulk scan defeats plain LRU by evicting the genuinely hot set; that's the scenario where LFU or a hybrid recency-plus-frequency policy earns its extra bookkeeping.

Problematic selector patterns

• Universal selector (*) — forces browser to match every element.
• Deep descendant selectors (A B C) — long scope increases matching work.
• Qualified universal (div ), attribute-heavy selectors ([data-="x"]) and :not() with complex expressions.
• ID/inline style overuse prevents reuse; overly-specific chains harm maintainability.

Why they’re bad

• Browsers match right-to-left; complex selectors make many node tests per element and slow repaint/reflow on large DOMs.

Guidelines

• Prefer class selectors (.btn) and short selector chains.
• Use BEM or utility classes for predictable specificity.
• Limit descendant depth; use direct child (>) sparingly.
• Avoid runtime generated generic attributes; cache computed styles in CSS classes.
• Keep selector count reasonable; reuse styles.

Profiling / spotting bottlenecks

• Use Chrome DevTools Performance + Coverage to find unused/expensive rules.
• In DevTools Elements, toggle rule sets to see repaint impact.
• Measure repaint/reflow (Performance tab: Layout events) while interacting; isolate by disabling suspected rules.
• Audit with Lighthouse and CSS coverage to trim large stylesheets.

A feature-flag service's contract centers on one asymmetry: the evaluate path is read constantly, on a hot path, by every service that checks a flag, while create/toggle/audit are low-volume management operations. The contract should reflect that asymmetry directly in its shape, not just in the implementation behind it.

The four endpoints

Create a flag (POST /flags): accepts a flag key, a human-readable description, and a default value, and returns the created flag's identifier and current state. This is a low-frequency, administrative operation, so its response can afford to be verbose (full flag metadata) without any latency concern.

Evaluate a flag (GET /flags/{key}/evaluate?context=...): the hot path. The request carries an evaluation context (user ID, environment, or other targeting attributes); the response should be as small as possible, essentially just the resolved boolean or variant value, because this call happens on every request path that checks the flag and any extra payload weight is paid millions of times over.

Toggle a flag (PATCH /flags/{key}): flips a flag on or off (or changes its targeting rules), and should return the new state plus a version or timestamp so a caller can confirm the toggle actually took effect and see what it changed from.

Retrieve audit logs (GET /flags/{key}/audit): returns a paginated history of who changed the flag, when, and what the before/after state was, which is the accountability trail for a service that can change application behavior without a code deploy.

Worked example: the evaluate response shape

{
  "flag_key": "new_checkout_flow",
  "value": true,
  "reason": "targeting_rule_match"
}

Compare that to a create response, which can be much richer:

{
  "flag_key": "new_checkout_flow",
  "description": "Enables the redesigned checkout flow for eligible users",
  "default_value": false,
  "created_at": "2026-07-28T12:00:00Z",
  "version": 1
}

The evaluate response is deliberately minimal (three small fields); the create response can afford ten times the payload because it runs orders of magnitude less often.

Performance and safety considerations the schema has to account for

• Evaluate must be cacheable and fast to parse, so its schema stays flat and small; nesting a full targeting-rule explanation into every evaluate call would add latency to the busiest path in the system for the sake of a debugging convenience almost nobody needs on every call.
• Toggle must be auditable by construction, not as an afterthought: every toggle response including a version number means a caller (and the audit log) can always answer "what did this flag look like immediately before this specific change."
• The evaluation context in the evaluate request needs a stable, documented shape (which attributes are supported for targeting) so that adding a new targeting dimension later is an additive, backward-compatible schema change, not a breaking one for every existing caller.

Trade-offs and pitfalls

The most common mistake is putting all four operations behind one uniform, verbose response schema for consistency's sake, which quietly taxes the highest-traffic endpoint (evaluate) to make the lowest-traffic ones (create, audit) marginally easier to read. A feature-flag contract earns its keep specifically by treating "how often is this called" as a first-class input into how big its response is allowed to be.

Direct answer

Name two or three sources of engagement that are durable, ownership of a real problem, autonomy to fix something broken, seeing your work actually used, because those are what survive a bad day, unlike novelty or initial excitement, which don't.

The framework

1. Separate fragile excitement from durable motivation: prestige, initial novelty, and a strong first impression wear off; ownership of an outcome, autonomy, and a teammate depending on you tend not to.
2. Contrast durable motivators with compensation explicitly: this question is implicitly testing whether your engagement is pay-dependent, if the work is only worth doing because of the paycheck, a bad day has nothing to pull you back, so naming non-comp durable motivators directly answers what's being tested.
3. Acknowledge that bad days are real rather than claiming immunity to them; naming what specifically pulls you through one is more credible than implying you never have them.
4. Tie the durable motivator to something concrete about this specific role's day-to-day, not a generic value that would apply anywhere.

Worked example

On a genuinely hard day earlier in my career, a project I owned hit a frustrating, unglamorous problem that took much longer than planned to actually fix. What got me back in the next morning wasn't excitement about the company, it was that the problem was mine to solve and a teammate was blocked on it; finishing it meant something specific and immediate, not abstract. That's the kind of motivator I'm looking for in this role too: a defined area of ownership where the work is visibly mine and visibly used, not just a mission statement I agree with in the abstract.

Trade-offs and pitfalls

An answer built entirely on external motivators invites the obvious follow-up about leaving for more money, while an answer that claims total immunity to bad days reads as unconvincing; the credible middle ground names something specific that held up under a real bad day.

Approach

Two very different access patterns share one storage bill: thumbnails are read constantly but are tiny, originals are large but almost never read again after day one. Design around that asymmetry instead of applying one policy to both.

Strategy

• Thumbnails: keep in standard (hot) storage, and put a CDN (content delivery network, a caching layer close to users) in front of them with a long cache TTL (time-to-live). Since they're small and requested constantly, the CDN absorbs most of the read traffic, keeping origin storage cost and request cost low even though the tier itself is the expensive one.
• Originals: transition to a cheaper, infrequent-access class after a short buffer (a couple of days, not day one, since users often edit or delete a fresh upload and an early transition can trigger a minimum-storage-duration charge), then to an archive-class tier after a longer window, since the question states they're "almost never read again" past the first day.

Worked example

At 10 million images/month, average 4 MB originals and 50 KB thumbnails: originals total about 39,060 GB/month, thumbnails about 477 GB/month, so originals are roughly 80x the stored bytes even though thumbnails get nearly all the traffic. At an illustrative $0.023/GB-month, leaving originals in standard storage costs about $898/month per monthly cohort; moving them to an archive class at an illustrative $0.004/GB-month cuts that to about $156/month, a saving near $742/month (about 83%) per cohort, compounding every month new uploads land. Thumbnails, by contrast, cost only about $11/month even fully hot, because they're small; there's no real saving available there, which is exactly why they're not worth tiering down.

Trade-offs

• Archiving originals adds retrieval latency and a retrieval fee for the rare user who wants their full-resolution download; that's an acceptable trade given how rarely it happens, but the product needs a "this may take a moment" state for that path.
• An alternative or complementary lever is re-encoding originals to a smaller lossy format once they're old enough that print-quality is unlikely to matter, trading some quality for less-than-linear byte reduction; worth evaluating if archive-tier savings alone aren't enough, but it's a one-way, quality-losing move, so treat it separately and more cautiously than a reversible storage-class transition.

Direct answer. Take a time range, a granularity, and a set of filter dimensions as query parameters, return a compact array-of-points shape rather than a deeply nested object, and fail with a clear 400 (not a slow, expensive query) when a client asks for a combination that would be too expensive to compute on demand.

The contract.

GET /metrics/{metric_name}?start=2026-07-01T00:00:00Z&end=2026-07-28T00:00:00Z&granularity=hour&dimension=region:us-east

Response:

{
  "metric": "api_requests_total",
  "granularity": "hour",
  "points": [
    { "ts": "2026-07-01T00:00:00Z", "value": 18234 },
    { "ts": "2026-07-01T01:00:00Z", "value": 17902 }
  ],
  "truncated": false
}

• start / end: an explicit ISO 8601 range, never an open-ended "give me everything," which is both a usability requirement (a dashboard always renders a bounded window) and a load-safety requirement.
• granularity: an enum (minute/hour/day), not a free-form duration string, so the server can reject an unsupported value outright rather than silently rounding it to something else.
• dimension: an optional filter (region, endpoint, status class), following the same query-parameter-per-concept convention as general filtering elsewhere in a REST API.
• points: a flat array of {timestamp, value} pairs, the simplest possible shape a charting library can consume directly with no client-side reshaping.
• truncated: an honest signal that the server capped this response at its per-call point ceiling (say, 10,000 points) and did not return every point the requested range/granularity combination would otherwise imply, so the client knows to narrow its request rather than silently receiving an incomplete-looking chart with no explanation. This only fires for combinations that are large but still inside the hard limit below; a combination that exceeds the hard limit is rejected outright before it ever runs (see 'Failing gracefully'), not silently truncated.

Failing gracefully instead of overloading the service. The soft cap behind truncated and the hard rejection below are two different thresholds, not the same one: reject (400) a request whose range/granularity combination would produce a number of points far beyond even the truncation ceiling (say, a full year at minute granularity, which is roughly half a million points, verified: 365 days times 24 hours times 60 minutes is 525,600, against a 10,000-point truncation ceiling) BEFORE running the underlying query, with a message naming the actual limit and suggesting a coarser granularity or a narrower range; this protects the service from being asked to compute and serialize an enormous response, and gives the client an immediately actionable error instead of a slow timeout. A combination that is large but still under the hard limit gets computed and returned with truncated: true instead, since it is cheap enough to be worth computing even though the client asked for more than the response will actually contain.

Why this is easy for dashboard developers. The flat points array needs no client-side transformation to feed into a charting library; the explicit granularity and truncated fields let a dashboard show an honest "zoom in for more detail" affordance instead of silently rendering incomplete or misleadingly-aggregated data.

Why it is hard to overload. The combination of a mandatory bounded time range, an enum-constrained granularity, and an up-front rejection of overly-broad requests means no single client request can accidentally (or deliberately) demand an unbounded amount of server-side computation; the cost of any single valid request is bounded by construction, not by hoping clients behave well.

Direct answer

The call comes down to three things: how urgent the situation is, how much damage a wrong guess could cause, and how much of the answer is actually discoverable on my own versus locked in someone's head. When the blast radius is small and the information is findable, I work it out myself; when either the stakes are high or the knowledge simply isn't written down anywhere I can reach, I ask, and I try to ask well rather than asking instead of trying.

What pushes the decision each way

Toward figuring it out alone: low stakes if I'm wrong, a reversible action, and real evidence I can search, like existing code, logs, or documentation, even if imperfect. I'd rather spend twenty minutes tracing something myself than interrupt someone for a question the system can actually answer.

Toward asking: anything with real blast radius if I get it wrong, anything time-sensitive where figuring it out alone would blow a deadline that asking wouldn't, and anything that lives only in a person's head with no written trace, since no amount of my own digging will surface knowledge that was never recorded anywhere.

I also weigh whose time is actually being spent either way. Struggling alone for an hour on something a five-minute answer would resolve isn't more virtuous, it's just a worse use of everyone's time, mine included, once you account for the risk of getting it wrong.

A short illustration each way

I once spent about thirty minutes tracing through a configuration file to understand a setting rather than asking, because getting it wrong would have been low-stakes and immediately obvious if wrong, and I learned something about the system I'd have missed by just being told the answer. A different time, on a system with production traffic, I hit a setting I didn't understand within the first hour on a team, and I asked immediately rather than experimenting, because a wrong guess there could have affected real users, and there was someone two seats away who could tell me in thirty seconds what would have taken me an unknown amount of digging to maybe find.

Trade-offs and pitfalls

The pitfall on one end is interrupting people constantly for things you could find yourself, which costs their time and slows down your own ability to build real familiarity with the system. The pitfall on the other end is treating asking as a failure and pushing through alone on something high-stakes, which is how avoidable mistakes happen in systems you don't yet understand well enough to know what you don't know.

Clarify goals & constraints

• Keep UI responsive across tabs, minimize latency, preserve security (avoid XSS/CSRF risks), and have deterministic conflict resolution when two tabs update the same state (e.g., cart, auth).

APIs to use

• BroadcastChannel (primary inter-tab signalling — low latency)
• localStorage events (fallback for older browsers)
• Service Worker (for background sync with server)
• IndexedDB (durable, large structured state)
• Navigator.sendBeacon / fetch for server sync

Overall strategy

1. Single source of truth: server is authoritative. Tabs keep a local cache (IndexedDB).
2. Update flow: user action → optimistic local update → write to IndexedDB + broadcast a compact operation over BroadcastChannel (includes op, payload, meta).
3. Server reconciliation: send operation to server; server applies, returns canonical state or op-ack.
4. Finalize: on server ack, tabs update local cache and UI. If server rejects, broadcast rollback op.

Conflict resolution (deterministic)

• Use Lamport timestamps plus stable tabId:
  • Each op carries {tabId, lamportCounter, opId}.
  • Compare by lamportCounter then tabId to break ties (lexicographic).
• For convergent CRDT-friendly domains (shopping cart), use simple CRDTs (observed-remove set + quantities) to ensure eventual consistency without central rollback.

Race handling & performance

• Coalesce rapid ops per tab (debounce + batching).
• Keep broadcasts lightweight (operation diffs, not full state).
• Use Service Worker for background sync retries; fall back to periodic reconciliation (on focus, network reconnect).

Security

• Do NOT store auth tokens in localStorage. Use HTTP-only, Secure, SameSite cookies for auth. For auth status propagation, broadcast only a boolean/state nonce — avoid secrets.
• Sanitize any data that may be rendered; use CSP and input validation.
• Verify origin in BroadcastChannel handlers and ignore malformed ops.
• On sensitive ops, require server-side verification (CSRF tokens, double-submit cookie if using non-HTTP-only tokens).

Example determinism rule

• Apply op A before B if:
  • A.lamport < B.lamport OR
  • A.lamport == B.lamport AND A.tabId < B.tabId

Edge cases

• Offline: record ops in IndexedDB, broadcast locally, retry via SW when online.
• Tab crash: other tabs will reconcile via server on next heartbeat or focus.
• Large state: sync diffs; provide snapshot checkpoints occasionally.

This approach balances responsiveness, security, and determinism: server authority + optimistic local ops + Lamport+tabId deterministic ordering (or CRDTs where applicable), BroadcastChannel for fast propagation, IndexedDB for durability, and Service Worker for reliable server sync.