Day 63: Review – Week 9

Day 63 — Review – Week 9

Coding problem

Solution outline (coding)

• Review HashMap, Trie, Twitter design — verbalize API and complexity.
• Implement one from scratch on paper in 15 minutes.
• Compare to standard library (when you would not roll your own in production).

Time complexity: Varies.

Space complexity: Varies.

class ReviewDay:
  """Practice / review: Review – Week 9."""

  def practice_plan(self):
    return [
      "Pick 2–3 problems from this phase; re-solve timed without notes.",
      "For each: pattern name, time/space complexity, one alternative approach.",
    ]


# Input:  (your choice of problems from this week or phase)
# Output: a short list of gaps to drill before the next session

SQL interview practice

1. Interview question

Companies / track: Review / mixed (see weekly theme)

This is a review / mixed day. Expect SQL that blends data quality, funnels, and metric definitions—the same mix you see across consumer tech and ads analytics.

What you are asked to write (SQL prompt):

Review / mixed week — use the same tables and deliverables as in a standard onsite SQL round.
Summarize your data-structure-like BigQuery tables into a design-doc-style query set: key retrieval latency, version history correctness, and storage growth monitoring.

Tables implied by the prompt:

• Infer schemas from the prompt and state them before coding.

Engine: BigQuery — use its date, array, and approximate functions as documented.

2. Solution outline

• Clarify out loud: result grain (one row per what?), join keys, time zone, and any ORDER BY / LIMIT / tie-breakers.
• Map Review to SQL: say the relational equivalent (e.g. hash map → GROUP BY + key; two pointers → ordered window + filter).
• Arrays / UDFs: UNNEST and offsets for index; say when logic belongs in SQL vs a UDF.
• Structure: CTEs (WITH) — one step per CTE; validate on a tiny slice (counts, nulls, duplicates).

SELECT design_table, AVG(lookup_latency_ms) AS p50_latency
FROM ds_benchmarks
GROUP BY design_table;