Technical Tools and Stack Proficiency Questions

Assessment of a candidates practical proficiency across the technology stack and tools relevant to their role. This includes the ability to list and explain hands on experience with programming languages, frameworks, libraries, cloud platforms, data and machine learning tooling, analytics and visualization tools, and design and prototyping software. Candidates should demonstrate depth not just familiarity by describing specific problems they solved with each tool, trade offs between alternatives, integration points, deployment and operational considerations, and examples of end to end workflows. The description covers developer and data scientist stacks such as Python and C plus plus, machine learning frameworks like TensorFlow and PyTorch, cloud providers such as Amazon Web Services, Google Cloud Platform and Microsoft Azure, as well as design tools and research tools such as Figma and Adobe Creative Suite. Interviewers may probe for evidence of hands on tasks, configuration and troubleshooting, performance or cost trade offs, versioning and collaboration practices, and how the candidate keeps skills current.

EasyTechnical

58 practiced

Explain how Prometheus and Grafana work together in an observability stack. Describe what kinds of metrics you would export from a web service, how to instrument them, and how to avoid cardinality explosion in Prometheus.

Sample Answer

Prometheus and Grafana complement each other: Prometheus scrapes and stores time-series metrics (pull model), evaluates alerts, and provides a query language (PromQL). Grafana visualizes Prometheus metrics and builds dashboards/alerts from PromQL queries.

Metrics to export from a web service:- Request rate: counter (http_requests_total{method,handler,status})- Latency: histogram or summary (http_request_duration_seconds_bucket)- Error rate: counter (http_errors_total{handler,status})- Resource usage: process_cpu_seconds_total, process_resident_memory_bytes- Business metrics: active_users_gauge, queue_length_gauge

Instrumenting (example in Python using prometheus_client):

python

from prometheus_client import Counter, Histogram, start_http_server
REQUESTS = Counter('http_requests_total','', ['method','handler','status'])
LATENCY = Histogram('http_request_duration_seconds','', ['handler'])

# In request handler:
with LATENCY.labels(handler="/login").time():
    REQUESTS.labels(method="POST", handler="/login", status="200").inc()

Serve /metrics endpoint; Prometheus scrapes it.

Avoiding cardinality explosion:- Limit label values: avoid user IDs, session IDs, UUIDs as labels.- Use coarse labels (status_class=5xx) and put high-cardinality data in logs/traces.- Cardinality caps: enforce whitelist of handlers, or bucketize values (e.g., latency ranges).- Aggregate before labeling (e.g., hash to fixed buckets) and use histograms for distributions.

Best practices: use stable label keys, document metrics, add unit suffixes, and test scrape performance. Grafana then builds dashboards (rate(), histogram_quantile()) and alerting rules based on those metrics.

MediumTechnical

52 practiced

Describe secure approaches to store and rotate application secrets across environments (local, dev, staging, prod). Compare HashiCorp Vault and AWS Secrets Manager and explain how you would implement automatic rotation and access policies.

Sample Answer

Secure approaches:- Never hard-code secrets. Use a centralized secrets manager for dev/staging/prod; local use short-lived developer tokens or a local dev Vault with tightly-scoped credentials.- Follow least privilege, separation of duties, environment-specific namespaces, and audit logging. Encrypt secrets at rest and in transit (TLS), enforce MFA and key rotation.

HashiCorp Vault vs AWS Secrets Manager:- Vault: vendor-neutral, powerful dynamic secrets (DB, SSH), lease/renew model, flexible auth backends (Kubernetes, AppRole, OIDC), policy language (HCL), strong secret revocation. Good for multi-cloud/hybrid and advanced workflows.- AWS Secrets Manager: fully managed, integrates with RDS for rotation, native IAM-based access, simpler to operate in AWS-centric infra, built-in rotation Lambda support, per-secret pricing.

Automatic rotation & implementation:- Dynamic secrets (preferred): Vault generates DB credentials per-client with TTL; Vault revokes automatically when TTL expires. Implementation: configure database secrets engine, create role with SQL templates, apps authenticate via AppRole/Kubernetes and request credentials.- AWS Secrets Manager rotation: attach a rotation Lambda that creates new DB user, updates secret, tests, and swaps. Use Secrets Manager automatic rotation (7/30-day schedule).- For both, supply apps using short-lived tokens/credentials fetched at startup and cached briefly; implement retry/backoff and credential refresh before expiry.

Access policies examples:- Vault policy (HCL):

hcl

path "secret/data/prod/*" {
  capabilities = ["read"]
}
path "database/creds/prod-app" {
  capabilities = ["read"]
}

- AWS IAM policy (JSON):

json

{
  "Version":"2012-10-17",
  "Statement":[
    {"Effect":"Allow","Action":["secretsmanager:GetSecretValue"],"Resource":"arn:aws:secretsmanager:us-east-1:123456789012:secret:prod/*"}
  ]
}

Deployment notes:- Use auth methods aligned to runtime: EC2/ECS/IAM roles or Kubernetes ServiceAccount + IRSA for AWS; use Vault Kubernetes auth or AppRole for k8s.- Local dev: use Vault dev server or a dev-only secrets file protected by OS keyring or direnv; never commit secrets.- Monitoring: enable audit logs, alert on failed accesses, rotation errors, and unusual read patterns.- CI/CD: grant pipeline ephemeral access via short-lived tokens; avoid baking secrets into images; inject at deploy time with sidecar or environment injection.

Trade-offs:- Choose Vault if you need multi-cloud, dynamic credentials, or advanced secret types. Choose AWS Secrets Manager for lower ops overhead within AWS and straightforward integration.

MediumSystem Design

89 practiced

Design a CI/CD pipeline for a microservices application with ~20 services in separate repos. Include build parallelism, artifact repository choice, integration testing, canary releases, and automated rollback mechanisms. Mention tools you would use and why.

Sample Answer

Requirements & constraints:- ~20 independent service repos, CI per-repo, fast feedback, parallel builds, immutable artifacts, integration/e2e tests, gradual (canary) production rollout, automatic rollback on bad metrics, observable.

High-level architecture:- GitHub (or GitLab) for source → CI orchestrator (Jenkins X / Jenkins with Kubernetes agents or GitHub Actions runners) → Artifact repo (JFrog Artifactory or Sonatype Nexus) → Container registry (Harbor/ECR/GCR) → Kubernetes cluster(s) with service mesh (Istio/Linkerd) → CD controller (ArgoCD/Spinnaker/Argo Rollouts + Flagger) → Monitoring (Prometheus + Grafana) + APM (Jaeger/NewRelic).

Key components & choices:1. CI orchestration & parallel builds- Use Jenkins on Kubernetes with dynamic agents (K8s plugin) or GitHub Actions self-hosted runners. Each repo has its Jenkinsfile/workflow; a central Jenkins controller schedules per-repo pod agents so builds run in parallel across services.- Use pipeline templates/Shared Libraries to enforce consistency.- Cache dependencies (Maven/Gradle/npm) using a cache service to speed repeated builds.

2. Artifact repository & image storage- Use Artifactory or Nexus for binaries and Helm charts; push immutable Docker images to ECR/GCR/Harbor with tagging: <service>:<git-sha>-<semver>.- Store Helm charts (or OCI Helm) in the artifact repo to version releases.

3. Integration & testing- CI stages: unit tests → build → publish artifact/image → integration tests triggered in ephemeral test namespace in Kubernetes using test harness. Use contract tests (PACT) and consumer-driven contracts where applicable.- Run parallel integration tests per service group; spin up required dependent services as test doubles or real ephemeral deployments using Helm/Kustomize.

4. Canary releases & promotion- Use Argo Rollouts or Flagger with Istio to implement progressive canaries (traffic shifting, header-based targeting). CD pipeline pushes new manifests (Helm + image tag) to ArgoCD which syncs to cluster. Argo Rollouts controls gradual traffic increase (e.g., 5% → 25% → 100%) with evaluation windows.

5. Automated rollback- Define success criteria: SLOs/metrics (error rate, latency, business KPIs). Flagger/Argo Rollouts integrates with Prometheus and runs metric analysis during canary. If thresholds are breached, CD controller triggers automated rollback to previous stable revision. Also support manual approval gates via Slack/PR.- Keep immutable artifacts and retain previous manifests/images to revert quickly.

6. Observability & safety nets- Prometheus + Grafana + Alertmanager, distributed tracing with Jaeger, logs in ELK/Fluentd. Add chaos testing in staging.- Security scanning (Snyk/Trivy) in CI and image signing (Cosign) before deployment.

Data flow / pipeline example:- Developer opens PR → CI runs linters/unit tests in parallel agents → on merge, build image & push to registry, publish artifact to Artifactory → trigger integration pipeline which deploys to ephemeral namespace and runs integration/e2e/contract tests → if green, create Helm release and push to CD repo → ArgoCD notices change and creates Argo Rollout which performs canary using Istio; Prometheus evaluates metrics → success promotes, failure auto-rollback and alerts.

Scalability & trade-offs:- Jenkins + K8s agents scales build capacity; GitHub Actions simpler but may cost more at scale. ArgoCD + Argo Rollouts offers GitOps traceability; Spinnaker is heavier but powerful for multi-cloud enterprises.- Trade-off: full automation requires robust metric definitions to avoid false rollbacks; invest in good observability and contract tests to reduce blast radius.

This design provides fast parallel CI, immutable artifacts, robust integration testing, controlled canary deployments, and automated rollback driven by observable metrics using industry-proven tools.

EasyTechnical

47 practiced

Describe how you typically configure your IDE and developer environment for productivity (language tools, linters, formatters, debug configuration). Pick one stack (e.g., Python + VS Code or Java + IntelliJ) and list specific extensions and settings you find essential.

Sample Answer

I use Python + VS Code and configure it to reduce friction, enforce consistency, and speed up debugging.

Key extensions:- Python (ms-python.python) — core language support, linting, IntelliSense.- Pylance — fast type checking and auto-complete.- isort, Prettier (or Python autopep8/black integration) — import/order & formatting.- Flake8 or pylint — linting rules.- GitLens — git context and blame.- Docker — container dev + compose integration.- EditorConfig — consistent whitespace across editors.

Essential settings (settings.json excerpt):

json

{
  "python.pythonPath": "${workspaceFolder}/venv/bin/python",
  "python.formatting.provider": "black",
  "python.linting.enabled": true,
  "python.linting.flake8Enabled": true,
  "editor.formatOnSave": true,
  "editor.codeActionsOnSave": {
    "source.organizeImports": true,
    "source.fixAll": true
  },
  "python.analysis.typeCheckingMode": "basic"
}

Debug configuration (launch.json excerpt):

json

{
  "version": "0.2.0",
  "configurations": [
    {
      "name": "Python: Attach (Remote)",
      "type": "python",
      "request": "attach",
      "connect": {"host": "localhost", "port": 5678},
      "pathMappings": [{"localRoot": "${workspaceFolder}", "remoteRoot": "/app"}]
    }
  ]
}

Workflow notes:- Use a venv per project and set pythonPath to it.- Auto-format on save with Black and organize imports with isort to keep PRs clean.- Enforce linting in CI (flake8/pylint) with the same rules as local to avoid “works on my machine”.- Use Pylance for faster static analysis and type hints; add mypy in CI for stricter checks when needed.- Add VS Code tasks for test runs (pytest) and Docker compose up to streamline dev loops.

This setup keeps feedback immediate, PRs consistent, and debugging straightforward.

EasyTechnical

52 practiced

Explain the difference between git merge and git rebase. Provide a concise example workflow (commands) in which you would prefer rebase over merge, outline the risks of rewriting history on shared branches, and describe how to recover if a rebase goes wrong.

Sample Answer

git merge vs git rebase — short:- merge: combines two branches by creating a new commit that preserves both branches’ history (non‑destructive). Good for public/shared history.- rebase: moves (replays) your commits onto a new base, producing a linear history as if you developed from that base (rewrites commit hashes).

When to prefer rebase (concise workflow):- You have a feature branch and want a clean linear history before opening a PR.

Example commands:

bash

# on feature branch
git checkout feature
git fetch origin
git rebase origin/main   # replay feature commits on top of latest main
# resolve conflicts if any, then:
git rebase --continue
# fast-forward/main stays linear; push (force-with-lease required)
git push --force-with-lease origin feature

Risks of rewriting history on shared branches:- If others have based work on the original commits, rebasing and force-pushing will change commits they reference, causing merge conflicts, duplicated commits, or lost work.- Can break CI or PRs that rely on previous commit IDs.

How to recover if a rebase goes wrong:- Abort mid-rebase:

bash

git rebase --abort

- If you completed a bad rebase and force-pushed, recover original branch using the reflog (locally) or the remote branch’s old ref:

bash

# find lost commit
git reflog
git checkout -b recover <commit-hash>
# or reset branch to the previous remote: 
git fetch origin
git reset --hard origin/feature@{1}   # careful: this overwrites local

Best practice: rebase local/private branches only, communicate before force-push, and use --force-with-lease to reduce risk.

Unlock Full Question Bank

Get access to hundreds of Technical Tools and Stack Proficiency interview questions and detailed answers.

Join thousands of developers preparing for their dream job.