MediumTechnical

73 practiced

Walk through how you designed and versioned APIs in one project: explain the choice between REST and GraphQL, your versioning policy, authentication and authorization approach, pagination and filtering patterns, contract testing strategy, rate-limiting, and how breaking changes were communicated and migrated.

MediumTechnical

49 practiced

Pick one feature you owned end-to-end and describe the full lifecycle: requirements gathering, API contract design, frontend component architecture and state management, schema changes and DB migration plan, CI/CD steps and rollout strategy (feature flags/canary), testing plan, and how you measured success after release. Include timelines and blockers you removed.

Sample Answer

**Situation & Scope (Week 0–2)** I owned an “Share Report” feature end-to-end for a web analytics product: let users generate a shareable, time-bound link to a dashboard. Stakeholders: PM, design, security. Primary goals: secure, revocable links, minimal latency, audit logs.

**Requirements & API contract (Week 2–3)** Designed REST endpoints: POST /shares (create { dashboard_id, expires_at, permissions }) → 201 { share_id, url }, GET /shares/{id}, DELETE /shares/{id}. Auth: JWT + service token for link validation. Drafted OpenAPI spec and reviewed with backend/frontend.

**Frontend component & state (Week 3–5)** React modal component with local state (form inputs) and async hooks (useSWR/mutation) for creating links. Kept optimistic UX: show generated URL once server confirms. Centralized share state in Redux slice to allow listing and revocation across pages.

**Schema & DB migration (Week 4)** Added shares table: id (uuid), dashboard_id FK, token (hashed), expires_at, created_by, revoked boolean, created_at. Migration script with backfill for existing dashboards = no-op. Token stored hashed; raw token returned once on create.

**CI/CD & rollout (Week 6)** Pipeline: unit tests → integration tests (test DB) → staging. Feature behind LaunchDarkly flag default off. Canary rollout: 5% of users for 48h, monitor errors/latency, then 25%, 100%.

**Testing plan** Unit tests for API, frontend; integration tests for token flow; e2e Cypress for modal and link access; security review and pen-test for token reuse.

**Monitoring & success metrics (Weeks 7–10)** Tracked: creation rate, share click-through, average access latency, revocation rate, 500s. Success: 10% adoption among power users in 4 weeks, <1% error rate. Implemented audit events in ELK.

**Blockers removed** - Resolved cross-team auth schema mismatch by adding a lightweight service-token validation endpoint. - Reduced production latency by changing token hashing from Argon2 to bcrypt with tuned params after load testing.

Result: Feature shipped in 10 weeks, met adoption and reliability targets; product team reported improved collaboration and reduced manual report exports.

MediumTechnical

57 practiced

Describe a CI/CD configuration you built or improved (preferably on Azure DevOps): include the pipeline YAML structure, caching strategies for dependencies, parallel job matrices, test matrices, secrets handling, environment protection rules, and how you promoted releases between environments.

Sample Answer

**Situation & goal**I improved our Azure DevOps CI/CD to speed feedback for a full‑stack app (React + .NET Core) and enforce gated promotions from dev → staging → prod.

**Pipeline YAML (high level)**

yaml

trigger:
  branches: [ main, develop ]

variables:
  buildConfiguration: 'Release'

stages:
- stage: Build
  jobs:
  - job: BuildApp
    pool: ubuntu-latest
    strategy:
      matrix:
        linux_node:
          NODE_VERSION: '16'
          DOTNET_VERSION: '7.0'
    steps:
    - task: UseNode@1 ... # install
    - task: UseDotNet@2 ... # install
    - script: npm ci
    - script: dotnet restore
    - script: npm run build && dotnet build
    - task: Cache@2 # cache node_modules and nuget
      inputs: ...
    - publish: $(Build.ArtifactStagingDirectory)

- stage: Test
  dependsOn: Build
  jobs:
  - job: UnitTests
    strategy:
      matrix:
        frontend:
          TEST_TYPE: 'frontend'
        backend:
          TEST_TYPE: 'backend'
    steps:
    - script: |
        if [ "$(TEST_TYPE)" = "frontend" ]; then npm test -- --ci; else dotnet test; fi

- stage: Deploy
  dependsOn: Test
  jobs:
  - deployment: DeployToEnv
    environment: 'dev'
    strategy:
      runOnce:
        deploy:
          steps:
          - download: current
          - script: deploy-script.sh

**Caching**- Used Cache task keyed by package-lock.json and global.json for deterministic restores.- NuGet and npm caches persisted between runs; cache miss falls back to restore.

**Parallel & test matrices**- Build uses a matrix to validate Node and .NET versions; Test stage runs frontend and backend tests in parallel jobs for fast feedback.

**Secrets handling**- Secrets stored in Azure Key Vault and linked as pipeline variables via service connection; non-exposable secrets referenced as variables.secrets and masked in logs.- Short-lived PATs and managed identities for deployment tasks.

**Environment protection & promotion**- Environments in Azure DevOps have approvals and checks: manual approvers for prod, automated gates (health checks, ARM/terraform plan). Promotion flow: Build → Dev auto-deploy; after smoke tests approval triggers Staging; after integration tests and security scan, manual approval + required approvals promote to Prod. Artifacts are immutable and referenced by buildId to ensure traceability.

**Outcome & metrics**- Reduced CI time by ~40%, flakiness dropped, and time-to-deploy shortened while enforcing safety gates.

EasyTechnical

44 practiced

For one representative project, explain your database selection and data modeling approach. Why did you choose relational (Postgres/MySQL) vs NoSQL (Mongo/Cassandra), what were the key schema decisions, indexing strategy, replication or sharding choices, and how did you handle backups and migrations? Include one query or access pattern you optimized and why.

Sample Answer

**Project & decision summary**

I built an e-commerce order management feature and chose PostgreSQL for strong ACID guarantees, complex joins (orders → order_items → products), and mature tooling. Consistency for payments and inventory made relational a better fit than a document store.

**Schema & key decisions**

- Core normalized tables: users, products, orders, order_items.- Kept product catalog normalized but used a JSONB column (product.metadata) for optional attributes.- Partitioned orders by month for large-volume archives (range partitioning).

**Indexing & query patterns**

- PKs & FKs for joins; multicolumn B-tree on (user_id, created_at) for user timelines.- GIN index on JSONB for metadata searches.- Partial index for active orders: (status) WHERE status = 'open'.

Optimized access pattern: list a user’s recent orders with totals. I replaced a repeated SUM join with a precomputed order_total column updated in transaction and indexed (user_id, created_at, order_total). Example query:

sql

-- fetch recent orders with total for a user
SELECT id, created_at, order_total, status
FROM orders
WHERE user_id = $1
ORDER BY created_at DESC
LIMIT 20;

This removed expensive aggregation on every request and improved latency from ~300ms to ~20ms.

**Replication, sharding, backups, migrations**

- Replication: async read replicas for reporting and scaling reads; primary for writes.- Sharding: not required; used partitioning and added horizontal sharding later if needed by customer_id.- Backups: nightly base backups + continuous WAL archiving; tested point-in-time restores.- Migrations: Flyway for versioned migrations, with feature-flagged deploys and backfill scripts run during maintenance windows.

**Outcome & learning**

Resulted in predictable performance, simple scaling path, and safe migrations. Key learning: favor fast read patterns (cached or precomputed) over repeated heavy aggregations for user-facing endpoints.

MediumTechnical

57 practiced

Explain how you handled schema migrations in production for tables with large volumes of data. Outline the migration scripts and tooling, strategies to avoid long locks (online schema change, CREATE TABLE + backfill, dual writes), how you monitored progress, and the rollback path in case of failure.

Sample Answer

**Situation & goal**I needed to add a nullable JSONB column and later backfill computed data for a table with 200M rows without downtime.

**Migration strategy**- Prefer online tools: gh-ost or pt-online-schema-change for MySQL; for Postgres use safe ALTERs (non-blocking) + pg_repack or CREATE TABLE + backfill.- For non-trivial schema changes: CREATE new_table (target schema) + chunked backfill + trigger-based dual writes -> swap.

**Example migration script (pseudo)**

sql

-- create shadow table
CREATE TABLE users_new (...) ;

-- backfill in chunks (app uses cursors or id ranges)
INSERT INTO users_new (id, ..., new_col)
SELECT id, ..., compute(...) FROM users WHERE id BETWEEN X AND Y;

**Dual-write / consistency**- Deploy small app change to write to both tables behind a feature flag; read from old table until cutover.- Use triggers as interim safety if app rollout is risky.

**Avoiding long locks**- Chunked backfills (LIMIT/ORDER BY id)- Use non-blocking ALTER (Postgres: ADD COLUMN with default NULL)- Use online schema-change tools to rewrite table without exclusive locks

**Monitoring**- Track rows processed, lag, error rate via Prometheus/Grafana- Log per-chunk durations and throughput; alert on slowdowns or replication lag- Run checksum (SELECT count, hash) between old and new partitions periodically

**Rollback plan**- Pause backfill and stop dual-writes- If inconsistency found: continue writing to old table, abort swap; roll forward fix or revert app to previous version- For destructive ops, have backups + PITR snapshot to restore specific timeframe

**Outcome & learnings**I executed multiple zero-downtime migrations using shadow tables + dual writes, reducing incidents and ensuring safe rollbacks through metrics and feature-flag controlled cutovers.

Full Stack Project Experience Overview Questions

Sample Answer

Sample Answer

Sample Answer

Sample Answer

Sample Answer

Unlock Full Question Bank