BigTech-FAANG-Job-Roadmap — Repo Dump

This file is auto-generated by scripts/dump_repo.py.

Tree

00-START-HERE/
  00-README.md
  01-Targeting-Your-Lane.md
  02-Interview-Loop-At-A-Glance.md
01-FOUNDATIONS/
  00-Foundations-Index.md
  01-DSA-and-Coding.md
  02-Computer-Systems.md
  03-Databases.md
  04-Software-Engineering-Practices.md
  05-Cloud-and-Reliability-Basics.md
02-ROLE-ROADMAPS/
  00-Role-Chooser.md
  01-SWE-Generalist.md
  02-Backend-Engineer.md
  03-Machine-Learning-Engineer.md
  04-Data-Engineer.md
  05-Data-Scientist.md
  06-DevOps-SRE.md
  07-MLOps-Engineer.md
03-INTERVIEWS/
  00-Interview-Index.md
  01-Recruiter-Screen-Playbook.md
  02-Coding-Interview-Playbook.md
  03-System-Design-Interview-Playbook.md
  04-ML-System-Design-Interview.md
  05-SQL-Data-Interview.md
  06-Behavioral-Interview-Playbook.md
  07-Take-Home-and-Project-Interviews.md
  08-Using-AI-Tools-Ethically.md
  09-Interview-Day-Operations.md
04-SYSTEM-DESIGN-LIBRARY/
  00-System-Design-Template.md
  01-Capacity-Planning-Cheatsheet.md
  02-Design-Patterns-and-Failure-Handling.md
  03-Common-Prompts-and-What-They-Test.md
05-ML-MLOPS/
  00-ML-Index.md
  01-ML-Fundamentals-for-Interviews.md
  02-Feature-Engineering-and-Data-Leakage.md
  03-ML-System-Design-Templates.md
  04-ML-Testing-and-ML-Test-Score.md
  05-LLM-Applications-and-Evaluation.md
  06-Monitoring-and-Drift.md
06-DATA/
  00-Data-Index.md
  01-SQL-Patterns.md
  02-Data-Modeling.md
  03-Pipelines-and-Orchestration.md
  04-Data-Quality.md
  05-Streaming-and-Late-Data.md
  06-Cost-and-Performance.md
07-INFRA-DEVOPS/
  00-Infra-Index.md
  01-Linux-Networking-Fundamentals.md
  02-Docker.md
  03-Kubernetes.md
  04-CICD-and-Safe-Rollouts.md
  05-Incident-Response.md
  06-Observability.md
08-CAREER/
  00-Career-Index.md
  01-Resume-LinkedIn-GitHub.md
  02-Applications-and-Networking.md
  03-Interview-Prep-Calendar.md
  04-Offer-Negotiation.md
  05-Company-Archetypes-and-How-to-Prepare.md
  06-Handling-Rejection-and-Iteration.md
README.md
RESOURCES.md
scripts/
  dump_repo.py

Files

00-START-HERE/00-README.md

# Start Here

You can use this repo in two modes:

- **Job search mode (4–12 weeks):** you already know the basics and want to maximize interview performance.
- **Career transition mode (8–24+ weeks):** you’re switching lanes (e.g., DS → DE, Backend → MLE) or returning after a gap.

## What “good” looks like across companies

Different company archetypes value different signals:

- **FAANG / high-growth consumer:** speed + scale tradeoffs, ambiguity handling, crisp communication, strong coding.
- **Enterprise software:** correctness, maintainability, incremental delivery, compatibility, compliance, stakeholder management.
- **Automotive / industrial:** safety mindset, verification culture, long-lived systems, careful risk management, reliability.

Same skills show up everywhere; the **weighting** changes.

## 3-step setup

1. **Pick a lane** (role + level + company archetype)
   - Use [02-ROLE-ROADMAPS/00-Role-Chooser.md](../02-ROLE-ROADMAPS/00-Role-Chooser.md)
2. **Baseline yourself**
   - Do one timed coding interview (45–60 min)
   - Do one “design a service” prompt (45–60 min)
   - Do one behavioral story (15 min)
   - Score yourself using [00-START-HERE/02-Interview-Loop-At-A-Glance.md](02-Interview-Loop-At-A-Glance.md)
3. **Pick a cadence you can sustain**
   - 60–90 min/day beats 6 hours on Sunday.

## The golden rule

Interview prep fails when you optimize for _feeling prepared_ (reading) instead of _being prepared_ (practice under constraints).

Practice should resemble the interview:

- timeboxed
- verbalized thinking
- written tradeoffs
- explicit assumptions
- post-mortem after each session

## A concrete 7-day kickoff plan

This plan is meant to create momentum and reveal the biggest gaps.

Day 1: Choose lane + set scope

- Define target roles/levels and company archetypes.
- Write a one-paragraph “why me” narrative (role fit, projects, domain).
- Pick your core stack (language + infra/cloud).

Day 2: Resume + recruiter pass

- Rewrite resume for readability (one screen = one story).
- Remove ambiguity: add numbers, ownership, and impact.
- Build a 30-second pitch and a 2-minute deeper version.

Day 3: Coding baseline

- 2 problems: one easy/medium, one medium.
- Focus on: correctness, constraints, and clean explanation.

Day 4: System design baseline

- Design a small service (URL shortener / rate limiter / notifications).
- Write requirements and then draw the simplest viable design.

Day 5: Behavioral baseline

- Draft 6 stories: conflict, failure, leadership, ambiguity, deep dive, impact.
- Convert each into: context → actions → results → learnings.

Day 6: Iterate + tighten

- Re-do one coding problem you failed _without looking at the answer_.
- Re-do the same system design prompt with a stronger structure.

Day 7: Mock loop

- 45 min coding + 45 min design + 15 min behavioral.
- Write a post-mortem: top 3 gaps + top 3 strengths.

## Common failure modes (and fixes)

- **Failure:** “I know the topic” but can’t solve under time.
  - **Fix:** timeboxed reps + post-mortems + spaced repetition.

- **Failure:** jumping to architecture without requirements.
  - **Fix:** enforce a template: requirements → constraints → SLOs → design.

- **Failure:** over-indexing on fancy tools.
  - **Fix:** choose boring defaults first; add complexity only for a reason.

- **Failure:** behavioral answers feel generic.
  - **Fix:** use specific numbers, tradeoffs, and your decision criteria.

00-START-HERE/01-Targeting-Your-Lane.md

# Targeting Your Lane (Role × Level × Company)

If you try to prepare for “everything”, you end up prepared for nothing.

Define your lane using three axes:

## 1) Role

- **SWE (generalist):** coding + fundamentals + some design.
- **Backend:** APIs, storage, distributed systems, reliability.
- **MLE:** modeling + data + production ML engineering.
- **DE:** data modeling, pipelines, orchestration, quality, cost.
- **DS:** experimentation, causal thinking, metrics, storytelling.
- **DevOps / SRE:** operability, incident response, automation, systems.
- **MLOps:** ML platforms, deployment, monitoring, reliability of ML systems.

## 2) Level

Levels differ mostly in **scope** and **judgment**.

- **Junior/Entry:** correctness + learning + basic collaboration.
- **Mid:** ownership of components, good debugging, shipping reliably.
- **Senior:** ambiguity handling, system-level thinking, influence.
- **Staff+ (where applicable):** multi-team scope, strategy, long-term risk management.

## 3) Company archetype

### FAANG / high-growth

- You’ll be evaluated on communication under ambiguity, speed of iteration, and scale tradeoffs.
- System design tends to probe: capacity planning, cache/queue patterns, failure handling.

### Enterprise software

- Expect deeper questions on maintainability, integration, migration, and reliability.
- “How do you evolve this safely?” matters as much as “how do you build it?”.

### Automotive / industrial

- Risk and safety mindset matters; verification culture is common.
- Expect emphasis on reliability, requirements clarity, and disciplined engineering.

## Lane definition template

Write this down before you start.

- Target roles:
- Target level:
- Target company archetypes:
- Primary geography/time zone:
- Interview language:
- Primary tech stack (language + cloud):
- Dealbreakers (on-call, relocation, remote, domain):

## What to do if you’re not sure

Pick a “default lane” that maximizes optionality:

- SWE/Backend at mid-level
- strong coding + foundational system design
- basic cloud + observability
- 6 strong behavioral stories

That lane transfers well into MLE/DE/DevOps once fundamentals are strong.

00-START-HERE/02-Interview-Loop-At-A-Glance.md

# Interview Loop at a Glance

Most loops are some variation of:

1. **Recruiter screen** (fit + logistics)
2. **Technical screen** (coding / SQL / ML / infra)
3. **Onsite / virtual onsite** (multiple rounds)
4. **Hiring committee / debrief** (calibration)

## What interviewers are really scoring

Across companies, the scoring typically reduces to:

- **Correctness:** you can produce correct solutions and validate them.
- **Reasoning:** you can explain tradeoffs and constraints.
- **Signal-to-noise:** you communicate without wandering.
- **Engineering maturity:** you build maintainable systems, not just demos.
- **Ownership:** you take responsibility for outcomes.

## Coding round signals

Good

- Clarifies requirements and constraints early.
- Chooses an approach that fits time and complexity.
- Writes clean code with tests / edge cases.
- Narrates tradeoffs and alternative approaches.

Bad

- Starts coding without clarifying input/output.
- Overcomplicates: premature optimization, clever tricks.
- Can’t reason about complexity or edge cases.

## System design round signals

Good

- Defines requirements and makes them measurable (SLOs, throughput, latency).
- Proposes a simple baseline architecture first.
- Identifies bottlenecks and failure modes.
- Connects tradeoffs to product goals.

Bad

- Talks in buzzwords without data flows.
- No capacity planning.
- No failure handling or operational plan.

## Behavioral round signals

Good

- Uses concrete stories with impact and learning.
- Shows judgment and ownership (not blame).
- Demonstrates collaboration and conflict handling.

Bad

- Generic STAR with no specifics.
- No reflection on what you’d do differently.

## How loops differ by role

- **Backend:** more depth in storage, distributed systems, APIs, reliability.
- **MLE/MLOps:** production readiness, data issues, monitoring, deployment patterns.
- **DE:** SQL, modeling, pipelines, orchestration, cost, quality.
- **DS:** experimentation, metrics, ambiguity-to-plan, stakeholder influence.
- **DevOps/SRE:** incident response, operability, automation, systems fundamentals.

## How loops differ by company archetype

- **FAANG/high-growth:** fast iteration, scale assumptions, structured rubric, strong calibration.
- **Enterprise:** integration/migration, governance, long-lived systems, stakeholder nuance.
- **Automotive/industrial:** safety mindset, verification, traceability, risk control.

## Quick self-scoring rubric (0–2)

Use this after every practice session.

- Requirements clarified: 0/1/2
- Correct solution delivered: 0/1/2
- Tradeoffs explained: 0/1/2
- Edge cases tested: 0/1/2
- Communication clarity: 0/1/2
- Post-mortem written: 0/1/2

If you’re consistently below 8/12, shorten scope and increase reps.

01-FOUNDATIONS/00-Foundations-Index.md

# Foundations Index

If you’re targeting multiple company archetypes, foundations are your unfair advantage: they transfer between domains and reduce interview variance.

This folder is split into foundations that show up in _most_ loops:

- Coding fundamentals (data structures, algorithms, complexity)
- Computer systems (OS, networking)
- Databases (modeling, indexing, transactions)
- Engineering craft (testing, debugging, maintainability)
- Cloud + reliability basics

## How to study foundations efficiently

### The “practice loop”

For each topic, do a weekly loop:

1. Read 1–2 short references
2. Implement 1–3 small exercises
3. Do 1 timed interview-style prompt
4. Write a post-mortem: what failed, why, what rule prevents it next time

### What _not_ to do

- Don’t binge-watch content without doing reps.
- Don’t memorize solutions; memorize _problem types_ and _decision rules_.

## Company archetype weighting (rough)

- **FAANG/high-growth:** strongest weight on coding + system design communication.
- **Enterprise:** weight shifts toward maintainability, migrations, and operating in constraints.
- **Automotive/industrial:** higher emphasis on correctness, traceability, and risk management.

## Recommended order (4 weeks)

Week 1

- Coding mechanics + complexity
- OS basics (process vs thread, memory)

Week 2

- Networking (HTTP, TCP, latency)
- Databases (indexes, transactions)

Week 3

- Reliability basics (SLOs, retries, timeouts)
- Debugging + testing practices

Week 4

- Cloud primitives (compute, storage, queues)
- Combine topics in system design exercises

## Next pages

- [01-FOUNDATIONS/01-DSA-and-Coding.md](01-DSA-and-Coding.md)
- [01-FOUNDATIONS/02-Computer-Systems.md](02-Computer-Systems.md)
- [01-FOUNDATIONS/03-Databases.md](03-Databases.md)
- [01-FOUNDATIONS/04-Software-Engineering-Practices.md](04-Software-Engineering-Practices.md)
- [01-FOUNDATIONS/05-Cloud-and-Reliability-Basics.md](05-Cloud-and-Reliability-Basics.md)

01-FOUNDATIONS/01-DSA-and-Coding.md

# DSA & Coding (Interview-Grade)

The goal isn’t “know all algorithms”. The goal is to reliably:

- identify the right approach quickly
- implement correctly under time
- communicate tradeoffs

## Core patterns you must recognize

### Arrays / strings

- Two pointers
- Sliding window
- Prefix sums / difference arrays
- Sorting + scanning

### Hashing

- Frequency maps
- De-dup and membership
- “Seen set” to break cycles

### Trees / graphs

- BFS vs DFS decision rules
- Topological ordering (DAG)
- Shortest path when edges have weights

### Dynamic programming

- Define state + transition + base case
- Start with 2D DP, then optimize
- If stuck: recursion + memo first

## How interviewers evaluate you

They’re typically scoring:

- correctness and edge cases
- complexity reasoning
- clarity (naming, structure)
- debugging ability

## A 45-minute coding process

1. Restate problem and confirm inputs/outputs
2. Identify constraints and edge cases
3. Propose 1–2 approaches; pick one
4. Write code in small compilable chunks
5. Test with 2–3 cases (happy path + edge)
6. State complexity and any follow-ups

## Common failure cases

- **Off-by-one bugs** in loops/pointers
  - Fix: write invariants (what’s true each iteration)

- **Wrong data structure** (e.g., list instead of set)
  - Fix: ask “do I need membership in O(1)?”

- **DP panic**
  - Fix: first write recursion with memo; only then convert to bottom-up

## Practice plan (minimum effective dose)

- 3 days/week: 1 medium problem timed (45–60 min)
- 2 days/week: 30 min pattern drill (same pattern, different problems)
- 1 day/week: redo a previously-missed problem from scratch

## Notes by company archetype

- **FAANG:** speed + clear communication; they expect structured thinking.
- **Enterprise:** still cares about correctness, but may value maintainability and tests more.
- **Automotive/industrial:** correctness and disciplined reasoning can outweigh “flashy” speed.

01-FOUNDATIONS/02-Computer-Systems.md

# Computer Systems (OS + Networking)

Systems knowledge matters because many “senior” bugs are systems bugs: timeouts, memory, contention, caching, and partial failure.

## OS basics you should be able to explain

- process vs thread
- context switching and why too many threads hurt
- memory: stack vs heap, GC basics (if using managed languages)
- IO vs CPU bound
- locks vs lock-free intuition (don’t overclaim)

### Interview-grade mental models

- Latency is not just “slow code”; it’s often queueing.
- Most outages are dependency + retry storms + timeouts misconfigured.

## Networking basics you should be able to explain

- DNS and where caching happens
- TCP vs UDP (and why HTTP/3 exists)
- TLS basics: what it gives you, handshake cost, cert rotation
- HTTP semantics: idempotency, retries, timeouts

## Practical debugging checklist

When a service is “slow”:

1. Is it CPU bound? (high CPU)
2. Is it IO bound? (waiting on DB, remote calls)
3. Is it lock/contention bound? (high latency but low CPU)
4. Is it GC bound? (stop-the-world pauses)
5. Is it saturation? (queues growing, p95 exploding)

## Company archetype differences

- **FAANG/high-growth:** expects you to reason about tail latencies and tradeoffs.
- **Enterprise:** expects you to manage compatibility, change control, and safe rollouts.
- **Automotive/industrial:** expects careful risk thinking, testing discipline, and verification mindset.

01-FOUNDATIONS/03-Databases.md

# Databases (Interview Foundations)

Databases show up in almost every role: they are the “ground truth” and the bottleneck.

## Concepts to master

- Data modeling: entities, relationships, normalization vs denormalization
- Indexes: what they accelerate and what they cost
- Transactions: atomicity and isolation; practical pitfalls
- Replication and read scaling
- Partitioning/sharding and hotspots

## “Good enough” SQL knowledge

- join types and when they change row counts
- group by + having
- window functions basics
- explain plans (conceptually)

## Common failure modes

- **Index cargo cult:** adding indexes everywhere
  - Cost: write amplification, storage, slower inserts/updates

- **Hot partition:** all traffic hits one shard
  - Fix: choose partition keys with access patterns in mind

- **Ignoring isolation:** phantom reads / lost updates
  - Fix: pick correct isolation/locking approach, use idempotency

## Archetype emphasis

- **FAANG:** expects reasoning about scale + consistency.
- **Enterprise:** expects migrations, compatibility, and operational constraints.
- **Automotive/industrial:** expects reliability, traceability, sometimes stricter governance.

01-FOUNDATIONS/04-Software-Engineering-Practices.md

# Software Engineering Practices (That Interviewers Notice)

Strong candidates write code that is correct _and_ maintainable under change.

## Practices that transfer to interviews

- Name things clearly
- Keep functions small with single responsibility
- Validate inputs and handle errors explicitly
- Write small tests / examples for edge cases

## Testing mindset

In interviews, you usually can’t write full test suites, but you can show the mindset:

- boundary cases
- invariants
- “what could go wrong in production?”

## Debugging approach

1. Reproduce with smallest case
2. Form a hypothesis
3. Add one probe/log/print to confirm or refute
4. Fix + prevent (guardrail)

## Common failure modes

- Overengineering (patterns before problems)
- No error handling (happy path only)
- Inconsistent naming and messy control flow

01-FOUNDATIONS/05-Cloud-and-Reliability-Basics.md

# Cloud & Reliability Basics

Cloud interviews are rarely about vendor trivia. They’re about architecture and operability.

## Primitive building blocks

- compute: VMs, containers, serverless
- storage: object, block, file
- databases: relational, key-value, document
- messaging: queues, pub/sub, streams
- networking: VPC, load balancing, DNS

## Reliability building blocks

- timeouts and retries (with backoff)
- idempotency
- circuit breaking / bulkheads
- graceful degradation
- rate limiting
- observability (metrics/logs/traces)

## SLO-first thinking

- Define user-facing SLOs (latency, availability, freshness)
- Design for the tails (p95/p99)
- Plan for incidents (runbooks, rollback, alerts)

## Failure mode you must avoid

**Retry storm:** dependency slows → callers retry aggressively → dependency gets worse.

Mitigations:

- cap retries
- add jitter
- use timeouts
- implement circuit breakers
- shed load early

02-ROLE-ROADMAPS/00-Role-Chooser.md

# Role Chooser

This chooser helps you pick a lane based on what you enjoy and what companies will expect.

## Quick decision guide

Choose **Backend Engineer** if you like:

- APIs, data modeling, performance
- distributed systems tradeoffs
- reliability and operability

Choose **MLE** if you like:

- modeling + data + iteration
- product metrics and model quality
- shipping models to production (not just notebooks)

Choose **MLOps** if you like:

- platforms, pipelines, deployment, monitoring
- reliability for ML systems
- enabling other teams to ship models

Choose **Data Engineer** if you like:

- SQL + modeling + pipelines
- cost, quality, lineage
- making data reliable for analytics/ML

Choose **Data Scientist** if you like:

- experimentation, causal reasoning
- stakeholder influence
- turning messy questions into measurable decisions

Choose **DevOps/SRE** if you like:

- incidents and reliability
- automation, CI/CD, infra as code
- systems performance and debugging

Choose **SWE generalist** if you want optionality:

- strong coding + fundamentals
- enough design to pass mid-level loops
- later specialization based on projects

## Interview expectations by lane

- SWE/Backend: coding + system design + behavioral
- MLE: coding (varies) + ML theory + ML system design + behavioral
- MLOps/DevOps/SRE: systems + ops + design + behavioral
- DE: SQL + pipelines + modeling + behavioral
- DS: case studies + stats + experiments + behavioral

## Fast sanity test

If you can’t describe (in 2 minutes) what you ship and how it runs in prod, you’re not ready for senior roles in Backend/MLE/MLOps/SRE.

## Next steps

Pick the role page in this folder and follow its plan.

02-ROLE-ROADMAPS/01-SWE-Generalist.md

# SWE (Generalist) Roadmap

Generalist SWE is the highest-optionality path: strong coding + fundamentals + enough design to build and operate real services.

## What interviewers expect

### Entry / Junior

- solid coding fundamentals
- basic debugging and correctness
- coachability and clear communication

### Mid

- reliable delivery: can own components end-to-end
- good engineering judgment (tests, API design)
- basic system design for small services

### Senior+

- ambiguity handling: can turn vague goals into a plan
- system-level tradeoffs and operational mindset
- influence across teams

## Skill pillars (in priority order)

1. Coding fundamentals (patterns + correctness)
2. Systems basics (networking, OS, databases)
3. System design basics (requirements → design → failure handling)
4. Engineering craft (testing, maintainability, reading code)
5. Behavioral stories (ownership, conflict, impact)

## 8-week plan (job search mode)

Week 1–2: Coding + foundations

- 3 timed coding problems/week + mistake log
- Review: complexity + edge cases

Week 3–4: System design intro

- 1 design prompt/week using [04-SYSTEM-DESIGN-LIBRARY/00-System-Design-Template.md](../04-SYSTEM-DESIGN-LIBRARY/00-System-Design-Template.md)
- Add 2 mini-drills/week (caching, queues, DB indexing)

Week 5–6: Depth + polish

- Mock interviews (coding + design)
- Rewrite 6 behavioral stories (impact + tradeoffs)

Week 7–8: Full loop simulation

- 2 full mock loops/week
- Fix only the top 3 recurring failures

## Projects that create real signal

Pick projects that prove execution and reliability:

- A small API service with authn/authz, DB, caching, rate limiting
- Observability: metrics + logs + traces + dashboards
- A safe deployment strategy (blue/green or canary)

Avoid:

- toy apps with no tests, no monitoring, no failure plan

## Company archetype adjustments

- **FAANG/high-growth:** invest more in system design communication and scale math.
- **Enterprise:** invest more in migrations, compatibility, maintainability.
- **Automotive/industrial:** invest more in correctness, verification mindset, risk control.

02-ROLE-ROADMAPS/02-Backend-Engineer.md

# Backend Engineer Roadmap

Backend interviews test whether you can build reliable services: APIs, data, scaling, and operability.

## What backend loops emphasize

- API design and data contracts
- storage choices and consistency tradeoffs
- scaling and latency (especially p95/p99)
- reliability patterns (timeouts, retries, rate limits)
- operational excellence (debugging, incidents, rollbacks)

## Core competencies

### 1) Data and storage

- relational modeling and indexes
- transactions and isolation intuition
- caching and invalidation
- partitioning/sharding basics

### 2) Distributed systems mindset

- partial failure is normal
- idempotency and retries
- backpressure and queueing

### 3) Operability

- SLIs/SLOs
- dashboards/alerts
- runbooks and safe rollouts

## 10-week plan (mid/senior)

Weeks 1–2: Refresh foundations

- Databases + networking + reliability basics
- 2 design mini-drills/week (cache, queue, storage)

Weeks 3–6: System design reps

- 1 full prompt/week
- Focus prompts: rate limiter, notification system, feed/timeline, file upload

Weeks 7–8: Production thinking

- Add failure modes + rollback + observability to every design
- Practice explaining tradeoffs succinctly

Weeks 9–10: Mock loops

- Combine coding + design + behavioral

## Common backend failure cases

- Over-indexing on microservices without reason
- No capacity planning (“we’ll scale later”)
- No failure handling (timeouts/retries/circuit breakers)
- No data model clarity (no keys/indexes/partition strategy)

## Projects that read as “backend”

- API service with schema versioning + migrations
- Background jobs + queues + idempotency
- Multi-tenant architecture considerations (authz, quotas)

## Company archetype adjustments

- **FAANG/high-growth:** emphasize scale math, tail latency, de-risking launches.
- **Enterprise:** emphasize migrations, change management, compatibility.
- **Automotive/industrial:** emphasize correctness, risk control, verification discipline.

02-ROLE-ROADMAPS/03-Machine-Learning-Engineer.md

# Machine Learning Engineer (MLE) Roadmap

MLE is “software engineering for learning systems”. The job is not just training models; it’s building systems that improve safely over time.

## What gets evaluated

- core ML concepts and evaluation
- data quality, leakage, bias
- production readiness: deployment, monitoring, iteration
- ability to turn product goals into measurable objectives

## MLE foundations

### ML fundamentals (interview-grade)

- supervised learning: classification/regression
- metrics: precision/recall, ROC-AUC, calibration
- bias/variance and regularization intuition
- offline vs online evaluation

### Data + features

- leakage patterns
- label quality and feedback loops
- feature freshness and ownership

### Production ML engineering

- training/serving skew
- monitoring for drift and silent failures
- rollback, shadow deploy, A/B testing

## 12-week plan

Weeks 1–3: Refresh ML fundamentals

- create a one-page “metrics cheat sheet” per problem type
- practice explaining tradeoffs: precision vs recall, latency vs accuracy

Weeks 4–6: ML system design

- 1 prompt/week: ranking/recommendation, fraud/spam, search, forecasting
- use [05-ML-MLOPS/03-ML-System-Design-Templates.md](../05-ML-MLOPS/03-ML-System-Design-Templates.md)

Weeks 7–9: Production readiness

- monitoring plan, testing plan, rollback plan
- map to ML Test Score rubric

Weeks 10–12: Mock loops

- coding (varies), ML system design, behavioral

## Common failure cases

- treating ML like a notebook project
- no plan for data/label issues in production
- confusing metric optimization with product success
- ignoring cost/latency constraints

## Company archetype adjustments

- **FAANG/high-growth:** emphasis on large-scale systems + experimentation.
- **Enterprise:** emphasis on reliability, governance, model risk management.
- **Automotive/industrial:** emphasis on safety, verification, and risk control (often stricter acceptance criteria).

02-ROLE-ROADMAPS/04-Data-Engineer.md

# Data Engineer Roadmap

DE interviews test whether you can build reliable data products: correct, cost-efficient, and understandable.

## Core competencies

1. SQL under time

- joins, group by, window functions
- correctness and performance intuition

2. Data modeling

- dimensional vs normalized models
- keys, grain, slowly changing dimensions

3. Pipelines and orchestration

- batch vs streaming
- idempotency, backfills, reprocessing

4. Data quality and reliability

- freshness, completeness, accuracy
- lineage and governance
- cost control

## 10-week plan

Weeks 1–2: SQL drill

- 4 timed SQL sessions/week
- keep a mistake log by failure type

Weeks 3–4: Modeling

- design schemas for common domains (orders, payments, events)

Weeks 5–7: Pipelines

- design batch + streaming pipelines
- handle late data and schema evolution

Weeks 8–10: Mock DE loop

- SQL + system design (data platform) + behavioral

## Common failure cases

- wrong assumptions about data grain
- ignoring late/out-of-order events
- no backfill strategy
- no quality checks or alerting

## Company archetype adjustments

- **FAANG/high-growth:** scale + real-time needs often stronger.
- **Enterprise:** governance, compliance, and integration are heavier.
- **Automotive/industrial:** lifecycle is long; traceability and reliability are key.

02-ROLE-ROADMAPS/05-Data-Scientist.md

# Data Scientist Roadmap

DS interviews often test whether you can make decisions with data under ambiguity.

## What DS loops commonly include

- metrics and experiment design
- SQL / analysis
- product sense / case studies
- sometimes modeling
- storytelling and stakeholder influence

## Core competencies

### 1) Metrics and experiments

- define success metrics and guardrails
- power/variance intuition
- A/B testing pitfalls

### 2) Causal reasoning intuition

- confounding, selection bias
- when correlation is enough vs not

### 3) Communication

- explain results clearly
- tie analysis to business decision

## 10-week plan

Weeks 1–2: SQL + analysis

- 3–4 timed SQL drills/week
- practice writing “one-page” conclusions

Weeks 3–6: Experimentation

- 1 case/week: metric definition + experiment plan + pitfalls

Weeks 7–8: Product sense

- practice turning vague goals into measurable plans

Weeks 9–10: Mock loop

- case study + SQL + behavioral

## Failure modes

- metric confusion (optimizing a proxy that harms long-term goals)
- p-hacking / post-hoc stories
- unclear narrative and recommendations

## Archetype adjustments

- **FAANG/high-growth:** large-scale experimentation cultures; speed and rigor.
- **Enterprise:** domain and stakeholder management may matter more.
- **Automotive/industrial:** safety/regulatory context can constrain experimentation; offline evaluation may dominate.

02-ROLE-ROADMAPS/06-DevOps-SRE.md

# DevOps / SRE Roadmap

DevOps/SRE interviews evaluate whether you can keep systems healthy under change: automation, reliability, and incident leadership.

## Core competencies

- Linux + networking fundamentals
- containers and Kubernetes basics
- observability (metrics/logs/traces)
- CI/CD, safe rollouts, IaC
- incident response and postmortems

## 10-week plan

Weeks 1–2: Systems fundamentals

- networking + Linux debugging drills

Weeks 3–5: Containers + Kubernetes

- understand core primitives and failure modes

Weeks 6–7: CI/CD + deployment safety

- blue/green, canary, feature flags

Weeks 8–10: Incidents and reliability

- practice incident scenarios and communication

## Interview failure modes

- tool trivia without fundamentals
- no mental model for debugging
- ignoring SLOs, saturation, and feedback loops

## Archetype adjustments

- **FAANG/high-growth:** large fleets and standardized SRE practices.
- **Enterprise:** heterogeneous systems, compliance, slower change windows.
- **Automotive/industrial:** safety and long-lived systems; higher emphasis on risk control.

02-ROLE-ROADMAPS/07-MLOps-Engineer.md

# MLOps Engineer Roadmap

MLOps sits between platform engineering and ML: you enable teams to ship models reliably.

## What gets evaluated

- deployment strategies for models
- monitoring and drift
- feature stores and data pipelines
- reproducibility and governance
- platform design and developer experience

## Core pillars

1. Software + platform engineering fundamentals
2. ML production readiness (tests, monitoring, rollback)
3. Data reliability (freshness, lineage)

## 12-week plan

Weeks 1–3: Infra foundations

- containers, Kubernetes, CI/CD, observability

Weeks 4–6: ML production basics

- training/serving skew, feature freshness, deployment patterns

Weeks 7–9: Platform design

- multi-tenant pipelines, quotas, cost control

Weeks 10–12: Mock loops

- platform/system design + behavioral

## Failure modes

- treating MLOps as “just Kubernetes”
- no ML-specific monitoring/testing plan
- weak story on how the platform improves team velocity and safety

## Archetype adjustments

- **FAANG/high-growth:** platform scale and experimentation tooling.
- **Enterprise:** governance, approvals, model risk management.
- **Automotive/industrial:** safety, verification, traceability.

03-INTERVIEWS/00-Interview-Index.md

# Interview Index

This folder is the practical “how to pass the loop” playbook.

## Choose your track

- SWE/Backend: start at [03-INTERVIEWS/02-Coding-Interview-Playbook.md](02-Coding-Interview-Playbook.md) and [03-INTERVIEWS/03-System-Design-Interview-Playbook.md](03-System-Design-Interview-Playbook.md)
- MLE/MLOps: add [03-INTERVIEWS/04-ML-System-Design-Interview.md](04-ML-System-Design-Interview.md)
- DE/DS: add [03-INTERVIEWS/05-SQL-Data-Interview.md](05-SQL-Data-Interview.md)
- Everyone: [03-INTERVIEWS/06-Behavioral-Interview-Playbook.md](06-Behavioral-Interview-Playbook.md)

## The weekly cadence that works

If you only have 60–90 minutes/day:

- 3 days: coding reps
- 1 day: system design rep
- 1 day: behavioral rep
- 1 day: role-specific (ML/SQL/infra)
- 1 day: rest or catch-up

## Post-mortem template

After each interview practice:

- What went well?
- What broke (exact moment)?
- Root cause (knowledge vs execution vs communication)?
- Fix rule (a sentence you’ll follow next time)
- One follow-up drill to prevent recurrence

03-INTERVIEWS/01-Recruiter-Screen-Playbook.md

# Recruiter Screen Playbook

Recruiter screens are not “small talk”. They decide whether you enter the technical funnel.

## What the recruiter is trying to learn

- Are you credible for the level?
- Is your experience aligned with the role?
- Can the company close you (comp, location, timing)?
- Are there obvious risks (communication, mismatch, unrealistic expectations)?

## Your 90-second pitch

Structure:

1) Who you are (role + years + domain)
2) What you shipped (2–3 highlights)
3) What you want next (target role + scope)
4) Why this company (1–2 concrete reasons)

## Questions you should ask

- What level is this role hiring at?
- What is the interview loop and timeline?
- What does success look like in the first 3–6 months?
- Team match process (before or after onsite)?
- Remote/hybrid expectations and location constraints?
- On-call expectations (if relevant)?

## Common failure modes

- Rambling history with no “so what”
- No clear target role/level
- Over-selling a niche skill for a generalist role
- Avoiding compensation discussion entirely (you can defer, but don’t dodge)

## Company archetype notes

- **FAANG/high-growth:** usually structured level bands and calibrated loops.
- **Enterprise:** role scope varies; clarify team and expectations early.
- **Automotive/industrial:** clarify domain constraints (safety/regulatory, onsite needs).

03-INTERVIEWS/02-Coding-Interview-Playbook.md

# Coding Interview Playbook

Coding interviews are about building confidence in your reasoning under constraints.

## The structure to follow (every time)

1. Clarify requirements and constraints
2. Example walkthrough
3. Approach + complexity
4. Implement in small steps
5. Validate with tests
6. State complexity + improvements

## Communication rules

- Narrate decisions, not every keystroke.
- If stuck for >3 minutes: step back, propose alternatives.
- If you made an assumption: say it explicitly.

## What causes fails

- Incorrect solution or unhandled edge cases
- No explanation of approach
- Inability to debug
- Disorganized code that can’t be reasoned about

## How to train

- Prefer 1 timed problem + post-mortem over 5 untimed.
- Redo failed problems 48–72 hours later.
- Keep a “mistake log” grouped by failure type.

03-INTERVIEWS/03-System-Design-Interview-Playbook.md

# System Design Interview Playbook

System design interviews test your ability to design systems under ambiguity, justify tradeoffs, and communicate clearly.

## The only structure you need

Use the template in [04-SYSTEM-DESIGN-LIBRARY/00-System-Design-Template.md](../04-SYSTEM-DESIGN-LIBRARY/00-System-Design-Template.md).

## What interviewers expect (by level)

- **Mid:** a coherent architecture + basic scaling + failure handling.
- **Senior:** capacity planning + tradeoffs + operability + migrations.
- **Staff+:** multi-system tradeoffs, org constraints, long-term risk management.

## Common ways candidates fail

- No requirements: architecture doesn’t match the problem.
- No numbers: can’t justify capacity.
- No failure plan: ignores partial failure.
- Buzzwords over data flows.

## How to practice

- Do 1 prompt/week end-to-end (60–90 min).
- Do 2 “mini drills” (15 min) on one topic (cache, queue, storage).

03-INTERVIEWS/04-ML-System-Design-Interview.md

# ML System Design Interview

ML system design is not a modeling exam. It’s a product + data + production reliability exam.

## A template that works

1. Define product goal and measurable metrics
2. Define data sources and labeling strategy
3. Define model approach (baseline first)
4. Define training pipeline (features, freshness, leakage controls)
5. Define serving (latency, caching, fallbacks)
6. Define evaluation (offline + online)
7. Define monitoring (drift, data quality, silent failures)
8. Define iteration + rollback

Reference anchors:

- Rules of ML emphasizes “pipeline first, simple model first”.
- ML Test Score gives a rubric for tests and monitoring.

## Common prompts

- recommendations / ranking
- fraud/spam detection
- search relevance
- forecasting
- personalization
- LLM application with retrieval

## What interviewers want to hear

- baselines and iteration plan
- how you avoid leakage
- how you handle feedback loops
- how you monitor and rollback safely

## Failure modes

- jumping to deep learning without a baseline
- no plan for labels and data quality
- no monitoring or rollback plan
- optimizing offline metrics without product constraints

03-INTERVIEWS/05-SQL-Data-Interview.md

# SQL / Data Interview Playbook

SQL interviews are not about memorizing syntax; they’re about correctness and reasoning under time.

## The process

1. Clarify table schemas and grain
2. Identify joins and cardinality
3. Write the simplest correct query
4. Validate with a small example
5. Optimize only if asked

## High-frequency topics

- joins and deduping
- window functions
- cohort retention
- funnels
- sessionization
- slowly changing dimensions

## Failure modes

- wrong grain assumptions
- accidental row multiplication
- filtering in WHERE vs HAVING incorrectly

## Practice plan

- 3 timed SQL sessions/week
- keep a log of mistakes by category

03-INTERVIEWS/06-Behavioral-Interview-Playbook.md

# Behavioral Interview Playbook

Behavioral rounds are where strong engineers lose offers: not because of bad people skills, but because their stories don’t show judgment.

## The scoring model (what they infer)

- ownership and accountability
- conflict handling
- judgment under ambiguity
- communication and influence
- learning and growth

## A story structure that works

Use a modified STAR:

1. Context (one paragraph)
2. Goal (what success meant)
3. Constraints (time, people, risk)
4. Actions (what _you_ did; decision criteria)
5. Results (numbers, impact)
6. Reflection (what you’d do differently)

## Build a story bank (6–8 stories)

- a failure and what you learned
- a conflict / disagreement
- a time you led without authority
- a deep technical dive
- a high-impact delivery
- a time you improved reliability or quality

## Common failure modes

- generic stories with no specifics
- blaming others
- no reflection or learning

## Company archetype notes

- **FAANG/high-growth:** structured rubrics; crisp stories with metrics help.
- **Enterprise:** cross-functional influence and change management matter.
- **Automotive/industrial:** risk control, verification mindset, reliability culture resonate.

03-INTERVIEWS/07-Take-Home-and-Project-Interviews.md

# Take-Home and Project Interviews

Take-homes often measure what whiteboard interviews miss: code quality, architecture, testing, and communication.

## The scoring rubric (usually)

- correctness
- clarity and maintainability
- tests and edge cases
- reasonable architecture and tradeoffs
- documentation (how to run + decisions)

## How to respond (high leverage)

Before you start:

- confirm time expectations and submission format
- clarify ambiguous requirements
- ask about evaluation criteria

While building:

- keep the scope small and solid
- write tests for the “core” path
- add minimal observability/logging

Delivery:

- include a short README: setup, run, test, decisions, tradeoffs, next steps

## Common failure modes

- too much scope, unfinished core
- no tests
- no error handling
- unclear instructions to run

## If you’re time-constrained

Prioritize in this order:

1) correctness
2) clean structure
3) tests
4) docs
5) extras

03-INTERVIEWS/08-Using-AI-Tools-Ethically.md

# Using AI Tools Ethically (2025–2026)

Many companies are evolving their stance on AI-assisted development. Your safest strategy is to be transparent and to follow the interview’s rules.

## Principles

- Follow the explicit policy for the interview.
- If unclear, ask the recruiter for rules before the interview.
- Never paste proprietary company details into tools.

## How to use AI tools well (when allowed)

- Use them for: boilerplate, syntax recall, edge case brainstorming, test ideas.
- Avoid: copying full solutions you can’t explain.

## What interviewers are watching

- Do you understand the solution and tradeoffs?
- Can you debug when the suggested code is wrong?
- Do you maintain ownership of decisions?

## Failure modes

- using a tool as a crutch without understanding
- producing code you can’t reason about
- violating interview rules

03-INTERVIEWS/09-Interview-Day-Operations.md

# Interview Day Operations

Interview days are high cognitive load. Your goal is to reduce avoidable variance.

## Before the day

- Confirm schedule and tech setup.
- Prepare water/notes.
- Review your top 6 behavioral stories.
- Warm up with 1 easy coding problem (not a hard one).

## During rounds

- Ask clarifying questions early.
- Write assumptions down.
- Timebox: if stuck, step back and propose alternatives.
- Summarize tradeoffs and next steps at the end.

## Between rounds

- Don’t try to learn new topics.
- Write a 3-line note: what worked, what to fix next round.

## After the loop

- Write a quick debrief while memory is fresh.
- Send a short thank-you to recruiter if appropriate.

04-SYSTEM-DESIGN-LIBRARY/00-System-Design-Template.md

# System Design Template (Use This Every Time)

This is a repeatable structure to keep you from rambling.

## 1) Requirements

### Functional

- What does the system do?
- Who are the users?
- What are the core APIs?

### Non-functional

- latency targets (p50/p95/p99)
- availability target (e.g., 99.9%)
- consistency requirements
- data retention and privacy constraints

## 2) Back-of-the-envelope numbers

Estimate:

- QPS (reads/writes)
- peak factor
- data size per object
- storage growth
- bandwidth

The point is not perfect math—it’s to justify design choices.

## 3) High-level architecture

Start simple:

- clients → API layer → core services → storage

Then add scaling elements:

- caching
- queues/streams
- read replicas
- sharding/partitioning

## 4) Data model

- key entities
- indexes needed
- partition key and why

## 5) Deep dives (pick 1–3)

- caching strategy and invalidation
- consistency model
- rate limiting
- search/indexing
- async processing

## 6) Failure modes and resilience

- timeouts, retries (with jitter), circuit breakers
- dependency degradation plan
- disaster recovery (RPO/RTO)

## 7) Observability and operations

- SLIs/SLOs
- dashboards + alerts
- runbooks and rollback strategy

## 8) Security and privacy

- authn/authz
- data encryption (in transit/at rest)
- least privilege

## 9) Tradeoffs recap

End with 3–5 explicit tradeoffs:

- what you optimized for
- what you sacrificed
- what you’d do next if given more time

04-SYSTEM-DESIGN-LIBRARY/01-Capacity-Planning-Cheatsheet.md

# Capacity Planning Cheatsheet

Capacity planning is about making design choices defensible.

## A minimal template

1. Users and traffic

- DAU/MAU (if relevant)
- QPS average and peak factor

2. Data size

- size per record/object
- storage growth per day

3. Bandwidth

- read/write bandwidth at peak

4. Latency budget

- p95/p99 target
- where time goes (network, compute, DB)

## Useful rules of thumb

- You don’t need perfect math; you need the right order of magnitude.
- Tail latency gets worse under saturation; plan for headroom.
- Caches reduce load but introduce invalidation complexity.

## Common mistakes

- ignoring peak factor
- ignoring read/write asymmetry
- no plan for hot keys/hot partitions

04-SYSTEM-DESIGN-LIBRARY/02-Design-Patterns-and-Failure-Handling.md

# Design Patterns & Failure Handling

Most system design interviews are evaluating your handling of partial failure.

## Core patterns

- Caching (read-through, write-through, write-back)
- Queues and async workers
- Idempotency keys
- Rate limiting
- Circuit breakers and bulkheads
- Backpressure

## Failure handling checklist

- Timeouts set everywhere (and sane)
- Retries capped + backoff + jitter
- Fallbacks for degraded dependencies
- Dead-letter queues for async
- Rollback plan

## Observability checklist

- SLIs: latency, errors, saturation
- dashboards show p95/p99
- alerts are actionable
- tracing for dependency chains

04-SYSTEM-DESIGN-LIBRARY/03-Common-Prompts-and-What-They-Test.md

# Common System Design Prompts (and what they test)

This is a “why this question” map so you can practice deliberately.

## URL shortener

Tests:

- API design and data modeling
- capacity planning basics
- caching and TTL

## Rate limiter

Tests:

- algorithms (token bucket/leaky bucket)
- distributed coordination tradeoffs
- hot keys and performance

## Notification system

Tests:

- async processing
- retries, DLQs
- user preferences, idempotency

## Feed / timeline

Tests:

- fanout tradeoffs (push vs pull)
- storage and caching
- consistency and freshness

## File upload / media processing

Tests:

- object storage patterns
- async processing pipelines
- security and abuse prevention

05-ML-MLOPS/00-ML-Index.md

# ML & MLOps Index

ML interviews vary wildly by company and role. The consistent theme: can you build reliable ML systems, not just train models.

## Core pillars

1. **Modeling fundamentals** (bias/variance, metrics, evaluation)
2. **Data** (quality, leakage, features, labeling)
3. **Production** (deployment, monitoring, iteration)

## Production mindset (high signal)

Two reference frames this repo uses:

- Rules of ML (engineering-first approach)
- ML Test Score (tests/monitoring rubric for production readiness)

See [RESOURCES.md](../RESOURCES.md).

## What changes in 2025–2026

- More interviews explicitly evaluate how you work with AI tools.
- LLM/GenAI systems design shows up more (retrieval, evaluation, safety, cost).
- MLOps signals matter more: monitoring, rollback, shadow deploy, data issues.

## Next pages

- [05-ML-MLOPS/01-ML-Fundamentals-for-Interviews.md](01-ML-Fundamentals-for-Interviews.md)
- [05-ML-MLOPS/04-ML-Testing-and-ML-Test-Score.md](04-ML-Testing-and-ML-Test-Score.md)
- [05-ML-MLOPS/06-Monitoring-and-Drift.md](06-Monitoring-and-Drift.md)

05-ML-MLOPS/01-ML-Fundamentals-for-Interviews.md

# ML Fundamentals for Interviews

The goal: explain ML clearly, choose reasonable metrics, and reason about tradeoffs.

## Core concepts

- bias/variance intuition
- overfitting and regularization
- train/validation/test splits
- calibration and thresholds

## Metrics cheat sheet

- Classification: precision/recall, ROC-AUC, PR-AUC
- Ranking: NDCG, MAP
- Regression: MAE/MSE, pinball loss (quantiles)

## Practical evaluation

- Offline metrics are not product success.
- Define guardrails: latency, cost, fairness, safety.
- Use online experiments when possible; otherwise use careful offline validation.

## Failure modes

- optimizing the wrong metric
- leakage
- dataset shift

05-ML-MLOPS/02-Feature-Engineering-and-Data-Leakage.md

# Feature Engineering & Data Leakage

Leakage is one of the fastest ways to fail an MLE interview because it shows weak production intuition.

## Common leakage patterns

- using future information (post-outcome fields)
- target leakage through derived aggregates
- using labels as features (directly or indirectly)
- sampling bias (logging only shown items)

## Defensive checklist

- define what is available at serving time
- version features and enforce freshness
- validate training/serving parity
- monitor feature coverage and distribution

## Feature ownership

Production ML improves when feature columns have owners, documentation, and monitoring.

05-ML-MLOPS/03-ML-System-Design-Templates.md

# ML System Design Templates

Use these templates to structure design discussions.

## Template A: Ranking / Recommendations

- Goal and metrics (CTR, watch time, satisfaction)
- Candidate generation vs ranking
- Features and freshness
- Training pipeline and evaluation
- Serving latency and fallbacks
- Monitoring: drift, bias, feedback loops

## Template B: Fraud / Abuse

- High recall vs high precision tradeoff
- Label acquisition and adversarial behavior
- Real-time scoring vs batch
- Human-in-the-loop
- Monitoring for concept drift and false positives

## Template C: Forecasting

- horizon and granularity
- missing data and seasonality
- evaluation beyond MSE (business cost)
- retraining schedule

05-ML-MLOPS/04-ML-Testing-and-ML-Test-Score.md

# ML Testing and the ML Test Score

Traditional software tests check deterministic behavior. ML systems are probabilistic, so you need broader coverage: data, training, serving, and monitoring.

## What “production-ready” means

- data is validated
- training is reproducible
- serving matches training assumptions
- monitoring detects silent failures
- rollback is possible

## A pragmatic test checklist

### Data tests

- schema checks
- missingness/coverage
- distribution sanity

### Training tests

- deterministic seeds where possible
- training data versioning
- metric regression checks

### Serving tests

- training/serving skew checks
- latency budget checks

### Monitoring

- drift detection
- alerting for stale features
- outcome monitoring and feedback loops

## Why interviewers like this

It shows you understand ML technical debt and can build systems that don’t degrade silently.

05-ML-MLOPS/05-LLM-Applications-and-Evaluation.md

# LLM Applications and Evaluation (Interview Notes)

LLM/GenAI interviews often focus on evaluation, cost, latency, and safety—not on prompt poetry.

## Common system types

- Chat assistant with tools
- Retrieval-augmented generation (RAG)
- Classification / routing
- Summarization

## What to define early

- user goal and failure impact
- latency and cost constraints
- acceptable hallucination risk

## Evaluation playbook

- Create a representative evaluation set.
- Define metrics (task success, factuality, latency, cost).
- Add human review for high-risk slices.
- Monitor regressions across model versions.

## Failure modes

- no evaluation plan (only anecdotes)
- ignoring cost and tail latency
- no safety/abuse considerations

05-ML-MLOPS/06-Monitoring-and-Drift.md

# Monitoring, Drift, and Silent Failures

The most dangerous ML failures are quiet: performance decays while dashboards look “fine”.

## What to monitor

- input data distribution
- feature coverage/freshness
- model output distribution
- outcome metrics (delayed labels)
- business guardrails (latency, cost)

## Drift types

- covariate shift (inputs changed)
- concept drift (relationship changed)
- label drift (labels changed)

## Common silent failures

- a joined table stops updating
- feature coverage drops
- model is stale

## Response plan

- detect → triage → rollback/shadow → fix pipeline → re-deploy

06-DATA/00-Data-Index.md

# Data Index (DE + DS foundations)

Data roles fail in interviews for predictable reasons:

- weak SQL fundamentals under time
- hand-wavy data modeling
- ignoring quality/lineage/cost
- not turning ambiguity into a plan

## Core skills by role

### Data Engineer

- SQL + modeling
- batch and streaming pipelines
- orchestration
- data quality + lineage
- cost and reliability

### Data Scientist

- metrics and experiments
- causal reasoning intuition
- storytelling and stakeholder influence
- practical modeling (when relevant)

## Next pages

- [06-DATA/01-SQL-Patterns.md](01-SQL-Patterns.md)
- [06-DATA/02-Data-Modeling.md](02-Data-Modeling.md)
- [06-DATA/04-Data-Quality.md](04-Data-Quality.md)

06-DATA/01-SQL-Patterns.md

# SQL Patterns (High Frequency)

This page is about patterns, not syntax.

## Pattern 1: Deduplicate latest row

Approach:

- define partition key
- order by timestamp
- pick row_number = 1

## Pattern 2: Funnel conversion

Approach:

- define steps
- join events per user/session
- compute drop-off

## Pattern 3: Cohort retention

Approach:

- cohort by first event date
- compute retention by week/month

## Mistakes to avoid

- accidental row multiplication
- filtering too early (before dedupe)
- wrong grain

06-DATA/02-Data-Modeling.md

# Data Modeling (DE / Analytics)

Good models reduce downstream confusion and rework.

## Start with grain

Define what one row means. Many modeling bugs are really grain bugs.

## Common approaches

- normalized models for core entities
- dimensional models for analytics

## Practical checklist

- primary keys and uniqueness
- time fields and timezone policy
- handling late arriving data
- schema evolution and compatibility

06-DATA/03-Pipelines-and-Orchestration.md

# Pipelines and Orchestration

Pipelines are systems: they fail, they backfill, and they need observability.

## Concepts that interviewers probe

- idempotency (safe retries)
- backfills and reprocessing
- dependency management
- SLAs and freshness
- cost control

## Failure modes

- non-idempotent jobs corrupt data
- backfills overload systems
- silent failures due to missing alerting

06-DATA/04-Data-Quality.md

# Data Quality

Quality is not a dashboard; it is a set of checks and ownership.

## Dimensions to monitor

- completeness
- freshness
- accuracy
- consistency

## Practical playbook

- define contracts per dataset
- add automated checks at ingestion and transformation
- alert on violations
- document owners and SLAs

06-DATA/05-Streaming-and-Late-Data.md

# Streaming and Late Data

Streaming systems fail in interviews when candidates assume perfect ordering and completeness.

## Concepts to handle explicitly

- out-of-order events
- late arrivals
- deduplication
- exactly-once vs at-least-once semantics

## Practical strategies

- event time vs processing time
- watermarks
- idempotent consumers
- replay/backfill plan

## Failure modes

- double counting due to retries
- missing late data leading to wrong analytics

06-DATA/06-Cost-and-Performance.md

# Cost and Performance (Data Systems)

Cost is a first-class requirement in data platforms.

## Common cost drivers

- scanning too much data
- storing duplicates
- unbounded retention
- too many materializations

## Practical optimizations

- partitioning/clustering
- incremental processing
- caching and reuse
- retention policies

## Failure modes

- “it works” but at unsustainable cost
- no observability into data platform spend

07-INFRA-DEVOPS/00-Infra-Index.md

# Infra / DevOps / SRE Index

Infra interviews evaluate whether you can keep systems healthy under change.

## Core pillars

- Linux fundamentals
- networking
- containers and Kubernetes
- CI/CD and safe rollouts
- observability
- incident response

## What “senior” means in infra

- You can debug unknown issues methodically.
- You can design for reliability and operability.
- You can prevent entire classes of incidents (guardrails).

## Next pages

- [07-INFRA-DEVOPS/02-Docker.md](02-Docker.md)
- [07-INFRA-DEVOPS/03-Kubernetes.md](03-Kubernetes.md)
- [07-INFRA-DEVOPS/05-Incident-Response.md](05-Incident-Response.md)

07-INFRA-DEVOPS/01-Linux-Networking-Fundamentals.md

# Linux + Networking Fundamentals

Most infra interviews are debugging interviews.

## Linux basics to know

- processes, signals
- file descriptors
- basic resource inspection (CPU, memory)

## Networking basics to know

- DNS, TCP, TLS
- HTTP semantics and idempotency
- timeouts and retries

## Debugging checklist

1. Is the system saturated?
2. Is there a dependency issue?
3. Is there a config/rollout change?
4. Is there packet loss or DNS failure?

07-INFRA-DEVOPS/02-Docker.md

# Docker (Interview Essentials)

Docker topics often appear as practical questions: packaging, isolation, and debugging.

## What you should be able to explain

- image vs container
- layers and caching
- why containers are not VMs
- common failure: missing dependencies, wrong entrypoint

## Practical checklist

- small images (multi-stage builds)
- explicit health checks
- env var configuration

07-INFRA-DEVOPS/03-Kubernetes.md

# Kubernetes (Interview Essentials)

Kubernetes questions test operational intuition: scheduling, reliability, and debugging.

## Core primitives

- Pods, Deployments
- Services and Ingress
- ConfigMaps and Secrets
- autoscaling (HPA) basics

## Common failure modes

- misconfigured probes causing crash loops
- resource limits too low/high
- networking and DNS issues

## Debugging approach

- check pod status/events
- check logs
- verify service endpoints
- isolate config changes

07-INFRA-DEVOPS/04-CICD-and-Safe-Rollouts.md

# CI/CD and Safe Rollouts

CI/CD interviews are about reducing risk while maintaining speed.

## Core elements

- automated tests
- build artifacts are immutable
- environments are reproducible (IaC)
- progressive delivery (canary/blue-green)

## Deployment safety checklist

- health checks and readiness probes
- rollback plan
- feature flags for risky changes
- metrics-based rollout gates

## Failure modes

- deploying without observability
- no rollback path
- manual steps that drift over time

07-INFRA-DEVOPS/05-Incident-Response.md

# Incident Response

Incident response is a leadership exercise under time pressure.

## What good looks like

- triage quickly (scope, impact)
- stop the bleeding (rollback, disable feature)
- communicate clearly
- write a blameless postmortem with action items

## A practical incident checklist

1. Declare incident and assign roles
2. Assess impact and user-facing symptoms
3. Mitigate (rollback, failover, rate limit)
4. Verify recovery
5. Preserve data for analysis
6. Postmortem and follow-ups

## Postmortem quality bar

- timeline
- contributing factors
- what detection missed
- action items with owners and dates

07-INFRA-DEVOPS/06-Observability.md

# Observability

Observability is how you debug production without guessing.

## The three pillars

- metrics: what is happening?
- logs: what happened?
- traces: where did time go?

## What to monitor

- latency (p50/p95/p99)
- error rate
- saturation (CPU, memory, queues)

## Alerting rules

- alerts must be actionable
- avoid alert fatigue
- focus on SLO-impacting signals

## Failure modes

- dashboards with only averages
- alerts that fire but don’t help diagnose

08-CAREER/00-Career-Index.md

# Career Index

Job prep is a pipeline:

1. targeting and positioning
2. application throughput
3. interview performance
4. offer negotiation

This folder covers the non-technical pieces that routinely gate strong engineers.

## Where to start

- If you have no interviews: [08-CAREER/01-Resume-LinkedIn-GitHub.md](01-Resume-LinkedIn-GitHub.md)
- If you’re getting screens but failing: [03-INTERVIEWS](../03-INTERVIEWS)
- If you have offers: [08-CAREER/04-Offer-Negotiation.md](04-Offer-Negotiation.md)

## Industry differences

- **FAANG/high-growth:** highly structured loops; signals are consistent across teams.
- **Enterprise:** role scope can vary widely; hiring may emphasize domain.
- **Automotive/industrial:** hiring often values safety, reliability, long-term ownership.

08-CAREER/01-Resume-LinkedIn-GitHub.md

# Resume, LinkedIn, GitHub (Recruiter Pass)

Your resume is a throughput tool. It should make it easy for a recruiter and hiring manager to say “this person fits”.

## Resume principles

- one screen = one story
- lead with impact and ownership
- numbers beat adjectives

### Bullet formula

"Did X by doing Y, resulting in Z" (with constraints/tradeoffs when relevant)

Example:

- Reduced p95 latency by 35% by adding caching + query optimization, improving checkout completion rate.

## LinkedIn

- headline: target role + credibility
- about: 5–7 lines, specific strengths
- featured: 2–3 strong projects or talks

## GitHub

Focus on 1–2 repos that show:

- readable code
- tests
- docs
- real operational thinking (monitoring, deployment notes)

Avoid a graveyard of half-finished repos.

08-CAREER/02-Applications-and-Networking.md

# Applications and Networking

Most candidates under-invest in pipeline management.

## The pipeline model

- applications → recruiter screens → technical screens → onsite loops → offers

If applications aren’t turning into screens, fix positioning and targeting.

## Networking that works

- ask for 15 minutes to understand the role/team
- be specific: why this role, why you fit
- follow up with a concise thank-you and resume

## Tracking

Use a simple spreadsheet:

- company, role, level
- referral status
- dates per stage
- notes and follow-ups

08-CAREER/03-Interview-Prep-Calendar.md

# Interview Prep Calendar (Sustainable)

Most plans fail because they’re too intense to sustain.

## 60–90 minutes/day plan

Mon: coding timed + postmortem
Tue: coding pattern drill
Wed: system design mini drill
Thu: coding timed + redo mistakes
Fri: behavioral story practice
Sat: role-specific (ML/SQL/infra)
Sun: rest or mock loop

## Rules

- Every session ends with a postmortem.
- Fix the top 3 recurring failures first.
- Redo failed problems after 48–72 hours.

08-CAREER/04-Offer-Negotiation.md

# Offer Negotiation (Practical)

Negotiation is not about being aggressive; it’s about aligning on value and reducing uncertainty.

## The only three levers that matter

1. **Competing options** (real alternatives reduce uncertainty)
2. **Role clarity** (level, scope, team, location)
3. **Risk profile** (remote, immigration, on-call, stability)

## Before you negotiate

- Confirm the level/title in writing.
- Confirm location and remote expectations.
- Ask for full comp breakdown: base, bonus, equity/RSUs, refreshers, sign-on.
- Ask about vesting schedule and performance review cadence.

## A negotiation script that works

Use calm, factual language:

1. Express excitement and fit.
2. Ask for time to review.
3. Present constraints or competing options.
4. Ask what flexibility exists.

Example structure:

"I’m excited about the role and I think I can have strong impact. I’m reviewing the offer details this week. Based on my other conversations and my current comp, I’d be comfortable signing if we can improve the overall package—especially the equity and/or sign-on. What flexibility do we have?"

## Common traps

- **Negotiating before the offer is complete** (you don’t know what you’re negotiating).
- **Over-optimizing one component** (base vs equity vs sign-on) without thinking in totals.
- **Ignoring refreshers** (long-term comp can dominate).
- **Not clarifying scope** (a “great comp” for a role you’ll hate is not great comp).

## Company archetype notes

- **FAANG/high-growth:** tends to be structured bands; negotiation often moves sign-on/equity more than base.
- **Enterprise:** sometimes more base/bonus flexibility; equity may be smaller.
- **Automotive/industrial:** may trade higher base for smaller equity; stability and benefits can be strong.

## Non-comp terms worth negotiating

- start date
- relocation support
- immigration support
- remote/hybrid terms
- team match (when possible)
- on-call expectations

## Decision checklist

- Is the role scope aligned with the level?
- Is the manager strong?
- Can you grow in the company’s structure?
- Do you accept the on-call and incident culture?
- Does the product/company trajectory fit your risk tolerance?

08-CAREER/05-Company-Archetypes-and-How-to-Prepare.md

# Company Archetypes and How to Prepare

Preparation changes based on what the company optimizes for.

## FAANG / high-growth consumer

- structured loops and calibration
- heavy emphasis on coding + system design communication
- strong expectation of dealing with ambiguity

Prep focus:

- timed coding reps
- system design practice with numbers
- behavioral stories with impact

## Enterprise software

- role scope varies widely
- migrations, integrations, maintainability matter
- stakeholder influence can matter more

Prep focus:

- explain tradeoffs for maintainability
- migration strategies
- examples of long-term ownership

## Automotive / industrial

- safety/reliability culture
- long-lived systems and verification
- domain constraints may matter

Prep focus:

- correctness and risk control
- testing discipline
- reliability and incident stories

08-CAREER/06-Handling-Rejection-and-Iteration.md

# Handling Rejection and Iteration

Rejection is often variance, not a verdict. The key is to extract signal and iterate.

## Post-interview debrief

- Which round likely failed (coding/design/behavioral)?
- Was it knowledge, execution, or communication?
- What is the smallest drill that would prevent it?

## A 2-week improvement cycle

Week 1
- fix the top failure mode with focused reps

Week 2
- run a mock loop and re-score

## Keep a “wins log”

Track improvements (e.g., fewer bugs, better structure). This reduces burnout and keeps progress measurable.

README.md

# BigTech / FAANG Job Roadmap (2026)

This repository is a practical, end-to-end job-preparation roadmap for:

- Software Engineer (Generalist)
- Backend Engineer
- Machine Learning Engineer (MLE)
- Data Engineer (DE)
- Data Scientist (DS)
- DevOps / Platform / SRE
- MLOps Engineer

It is written to reflect common hiring loops in:

- FAANG / MAANG and other “high-signal” Silicon Valley companies
- Big Tech & unicorns
- Enterprise software (large internal platforms, compliance-heavy)
- Automotive & industrial giants (safety, long product cycles, embedded + cloud)

The emphasis is on what actually gets evaluated: problem-solving, engineering tradeoffs, communication, and execution.

## How to use this repo

1. Start in [00-START-HERE/00-README.md](00-START-HERE/00-README.md)
2. Choose a lane using [02-ROLE-ROADMAPS/00-Role-Chooser.md](02-ROLE-ROADMAPS/00-Role-Chooser.md)
3. Build fundamentals in [01-FOUNDATIONS/00-Foundations-Index.md](01-FOUNDATIONS/00-Foundations-Index.md)
4. Practice interviews in [03-INTERVIEWS/00-Interview-Index.md](03-INTERVIEWS/00-Interview-Index.md)
5. Deepen system design in [04-SYSTEM-DESIGN-LIBRARY/00-System-Design-Template.md](04-SYSTEM-DESIGN-LIBRARY/00-System-Design-Template.md)
6. For ML/data/infra specialization, use the domain folders:
   - [05-ML-MLOPS/00-ML-Index.md](05-ML-MLOPS/00-ML-Index.md)
   - [06-DATA/00-Data-Index.md](06-DATA/00-Data-Index.md)
   - [07-INFRA-DEVOPS/00-Infra-Index.md](07-INFRA-DEVOPS/00-Infra-Index.md)
7. Close the loop: [08-CAREER/04-Offer-Negotiation.md](08-CAREER/04-Offer-Negotiation.md)

## What this repo is (and isn’t)

- This is a _roadmap + playbooks_, not a motivational blog.
- It focuses on _transferable signals_: clarity, correctness, tradeoffs, and operational thinking.
- It includes checklists, common failure modes, and role/industry differences.
- It links to credible external resources and summarizes them in our own words.

## Source philosophy

To avoid “cargo cult” advice, sections are grounded in:

- Hiring-side guidance (e.g., Google hiring pages, Amazon interview principles)
- Long-running interview prep communities (e.g., Tech Interview Handbook)
- Systems/infra docs (Kubernetes, Docker, cloud architecture centers)
- Production ML engineering guidance (Rules of ML, ML Test Score)

See [RESOURCES.md](RESOURCES.md).

## Contributing

If you want to tailor this repo to a specific role/company (e.g., Staff Backend at enterprise, or MLE at an automotive OEM), add a short file under [08-CAREER](08-CAREER) with:

- target role and level
- target geography
- interview loop observed
- your prep plan + what worked

RESOURCES.md

# Resources (Curated, credible)

This repository is intentionally link-light inside each page; this file is the canonical resource list.

## Hiring loops, evaluation signals, and preparation

- Google: How we hire
  - https://www.google.com/about/careers/applications/how-we-hire/
- Amazon: Leadership Principles (core behavioral rubric)
  - https://www.amazon.jobs/en/principles
- Tech Interview Handbook (interview process, prep structure, resume guidance)
  - https://www.techinterviewhandbook.org/
  - Source repo: https://github.com/yangshun/tech-interview-handbook

## System design and distributed systems

- System Design Primer (canonical topics, question bank, approach)
  - https://github.com/donnemartin/system-design-primer
- Microservices: Martin Fowler (tradeoffs, organizational coupling)
  - https://martinfowler.com/articles/microservices.html

## Cloud architecture and reliability

- AWS Architecture Center / Well-Architected pillars
  - https://aws.amazon.com/architecture/
- Azure Architecture Center
  - https://learn.microsoft.com/azure/architecture/
- Google Cloud Architecture Center + Well-Architected Framework
  - https://docs.cloud.google.com/architecture

## DevOps / platform fundamentals

- Kubernetes documentation
  - https://kubernetes.io/docs/home/
- Docker documentation
  - https://docs.docker.com/get-started/

## ML production readiness and MLOps

- Rules of ML (Google best practices for production ML engineering)
  - https://developers.google.com/machine-learning/guides/rules-of-ml
- The ML Test Score paper (rubric for production readiness, tests/monitoring)
  - https://research.google/pubs/pub46555/
- Chip Huyen: MLOps Guide (career-oriented curriculum + case studies)
  - https://huyenchip.com/mlops/

## Engineering culture and operating models

- Netflix culture memo (high-performance culture, context not control)
  - https://jobs.netflix.com/culture
- Spotify engineering blog (recent operational practices and trends)
  - https://engineering.atspotify.com/

## Notes on usage

- This repo summarizes these resources in our own words.
- Do not copy/paste proprietary interview questions.
- Use resources to validate _principles_ (tradeoffs, evaluation signals), not to memorize solutions.