PART 1. WHAT YOU KNOW ABOUT THRIVE (use this in your answers)

  • Company is 10+ years old, everything runs on AWS.
  • Core app is PHP, mostly APIs for mobile apps, plus smaller APIs.
  • They moved from a Puppet-based system to Kubernetes on EKS.
  • CI is GitHub Actions, CD is Argo CD.
  • Still have legacy systems in different AWS accounts. They want to move them into the main prod account (caches, ALBs, services).
  • Biggest priorities: cost, legacy migration, Kubernetes work.
  • Most incidents are app-related: DB slowness or cache issues make PHP-FPM workers fill up, Nginx upstream queues grow, error rate goes up.
  • One past infra issue: CPU steal on Kubernetes nodes.
  • They care about early signals, SLOs, and error rate. They are starting to use AI for monitoring.
  • They scale on PHP-FPM busy workers, not CPU, because CPU is a late signal.

Use these words in your answers: early signals, user impact, step by step, reduce cost, reduce risk, root cause.

PART 2. KEEP YOUR STORY CONSISTENT

  • Current/last company: FitTech (Senior SRE, Jan 2024 – now). Update the resume.
  • Home Depot: DevOps Engineer, 2022–2023.
  • XPO Logistics: Cloud/DevOps Engineer, 2020–2021.
  • Cost savings: 28% everywhere.
  • Be ready to explain the 28%: rightsizing EC2 and EKS nodes, tuning pod requests, deleting unused EBS/snapshots/ALBs, shutting down dev/test at night, Terraform defaults, cost alerts.

PART 3. KUBERNETES

Troubleshooting order (say it out loud like this):

  1. kubectl get pods -n ns – check status.
  2. kubectl describe pod – read Events at the bottom.
  3. kubectl logs pod, and kubectl logs pod --previous if it crashed.
  4. kubectl get svc, kubectl get endpoints – does the Service selector match pod labels?
  5. Check Ingress / ALB target health.
  6. Check what changed in Git / Argo CD. If urgent, roll back first.

Common pod states:

  • Pending: not enough CPU/memory on nodes, node selector or taint problem, PVC not bound.
  • ImagePullBackOff: wrong image name/tag, no ECR permission.
  • CrashLoopBackOff: app starts and crashes. Check logs, env vars, secrets, config.
  • OOMKilled: memory limit too low or memory leak.
  • Running but not Ready: readiness probe failing, so no traffic.

Probes:

  • Readiness: is the pod ready to get traffic? If it fails, pod is removed from Service.
  • Liveness: is the app stuck? If it fails, container restarts.
  • Startup: for slow-starting apps, protects from liveness killing it too early.
  • Tip: liveness should NOT check the database. If DB is slow, all pods restart and make it worse.

Requests and limits:

  • Requests: what the scheduler reserves. Used for placement and cost.
  • Limits: the max. Over memory limit = OOMKilled. Over CPU limit = throttled.
  • Requests too high = wasted money. Too low = noisy neighbors and evictions.

Scaling:

  • HPA: scales pods. Default on CPU/memory, but can use custom metrics.
  • Custom metrics: Prometheus Adapter, or KEDA (easier, scales on Prometheus queries).
  • Cluster Autoscaler or Karpenter: adds/removes nodes. Karpenter is faster and picks cheaper instance types.
  • PDB (PodDisruptionBudget): keeps a minimum number of pods during node drains and upgrades.

Deployments:

  • Rolling update: maxSurge and maxUnavailable control speed.
  • Blue/green: two versions, switch traffic at once, easy rollback.
  • Canary: small % of traffic first (Argo Rollouts can do this).

Networking:

  • Service types: ClusterIP (internal), NodePort, LoadBalancer.
  • Ingress with AWS Load Balancer Controller creates ALBs. Use IngressGroup to share one ALB across many services. This saves money (good for their consolidation).
  • DNS problems: check CoreDNS pods.

Security:

  • RBAC for access, namespaces per team.
  • IRSA (IAM Roles for Service Accounts) or EKS Pod Identity, so pods get AWS access without static keys.
  • Network Policies to limit pod-to-pod traffic.
  • Secrets: AWS Secrets Manager with External Secrets Operator.
  • Image scanning in CI (Trivy) and ECR scanning.

PART 4. PHP-FPM AND NGINX (very important for Thrive)

How it breaks:
DB or cache gets slow → PHP-FPM workers wait → all workers busy → requests wait in listen queue → Nginx upstream timeouts → 502/504 errors → users feel it.

What to monitor:

  • PHP-FPM: active processes, idle processes, max children reached, listen queue, slow requests.
  • Nginx: upstream response time, 5xx rate, active connections.
  • Tool: php-fpm status page + php-fpm exporter for Prometheus.

How to scale:

  • Scale on busy worker % (for example 70–80%) or listen queue, not CPU.
  • Use KEDA or HPA with Prometheus custom metrics.
  • Warning: if DB is the root cause, more PHP pods = more DB connections = worse. Use connection limits, pooling (RDS Proxy for MySQL/Postgres), and check DB latency first.

Key settings:

  • pm.max_children: max workers per pod. Size it by memory: pod memory / memory per worker.
  • request_terminate_timeout and Nginx timeouts: so stuck requests don't hold workers forever.
  • Timeouts to DB and cache in the app, so one slow dependency doesn't take everything down.

PART 5. OBSERVABILITY AND SLOs

Four golden signals: latency, traffic, errors, saturation.

SLI, SLO, error budget:

  • SLI: what you measure. Example: % of requests that succeed in under 300 ms.
  • SLO: the target. Example: 99.9% over 30 days.
  • Error budget: 0.1% allowed failures. If used up, slow down releases and fix reliability.

Burn rate alerts (impress them with this):

  • Burn rate = how fast you use the error budget.
  • Fast burn: for example 14x over 1 hour → page right away.
  • Slow burn: for example 2–3x over 6 hours → ticket or warning.
  • Better than fixed thresholds: fewer false alerts, catches real problems early.

Leading vs lagging signals:

  • Leading (early): PHP-FPM queue growing, cache hit rate dropping, DB latency going up, connection count rising.
  • Lagging (late): CPU, error rate, users complaining.

Alerting rules:

  • Page only on user impact (errors, latency, SLO burn).
  • Everything else goes to dashboards or warnings.
  • Every alert must be actionable and have a runbook.

Monitoring a web app + cache + RDS:

  • App: request rate, 5xx rate, p95/p99 latency, pod restarts.
  • Cache (ElastiCache Redis): hit rate, evictions, memory, connections, latency.
  • RDS: CPU, FreeableMemory, FreeStorageSpace, DatabaseConnections, Read/Write latency, IOPS, DiskQueueDepth, ReplicaLag. Turn on Performance Insights for slow queries. RDS events to SNS.
  • ALB: UnHealthyHostCount, HTTPCode_ELB_5XX, TargetResponseTime.
  • Nodes: CPU steal time (their past issue).

CPU steal:

  • Means the hypervisor is giving CPU time to other VMs.
  • Common on burstable instances (t3) when credits run out.
  • Fix: use non-burstable types (m5/m6i/m7i), or check t3 unlimited, and monitor node_cpu_seconds_total{mode="steal"}.

AI in monitoring:

  • Anomaly detection (Datadog Watchdog, CloudWatch anomaly detection) catches unusual patterns.
  • AI helps summarize incidents and logs, but humans still decide.

PART 6. AWS

Multi-account consolidation (their big project):

  1. Inventory what runs in each account (services, caches, ALBs, DBs, costs).
  2. Plan the order: low-risk services first.
  3. Networking: VPC peering or Transit Gateway so accounts can talk during migration.
  4. Move service into the main EKS cluster with Terraform + Argo CD.
  5. Share ALBs with IngressGroup, combine caches where safe.
  6. Shift traffic slowly with Route 53 weighted records.
  7. Monitor, then turn off the old resources.

Cost optimization list:

  • Rightsize EC2 and EKS nodes, tune pod requests.
  • Karpenter for better node packing and cheaper instances.
  • Spot instances for stateless workloads and dev/test.
  • Savings Plans / Reserved Instances for steady prod usage.
  • Graviton (ARM) instances: about 20% cheaper.
  • Delete unused EBS volumes, snapshots, old ALBs, unattached Elastic IPs.
  • Move gp2 to gp3 volumes (cheaper).
  • NAT Gateway data costs: use VPC endpoints for S3 and ECR.
  • S3 lifecycle policies.
  • Shut down dev/test at night and weekends.
  • Visibility: Cost Explorer, tags, Kubecost for cost per service/namespace.

RDS basics:

  • Multi-AZ for high availability (automatic failover).
  • Read replicas for read scaling.
  • Automated backups and snapshots.
  • Private subnets, security groups, least privilege.
  • RDS Proxy for connection pooling.

PART 7. TERRAFORM

  • Remote state in S3 with DynamoDB locking.
  • Modules to reuse code.
  • terraform plan before apply, review in pull request.
  • Run in CI (GitHub Actions) with plan output in the PR.
  • terraform import to bring legacy resources into code (useful for their legacy accounts).
  • Drift: when someone changes things by hand. Detect with scheduled plan.
  • Never put secrets in code. Use Secrets Manager.

PART 8. CI/CD

  • GitHub Actions: build, test, scan image, push to ECR, update Helm values or image tag in Git.
  • Argo CD: watches Git and syncs to cluster (GitOps). Git is the source of truth.
  • Rollback: revert the Git commit, or Argo CD rollback.
  • Use OIDC from GitHub Actions to AWS, no long-lived keys.
  • Safe deploys: small changes, canary or rolling, health checks, automatic rollback.

PART 9. INCIDENT RESPONSE

Steps:

  1. Detect (alert).
  2. Assess impact: how many users, which service.
  3. Communicate: incident channel, status updates.
  4. Mitigate first: rollback, scale, restart, failover. Fix users first, find root cause later.
  5. Find root cause.
  6. Blameless postmortem: timeline, root cause, action items.
  7. Follow up on action items.

Key words: MTTR, blameless, mitigation first, action items.

PART 10. PRACTICE SCENARIOS (they may ask live)

  1. Error rate suddenly goes up. What do you do?
    Check what changed (deploys in Argo CD). Check dashboards: is it one service or all? Check PHP-FPM workers, Nginx upstream, cache hit rate, RDS latency and connections. If a recent deploy, roll back. Then root cause.

  2. Latency is high but CPU is low.
    Workers are waiting on something: DB, cache, or external API. Check RDS slow queries and Performance Insights, cache hit rate, PHP-FPM listen queue. CPU is low because workers are waiting, not working.

  3. Pods keep restarting.
    describe pod: OOMKilled or liveness failure? Logs with --previous. If OOM, raise memory or fix leak. If liveness, check if probe is too strict or checks the DB.

  4. A node is NotReady.
    kubectl describe node, check kubelet, disk pressure, memory pressure. Cordon and drain if needed. Karpenter or ASG replaces it.

  5. RDS connections are at max.
    Find which app opens too many connections. Lower pm.max_children or pod count, add RDS Proxy, check for connection leaks. Short-term: kill idle connections carefully.

  6. Cache goes down.
    All traffic hits the DB, DB slows, PHP workers fill up. Protect the DB: rate limit, timeouts, ElastiCache Multi-AZ with replicas.

  7. Reduce AWS cost by 20% in 3 months.
    Get visibility first (Cost Explorer, Kubecost, tags). Quick wins: unused resources, gp3, dev/test schedules. Then rightsize, Karpenter, Spot for stateless, Savings Plans, Graviton. Track monthly.

  8. Migrate a legacy service from another account to EKS.
    See Part 6 steps. Containerize, add probes and monitoring, deploy with Argo CD, shift traffic with Route 53 weights, keep rollback ready.

PART 11. LINUX BASICS (quick review)

  • top / htop: CPU and memory.
  • df -h: disk space. du -sh: folder size.
  • free -m: memory.
  • ss -tulpn or netstat: open ports.
  • curl -v: test HTTP.
  • dig / nslookup: DNS.
  • journalctl -u service: service logs.
  • ps aux | grep php-fpm: processes.
  • Load average vs number of CPUs.

PART 12. QUESTIONS TO ASK (tech interview)

  1. Are you scaling PHP-FPM with KEDA or HPA custom metrics?
  2. Do you use burn-rate alerts on your SLOs today?
  3. What is the next legacy account or service to migrate?
  4. Are you using Karpenter or Cluster Autoscaler, and any Spot?
  5. What would success look like in the first 90 days?

PART 13. TIPS FOR THE DAY

  • If you don't know something, say: "I haven't used that directly, but here is how I would approach it." Then explain your thinking.
  • Think out loud in troubleshooting questions. They want to see your process.
  • Always say: mitigate first, then root cause.
  • Connect answers to their problems: PHP-FPM, cost, migration, early signals.
  • Keep answers short, then give one real example.

THRIVE MARKET SRE – QUESTIONS AND ANSWERS

  1. TELL ME ABOUT YOURSELF

Hi, my name is Aisel. I'm a Site Reliability Engineer with over 6 years of experience in AWS, Kubernetes, and production support.

In my current role at FitTech, I manage production workloads on Amazon EKS. I build CI/CD pipelines with Jenkins and GitHub Actions, deploy with Helm and Argo CD, and manage AWS infrastructure with Terraform. I use Prometheus, Grafana, Datadog, and CloudWatch for monitoring, and I take part in incident response and root cause analysis. I also helped reduce our cloud costs by 28%.

Before that, I was a DevOps Engineer at Home Depot, supporting a Kubernetes microservices platform, and at XPO Logistics, building AWS infrastructure with Terraform.

I enjoy troubleshooting, finding root causes, and automating work so problems don't come back. This role is a great match because it focuses on Kubernetes migration, cost, and reliability, which is exactly what I've been doing.

  1. WHAT ARE YOUR DAY-TO-DAY RESPONSIBILITIES?

My day usually starts with checking dashboards and alerts in Datadog and Grafana to make sure production is healthy. Then I review any issues from the night before.

During the day I work on a mix of things: supporting deployments with Argo CD, fixing or improving CI/CD pipelines in GitHub Actions and Jenkins, writing Terraform for new infrastructure, and helping developers troubleshoot problems in Kubernetes.

I also work on improvement projects, like cost optimization, better alerting, and automation with Bash and Python.

When I'm on call, I respond to incidents, restore service, and then do root cause analysis and write the postmortem.

  1. TELL ME ABOUT A PROJECT YOU'RE PROUD OF (COST OPTIMIZATION)

At FitTech, our AWS bill was growing every month, and I was asked to reduce it.

First, I looked at the data in AWS Cost Explorer, and at real CPU and memory usage in CloudWatch and Datadog. I found three main problems: oversized EC2 instances and EKS nodes, unused resources like old EBS volumes, snapshots, and load balancers, and dev and test environments running 24/7.

Then I fixed them step by step. I rightsized instances and EKS node groups, tuned CPU and memory requests for pods, wrote Python and Bash scripts to find and clean unused resources, and scheduled dev and test to shut down at night and on weekends. I moved EBS volumes from gp2 to gp3. I also put the right sizes into Terraform, so new resources were created correctly, and set up cost alerts.

The result was a 28% reduction in monthly cloud cost, with no impact on performance.

  1. TELL ME ABOUT ANOTHER PROJECT (MONITORING / SLOs)

At FitTech, our alerting was noisy. I had added many alerts on CPU, memory, and restarts, and on-call engineers were getting alert fatigue.

I reviewed all the alerts with the team and removed or tuned the noisy ones. Then we moved to SLI and SLO based alerting, focused on what users feel: error rate and latency. We used burn-rate alerts, so we got paged when the error budget was being used too fast. CPU and memory moved to dashboards for troubleshooting.

The result was far fewer alerts, almost every page was a real issue, and our MTTR went down because the team trusted the alerts.

  1. TELL ME ABOUT A PROJECT (KUBERNETES RELIABILITY AT HOME DEPOT)

At Home Depot, many incidents happened during releases because pods received traffic before the app was ready, or stayed running when the app was stuck.

I collected data from past incidents and proposed adding readiness and liveness probes. I tested it on one service first, showed the results, and then worked with developers to roll it out to other services. I also set up the ALB Ingress Controller and supported rolling and blue/green deployments.

The result was fewer failed deployments and safer releases.

  1. TELL ME ABOUT AN INCIDENT YOU HANDLED

At FitTech, one afternoon we got alerts that the error rate and latency on one of our main APIs were going up fast. Users were getting timeouts.

First, I joined the incident channel and checked what changed. There was no recent deployment. In the dashboards, CPU on the pods looked normal, but latency was high, which told me the app was waiting on something. I checked the database and saw DatabaseConnections on RDS was almost at the max.

To mitigate, we scaled down a background worker service that was opening too many connections, and the errors dropped within a few minutes.

For root cause, we found a new batch job had been released earlier that day. It opened a new DB connection for every task and didn't close them. The developers fixed the connection handling, and we added connection pooling.

After the postmortem, I added alerts on DB connections and latency as early warning signals, and we added connection limits for that service. We didn't have that problem again.

What I learned: CPU can look fine while users are suffering, so watch dependencies like the database, and always mitigate first, then find the root cause.

  1. TELL ME ABOUT A TIME YOU COLLABORATED WITH DEVELOPERS

At FitTech, a development team was having frequent deployment failures, and they felt it was an infrastructure problem.

Instead of arguing about whose fault it was, I set up a meeting and we looked at the data together: Argo CD history, pod events, and logs. We found that most failures were from missing config values and wrong resource limits.

We worked together on a fix. I added validation steps in the GitHub Actions pipeline to check Helm values before deploy, and they updated their resource settings. I also wrote a short runbook for them.

Deployment failures dropped a lot, and the relationship between our teams got much better. I learned that good collaboration starts with shared data, not blame.

  1. TELL ME ABOUT A TIME YOU DISAGREED WITH YOUR MANAGER

At FitTech, my manager wanted to deploy a big change to production all at once to save time. I was worried because it touched many services, and rollback would be hard.

I talked to him one on one and explained the risk. I suggested deploying in smaller parts, starting with one low-risk service, using Argo CD for fast rollback. It only added about a day.

He agreed. In the first small deploy, we found a config problem and fixed it in minutes with no customer impact. After that, smaller step-by-step deploys became our normal process.

I learned to disagree with data and a clear solution, and to respect the final decision.

  1. TELL ME ABOUT A FAILURE OR MISTAKE

At FitTech, I added many alerts with low thresholds, thinking more alerts would catch more problems. It created too much noise, and the team started getting alert fatigue.

I owned it, reviewed the alerts with the team, removed the noisy ones, added time windows, and moved to SLO-based alerting on user impact.

I learned that more alerts don't mean better monitoring. Every alert must be actionable.

  1. TELL ME ABOUT A TIME YOU TOOK INITIATIVE

At Home Depot, my team's plan was only to support deployments. But I noticed many incidents were caused by missing health checks.

It wasn't in our plan, but I collected incident data, proposed readiness and liveness probes, tested on one service, showed the results, and then rolled it out with developers. It reduced failed deployments and made releases safer.

I learned: when I see a problem, I collect data, start small, show results, and then get the team on board.

  1. TELL ME ABOUT A TIME YOU HELPED A JUNIOR ENGINEER

At Home Depot, a junior engineer deployed a service to Kubernetes and it wasn't working. I sat with him and we went step by step: get pods showed CrashLoopBackOff, logs showed a missing environment variable because of a typo in the secret name. After fixing it, the app still wasn't reachable, and we found the Service selector didn't match the pod labels.

I didn't just fix it for him. I guided him, and then asked him to write a short runbook. Other new engineers started using it too.

  1. HOW DO YOU HANDLE PRESSURE DURING AN OUTAGE?

I stay calm and focus on facts. First, I check impact and what changed. I communicate clearly in the incident channel, even if it's just "still investigating." I focus on restoring service first, then root cause later. Having good runbooks and dashboards also helps a lot under pressure.

  1. HOW DO YOU PRIORITIZE WHEN MANY THINGS HAPPEN AT ONCE?

Production incidents and user impact always come first. Then I look at risk and urgency: security issues and things that could cause an outage next. Then planned project work. If priorities are not clear, I talk to my manager and the team so we agree on what's most important.

  1. HOW DO YOU KEEP LEARNING?

I learn by doing: I set up small labs to test new tools like Karpenter and KEDA. I read AWS and Kubernetes documentation and blogs, and learn from postmortems at other companies. I also use AI tools to help me learn faster and write scripts.

  1. WHAT ARE YOUR STRENGTHS?

I'm very good at troubleshooting. I stay calm, follow the data, and find the root cause. I also like automation, so I fix problems in a way that prevents them from coming back.

  1. WHAT IS YOUR WEAKNESS?

Earlier in my career, I sometimes tried to fix everything myself instead of asking for help quickly. I learned that during incidents, asking early and sharing information saves time. Now I communicate early and involve the right people quickly.

  1. HOW DO YOU USE AI IN YOUR WORK?

I use AI coding assistants to help write Bash and Python scripts, Terraform, and GitHub Actions workflows faster. I also use them to help explain errors and logs during troubleshooting. But I always review and test the output before using it in production.

  1. WHY THRIVE MARKET?

I like Thrive Market's mission of making healthy and sustainable products more accessible. And technically, this role matches my experience very well: migrating legacy systems to Kubernetes, AWS cost optimization, and improving reliability with better signals and SLOs. I'd love to help the team with those projects.

  1. WHY ARE YOU LOOKING FOR A NEW JOB?

(Choose the one that's true.)
If the contract ended: My contract ended, and I'm looking for a long-term role where I can grow with a strong team.
If still working: My contract is ending soon, and I'm looking for a long-term role where I can grow with a strong team.

  1. SALARY EXPECTATIONS

Based on the role and my experience, I'm targeting a base salary of $145,000 to $160,000. I'm flexible depending on the full compensation package.

  1. WHERE DO YOU SEE YOURSELF IN 3 TO 5 YEARS?

I want to grow into a senior or lead SRE role, where I help design reliable systems, guide other engineers, and drive bigger projects like platform improvements and cost strategy.

  1. DO YOU HAVE ON-CALL EXPERIENCE?

Yes. At FitTech I'm part of the on-call rotation. I respond to alerts, restore service, communicate in the incident channel, and then help with root cause analysis and postmortems. I also work to reduce noisy alerts so on-call is sustainable for the team.

  1. QUESTIONS TO ASK THEM

  2. What would success look like in the first 90 days?

  3. What is the next legacy system or account you plan to migrate?

  4. Are you using KEDA or HPA with custom metrics to scale PHP-FPM?

  5. Do you use burn-rate alerts on your SLOs?

  6. How is on-call organized, and how big is the team?

  7. CLOSING

Thank you for your time today. I'm really excited about this role. The Kubernetes migration, cost work, and reliability improvements are exactly what I enjoy and have done before. I believe I can help the team move faster and make the systems more reliable and cost-efficient. What are the next steps?

Tip: practice each answer out loud 2 or 3 times. Don't memorize word by word, just remember the main steps of each story. If you want, I can quiz you one question at a time.