Full Stack Project Experience Overview Questions

Be ready to discuss 2-3 significant projects where you owned features end-to-end. Clearly articulate the frontend technologies, backend services, databases, and your specific contributions. Highlight decisions that improved performance, scalability, or user experience.

EasyTechnical

60 practiced

Give an example where you used spreadsheets or Excel for analysis or planning in a project (e.g., release risk matrix, cost estimates, bug triage, telemetry rollups). Include the structure (columns), key formulas or pivot tables used, and how the spreadsheet informed a decision.

HardTechnical

59 practiced

Describe a complex transitive dependency vulnerability you had to remediate across multiple services. Explain detection (scanning), prioritization (risk vs exposure), remediation plan (upgrade, patch, workaround), coordinating releases across teams, and how you validated the vulnerability was fixed.

Sample Answer

Situation: During a routine SCA (Snyk + internal SBOM scans) I found a high-severity CVE in a transitive dependency (an insecure XML deserialization bug in library X pulled in via our shared-utils package). It affected ~18 microservices across three teams; several services were customer-facing and had public ingress.

Task: My goal was to eliminate the vulnerable artifact across all services quickly without breaking releases or causing regressions.

Action:- Detection: Correlated SCA findings with build SBOMs and CI logs to enumerate exactly which services and runtime images included the vulnerable jar and which code paths could reach it. Ran targeted dynamic tests to confirm exploitability.- Prioritization: Assessed risk = CVE severity + exploitability (reachable deserialization code) + exposure (publicly accessible services) + compensating controls (WAF rules, input validation). Prioritized 5 customer-facing services for immediate remediation, 8 internal services next, 5 low-risk last.- Remediation plan: - Preferred fix: upgrade the transitive dependency to patched version by bumping the direct dependency in shared-utils and releasing a patch version (semantic versioning + changelog). - Where immediate upgrade was risky (incompatibility), applied a temporary workaround: disabled the vulnerable feature via library config and added a runtime guard (input validation & strict XML parser settings). - For services that could not accept shared-utils upgrade immediately, created a one-off override in their dependency lockfiles to force the patched transitive version.- Coordination: Created a remediation runbook with affected services, required change lists, tests, and rollback steps. Set up a cross-team Slack channel and weekly triage calls; used a shared JIRA epic with sub-tasks per service. I provided PR templates, automated CI checks to ensure the patched artifact is present, and scheduled staggered release windows to avoid simultaneous risk.- Validation: After deploys I: - Re-ran SCA and verified the SBOMs no longer included the vulnerable version. - Executed integration tests focusing on serialization paths and fuzz tests to ensure behavior unchanged. - Performed canary rollouts with increased monitoring for errors and latency. - Ran an external scanner and a minimal pen-test focused on the CVE exploit vector. - Monitored logs and WAF telemetry for indicators of attempted exploitation.

Result: All 18 services were remediated within 12 days; the SCA reports returned zero instances of the vulnerable artifact. No regressions were observed in canaries; overall incident process reduced mean time to remediate similar transitive CVEs from 21 days to 6 days after we automated SBOM checks in CI and added the runbook. Key learning: maintain authoritative SBOMs, enforce SCA in CI, and prepare safe temporary mitigations to buy time for coordinated upgrades.

HardTechnical

86 practiced

Design a zero-downtime schema migration for a very large table (billions of rows) that needs a new non-nullable column with a default value. Explain the expand-contract approach, backfill strategy, how to make deployments backward-compatible, and how to coordinate app and DB changes.

Sample Answer

Requirements & constraints:- Add a new non-nullable column col_new with default value (e.g., 0) to a huge table with billions of rows, without downtime, while keeping app compatibility during rollout.

Expand-Contract approach (safe phased rollout):1. Expand (add nullable column, deploy app reading/writing both): - ALTER TABLE ADD COLUMN col_new_tmp TYPE NULL; - Deploy app change #1: write to col_new_tmp and keep reading existing col_old behavior. This is backward-compatible because old app still ignores col_new_tmp.2. Backfill (populate column asynchronously): - Run an online, chunked backfill job to set col_new_tmp = default or computed value. - Use id ranges or indexed cursor, LIMIT, and small transactions to avoid large locks. - Example backfill loop (pseudo-SQL/psuedocode):

sql

-- run in batches
UPDATE my_table
SET col_new_tmp = 0
WHERE col_new_tmp IS NULL
AND id BETWEEN :start AND :end;

- Use tombstones/markers to track progress and retry safely. Throttle by sleep or DB load.

3. Make reads use new column (feature-flagged): - Deploy app change #2: start reading col_new_tmp where present, fallback to computed/default for nulls. - Verify metrics, error rates.

4. Contract (make column non-nullable and remove legacy): - After backfill complete and all apps using new column, ALTER TABLE ALTER COLUMN col_new_tmp SET NOT NULL; optionally set DEFAULT. - Rename/delete legacy column or drop once all consumers removed.

Backfill strategies & safety:- Use parallel workers partitioned by primary key ranges to speed up while avoiding hotspots.- Use small transactions (e.g., 1000–10000 rows) to keep WAL/replication healthy.- Monitor replication lag, lock contention, CPU/IO. Pause if thresholds exceeded.- For computed defaults, compute value in backfill to avoid per-row compute at read time.

Backward-compatibility & deployments:- Always ensure each deploy is backward-compatible: - Schema-first: add nullable column(s) before app starts depending on them. - App writes to both old and new places during transition (dual-write) or write to new and keep reading old until backfill complete. - Use feature flags and gradual traffic shifts. - Support mixed schema reads: read new column when non-null, else fallback.- Coordinate DB migrations with release windows; use CI to run migration scripts in staging.

Coordination & operational checklist:- Pre-migration: plan batch size, concurrency, fallback, monitoring dashboards.- Run smoke tests and a short canary deployment.- Communicate with SRE/DBA for throttling and emergency pause.- Post-migration: remove dual-write and legacy column after verifying metrics for some retention window.- Keep migration idempotent and resumable.

Trade-offs:- Dual-write increases complexity but minimizes read-time cost.- Backfill over time is slow but avoids downtime; faster approaches risk load/lag.

This approach ensures zero-downtime, reversible steps, safe backfill, and clear coordination between app and DB changes.

HardSystem Design

57 practiced

You're migrating an on-prem monolith to the cloud and splitting it into microservices. Provide a step-by-step migration plan covering service extraction strategy, data ownership, transaction boundaries, API gateway/routing, CI/CD changes, monitoring, and rollback plans to minimize downtime and risk.

Sample Answer

Requirements & constraints:- Minimize downtime, preserve data consistency, incremental rollout, support rollback, team can ship small services.- Target cloud: container orchestration (K8s/EKS/GKE), managed DBs, API Gateway (e.g., AWS API Gateway/ALB), CI/CD (GitHub Actions/CodePipeline), observability stack (Prometheus, Grafana, ELK/X-ray).

Migration plan (step-by-step):

1. Assessment & decomposition- Map domain boundaries, identify bounded contexts, transaction hotspots, high-coupling modules, and hot paths.- Prioritize candidate services by business value, low coupling, and independent data needs (start with read-heavy or non-critical services).

2. Service extraction strategy- Strangler pattern: route new requests to microservices while falling back to monolith for unchanged endpoints.- Extract one vertical slice at a time: API -> service logic -> database ownership.- Start with stateless services to simplify scaling and rollback.

3. Data ownership & transaction boundaries- Assign each microservice its own data store where possible (schema per service).- For shared legacy DB, create a migration plan: read replicas, table-by-table migration, use change data capture (CDC) (Debezium) to sync writes during transition.- Replace distributed transactions with eventual consistency and compensating transactions. Use sagas (choreography or orchestration) for multi-service flows.

4. API gateway & routing- Put API Gateway in front. Implement traffic steering rules: path-based routing and feature flags.- Use gateway for authentication/ratelimiting/observability. Support canary releases and A/B by routing percentages.

5. CI/CD changes- Convert monolith CI to multi-repo or mono-repo with per-service pipelines. Each service has unit/integration tests, image build, and deployment manifests.- Implement automated canary and blue/green deployments; rollbacks automated on health/metric failures.- Automate DB migration scripts, with pre/post checks and backward-compatible schema changes (add columns, not remove).

6. Monitoring & observability- Instrument services with distributed tracing (OpenTelemetry), structured logs, metrics (latency/error rates), and dashboards.- Define SLOs and alerting thresholds tied to business KPIs.- Create runbooks for common failures.

7. Rollback & risk mitigation- Use feature flags and gateway routing to quickly toggle new service traffic.- Keep the monolith as a fallback behind the gateway until decommissioned.- Maintain backward-compatible APIs and dual-write/dual-read modes during cutover.- Test rollback procedures in staging (simulated failures, DB divergence tests).

8. Cutover & decommission- Gradually increase traffic to new services with canary -> 25% -> 50% -> 100% while monitoring.- Once stable, remove dual-write and migrate live reads fully to service-owned DB; verify CDC catch-up.- Decommission monolith components incrementally.

Key trade-offs and notes:- Prioritize business-critical paths and reduce blast radius.- Accept temporary operational complexity (CDC, dual-write) to avoid downtime.- Emphasize testing, tracing, and automated rollback for minimal risk.

HardSystem Design

45 practiced

Design a logging and tracing strategy for a distributed full-stack application so engineers can perform root-cause analysis within 10 minutes. Cover log structure and format (JSON, fields), correlation IDs, trace sampling, retention policies, cost control, and querying/visualization tools.

Sample Answer

Requirements & goals:- Enable engineers to identify root cause in <10 minutes: fast triage, linked traces+logs, searchable structured logs, low noise, cost-bounded.

High-level design:- Instrument app (frontend, backend, workers) with OpenTelemetry libraries. Send traces & logs to a local collector (OTel Collector) which enriches, samples, and forwards to storage/visualization (e.g., Tempo/Jaeger for traces + Elasticsearch/ClickHouse/Honeycomb/Datadog for logs/metrics). Correlate via propagated headers.

Log structure & format (JSON):- Single-line JSON logs, UTF-8, newline delimited.- Required fields: - timestamp (ISO8601, nanosec) - level (DEBUG/INFO/WARN/ERROR) - service (name) - env (prod/stage) - hostname / pod - trace_id (W3C traceparent or hex) - span_id - correlation_id / request_id (X-Request-ID) - user_id (if authenticated) - http.method, http.path, http.status, http.route - latency_ms - error (boolean) and error_message / error_type - sampling_decision - event (short message) - attributes (map) for app-specific keys- Keep messages human-readable but avoid stack dumping in logs—store stack trace in a dedicated field.

Correlation IDs & propagation:- Use W3C Trace Context (traceparent) + X-Request-ID for external visibility.- Generate request_id at ingress (API gateway / frontend). Always propagate via headers across services, message queues, background jobs (add as message metadata).- On inbound requests with no trace, create new trace and set correlation_id = request_id. Log libraries automatically include trace_id/span_id/correlation_id.

Tracing & sampling:- Hybrid sampling: - Head-based: keep all ERROR spans/traces, all traces exceeding latency SLO (p99 > threshold), all traces from VIP customers. - Probabilistic for normal traffic: e.g., 1-5% adaptive sampling. - Tail-based (recommended): ingest metadata, keep all traces that later show errors or high latency—collector stores small index of trace heads, then decides to keep full traces when flagged.- Capture spans with enough attributes to localize failures (db calls, downstream calls, cache hits, feature flags).

Retention & tiering:- Traces: hot (30 days), warm (90 days), cold (archive) depending on compliance.- Logs: - Hot (indexed searchable fields + raw): 7–30 days (fast queries) - Warm (less indexed, compressed): 30–90 days - Cold (cheap object storage): 1+ year for audits (search limited)- Store only essential indexed fields (trace_id, timestamp, service, level, user_id, error, route); raw JSON in blob store if full payload needed.

Cost control:- Index only necessary fields; use columnar stores (ClickHouse) or log-optimized stores.- Compression (gzip/snappy), batching, and backpressure at the collector.- Dynamic sampling: raise sampling when ingest costs spike; lower debug-level logs in prod via config flags/feature toggles.- Retention lifecycle rules and automated rollups (daily aggregates, histograms).- Set quotas per service/team and alert when nearing budget.- Use synthetic logs/traces sparingly for testing.

Querying & visualization:- Traces: Jaeger/Tempo/Honeycomb/Datadog APM with distributed trace view, flame graphs, span timeline.- Logs: Kibana/Grafana Loki/Honeycomb/Datadog logs. Prebuilt dashboards: - Service health (errors, latency p50/p95/p99) - Top error types by service - Traces for slow/error requests- Provide one-click “show logs for trace_id” and “show trace for request_id” via links embedded in UI.- Offer common saved queries: recent errors in last 10 min by service, slowest routes, top downstream failures.- Alerting: threshold (error rate > X), anomalies via ML baselining, and SLO burn rates; alerts include trace_id and links.

Operational practices for <10-min RCA:- On alert, Pager contains alert + top offending trace_id(s) + sample logs link.- Checklist: reproduce, trace timeline, failing span (db/remote), correlated logs (same trace_id), recent deploys (link to CI), feature flags.- Playbooks for common failure modes (DB overload, 500s from downstream, auth failures).

Trade-offs & notes:- Tail-based sampling reduces missed errors but costs more architecture complexity.- Indexing more fields improves query speed but increases cost—start minimal, iterate based on most-used queries.- Prioritize fast links between logs and traces over storing everything in hot storage.

Metrics to monitor:- Ingest rate, storage cost/day, query latency, percentage of traces retained by sampling, time-to-first-signal (goal <2 minutes), RCA time (goal <10 minutes).

This strategy balances fidelity for RCA with cost controls and operational workflows so engineers can quickly pivot from alert to root cause with trace-linked logs, targeted sampling, and tiered retention.

Unlock Full Question Bank

Get access to hundreds of Full Stack Project Experience Overview interview questions and detailed answers.

Join thousands of developers preparing for their dream job.