← Salesforce Interview Insights

Salesforce·Software Engineer·Onsite - System Design / Architecture·Senior

Senior
Jun 2026

Summary

Salesforce software engineer interview that went deep on Kubernetes internals, production debugging, and platform security. Three meaty questions back to back with no warmup fluff, which I appreciated but also was not fully ready for.

Questions Asked (3)

Q1

Walk through each component of the Kubernetes control plane and explain what the worker nodes are responsible for.

System DesignTechnical Trade-offs
Author's notes

Felt okay on this one.

Create a free account to read the full note

AI HintsAI Generated

Suggested Approach

Start by defining the control plane as the cluster's brain and worker nodes as the muscle, then systematically walk through each control plane component (API server, etcd, scheduler, controller manager, cloud controller manager) and explain how they interact. Finally, describe worker node responsibilities (kubelet, kube-proxy, container runtime) and how they execute workloads, emphasizing the separation of concerns and trade-offs like scalability and fault tolerance.

Pro tip: Tie each component to a real-world failure scenario or trade-off—e.g., how etcd latency impacts API server responsiveness—to show depth beyond memorization. Mention that Salesforce runs on Kubernetes, so understanding these internals is critical for building resilient multi-tenant services.

1. Define the control plane and worker nodes

Briefly state that the control plane manages cluster state and makes global decisions, while worker nodes run the actual application workloads. This sets the stage for a clear separation of responsibilities.

2. Walk through control plane components

Explain each component: API server (front door, REST endpoint), etcd (consistent key-value store for cluster state), scheduler (assigns pods to nodes), controller manager (runs controllers to reconcile desired state), and cloud controller manager (integrates with cloud provider APIs).

3. Describe worker node responsibilities

Detail how kubelet manages pod lifecycle on the node, kube-proxy handles network routing, and the container runtime (e.g., containerd) runs containers. Emphasize that worker nodes report status back to the control plane.

4. Explain interactions and trade-offs

Discuss how components communicate (e.g., kubelet watches API server, scheduler binds pods) and highlight trade-offs like high availability of control plane vs. cost, or etcd performance vs. cluster size.

5. Summarize with a real-world example

Give a concise example of deploying a pod: API server receives request, etcd stores it, scheduler assigns node, kubelet starts container, and status updates flow back. This reinforces understanding.

Key Points to Mention

  • API server as the central communication hub and only component that talks to etcd
  • etcd as the source of truth for cluster state, with consistency and backup considerations
  • Scheduler's role in filtering and scoring nodes, and its pluggable architecture
  • Controller manager's reconciliation loops (e.g., node controller, deployment controller)
  • Kubelet as the node agent that registers the node and manages pod specs
  • Kube-proxy and container runtime (e.g., containerd, CRI-O) for networking and execution

AI-generated suggestions, not part of the candidate's original notes. May be inaccurate — verify before relying on them.

Q2

A deployment rollout is stuck in CrashLoopBackOff. What kubectl commands do you run and what are you looking for at each step?

Root Cause AnalysisTechnical Trade-offs
Author's notes

This was the most fun question and also where I embarrassed myself a bit.

Create a free account to read the full note

AI HintsAI Generated

Suggested Approach

Start by describing the systematic debugging process: first get an overview of the pod status, then dive into logs and events, and finally inspect the pod configuration. Emphasize that you're looking for patterns like application errors, configuration issues, or resource constraints at each step.

Pro tip: Mention that you always check the previous container logs with `kubectl logs --previous` because the current container may have already restarted, and the crash cause is often in the previous instance. Also, use `kubectl describe pod` to see events and resource limits, which can reveal OOMKills or scheduling issues.

1. Get an overview of the pod status

Run `kubectl get pods` to identify the crashing pod and its restart count. Then use `kubectl describe pod <pod-name>` to see events, container statuses, and resource limits.

2. Inspect container logs

Check current logs with `kubectl logs <pod-name>` and previous logs with `kubectl logs <pod-name> --previous` to find application errors or crash reasons.

3. Examine the pod's configuration

Use `kubectl get pod <pod-name> -o yaml` to review environment variables, volume mounts, and command/args for misconfigurations.

4. Check for resource constraints and node issues

Look for OOMKilled status in `kubectl describe pod` and check node conditions with `kubectl describe node <node-name>` if needed.

5. Correlate with deployment and recent changes

Run `kubectl rollout history deployment/<deployment-name>` and compare with recent changes to identify if a new rollout introduced the issue.

Key Points to Mention

  • Use `kubectl describe pod` to see events and container statuses, including exit codes and reasons like OOMKilled or Error.
  • Check both current and previous container logs with `kubectl logs` and `--previous` flag.
  • Inspect the pod's YAML for misconfigured environment variables, missing ConfigMaps/Secrets, or incorrect volume mounts.
  • Look for resource limits and requests that might cause OOMKills or CPU throttling.
  • Consider liveness and readiness probe failures that could lead to restart loops.
  • Correlate with recent deployment changes using `kubectl rollout history` and `kubectl rollout status`.

AI-generated suggestions, not part of the candidate's original notes. May be inaccurate — verify before relying on them.

Q3

Design a security hardening plan for a Kubernetes cluster and an end-to-end CI/CD pipeline on a managed Kubernetes service that supports canary releases and rollbacks.

System DesignTechnical Trade-offsAPI & Integrations
Author's notes

Two questions in one, which felt like a lot.

Create a free account to read the full note

AI HintsAI Generated

Suggested Approach

Structure your answer by first outlining the security hardening layers for the managed Kubernetes cluster, then detailing the CI/CD pipeline stages with integrated security controls, and finally explaining the canary release and rollback mechanisms. Emphasize how security is embedded throughout the pipeline and how canary releases enable safe, incremental rollouts with automated rollback triggers.

Pro tip: Leverage the managed service's built-in security features (e.g., AWS EKS with IAM roles for service accounts, Azure AKS with Azure AD integration) to reduce operational overhead, and use progressive delivery tools like Argo Rollouts or Flagger to automate canary analysis and rollbacks based on metrics.

1. Cluster Security Hardening

Secure the managed Kubernetes cluster by implementing network policies, RBAC with least privilege, pod security standards, and secrets management. Enable audit logging and integrate with cloud provider IAM for authentication and authorization.

2. CI/CD Pipeline Security Integration

Incorporate security checks at each stage: SAST, DAST, dependency scanning, container image scanning, and signing. Use immutable infrastructure and store artifacts in a secure registry with vulnerability scanning.

3. Canary Release Strategy

Implement canary releases using a service mesh or progressive delivery tool. Define metrics (e.g., error rate, latency) and thresholds for promotion or rollback. Automate traffic shifting and analysis.

4. Rollback Mechanism

Design automated rollback triggers based on canary analysis failures or manual intervention. Ensure rollback is fast and reliable, with versioned artifacts and declarative configurations.

5. Monitoring and Observability

Set up comprehensive monitoring, logging, and tracing to detect anomalies during canary releases. Use tools like Prometheus, Grafana, and Jaeger to provide visibility and inform rollback decisions.

Key Points to Mention

  • Use of managed Kubernetes features like IAM integration, network policies, and pod security policies
  • Shift-left security: integrating SAST, DAST, and dependency scanning in CI
  • Container image signing and admission controllers (e.g., OPA/Gatekeeper) to enforce policies
  • Progressive delivery tools (Argo Rollouts, Flagger) for automated canary analysis and rollback
  • Metrics-driven canary promotion with thresholds (e.g., error rate < 1%, latency < 100ms)
  • Immutable infrastructure and GitOps for declarative, version-controlled deployments

AI-generated suggestions, not part of the candidate's original notes. May be inaccurate — verify before relying on them.