From Amazon to Zoom: An SRE Engineer's Career Transformation Journey

In the tech industry, moving from one top-tier company to another is often not just about salary — it's about alignment in technical direction, growth potential, and personal vision. Manish, a DevOps/SRE mentor at GeeksforGeeks, recently shared his experience of leaving Amazon to join Zoom as a Site Reliability Engineer. His story covers the confusion of early career beginnings, self-taught career transition strategies, lessons from interview failures, and how to compensate for lacking direct project experience by building personal projects. For engineers considering a career transition or job change, these experiences offer considerable reference value.

From Cognizant to Amazon: A Real Journey of Self-Taught Transformation

Manish's career start was far from glamorous. After graduating from university, he joined Cognizant as an Advanced Java Developer, but was assigned to supply chain management — a domain he knew nothing about. When asked questions like "where do you see yourself in five years," he admits he had no idea at the time. This sense of confusion prompted him to start looking for a way out.

On a friend's suggestion, he used his project downtime to self-study data engineering technologies including Python, Scala, Kafka, Airflow, and SQL/NoSQL, while also preparing for AWS cloud certifications and actively seeking internal transfer opportunities. Eventually, a manager gave him an opportunity for a junior position in DevOps. Though it wasn't the data engineering direction he had originally envisioned, he seized it decisively.

After entering the DevOps field, his strategy was: spend the first year fully learning, treating the company's projects as his own training ground. He repeatedly studied the codebase, understood the build logic of Jenkins pipelines, and cross-validated project practices he saw on YouTube with his current work, striving to achieve an end-to-end architectural understanding. This approach of "studying company projects as if they were your own" laid the foundation for his subsequent job changes.

AWS Certification: AWS offers multiple tiers of professional certifications, with common paths ranging from entry-level Cloud Practitioner to Associate level (Solutions Architect Associate, Developer Associate, SysOps Administrator Associate), then Professional level (Solutions Architect Professional, DevOps Engineer Professional), and specialty certifications (such as Security, Data Analytics). For career changers, certifications alone don't guarantee an offer, but they systematically fill in foundational knowledge of cloud services, networking, security, and billing models, and provide a verifiable learning signal in resume screening. Manish preparing for AWS certifications during his Cognizant phase was exactly using the "certification + internal transfer" combination to push himself from Java developer onto the DevOps track.

Interview Setbacks and Self-Built Project Strategy: What Interviewers Really Want to Assess

After about a year and a half at Cognizant, Manish began actively sending out resumes. He soon encountered a dilemma that many engineers at service-based companies face: the 90-day notice period deterred most HR representatives, leaving few interview opportunities. What frustrated him even more was a CGI interview that lasted only five minutes before ending — the interviewer asked about Kubernetes architecture, and he knew almost nothing about it at the time.

This five-minute failure became a turning point. He began reading technical articles extensively, watching video tutorials, and built an EKS cluster from scratch on his laptop, deployed a complete project, integrated Jenkins pipelines, and even created a mini Kubernetes cluster. His core insight was: interviewers don't require you to have used a technology in real work — they assess whether you truly understand the principles and have hands-on ability. Building an end-to-end project locally and documenting errors and debugging experiences during the process becomes powerful evidence in interviews.

He also specifically emphasized the importance of resume optimization. He proactively reached out to engineers at Amazon, Microsoft, Adobe, and other companies on LinkedIn to review his resume, and continuously adjusted it to an ATS-friendly format.

EKS and mini Kubernetes clusters: EKS (Elastic Kubernetes Service) is a managed Kubernetes service on AWS where users only need to manage node groups and workloads while the control plane is operated by AWS, making it ideal for end-to-end projects: using Terraform to create VPCs, IAM roles, and EKS clusters, then deploying applications with kubectl or Helm, and integrating Jenkins/GitHub Actions pipelines. A "mini Kubernetes cluster" typically refers to a lightweight cluster built locally using kubeadm, k3s, minikube, or kind, aimed at understanding the collaboration between control plane components (API Server, etcd, Scheduler, Controller Manager) and worker node components (kubelet, kube-proxy, container runtime). Combining both demonstrates cloud deployment capability while also proving mastery of underlying principles.

Two Years at Amazon: Battle-Tested Growth and Leadership Principles

In 2024, Manish finally received an offer from Amazon. He recalls buying an Amazon T-shirt in his senior year of university — that T-shirt sat in his closet for nearly three years until the day he joined the company.

During his two years at Amazon, he gained growth far beyond technical skills. He mentioned that Amazon's 16 Leadership Principles become "deeply rooted in you," with "Insist on the Highest Standards" leaving a profound impression on him. He frequently faced problems with no existing solutions, no POC, no SOP — requiring him to investigate deeply, propose solutions, gain approval, and deliver results on his own.

This high-pressure environment brought not only technical skill improvement but also a qualitative transformation in stress resilience and confidence. He admits that Amazon can sometimes be frustrating, but these experiences truly shape a person — "if you've worked at Amazon, you can work at any company."

Amazon's 16 Leadership Principles: These are the core behavioral guidelines Amazon uses for hiring, performance evaluation, and promotion reviews, including Customer Obsession, Ownership, Invent and Simplify, Are Right A Lot, Learn and Be Curious, Hire and Develop the Best, Insist on the Highest Standards, Think Big, Bias for Action, Frugality, Earn Trust, Dive Deep, Have Backbone; Disagree and Commit, Deliver Results, Strive to be Earth's Best Employer, and Success and Scale Bring Broad Responsibility. Behavioral questions in interviews typically require answers using the STAR structure and explicitly correspond to one or two of these principles. The "Insist on the Highest Standards" that Manish mentioned is exactly Insist on the Highest Standards, emphasizing delivering reliable results even in scenarios with no existing solutions, no POC, and no SOP.

Why Leave Amazon: When Growth Direction No Longer Aligns with Personal Plans

Amazon was Manish's dream company, but he chose to leave after two years. His reason: the technical direction he wanted to pursue, the impact he wanted to create for the team, and the learning curve had become unclear in his current position at Amazon. When asked "where do you see yourself in five years," he once again felt uncertain.

During his preparation for leaving, he experienced intensive interviews and rejections — media.net, Warner Bros, PhonePe, eBay, Goldman Sachs, and other companies — some stopped at the second round, others fell at the final round. He once again applied his previous methodology: for technologies required by target positions but missing from his resume, he built personal projects to fill the gaps, using the hours from 11 PM to 2-3 AM for continuous learning and mock interviews. Ultimately, he received several offers including one from Zoom, and chose to join Zoom as a Site Reliability Engineer, stating that his current work content and technical direction are highly aligned with his five-year career plan.

AI's Impact on DevOps/SRE and Transition Advice

When discussing AI's impact on the DevOps and SRE fields, Manish's attitude is pragmatic: you can't avoid AI, but you can choose to collaborate with it. Using AI as a tool to improve delivery speed and quality, rather than as a competitor, is a wiser positioning. He also emphasizes that DevOps and SRE remain high-demand, high-paying directions.

For those wanting to transition into DevOps/SRE from other fields, his advice is: first build solid fundamentals, then use a complete end-to-end project to connect knowledge points including Linux, Shell, AWS, Terraform, Docker, Kubernetes, CI/CD, Prometheus, Grafana, and Python. From using Terraform to create AWS infrastructure, to deploying applications on EKS, integrating SonarQube and Trivy, configuring GitHub Actions or Jenkins pipelines, to using Prometheus and Grafana for monitoring visualization — this project can take three to six months to complete, but it gives you real content to discuss in interviews. After completing the project, simultaneously optimize your LinkedIn and resume to increase the probability of being discovered by HR.

Manish's experience ultimately follows a simple logic: fill gaps with projects when you encounter shortcomings, transform frustration into action when rejected, and maintain a rhythm of continuous learning. For engineers hesitating about whether to change jobs or transition careers, this may be more worth learning from than any technical guide.

Differences between SRE and DevOps: DevOps leans more toward the integration of culture, processes, and engineering practices, emphasizing development-operations collaboration, CI/CD, automation, and rapid feedback; SRE (Site Reliability Engineer) originated at Google and is a specific role that applies software engineering methods to operations problems, commonly using SLO/SLI/Error Budget to quantify reliability, and ensuring system stability through reducing toil, automation, and capacity planning. The two highly overlap in toolchains (Kubernetes, Terraform, Prometheus, Grafana, etc.), but SRE places more emphasis on driving decisions with measurable reliability targets. Understanding this difference helps career changers adjust their resume and project focus according to target positions.