Company Specific Technology Knowledge Questions

Deep knowledge of the specific company's technology stack, engineering architecture, platform components, and major technical challenges. This includes familiarity with the languages, frameworks, cloud providers, orchestration and infrastructure tools, internal platforms, common performance and scalability concerns, and recent engineering initiatives or launches. Interviewers probe this area to evaluate whether a candidate understands the precise technical environment they would join, can speak to tradeoffs in architecture and tooling, and can explain how their own technical skills map to the company specific needs.

HardSystem Design

24 practiced

A high-traffic marketing campaign will increase traffic 50x for 6 hours across regions. Using our stack (EKS, CDN, Redis, managed Kafka), propose a capacity and cost-optimized plan covering autoscaling policies, CDN strategies, caching, circuit breakers, and any temporary architectural changes to absorb the spike without service degradation.

Sample Answer

Requirements & constraints:- 50x traffic for a 6-hour window, global regions, preserve <200–500ms user latency, no data loss, cost-sensitive, use EKS, CDN, Redis, managed Kafka.

High-level approach:- Shift as much load to edge/CDN and cache; autoscale compute only for cache misses and write paths. Make short-lived architectural changes (feature flags, degraded-mode) to reduce backend work.

Architecture changes (temporary):- Enable CDN full-site caching for static assets and cacheable API responses (HTML snapshots, marketing content). Use CDN tiered cache + origin shield to reduce origin load.- Introduce CDN-based edge logic (Edge Workers/Lambda@Edge) to serve personalization tokens from signed cookies and return cached variants.- Serve read-heavy data from Redis replicas; make writes async via Kafka to downstream processors to avoid synchronous backend writes.

Autoscaling policies (EKS + Redis + Kafka):- EKS: - Horizontal Pod Autoscaler (HPA) based on request rate per pod + custom metrics (p95 latency, queue depth). - Cluster Autoscaler with cushion nodes (e.g., 20–30% headroom) pre-warmed 30–60 minutes before campaign, with node groups optimized for burst (mixed spot + on-demand; critical pods on on-demand). - Use PodDisruptionBudget and Pod Priority to keep critical paths available.- Redis: - Scale read replicas and use read-only replicas in regions. Increase max clients and connection pooling; switch to larger instance class temporarily.- Kafka: - Ensure topic partitioning sufficient (increase partitions) and increase broker throughput; use autoscaling of brokers if supported or pre-provision extra capacity.

Caching strategy:- Maximize TTLs for marketing content; use cache-key versioning for instant invalidation after the campaign.- Cache CDN-miss API responses in Redis with short TTLs (30s–5min) and probabilistic early refresh (refresh-ahead) to avoid stampede.- Local in-process LRU caches on pods for very hot keys and use request coalescing (singleflight) to prevent thundering herd.

Circuit breakers & graceful degradation:- Implement circuit breakers per downstream service with failure thresholds and exponential backoff.- Degrade non-essential features (recommendations, analytics, background enrichment) behind feature flags; convert synchronous calls to fire-and-forget or queueing through Kafka.- Serve stale-cache while async refresh happens (stale-while-revalidate).

Cost optimization:- Offload to CDN reduces origin compute cost dramatically.- Use spot instances for non-critical node groups; reserve minimal on-demand for control plane and critical services.- Temporarily increase Redis/Kafka instance size only for 6 hours rather than permanently.- Use request sampling for analytics rather than full ingestion.

Operational runbook:- Pre-warm: 60–90 minutes prior: increase CDN cache-population, scale nodes, increase Redis/Kafka capacity, enable edge logic.- During: monitor p95/p99 latency, origin requests/sec, Redis hit rate, Kafka lag, error rates. Auto-scale thresholds tuned to traffic curves.- Post-campaign: rollback TTLs and instance sizes, validate data integrity, run postmortem.

Monitoring & rollback:- Dashboards and alerts for key metrics; automated rollback scripts for feature flags.- Dry-run using synthetic traffic to validate autoscaling and cache hit rates before campaign.

Trade-offs:- More aggressive CDN caching may reduce personalization fidelity. Using edge personalization balances latency vs personalization. Temporary increases in managed DB/cache sizes incur short-term cost but prevent long tail outages.

This plan prioritizes edge/caching to minimize backend scale, uses temporary instance scaling and spot capacity for cost savings, and applies circuit breakers and graceful degradation to preserve user experience during the 6-hour spike.

MediumTechnical

30 practiced

As a Solutions Architect, describe how you would present the technical trade-offs between implementing strict consistency vs eventual consistency for a user profile service that supports cross-region updates: include UX expectations, latency, and operational complexity in your recommendation.

Sample Answer

Start by clarifying requirements: how often profiles are updated, whether cross-region updates are simultaneous, acceptable staleness for users, SLA for read latency, and business impact of conflicting updates.

High-level trade-off summary:- Strict consistency (e.g., global consensus/linearizability): guarantees all reads see the latest write immediately across regions. UX: users never see stale data; good for security-sensitive fields (passwords, email). Latency: higher read/write latency (cross-region round-trips or leader hops), typically 100s of ms to >1s depending on distance. Operational complexity: complex clustering, leader election, global failover, higher cost, harder to scale writes regionally. Requires careful DR and partition-tolerance planning.- Eventual consistency (e.g., async replication, CRDTs): low latency local reads/writes (tens of ms), high availability and regional independence. UX: transient stale reads possible; eventual convergence. Operational complexity: simpler to scale, but you must design conflict resolution, compensating UX (last-writer-wins, vector clocks, CRDTs), and robust monitoring for replication lag and divergence.

Concrete considerations and mitigations:- Hybrid model (recommended): use strong consistency for sensitive fields (auth, email verification, account lock) and eventual consistency for non-critical profile attributes (display name, avatar, preferences). Implement read-your-writes/session affinity for UX-sensitive flows (sticky sessions or client hints) so a user sees their recent changes immediately even if global replication lags.- Conflict handling: adopt deterministic resolution (CRDTs for mergeable fields, timestamp+source ordering for others) and present clear UX when manual resolution is needed (e.g., “We detected conflicting updates—choose which to keep”).- Latency targets: set SLOs (e.g., <50ms local read, <200ms write for local region). For strict consistency paths, budget cross-region RTTs and use geo-aware routing or single-write-region with fast replicas.- Operational practices: automate failover playbooks, test network partitions, monitor replication lag and conflict rates, and measure user-facing stale-read incidents. Cost: strict consistency increases cross-region egress and compute for consensus; eventual reduces these costs but may increase product support overhead for conflicts.

Recommendation: default to hybrid—strong consistency only where correctness is business-critical; eventual elsewhere with read-your-writes and well-defined conflict resolution. This balances UX (fast, mostly up-to-date experience), latency (low for majority operations), availability, and manageable operational complexity. Provide clear SLAs to stakeholders and instrument metrics to validate assumptions and iterate.

MediumSystem Design

35 practiced

For an order-processing service that must deliver near-real-time notifications to 10M users, design the core architecture using our stack (Kafka, Redis, WebSocket gateways, CDN push). Explain fan-out strategies, backpressure handling, and how you'd cost-control the solution during spikes.

Sample Answer

Requirements:- Deliver near-real-time notifications to 10M users (mobile/web)- Stack: Kafka (ingest/streaming), Redis (state, presence), WebSocket gateways, CDN push (edge delivery)- Low latency, reliable fan-out, backpressure, cost control during spikes

High-level architecture:- Producers (order service) -> Kafka topic(s) partitioned by user-id or tenant -> Consumer fleet (notification workers)- Notification workers resolve user subscriptions, preferences, presence via Redis (hot cache), enrich message, then route to delivery layer: - WebSocket gateways (stateful): maintain persistent connections; grouped by region/az and behind LB - CDN Push / Push-proxy: for offline users use APNs/FCM via push gateways or CDN edge for HTTP/S SSE fallback

Fan-out strategies:- Selective fan-out (preferred): workers compute target user list per event; push only to interested users.- Hierarchical fan-out: for large broadcasts, publish to an intermediate topic/channel per segment (e.g., tenant, region) and have dedicated fan-out workers per segment to fan to connection pools — reduces duplicate work.- Hybrid: direct for small lists, segment-based for large lists (>threshold), and chunked parallel processing for massive broadcasts.

Backpressure & reliability:- Kafka for durable buffering and replay; set consumer lag alarms and dynamic consumer scaling.- Rate-limited WebSocket gateways: accept messages into per-connection queues (bounded). If queue full: apply policy — prioritize, drop-low-priority, or persist-to-backlog (Redis stream) and notify client to poll/resync.- Token-bucket per-gateway for egress to avoid saturating downstream (push gateways, APNs). Use circuit-breakers to detect downstream overload and slow producers via feedback (control topic) or pause partitions.- Idempotency and at-least-once: include message IDs, sequence numbers, and resumable replay for reconnects.

Cost-control during spikes:- Auto-scale consumer and gateway fleets with horizontal pods and rapid cold-start limits (pre-warmed instances).- Use tiered delivery: real-time for active WebSocket connections; batched/email/push for low-priority; degrade non-essential features under cost thresholds.- Use sampling and rate-limits per tenant/user; configurable SLAs per customer (paid tiers get higher real-time guarantees).- Offload heavy fan-out to cheaper infra: CDN edge caching for static/broadcast content, and leverage push notification services for mobile to avoid WebSocket scaling.- Monitor cost metrics, set spike caps and graceful degradation policies (queueing > threshold -> switch to digest mode).

Trade-offs:- Selective fan-out minimizes bandwidth but requires per-event compute and presence lookups (Redis). Segment-based fan-out reduces compute but may send unnecessary messages.- Strong consistency vs availability: favor eventual delivery with durable retry to keep latency low during spikes.

Operational notes:- Metrics: consumer lag, per-gateway egress, per-connection queue lengths, P95/P99 latency, cost per million notifications.- Run chaos/scale tests, maintain deterministic replay windows in Kafka, and keep presence TTLs tuned to balance Redis cost vs accuracy.

HardTechnical

46 practiced

The engineering leadership wants a governance model for API versioning across dozens of teams to prevent breaking changes from reaching clients. Propose a policy and enforcement mechanism using our API gateway and CI tooling (GitLab CI, automated contract tests). Include policy elements and enforcement workflow.

Sample Answer

Policy (principles & rules)- Versioning scheme: use semantic API versioning at the API surface (v{major} in path or mandatory Accept/Version header). Major = breaking, minor/patch = non-breaking.- Backwards-compatibility rule: any change that alters request/response shape, required fields, status codes, or semantics must be a major version. Additive changes allowed in minor/patch.- Deprecation windows: announce deprecation ≥90 days, supported for at least one major-plus-90-days; auto-redirect + 410 after grace period.- Ownership & review: each API has an owner team and a contract-change reviewer (cross-team panel for cross-cutting APIs).- Required artifacts for changes: updated OpenAPI spec, consumer contract tests, migration guide, and compatibility report (OpenAPI diff).- Exceptions: explicit approved exceptions via Architecture Board.

Enforcement mechanism (CI + API Gateway)1. Contract-first workflow - Teams author OpenAPI + consumer contract tests (Pact or similar) in the repo. All changes occur via Merge Request (MR).2. GitLab CI pipeline (pre-merge & gating jobs) - openapi-diff job: run openapi-diff between current published spec and MR spec; categorize as additive/non-additive. If non-additive and major not bumped, fail MR. - consumer-driven contract verification: - Run consumer tests that produce pacts; publish pacts to Contract Registry (artifact repo). - Provider verification job: on MR, run provider verification against latest consumer pacts. Use GitLab CI agents to spin up provider in test container and run pact-provider-verifier. Fail MR if verification fails. - Schema fuzzing / property tests: run Schemathesis or JSON Schema fuzz tests for added safety. - Automated approval gating: all three jobs must pass to merge.3. Contract Registry + Policy Server - On successful merge, CI publishes new OpenAPI and verified contracts to a central Contract Registry and updates an API Catalog entry (owner, versions, deprecation dates). - A lightweight Policy Server (or GitLab CI job) validates that declared version bump aligns with detected diff; rejects pushes to prod registry otherwise.4. API Gateway enforcement (runtime) - Gateway reads the Contract Registry and enforces allowed versions per route. If a client calls an unsupported major version, gateway returns 410 with migration link. - Gateway can enforce schema validation (request/response) from the published OpenAPI to block runtime breaking requests. - Canary routing and gradual rollout: gateway supports routing X% traffic to new version for canary verification.5. Observability & audits - CI emits metrics for failed/succeeded verifications; gateway logs version usage, 4xx/5xx spikes, and deprecated-version traffic. - Weekly audit that flags APIs with contracts older than X days or active usage of deprecated versions.6. Human workflow tie-ins - MR template requires checklist: OpenAPI diff, pact verification, migration docs, owner sign-off. Architecture Board auto-notified for major bumps. - Emergency break-glass: immediate fallback route flag in gateway with postmortem required.

Why this works (reasoning)- Combining consumer-driven contracts with OpenAPI diffs prevents breaking changes from merging and reaching prod: pre-merge automated verification enforces compatibility; registry + gateway ensure runtime enforcement and deprecation lifecycle.- Using CI gates ensures developer workflow stays fast but safe; gateway validation ensures clients can’t bypass CI guarantees.- Observability and governance (owner, timelines, board) provide accountability and reduce surprise breakages.

Example tools & jobs- openapi-diff (CLI) → job: openapi-diff --base published.yml --head mr.yml- Pact Broker + pact-provider-verifier job in GitLab CI- Schemathesis job for fuzzing- API Gateway: Kong/Envoy with schema validation plugin or custom policy reading from Contract Registry

Metrics to track- Merge failures due to compatibility- Number of consumer pact failures- Calls to deprecated versions- Time-to-migration for consumers

This policy is enforceable end-to-end: CI prevents incompatible changes merging, registry centralizes authoritative API contracts, and the gateway enforces runtime behavior and deprecation.

EasyTechnical

26 practiced

A colleague asks: what are the three most common performance pitfalls you see in services running on EKS with sidecar proxies? For each pitfall, provide a brief diagnosis approach and one mitigation you would recommend in the company's context.

Sample Answer

1) CPU contention from sidecar proxies (envoy/istio) starving app containers Diagnosis: Check per-pod CPU usage (kubectl top, Metrics API), container CPU throttling (cadvisor, kubelet metrics), and pod-level CPU limits/requests. Correlate latency spikes with increased proxy CPU. Inspect proxy stats (envoy /stats) for active connections and filter-heavy CPU hotspots. Mitigation: Increase CPU requests for proxy or move proxy to its own QoS class (higher requests), tune proxy worker threads and filters, or run proxy as a dedicated DaemonSet with hostPort/NodePort termination if appropriate. Prefer node-level autoscaling (Cluster Autoscaler + HPA) to relieve CPU pressure.

2) Latency from excessive mutual TLS / TLS handshakes and mTLS CPU cost Diagnosis: Measure request latencies end-to-end and per-hop (app -> sidecar -> remote). Use proxy metrics for TLS handshake counts and CPU. Check connection reuse (keepalives) and observe short-lived connections in app logs or tcpdump. Mitigation: Enable connection pooling / keepalives in clients, enable TLS session resumption where supported, offload TLS to a dedicated gateway for north-south traffic, or tune Istio’s connection and concurrency settings to reduce handshakes.

3) Network throughput limits and head-of-line blocking due to default proxy buffering and MTU/mismatched CNI settings Diagnosis: Run iperf between pods, check proxy and pod network egress/inbound throughput metrics, and inspect proxy buffer/queue metrics. Verify CNI MTU settings and packet fragmentation. Look for increased retransmits in CNI stats. Mitigation: Tune proxy buffer sizes and concurrency, align CNI MTU across cluster, enable direct pod-to-pod routing for high-throughput flows (bypass sidecar for specific traffic via egress/ingress rules), and use network policies to segregate heavy-data paths.

Across all mitigations: codify tuning as part of cluster templates, include observability (prometheus dashboards, distributed traces) in solutions proposals, and validate with load tests before rollout.

Unlock Full Question Bank

Get access to hundreds of Company Specific Technology Knowledge interview questions and detailed answers.

Join thousands of developers preparing for their dream job.