Lyft Senior Data Engineer Interview Preparation Guide

Direct answer: "Most impactful" is a claim about scale, reach, or durability of a change, not automatically the project with the single biggest percentage. Come with a short comparison across two or three candidate projects on a common yardstick (people affected, durability of the fix, or how core the process was), and be ready to justify why that yardstick and not just report a number.

A framework for ranking impact across projects

When you don't have hard numbers

• Use proxy metrics: adoption rate, ticket volume, "still in use N months later," or direct stakeholder feedback.
• State explicitly that it's a proxy, not a causal measurement, rather than dressing it up as a precise result.
• Reach and durability are often easier to state honestly than a precise causal percentage, and they're still a legitimate basis for "most impactful."

Worked example (illustrative, arithmetic shown)

Two candidate projects: Project A fixed a rare edge-case bug, reducing its error rate from an estimated 3% to under 1% on the narrow path it affected. Project B rebuilt the new-user onboarding flow that every signup passes through; its effect on conversion wasn't cleanly isolated, but it has been in production for 12 months and the product runs roughly 2,000 signups a month. Reach comparison: Project B touches 2,000 x 12 = 24,000 users over that period, versus Project A's narrow edge case affecting a small estimated fraction of a much smaller baseline. Project B is presented as "most impactful" on reach and durability grounds, even though Project A has the cleaner percentage, and that trade-off is named explicitly rather than hidden.

Trade-offs and pitfalls

• Picking the project with the single biggest reported percentage without checking how narrow its scope was is a common overclaim.
• Confusing "impactful to me personally" with "impactful to the business" weakens the answer under questioning.
• Presenting a proxy metric as if it were a measured causal result erodes credibility once challenged.
• Failing to acknowledge a plausible rival project when asked invites doubt about the whole answer.

Direct answer

A trie (prefix tree) stores strings by sharing common prefixes as a path through a tree of characters: each node holds child pointers keyed by the next character, plus a marker for "a word ends here". insert, search, and startsWith all walk that path one character at a time, so each costs $O(L)$ where $L$ is the length of the word or prefix, independent of how many other words are stored. That's exactly what beats a hash set once the workload shifts to prefix queries: a hash set can tell you whether one exact string is a member in $O(L)$, but it has no way to answer "give me everything starting with pre" except scanning every stored string.

Approach

• Each TrieNode holds a dictionary of child nodes keyed by character, plus an is_word flag.
• insert(word): walk from the root, creating a child node for each character not already present, then mark the final node's is_word as true.
• search(word): walk the same path; if any character is missing, the word isn't stored. If the path exists, the word is present only if the final node's is_word is true (this is what distinguishes an exact match from merely being a prefix of something else).
• startsWith(prefix): identical walk, but the answer is simply whether the path exists at all; is_word is irrelevant.

class TrieNode:
    __slots__ = ("children", "is_word")

    def __init__(self):
        self.children: dict[str, "TrieNode"] = {}
        self.is_word = False


class Trie:
    def __init__(self):
        self.root = TrieNode()

    def insert(self, word: str) -> None:
        node = self.root
        for ch in word:
            if ch not in node.children:
                node.children[ch] = TrieNode()
            node = node.children[ch]
        node.is_word = True

    def _walk(self, prefix: str):
        node = self.root
        for ch in prefix:
            if ch not in node.children:
                return None
            node = node.children[ch]
        return node

    def search(self, word: str) -> bool:
        node = self._walk(word)
        return node is not None and node.is_word

    def startsWith(self, prefix: str) -> bool:
        return self._walk(prefix) is not None


if __name__ == "__main__":
    trie = Trie()
    trie.insert("apple")
    print(trie.search("apple"))     # True
    print(trie.search("app"))       # False: "app" was never inserted as a word
    print(trie.startsWith("app"))   # True: it's a valid prefix path
    trie.insert("app")
    print(trie.search("app"))       # True: now it's an inserted word too

Running this prints True, False, True, True, showing the exact distinction between a prefix existing in the tree and a full word being marked at that node.

Key points

• Sharing prefixes is the whole benefit: "app", "apple", and "application" only pay for the divergent suffixes once "app" has been walked.
• Trie versus hash table, concretely: reach for a trie when the workload needs prefix queries, autocomplete, or longest-prefix matching (for example IP routing or URL routing tables), since a hash set has no ordering by prefix at all. Reach for a hash set when you only ever need exact-match membership and words rarely share prefixes, since a trie pays a real per-character node overhead that a flat hash set avoids.
• Deletion (not shown above) needs care: unmark is_word at the target node, then optionally prune nodes back up toward the root, but only while a node has no children and isn't itself marking a shorter stored word.

Complexity

insert: $O(L)$ time, up to $O(L)$ new nodes in the worst case (no shared prefix). search: $O(L)$ time, $O(1)$ extra space. startsWith(prefix): $O(P)$ time where $P$ is the prefix length. Overall trie space is $O(\text{total characters across all stored words})$ in the worst case, less whenever words share prefixes.

Edge cases

• Empty string: insert("") marks the root itself as a word; search("") and startsWith("") should both be true afterward.
• A prefix longer than any stored word simply fails the walk partway through and returns the correct negative.
• Re-inserting the same word is idempotent (no duplicate storage, is_word just gets set again).
• Large alphabets (Unicode) increase the practical memory cost per node since the child dictionary can hold far more distinct keys; a compressed trie (radix/PATRICIA tree, collapsing single-child chains) reduces node count when words rarely branch.

Direct answer: To make eventual consistency between service A and B idempotent and reconciliation-friendly, service A publishes events with a stable event ID (or a monotonic sequence number per entity), service B's consumer deduplicates on that ID before applying any change, and a periodic reconciliation job independently compares A's and B's views to catch and repair anything that slipped through despite the idempotency guarantees.

Structured elaboration

Idempotent event processing on the consumer side. Every event from A carries a stable identifier; B's consumer checks (atomically, alongside applying the event) whether that ID has already been processed, using the same "dedup record plus the actual state change in one transaction" discipline as any idempotent write. This is what makes at-least-once delivery (which any reasonable messaging setup between A and B will actually provide) safe: redelivery is a no-op rather than a duplicate application.

Preserving ordering where necessary. If events for the same entity must be applied in order (e.g. "created" before "updated" before "deleted"), B's consumer needs either a strictly-ordered delivery channel per entity (partition by entity ID) or an explicit sequence number in each event that B checks against the last-applied sequence for that entity, rejecting or buffering an out-of-order arrival rather than applying it prematurely.

Supporting replays. Because B's state can, despite everything, still drift from A's (a bug, an extended outage, a schema-migration mistake), the design should support REPLAYING A's full event history into B from scratch (or from a checkpoint) to rebuild B's view, which requires A to retain (or be able to regenerate) its event history for at least as long as any realistic replay window, and requires B's apply logic to be safe to run repeatedly over the same events (which it already is, by the idempotency design above).

Reconciliation as the safety net, not the primary mechanism. A periodic job independently compares A's and B's data (via checksums, row counts, or a full diff on a schedule appropriate to the data's size and criticality) and either auto-repairs small, well-understood divergences or flags larger ones for human review. This is deliberately a SEPARATE mechanism from the event-driven sync path, its job is to catch failures of that path (a dropped event no retry ever recovered, a bug in the consumer's apply logic), not to be the primary way B stays in sync (that would defeat the point of event-driven propagation in the first place).

Worked example. Service A (an Orders service) publishes OrderUpdated{order_id, sequence, payload} events. Service B (a search index) consumes them, checking (order_id, sequence) against the last sequence it applied for that order, skipping (as an idempotent no-op) any event with a sequence it's already seen or older, and buffering (briefly) any event that arrives out of order, applying it once the gap is filled or timing it out into a "request full replay for this order_id" fallback if the gap doesn't close. Nightly, a reconciliation job compares a sample (or full set, for smaller datasets) of orders between A's source of truth and B's index, flagging any order where B's data doesn't match A's for investigation, this is how the team discovered a bug where B's consumer was silently dropping events during a brief scaling event, well before any customer noticed stale search results.

Trade-offs and pitfalls. Skipping the reconciliation job because "the event pipeline is reliable" is a common and risky shortcut, event-driven consistency mechanisms fail in ways that are often invisible until reconciliation (or a customer complaint) surfaces them, since a missed event usually produces no error, just quietly stale data.

My approach balances clarity, empathy, and actionable guidance so reviews improve the system and grow the author — not attack them.

Steps I follow:

• Start positive: call out what’s working (context + intent).
• Focus on code/design, not the person: reference specific lines, components, or diagrams.
• Use evidence and impact: explain why something matters for reliability, performance, or maintainability.
• Offer concrete alternatives or tests: show how to fix or validate.
• Invite dialogue: ask clarifying questions and offer pairing/mentorship.
• Close with encouragement: acknowledge effort and next steps.

Example review comment using SBI (Situation–Behavior–Impact):

Situation: In the new Spark ingestion job (etl/ingest_spark.py), you coalesced data before writing to the lake.
Behavior: Coalescing to 1 partition in the mapPartitions stage reduces parallelism and caused a long write time on large tables.
Impact: This increases pipeline latency and risks timeouts during peak loads, which could delay downstream dashboards.

Suggested next step: consider writing with dynamic partitioning or using repartition(num_partitions) based on executors; add a perf test with a representative dataset. Happy to pair to pick an appropriate partitioning strategy.

Direct answer

Track promotion redemptions with three tables: promotions (the rule definition), promotion_assignments (which users are eligible for which promotion), and promotion_redemptions (which assignments were actually used), so that redemption rate is a simple ratio between the last two tables.

Structured elaboration

• promotions(promotion_id PK, code, discount_type, discount_value, is_one_time_use, valid_from, valid_to).
• promotion_assignments(assignment_id PK, promotion_id FK, user_id FK, assigned_at): one row per user made eligible for a promotion, whether by targeting, opt-in, or automatic enrollment.
• promotion_redemptions(redemption_id PK, assignment_id FK, order_id FK, redeemed_at, is_one_time_use): one row per actual use. The is_one_time_use column is a copy of the flag from promotions, captured at redemption time so the one-time-use rule can be enforced with a partial unique index scoped to this table alone (a unique index cannot reference columns on another table, so the flag has to be denormalized onto the redemptions row itself to be enforceable this way).

Metrics fall out directly: redemption_rate = COUNT(DISTINCT promotion_redemptions.assignment_id) / COUNT(DISTINCT promotion_assignments.assignment_id) per promotion, and time_to_redemption = redeemed_at - assigned_at, averaged per promotion.

Worked example

CREATE TABLE promotions (
  promotion_id   BIGINT PRIMARY KEY,
  code           TEXT NOT NULL UNIQUE,
  discount_value NUMERIC(10,2) NOT NULL,
  is_one_time_use BOOLEAN NOT NULL DEFAULT TRUE
);

CREATE TABLE promotion_assignments (
  assignment_id  BIGINT PRIMARY KEY,
  promotion_id   BIGINT NOT NULL REFERENCES promotions(promotion_id),
  user_id        BIGINT NOT NULL,
  assigned_at    TIMESTAMP NOT NULL,
  UNIQUE (promotion_id, user_id)
);

CREATE TABLE promotion_redemptions (
  redemption_id  BIGINT PRIMARY KEY,
  assignment_id  BIGINT NOT NULL REFERENCES promotion_assignments(assignment_id),
  order_id       BIGINT NOT NULL,
  redeemed_at    TIMESTAMP NOT NULL,
  is_one_time_use BOOLEAN NOT NULL   -- copied from promotions.is_one_time_use when the redemption is written
);

-- Enforces "at most one redemption per assignment" only for assignments flagged
-- one-time-use; multi-use promotions are free to redeem the same assignment
-- more than once.
CREATE UNIQUE INDEX one_time_redemption_uq
  ON promotion_redemptions (assignment_id)
  WHERE is_one_time_use;

This was verified in sqlite3 (which supports partial indexes): for a one-time-use promotion, a second INSERT referencing the same assignment_id is correctly rejected by the partial unique index; for a non-one-time-use promotion (is_one_time_use = false), a second redemption against the same assignment_id correctly succeeds, since that row falls outside the partial index's WHERE clause. A plain, unconditional UNIQUE constraint on assignment_id (with no WHERE clause) would have blocked legitimate repeat redemptions for multi-use promotions too, which is why the constraint has to be partial rather than blanket.

Trade-offs and pitfalls

• Concurrency is the real risk with one-time-use promotions: two simultaneous checkout requests for the same user and promotion could both pass an application-level "already redeemed?" check before either commits; the partial UNIQUE index is what actually prevents the double-redemption race, by making the database itself reject the second insert rather than relying on a check-then-act race in application code.
• The is_one_time_use value on promotion_redemptions is a denormalized copy of the flag on promotions, captured at write time; if the promotion's flag ever changes after assignments already exist, already-written redemption rows keep whatever flag they were written with, so a promotion-level flag change does not retroactively tighten or loosen enforcement on rows written before the change.
• For promotions with stacking rules, conditional eligibility (new customer only, minimum basket size), expiration, and partial refunds, this schema is a floor, not a ceiling: those rules typically live in a separate eligibility-evaluation layer that reads promotions and the customer/order context at checkout time, rather than being encoded as extra columns on these three tables, because the rules themselves change far more often than the redemption-tracking shape does.
• Redemption rate as defined here silently excludes users who were never assigned in the first place; if the real question is "what fraction of ALL customers used this promotion," you need to join against the full customer base, not just promotion_assignments, which measures conversion only among those who were targeted.

Direct answer

Make learning bounded, deliberate and tied to decisions: a small, fixed slice of time, a shared view of which technologies matter, and time-boxed experiments that end in a written decision. The distraction comes from unbounded curiosity, so I would put limits on how much is explored at once and require every exploration to answer a question the team actually faces.

Structured elaboration

1. A fixed, small budget of time. For example half a day each fortnight per person (stated openly, and protected in planning), so learning never competes ad hoc with delivery.

2. A technology radar. A shared list that places each tool in one of four rings: adopt (proven, use it by default), trial (use it on one real, low-risk project to learn), assess (worth a short look, not yet used for real work), hold (do not start anything new with it, for example because it is being retired or has caused problems; Thoughtworks' public Technology Radar, which popularised these rings, now labels its fourth ring "Caution", and many teams keep "hold" for their own radar). It gives the team a common answer to "should we look at this?" and stops repeated debates.

3. Time-boxed spikes. A spike is a short experiment to answer one question. Rules: a named question, a time limit (say two days), a limited number of active spikes (a work-in-progress limit: for example at most two spikes running at once, and a new one starts only when one finishes), and a short written outcome (adopt, trial, drop, with reasons).

4. Rotating scout. One person per quarter tracks the landscape and reports back, so all eight people are not scanning news.

5. Just-in-time versus just-in-case. Learn deeply what you will use in the next quarter or two. Keep the rest at awareness level from the scout's summary. Example: if the team migrates to a new database next quarter, learn that database properly now (just-in-time); a new front-end framework nobody plans to use only needs a paragraph in the scout's summary (just-in-case learning means learning something ahead of any concrete need, in case it is wanted later; it is kept to awareness level and deep study waits until a real need appears).

6. Share once. A short demo or note to the team, so one person's spike benefits all of them.

Worked example

Team of 8, half a day (4 hours) per person every fortnight. A fortnight is 10 working days = 80 hours, so learning is 4/80 = 5% of each person's time, or 8 x 4 = 32 team hours per fortnight. Say a new deployment tool appears. The scout adds it to the radar under "assess". Two people run a two-day spike against one real service, and the note says: works, but migration effort is high, so "trial" only on the next new service. No one else's roadmap moved. Check the budget: two people x two days x 8 hours = 32 hours, which is exactly the whole team's pool for one fortnight (8 x 4 = 32), so the spike is funded by pooling the team's slice for that fortnight, and only one such spike fits per fortnight, which is another reason to cap active spikes.

Trade-offs & pitfalls

• Resume-driven adoption: adopting tools because they are new or look good on a CV, not because the team needs them. Require the spike to name the problem it solves.
• Learning time that vanishes under deadline pressure. If it disappears at the first crunch, it was never protected. Track whether it is actually taken.
• Everyone learning everything wastes effort. Specialise deliberately.
• Too many experiments running together cause the distraction you are trying to avoid. Limit them.
• If delivery is already at risk, temporarily reduce the slice openly rather than pretending it continues.

Direct answer

A high-stakes, multi-quarter investment with no direct revenue payoff needs everything a smaller business case needs, plus three things a smaller case can skip: a phased roadmap with milestones so the funder isn't asked to trust a single go or no-go moment months out, a range instead of a point estimate on the financial model so the pitch survives being challenged, and a rehearsed answer to the specific objections a skeptical stakeholder will raise. The core discipline is the same as any business case, name the problem in the funder's terms, cost it honestly, commit to metrics up front, it is just applied at a scale where one wrong assumption compounds over quarters instead of weeks.

Structured elaboration

1. Problem statement, quantified. For an investment with no direct revenue line, name the cost of not acting: an automated data-validation layer, for instance, is justified by the cost of the incidents and rework it prevents, not by new revenue it generates.
2. Financial modeling with a range. Model costs (engineering time, infrastructure, any headcount) and the benefit stream (savings, avoided incident cost, avoided rework) across at least two scenarios, conservative and expected, and state the key assumptions driving the gap between them. A funder shown only one number will spend the meeting arguing with it instead of engaging with the plan.
3. Risk assessment with mitigations. At multi-quarter scale, add the risk that the investment itself stalls or gets deprioritized partway through; the mitigation is usually the phased roadmap in the next step, not a one-line "we will manage risk."
4. Phased roadmap with milestones. Break the multi-quarter effort into phases that each produce a visible, independently valuable checkpoint (a pilot on one domain, then a second, then full rollout), so the funder can see progress and course-correct before the full spend is committed, rather than being asked for blind trust across the whole timeline at once.
5. Success metrics and objection handling. Set the KPIs (key performance indicators, the small number of measures you will actually report against) before the first phase starts, and prepare your answer to the two or three pushbacks you know are coming: "why not just add headcount instead of building this," "how do we know phase 2 won't slip like phase 1 might," and "what's the cost if we stop after phase 1." Answering these before they're asked is what separates a case that survives a skeptical room from one that doesn't.

Worked example

Take an automated data-validation layer proposed to replace a growing volume of manual data-quality review. Current state: manual review costs an estimated $40,000 a month in analyst time and still lets an estimated 3% of bad records through, each causing rework estimated at $500. On a monthly volume of 200,000 records, that is 200,000 times 3%, or 6,000 bad records slipping through, at $500 each, or $3,000,000 a month in downstream rework, a rounded, illustrative figure for the pitch, not a claimed measured cost, and the actual justification for the investment.

Proposed investment: build over two quarters. Phase 1 (one quarter, one data domain) is 4 engineers times 12 weeks, or 48 engineer-weeks. Phase 2 (full rollout) is 3 engineers times 12 weeks, or 36 engineer-weeks. Total 84 engineer-weeks at $10,000 per engineer-week fully loaded is $840,000, plus $8,000 a month in ongoing validation-service infrastructure, or $96,000 a year.

Benefit modeling, conservative case: the layer catches 60% of the bad records the manual process misses, avoiding 60% of $3,000,000, or $1,800,000 a month in rework, while manual-review effort drops by half, saving $20,000 a month, for a conservative monthly benefit of $1,820,000. Expected case: catches 85% of missed records, avoiding $2,550,000 a month plus the same $20,000 manual-review saving, for $2,570,000 a month. Even the conservative case pays back the $840,000 build cost in under a month, which is the number to lead with, since it survives a skeptic assuming the pessimistic scenario is the real one.

Trade-offs and pitfalls

The most common wrong turn at this scale is presenting the full multi-quarter ask as one indivisible decision: funders resist committing months of spend on a single point of trust, and a phased roadmap with real checkpoints is what earns the right to keep going after phase 1. A second is showing only the expected case: once a stakeholder finds one optimistic assumption, they discount the entire pitch, so a conservative-case number that still clears the bar is far more persuasive than a bigger optimistic one. A third is treating objection handling as improvisation; the two or three hardest questions are predictable, and walking in without answers to them reads as not having stress-tested your own plan. Finally, a roadmap with no independently valuable milestone (a phase 1 that produces nothing usable on its own) gives the funder no evidence to renew the investment on, and that is usually where multi-quarter initiatives get quietly killed at the first budget review after launch.

Direct answer

Handle genuinely missing reviews before touching the text, normalize unicode to a consistent form before lowercasing or stripping punctuation (order matters), and do the whole thing with vectorized .str accessor methods rather than .apply or a Python loop, since at tens of millions of rows that choice alone is the difference between minutes and hours.

Structured elaboration, in the order I'd apply it

1. Missing reviews first. Check df['review'].isna() and decide whether to drop those rows for the bag-of-words model or keep them with an explicit is_missing indicator, since "left no review" can itself be predictive (it may correlate with rating). Don't conflate a real NaN (not-a-number) with placeholder strings an earlier pipeline stage may have written, like 'n/a' or 'none'; check for both explicitly.
2. Unicode normalization before anything else touches the text. Curly ("smart") quotes and accented characters otherwise get mangled by later regex steps, or split what should be one word into two different tokens. Unicode NFKD normalization decomposes an accented character into a plain base letter plus a separate combining accent mark, which you can then strip:

import pandas as pd

df = pd.DataFrame({'review': [
    "Great product, LOVED it!!",
    "Terrible... würde nie wieder kaufen",
    None,
]})

df['review_clean'] = (
    df['review']
    .str.normalize('NFKD')
    .str.encode('ascii', 'ignore')
    .str.decode('ascii')
)

3. Lowercase and strip punctuation with vectorized .str methods, never a Python-level loop:

df['review_clean'] = df['review_clean'].str.lower()
df['review_clean'] = df['review_clean'].str.replace(r'[^\w\s]', ' ', regex=True)
df['review_clean'] = df['review_clean'].str.replace(r'\s+', ' ', regex=True).str.strip()

Worked example

Two reviews that look like they should end up as the same tokens, but do not: one with a curly apostrophe from the start, one with a plain straight apostrophe from the start.

import pandas as pd

df = pd.DataFrame({'review': [
    "Cafe’s GREAT!! Best review ever",   # curly apostrophe
    "Cafe's great too, ever",                # straight apostrophe
]})

df['review_clean'] = (
    df['review']
    .str.normalize('NFKD')
    .str.encode('ascii', 'ignore')
    .str.decode('ascii')
)
print(df['review_clean'].tolist())

df['review_clean'] = df['review_clean'].str.lower()
df['review_clean'] = df['review_clean'].str.replace(r'[^\w\s]', ' ', regex=True)
df['review_clean'] = df['review_clean'].str.replace(r'\s+', ' ', regex=True).str.strip()
print(df['review_clean'].tolist())

Output (verified by running this exact code):

['Cafes GREAT!! Best review ever', "Cafe's great too, ever"]
['cafes great best review ever', 'cafe s great too ever']

After NFKD plus ascii-encode/ignore: the curly-apostrophe review becomes "Cafes GREAT!! Best review ever", the apostrophe is gone with nothing left in its place. NFKD has no decomposition for typographic quote marks, so ascii-ignore just deletes the character outright. The straight-apostrophe review is untouched by this step (it was already plain ASCII).

After lowercasing, punctuation-strip, and whitespace collapse: the curly-apostrophe review ends as "cafes great best review ever", one token, cafes. The straight-apostrophe review ends as "cafe s great too ever", because the punctuation-strip regex replaces the surviving apostrophe with a space, splitting cafe's into two tokens, cafe and s.

So this pipeline does not make the two spellings converge to the same bag-of-words tokens, which is easy to assume incorrectly. If that convergence matters for your corpus, explicitly map common typographic punctuation to its ASCII equivalent before relying on NFKD, e.g. df['review'].str.replace('’', "'", regex=False), so a curly apostrophe becomes a real apostrophe and both spellings hit the punctuation-strip step identically.

Performance at tens of millions of rows

• Stick to .str accessor methods (vectorized, C-optimized under the hood) instead of .apply(lambda x: ...) or a Python for loop over rows.
• Each .str.replace() call scans the full column and allocates a new Series. Chaining four or five of them means four or five full passes plus several temporary full-length copies of the string column, which is often the real memory bottleneck rather than the final cleaned result. Where practical, combine multiple regex substitutions into fewer passes, or process the column in chunks (pd.read_csv(chunksize=...)) so several full copies are never held in memory at once.
• str.normalize() and complex regexes tend to be the slowest per-character steps. Benchmark on a real sample (e.g. 100k rows) before assuming the full pipeline runs fast enough; don't guess.
• If that is still too slow, look at Dask or Polars for out-of-core or multi-core string processing. For most tens-of-millions-row batch jobs, vectorized pandas .str methods on chunked reads are usually enough on their own.

Trade-offs and pitfalls

• Emojis: decide whether to strip them or keep them as a signal, they survive NFKD/ascii-ignore differently depending on their Unicode form.
• Leftover HTML markup if the reviews were scraped from a webpage needs its own stripping step; NFKD does nothing about <br> tags.
• Non-English reviews: NFKD plus ascii-encoding will silently strip non-Latin scripts (Chinese or Arabic text, for example) down to nothing. If the corpus is multilingual, filter or language-detect before applying ASCII normalization rather than after, or you lose that data with no error raised.

Core services
I would build a platform with a job API, scheduler, quota service, checkpoint store, metadata catalog, and node agents. The scheduler matches jobs to GPU pools, while the quota service enforces team budgets and priorities.

How jobs get compute
A team submits a job spec with requested GPUs, runtime, and a checkpoint policy. The scheduler grants a lease, which is a time-bounded claim on nodes. Workers heartbeat to renew the lease. On completion, failure, or preemption, the lease ends and the GPUs are released automatically.

Controls

• Per-team quotas and project budgets
• Priority classes for urgent training
• Spot first scheduling with fallback to on-demand
• Mandatory checkpoints for long jobs
• Admission control when the cluster is full

Worked example
A 64-GPU run might get 8 workers with 8 GPUs each and a 30-minute renewable lease. If a node fails, the job restarts from the last checkpoint instead of starting over.

This design keeps cost visible, failures recoverable, and shared capacity fair.

Direct answer

When a join key is extremely skewed, salt the hot key into several sub-keys to spread its traffic across multiple partitions or parallel tasks, join against each sub-key's slice, then merge the partial results, rather than accepting that one key's traffic bottlenecks a single task.

Structured elaboration

A naive keyed join sends every record for a given key to the same partition or task, so a small number of extremely hot keys concentrate disproportionate load onto whichever task happens to own them, regardless of how many parallel tasks exist overall. Salting appends a small random or round-robin suffix to the hot key on one side of the join (say, key -> key#0, key#1, ..., key#N), spreading its records across N parallel tasks instead of one; the other side of the join, which may not itself be skewed, needs to be broadcast or replicated across those same N sub-keys so a match is still found regardless of which sub-key a given hot-key record landed on. Pre-aggregation (partially aggregating on one side before the join, when the join is followed by an aggregation anyway) can reduce the volume that needs to flow through the join at all for the hottest keys.

Worked example

Joining a 100-million-distinct-key user stream with a product-updates stream, where a handful of "celebrity" or bot-like users generate a hugely disproportionate share of events: salting those specific hot user keys into, say, 8 sub-keys spreads a single hot user's traffic across 8 parallel tasks instead of concentrating it onto 1, while the (comparatively low-volume) product-updates side is broadcast to all 8 sub-key variants so a match is still found regardless of which sub-key instance processed a given user event.

Trade-offs and pitfalls

Salting only the actually-hot keys (detected via monitoring, not applied blanket to every key) avoids unnecessarily fragmenting and duplicating the non-hot majority of keys' state across multiple tasks for no benefit; applying it universally adds real overhead (state fragmentation, more complex merge logic) to keys that never needed it. Broadcasting the other side of the join to every sub-key variant multiplies that side's memory footprint by the salting factor, a cost that has to be weighed against the throughput gain, especially if the broadcast side itself isn't small.