Career Switch to Big Tech Frontend: From Humanities Graduate to Amazon Offer

Career Switch to Big Tech Frontend: From Humanities Graduate to Amazon Offer

Let me start with the conclusion: English major, worked as a translator for 2 years, self-taught frontend development from scratch for 8 months, and ultimately received an offer from Amazon. This isn't a fairy tale — there were countless moments I wanted to quit — but I want to document this journey completely to give confidence and reference to everyone considering a career switch.

Background

I graduated with an English degree in 2018. After graduation, I worked as a translator at a foreign trade company for 2 years. The pay was mediocre, the work was repetitive, and I couldn't see much room for growth. During the 2020 pandemic work-from-home period, I stumbled upon programming and found writing code genuinely interesting, so I started teaching myself.

Honestly, at the beginning I didn't even know "what a variable is" — looking at code gave me headaches. But I had one advantage: strong English skills, which made reading English documentation much easier than for most people. This advantage helped tremendously when learning React and reading official docs later on.

Self-Study Roadmap: 8 Months from Zero to Amazon Offer

Month 1: HTML/CSS Basics

I used freeCodeCamp and MDN documentation as my learning resources. HTML was manageable — tags and semantics aren't hard to grasp. CSS was genuinely difficult. Flexbox took me 3 reads to understand, and the different position values required repeated practice. During this phase, I built 3 static pages for practice: a personal homepage, a product landing page, and a responsive blog page.

Biggest pitfall: I was too perfectionistic at first, spending a week tweaking a single page. I later realized "done is better than perfect" is the right pace.

Months 2-3: JavaScript Core

This was the most painful phase. JS has too many concepts — hoisting, closures, prototypal inheritance, the "this" keyword, asynchronous programming... each one made me question my life choices. Closures in particular — I read at least 5 different articles before truly understanding them.

My learning method: first watch videos/read articles to understand concepts, then write code in the console to verify, and finally build small projects to reinforce. During this phase I built: a Todo List, a weather query app, and a simple calculator. The code was ugly, but at least it ran.

Months 4-5: React Framework

Before learning React, I first studied ES6+ features, because React code is full of arrow functions, destructuring, and template literals. Then I started with the React official documentation and followed along with a tutorial to build an e-commerce demo.

React's learning curve was steeper than I expected. Hooks had just come out, and many online tutorials still used class components, which confused me. I eventually decided to focus only on Hooks and use functional components exclusively, which actually made things clearer. During this phase I focused on: useState, useEffect, useContext, custom Hooks, and React Router.

Months 6-7: Project Practice

These two months I focused on building two complete projects. The first was a blog system using React + Node.js + MongoDB, implementing basic features like article publishing, comments, and tag categorization. The second was a task management tool mimicking Trello's kanban functionality, supporting drag-and-drop sorting, task assignment, and deadline reminders.

These two projects played a huge role in my interviews later. Interviewers were particularly interested in the task management tool because it involved deep technical points like drag-and-drop interaction, state management, and data persistence.

Month 8: Interview Preparation

In the final month I mainly did three things: practiced algorithm problems (about 80, mostly easy and medium), organized frontend interview knowledge, and did mock interview practice. Mock interviews were especially useful — I found a friend who was also preparing for interviews, and we interviewed each other twice a week. From stuttering nervously at the start to expressing myself fluently later, the improvement was obvious.

Interview Experience: 3 Small Companies for Practice + 4 Rounds at Amazon

Small Company Practice: Failed 2, Passed 1

Let me start with the small company interviews. The first was a startup — the interviewer asked many fundamental questions, and I did okay, but I completely failed the algorithm problem. Rejected. The second was a small education company — the interview was relatively simple, asking about React basics and project experience. I passed but didn't accept due to low salary. The third was an e-commerce company — the interviewer asked many CSS layout questions, and I didn't answer flexbox well. Rejected again.

After 3 small company interviews, my takeaway: fundamentals must be solid, especially CSS and JS basics. Small companies may not test algorithms, but Big Tech definitely will.

Amazon Round 1: Fundamentals + Algorithms

Amazon's first-round interviewer was young and friendly. Started with HTML/CSS fundamentals: the purpose of semantic tags, what BFC is, differences between flex and grid. Then JS fundamentals: closure use cases, prototypal inheritance patterns, Event Loop execution order, differences between Promise and async/await.

The React section covered: Hook usage considerations, understanding useEffect's dependency array, React's Virtual DOM and Diff algorithm. The algorithm problem was Two Sum — I had practiced it before and wrote it out in 5 minutes. The interviewer followed up with time complexity optimization, which I also answered.

Round 1 took about 1 hour. The interviewer said "fundamentals are pretty good" at the end, and I breathed a sigh of relief.

Amazon Round 2: Deep Project Dive + Code Writing

The second-round interviewer was clearly more senior and immediately dug into my projects. They asked how I implemented drag-and-drop in my task management tool. I said I used the react-beautiful-dnd library. They followed up: "How would you implement drag-and-drop without a third-party library?" I explained my approach using the HTML5 Drag and Drop API and the mousedown/mousemove/mouseup implementation.

Then they asked me to write debounce and throttle functions from scratch. I wrote debounce quickly, but throttle had a small bug that the interviewer pointed out and I fixed. Next came networking questions: HTTP caching mechanisms, cross-origin solutions, differences between WebSocket and HTTP long polling.

Round 2 took about 1 hour 15 minutes — noticeably harder than Round 1, but within my preparation range.

Amazon Round 3: Comprehensive + System Design

The third-round interviewer was likely a tech lead, asking more macro-level questions. They asked me to design a frontend error monitoring solution. Drawing on what I'd learned, I explained my approach covering error capture, data reporting, data aggregation, and alerting mechanisms. The interviewer followed up on several details — some I couldn't answer, but I honestly said "I'm not sure about this, but my thinking is..." and the interviewer seemed to appreciate my thought process.

Then we discussed broader technical topics: understanding of micro-frontends, thoughts on Serverless, and frontend engineering practices. I had read some articles on these topics and could share my understanding, even if not deeply.

HR Round: Why Career Switch + Career Planning

The HR round was the most nerve-wracking for me because I didn't know what to expect. The interviewer asked me to introduce myself, then asked: Why do you want to switch to frontend? What was the biggest challenge during your transition? How do you prove your learning ability? What's your 3-5 year career plan?

Regarding my career switch reason, I didn't say "translation pays poorly." Instead, I said: "In my translation work, I was exposed to technical documentation localization projects, which sparked my deep interest in programming. After thorough study and practice, I confirmed this is the direction I want to pursue long-term." This answer was both authentic and positive.

For learning ability, I gave 3 examples: going from zero to building complete projects in 8 months, my English proficiency helping me efficiently read technical documentation, and the continuous learning habits I developed during self-study. The HR seemed satisfied.

Key Takeaways and Advice

1. The Hardest Part of Career Switching Isn't Technology — It's Mindset

There were countless moments I wanted to quit — when I couldn't understand closures, when my project wouldn't run, when I saw CS graduates easily getting offers. But career switching is inherently a difficult path. If you've chosen it, you need to persist. My approach was setting small goals and rewarding myself for each one, maintaining positive reinforcement.

2. Projects Matter More Than Memorized Interview Questions

Interviewers were most interested in my project experience, not rote-memorized knowledge. So build projects with real depth rather than memorizing interview questions. Projects should have real use cases and technical challenges. Being able to explain "why you did it this way" is more important than "how you did it."

3. Find Your Differentiating Advantage

As a career switcher, I couldn't compete with CS graduates on fundamentals, but I had my own advantages: strong English skills, cross-domain thinking, and fast learning speed. I deliberately highlighted these strengths in interviews so interviewers could see my unique value.

4. Mock Interviews Are Crucial

Many people have solid technical skills but perform poorly in interviews simply because they lack practice. Find friends to do mock interviews with each other, or practice in front of a mirror. Interviews don't test whether you know something — they test whether you can clearly articulate what you know.

5. Don't Fight Alone

Self-study can easily lead to isolation and anxiety. I joined several frontend learning communities and connected with other self-learners for mutual encouragement. Discussing problems in groups was much more efficient than struggling alone.

FAQ

Q1: How long does it take to switch to frontend with zero experience?

It varies. Full-time study: 6-8 months to reach interview-ready level. Part-time study: possibly 1-1.5 years. The key is learning efficiency, not time. 4 focused hours daily beats 8 unfocused hours.

Q2: Will career switchers face discrimination in interviews?

Big Tech interviews mainly assess technical ability and don't care much about your academic background. However, HR rounds may ask about your career switch reason, so prepare a convincing answer. Frame your career switch as an advantage, not a disadvantage.

Q3: Self-study or bootcamp?

If you're self-disciplined, self-study is sufficient. If you need structure and accountability, bootcamps can help. But regardless of the approach, you ultimately need to write code and build projects yourself. Bootcamps aren't shortcuts — they're just one learning method.

Q4: Will my salary drop after switching careers?

Your initial salary may be lower than your previous job, but the growth potential is much greater. My Amazon offer was nearly double my translation salary. And tech industry salary growth is much faster than traditional industries.

Q5: How do I know if career switching is right for me?

Try studying for 1-2 months first. If writing code feels fun and gives you a sense of achievement, it's right for you. If after two months you still find it painful and uninteresting, it might not be. Interest is the best judge.