Technology and Platform Selection Questions

Evaluation and justification of technologies services and platforms used to implement systems across the stack. Candidates should be able to select compute options including virtual machines containers and serverless platforms as well as orchestration and workflow engines messaging systems batch and streaming processing engines object and block storage data warehouses and other data platforms. The topic encompasses comparing managed services and self managed deployments cloud versus on premise hosting and choosing frameworks runtimes and overall stacks based on workload characteristics. Assessment focuses on weighing trade offs across cost operational overhead reliability latency and throughput scaling characteristics vendor lock in development velocity team familiarity and learning curve maturity and community support security and compliance and monitoring and debugging complexity. Candidates should demonstrate how system requirements map to service capabilities justify build versus buy decisions and managed service choices design proof of concept experiments and outline migration and rollout planning while making pragmatic choices that balance performance cost and operational risk.

HardTechnical

60 practiced

Design an experiment and set of quantitative metrics to evaluate vendor lock-in risk when adopting a managed serverless FaaS platform for core business logic. Your plan should include technical indicators (proprietary APIs, SDK usage), operational indicators (data egress, monitoring lock-in), business indicators (migration cost, contract terms), and how to measure these during a 3-month POC. Propose thresholds that would trigger rejection or further mitigation.

Sample Answer

Requirements & scope:- Evaluate vendor lock-in risk for a managed FaaS used for core business logic over a 3-month POC.- Focus on technical, operational, and business indicators measurable in the POC. Produce thresholds for accept/reject/mitigate.

Experiment design (high-level):- Implement a representative subset of core logic (3–6 functions) that exercise typical patterns: HTTP triggers, background jobs, state access (DB + object storage), streaming, auth, vendor SDKs, CI/CD, and instrumentation.- Run two parallel branches: “native” implementation using the vendor’s recommended idioms/SDKs, and a “portable-first” variant that uses open standards (HTTP, OpenID Connect, generic SDKs, containerized functions if supported).- Track metrics continuously; run migration simulation tasks at month 2 and 3 (export code/config/data, rewire endpoints, replay traffic).

Technical indicators & measurements:1. Proprietary API surface area - Metric: % of function code lines calling vendor-specific APIs (SDK calls, bindings, annotations). - Measurement: static analysis + dependency graph. - Thresholds: >20% high risk, 5–20% moderate, <5% low.2. Runtime feature dependency - Metric: Count of features not reproducible elsewhere (e.g., proprietary triggers, built-in orchestration). - Measurement: Catalog features used vs. open equivalents; binary flag per feature. - Thresholds: ≥2 proprietary-only features → reject unless mitigated.3. Deployment artifact portability - Metric: Time & steps to produce a runnable artifact off-platform (minutes, manual steps). - Measurement: Attempt to build dockerized or plain code artifact and run locally or in competitor platform. - Thresholds: >8 manual steps or >120 minutes → high risk.

Operational indicators & measurements:4. Data egress and latency cost - Metric: GB egress per month and egress $; additional latency when calling external services. - Measurement: Billing export + synthetic latency tests. - Thresholds: Egress >10% of monthly bandwidth budget or >$1k/mo (example business-bound) → mitigation.5. Monitoring & observability lock-in - Metric: % of telemetry (traces, logs, metrics) requiring vendor agent/format to produce full context. - Measurement: Try exporting telemetry to vendor-neutral systems (OTLP/Prometheus/Jaeger) and measure loss of fields/trace continuity. - Thresholds: >30% loss → moderate risk; >60% loss → reject unless open export implemented.6. Operational runbook portability - Metric: Number of runbook procedures relying on vendor console-only actions. - Measurement: Catalog runbook steps for deployments, rollbacks, incident responses; attempt to execute without console. - Thresholds: >3 console-only critical steps → mitigate.

Business indicators & measurements:7. Migration cost estimate - Metric: Estimated person-hours to migrate core functions off-platform (hrs) and $ cost. - Measurement: Use results from migration simulations and effort logging. - Thresholds: >200 dev-hours or >$50k → high risk.8. Contract and data ownership - Metric: Days of notice to terminate, data export SLA, data deletion guarantees, termination fees. - Measurement: Legal review scoring (0–10) on favorable terms. - Thresholds: Notice >90 days, export SLA >30 days, or fees present → moderate/high risk.9. Vendor feature roadmap dependency - Metric: Fraction of planned critical features tied to vendor roadmap. - Measurement: Product/PM interview + vendor roadmap mapping. - Thresholds: >25% features vendor-dependent → mitigation.

POC measurement plan (3 months):- Week 0–2: Instrumentation and baseline: implement both branches, enable billing/telemetry exports, static analysis tools.- Week 3–6: Load & feature exercise: generate synthetic and some production-mirror traffic; collect metrics.- End of month 2: First migration simulation—export code/config/data; time migration steps and record blockers.- Month 2–3: Harden observability and attempt vendor-neutral monitoring; perform security review.- End of month 3: Final migration test and full metric aggregation; legal contract assessment.

Decision matrix & thresholds:- Reject if ANY: - Proprietary-only features ≥2, OR - Telemetry loss >60%, OR - Migration estimate >200 dev-hours, OR - Legal review score ≤4 (highly unfavorable).- Require mitigation if ANY: - Proprietary surface >20%, OR - Egress costs >10% of budget, OR - Runbook has >3 console-only steps, OR - Notice period >60 days or export SLA >14 days.- Acceptable if all core metrics in low/moderate bands and mitigation plan documented; acceptance requires documented rollback/migration plan with verified export and CI/CD portability.

Mitigations:- Restrict new development to vendor-agnostic patterns; wrap vendor SDK calls in adapter layer.- Implement OTLP/Prometheus/Jaeger exports; enforce structured logs.- Maintain CI that can deploy to an alternate target (containers or competing FaaS).- Contractually require exportability and shorter termination/export SLAs.

Why this works:- Combines measurable technical, operational, and contractual indicators with real migration attempts so estimates are empirical not theoretical.- Provides actionable thresholds for engineering and business stakeholders to decide accept/reject/mitigate within the POC timeframe.

HardTechnical

63 practiced

You are an engineering lead selecting a new platform (e.g., migrating from VMs to Kubernetes) that the team has not used. Describe a plan for ramping the team: training curriculum, pilot project selection, mentorship and pairing, success metrics, timeline, and how to measure adoption and technical debt introduced by the platform change.

Sample Answer

Situation: We need to migrate from VMs to Kubernetes and ramp a team with no prior K8s experience while minimizing risk and hidden technical debt.

Plan (high-level phases, ~4–6 months):1. Discover & Align (2 weeks)- Goals: business drivers, success metrics, non-functional constraints (SLA, compliance).- Identify low-risk pilot candidate(s) and stakeholders.

2. Training Curriculum (3 weeks + ongoing)- Week 1 (Foundations): Containers, Docker best practices, K8s primitives (Pods, Services, Deployments), manifests.- Week 2 (Platform & Patterns): Helm, ConfigMaps/Secrets, Namespaces, RBAC, Networking (Ingress/ServiceMesh intro), Storage, CI/CD integration.- Week 3 (Ops & Security): Observability (Prometheus/Grafana, logs), SLO/alerting, backup, security posture, pod lifecycle, resource requests/limits.- Delivery: mix of instructor-led workshops, hands-on labs, and bite-sized e-learning. Final assessment: deploy a sample app end-to-end.

3. Pilot Project (6–8 weeks)- Selection criteria: small, non-critical service with clear owner, bounded state, automated tests, CI in place.- Goals: production-like deployment, autoscaling, rollbacks, monitoring, and disaster recovery runbook.- Deliverables: helm chart, CI pipeline, runbook, postmortem.

4. Mentorship & Pairing- Create 2-track model: Platform team (experts/SREs) + feature teams.- Pair programmers: 1 platform engineer paired 1–2 days/week with pilot devs.- Office hours, Slack channel, rotate pairings so knowledge spreads.- Internal “K8s guild” for sharing patterns and reviewing charts.

5. Success Metrics & Adoption Measurement- Adoption metrics (weekly/monthly): % services migrated, % deployments via CI->K8s, time to deploy, deployment frequency, lead time for changes.- Reliability metrics: error rate, MTTR, SLO compliance.- Knowledge metrics: % engineers certified/assessed, number of successful independent deployments.

6. Measuring Technical Debt Introduced- Track debt items created during migration as explicit Jira epics tagged "k8s-debt".- Quantitative signals: increase in open incidents, flaky tests, pod restarts, resource over/under-provisioning, security scan findings, and manual rollback occurrences.- Periodic tech-debt sprints: dedicate 10–20% capacity post-pilot to pay down critical debt.- Use code/config linters (kubeval, helm lint), policy-as-code (OPA/Gatekeeper) to prevent drift.

Timeline summary:- Weeks 0–2: Align + prep- Weeks 3–5: Training + labs- Weeks 6–13: Pilot implementation + mentoring- Weeks 14–24: Gradual rollout (by risk), measurement, remediation cycles

Why this works:- Combines deliberate learning with hands-on practice.- Pilot minimizes blast radius and produces repeatable artifacts (charts, CI patterns).- Mentorship ensures tacit knowledge transfer and faster troubleshooting.- Explicit metrics and tracked debt make trade-offs visible and actionable.

MediumSystem Design

64 practiced

You must choose a platform for microservices that experience frequent short bursts and also run long-running batch jobs (hours). Evaluate managed Kubernetes (EKS/GKE) versus serverless functions (FaaS) and a hybrid approach (k8s for long jobs, serverless for bursty endpoints). Discuss cost, cold starts, scaling granularity, runtime limits, developer experience, and operations. Recommend a platform and justify migration considerations.

Sample Answer

Requirements recap:- Frequent short bursty HTTP endpoints (spiky, low-latency)- Long-running batch jobs (hours)- Cost-sensitive but values developer velocity and reliability- Need fine-grained scaling and operational simplicity where possible

Evaluation summary:

1) Managed Kubernetes (EKS/GKE)- Cost: Higher base cost (nodes, reserved capacity) but efficient for sustained load and long jobs; can use spot/Preemptible to reduce costs.- Cold starts: None for in-cluster services (always warm if pod density maintained).- Scaling granularity: Pod-level; autoscaler (HPA/VPA/KEDA) gives good control but scaling is heavier (minutes to scale many pods).- Runtime limits: No hard runtime limits — ideal for hours-long batches.- Developer experience: More complex (containerization, manifests, CI/CD, debugging). Good for polyglot workloads.- Operations: Requires cluster management, upgrades, observability, security hardening.

2) Serverless Functions (FaaS)- Cost: Very cost-effective for highly spiky, low-utilization endpoints (pay-per-invoke).- Cold starts: Real issue for latency-sensitive endpoints; mitigations (provisioned concurrency) add cost.- Scaling granularity: Very fine (per-request); near-instant concurrency.- Runtime limits: Provider-enforced timeouts (often 15m) — unsuitable for multi-hour batches.- Developer experience: Fast to iterate for simple endpoints; limited local debugging and dependency management complexity can grow.- Operations: Minimal infra ops; vendor lock-in and observability differences.

3) Hybrid (k8s for long jobs, serverless for bursty endpoints)- Cost: Best of both worlds: serverless for spiky, k8s for long/steady workloads; complexity increases.- Cold starts: Reduced impact on user-facing latency by using FaaS with provisioned concurrency or edge caches for critical endpoints.- Scaling granularity: Optimal: FaaS handles rapid concurrency; k8s handles heavyweight batch scale.- Runtime limits: Resolved by running long jobs on k8s.- Developer experience: More moving parts but teams can specialize; CI/CD pipelines must handle both artifacts and functions.- Operations: Slightly higher ops than pure FaaS but less than full-on k8s-only for services.

Recommendation:Adopt a hybrid approach. Use serverless functions (with provisioned concurrency for critical low-latency endpoints) for stateless, bursty APIs; run long-running batch jobs and stateful/memory-heavy services on managed Kubernetes. This minimizes cost for spiky traffic, avoids FaaS runtime limits, and leverages k8s for complex jobs.

Migration considerations:- Incremental migration: start by moving short, stateless endpoints to FaaS while keeping batch on k8s.- CI/CD: add pipelines for both function deployments and container images; standardize observability (distributed tracing, metrics) across both platforms.- Networking/security: ensure consistent auth, VPC access, and secrets management (IAM roles, service mesh or API gateway).- Cost ops: monitor cost by workload; use autoscaling policies, spot instances for batch, and tune provisioned concurrency.- Operational playbooks: define runbooks, SLOs, and test failover paths (e.g., if FaaS limits hit, fallback to k8s endpoints).

This hybrid minimizes latency and cost while supporting long-running jobs and gives teams room to converge tooling (containers/functions) over time.

MediumTechnical

59 practiced

You run large daily batch jobs with flexible deadlines but sometimes hard deadlines (must finish within 2 hours). Decide when to use spot/preemptible instances versus on-demand instances. Propose a scheduling and checkpointing strategy that minimizes cost while meeting deadlines with high confidence. Include fallback strategies and how to tune capacity buffers.

Sample Answer

Summary decision rule:- Use spot/preemptible instances for non-critical, long-running or flexible-deadline batches where cost reduction matters and you can tolerate occasional preemption.- Use on-demand for tasks with hard deadlines (must finish within 2 hours), for short critical phases near the deadline, or for control-plane services (coordinator, checkpoint storage).

Scheduling & checkpointing strategy:1. Job classification - Flexible: jobs with slack > 30% of expected runtime. - Soft-critical: slack between 10–30%. - Hard-critical: slack < 10% or explicit 2-hour deadline.

2. Baseline execution - Start most work on spot instances to save cost. - Persist periodic checkpoints to durable storage (S3/GCS) every T minutes or after X work units. - Choose checkpoint interval using Young/Daly approximation: T* ≈ sqrt(2 * MTTR * MTBF * C_overhead) simplified—practically, for frequent preemptions use 5–15 minute checkpoints; for stable markets 15–60 minutes.

3. Dynamic safety ramp before deadlines - Define a safety buffer B (e.g., 15–25% of remaining time or fixed 20 minutes). - When remaining time <= B, migrate remaining tasks to on-demand instances (or immediately provision on-demand capacity to complement spots). - Implement a rolling checkpoint and restart on on-demand if preemption occurred near deadline.

4. Capacity & autoscaling - Maintain a small on-demand baseline capacity (capacity buffer) sized to run the critical tail of workload: for N average concurrent critical tasks, buffer = ceil(N * p_timeout), where p_timeout is probability of spot shortfall tolerated (e.g., 0.05). Practically start with 5–10% of peak as on-demand. - Use predictive autoscaler: monitor spot market trends, preemption rate, and queue depth; if preemption rate rises above threshold, increase on-demand proportion.

5. Fallbacks & reliability - Fast fallback: if a spot is reclaimed and remaining job time + restart + provisioning > safety buffer, immediately reschedule that task on on-demand. - Global fallback: if overall preemption spike threatens meeting SLAs (based on simulation of current queue), switch new task launches to on-demand until risk subsides. - Use multi-zone and instance-type diversification to reduce correlated preemptions.

Operational tuning:- Measure MTTR (mean time to reclaim) and actual preemption frequency daily; adjust checkpoint interval T and buffer B accordingly.- Run A/B cost vs. success experiments: simulate deadline miss rate vs. % on-demand to find cost-optimal point under target confidence (e.g., 99% on-time).- Start conservative (10–15% on-demand buffer) and reduce if historical miss rate << target.

Implementation notes:- Keep checkpointing orthogonal: tasks must be resumable from checkpoints.- Coordinator tracks task progress, remaining work, and enforces the safety ramp decision.- Use spot fleets/instance groups with diversified types and fast-launch AMIs to minimize recovery time.

Example:- A 3-hour flexible job: run on spot with 15-min checkpoints. At 30 minutes before soft deadline, ensure at least 25% of remaining parallel capacity is on-demand; at 20 minutes (safety buffer) switch remaining tasks to on-demand to guarantee finish within 2 hours with >99% confidence.

This approach balances cost by maximizing spot use early, minimizes wasted work via checkpointing, and guarantees deadlines by switching to on-demand capacity within a tuned safety window and buffer.

MediumTechnical

60 practiced

Compare using a managed queuing service like AWS SQS against Redis Streams for background job processing that requires low latency (<50ms), at-least-once delivery, delayed retries, and occasional re-delivery. Discuss persistence, scaling, ordering guarantees, operational cost, and how you would implement deduplication and visibility timeouts in each system.

Sample Answer

Situation: You need low-latency (<50ms), at-least-once delivery with delayed retries and occasional redelivery. Both SQS and Redis Streams can work, but they differ across persistence, scaling, ordering, cost, and operational models.

Comparison (high level)- Persistence: SQS is durable by default (stored across AWS AZs). Redis persistence depends on RDB/AOF and cluster durability; a crash can lose recent writes unless AOF with fsync is used—so tune persistence for durability which may increase latency.- Latency: Redis Streams typically gives lower and more predictable latency (<50ms easily) because it's in-memory. SQS has higher and more variable latencies (tens to hundreds ms), though SQS FIFO reduces variability.- Scaling: SQS is fully managed and horizontally scales without ops work. Redis requires provisioning cluster nodes, scaling shards, and handling rebalancing—more ops but can be tuned for high throughput.- Ordering guarantees: SQS FIFO supports strict ordering and exactly-once via deduplication window; standard SQS is at-least-once, unordered. Redis Streams preserves insertion order per stream and consumer group, but ordering across shards requires extra design.- Operational cost: SQS is pay-per-request with cheap ops and no infra maintenance. Redis has instance/cluster costs and ops (backup, monitoring, failover), but can be cost-efficient at very low-latency high-throughput workloads.

Implementing required features

At-least-once & visibility timeout- SQS: Use visibility timeout per queue; on failure do not delete message so it becomes visible again. Tune visibility timeout > expected max processing time and use ChangeMessageVisibility to extend. Use Dead-Letter Queues (DLQ) for maxReceiveCount.- Redis Streams: Use consumer groups (XREADGROUP) and rely on pending entries list (PEL). On failure, don't XACK; a re-delivery process (XCLAIM or XPENDING→XCLAIM) moves stuck messages back to consumers after a timeout. Implement per-message processing deadlines in app or use a separate reclaimer coroutine.

Delayed retries- SQS: Support via DelaySeconds or by re-sending to a delay queue or using per-message delay in FIFO through message timers. Use DLQ for poisoned messages.- Redis Streams: Implement by moving messages to a sorted set with visibility timestamp or to a delay stream; a scheduler polls/sweeps the delay store and XADDs back into main stream when due.

Deduplication- SQS: FIFO queues provide automatic deduplication if a MessageDeduplicationId is supplied (or content-based). For standard SQS, dedupe must be at application level using an external idempotency store (DynamoDB with TTL).- Redis Streams: Maintain an idempotency store (Redis hash or separate DB) keyed by business id with TTL; use WATCH+transaction or Lua script to atomically check-and-add to stream to prevent duplicates. Alternatively use the stream message ID externally as dedupe key when re-pushing.

Recommendations- If absolute low latency (<50ms) and you can manage availability/persistence tradeoffs, use Redis Streams with careful persistence (AOF fsync compromise), consumer-group reclaimer, and a TTL-based idempotency store implemented in Redis (atomically via Lua). Shard thoughtfully to preserve ordering per key.- If you prefer minimal ops, strict durability, and simpler delivery semantics, use SQS FIFO (if ordering required) or standard SQS with idempotency in DynamoDB; accept slightly higher latency.

Edge considerations- Measure end-to-end latencies in realistic load, tune Redis persistence vs latency, and ensure your visibility/claiming logic handles worker crashes and long-running tasks. Use monitoring/metrics (XINFO, CloudWatch) and chaos tests to validate redelivery behavior.

Unlock Full Question Bank

Get access to hundreds of Technology and Platform Selection interview questions and detailed answers.

Join thousands of developers preparing for their dream job.