AWS Programmer Writer Interview Process, What I Learned

I had an opportunity to join the final round for a Programmer Writer (L4) position at AWS. It was not a success, but as this was my first time having a loop interview at a big corporation, I took this as a chance to learn more about the Amazon interview process and further improve myself. One thing to note, I will not be able to go into detail about the interviews in this article due to NDA, so this is only a high-level overview. With that said, this article gives an introduction to a Programmer Writer role, an interview process at AWS, and some reflection regarding the mistakes I made.

Why should you care?

This is intended for aspiring newcomers who are interested in joining bigger companies. During my research, I saw a lot of articles and videos about popular roles at Amazon (and AWS in particular) like software engineer, DevOps engineer, or so. However, I found little to no information regarding Programmer Writer, so this article can be a good entry point for you.

Overall, my experience was positive, but keep in mind, the interview process and experience can be different between teams and job levels at a big company like Amazon (e.g., L4 and L5), so your mileage may vary.

What does AWS Programmer Writer do?

To start, you should have some context about the Technical Writer role first. Technical writers are responsible for creating documentation to support the company itself or their respective customers. For example, documentation on internal procedures, product manuals, tutorials, and so on. They must be able to break down technical concepts into consumable chunks so the target audience can understand, be it intended for engineers, receptionists, or an average Joe. Besides, the writers should have a decent understanding of their responsible topics and be able to elicit information from subject matter experts.

Essentially, Programmer Writer is a specialized branch of Technical Writer. In this case, AWS Programmer Writer is responsible for creating AWS API documentation.

• They can write and understand codes.
• They target a wide range of audiences, from technical to non-technical personnel.
• They work with internal AWS experts to create necessary documentation and satisfy customer needs (e.g., for development, adoption, and migration).

AWS has multiple Programmer Writer teams, so you should ask what your team owns (e.g., Is the team responsible for translations, or internal documentation?)

What is the AWS Programmer Writer hiring process?

I met 3 recruiters in this process:

1. Technical Sourcer: Responsible for reaching out about the status of my application and job posting questions in the initial rounds.
2. Recruiting Coordinator: Responsible for managing interview schedules and logistics in later rounds.
3. Technical Recruiter: Prep call and final interview outcome.

All interviews did not have coding questions and were conducted virtually via Amazon Chime. There were 3 major rounds for this L4 position, and the whole process was about 1.5 months in length:

1. Initial screening
2. Writing samples
   • Prep call (consider this as round 2.5)
3. On-site

First round: Initial screening (60 minutes)

I applied on Amazon's career page, and Programmer Writer falls under the Editorial, Writing, & Content Management job family. Within one day the Technical Sourcer reached out to me to make an appointment for the first screening round. When the day came, I met with a senior member of the AWS Programmer Writer team. The session was 60 minutes long in total, about 50 minutes were for interviewing while the last 10 minutes were for any questions I had. This interview was a mix of technical and behavioral questions.

At a high level, there were 3 things I needed to express in this interview:

1. My interest in AWS in general and AWS documentation in specific (new to AWS).
2. My approach to technical writing and my own content.
3. My experience in web development.
4. How I solve issues (STAR!!!).

This round was interesting to me because it was more of a conversation. The interviewer asked multiple follow-ups based on my answers so it was not just a copy-paste from a question bank. A few days later, I received an email from Technical Sourcer to notify my eligibility for the second round.

Second round: Writing samples

This round was NOT a live test. Instead, the Technical Sourcer asked via email for a few writing samples that are related to the Programmer Writer role (e.g., API reference, Code samples, Complex system manual). If your domain is in technical writing, then perhaps you already have a fair amount of examples under your belt. However, my background is in Computer Science and technical writing just became my interest along the line, so I do not have much professional experience in this regard. As a side hobby, I operate my personal technology blog at hungvu.tech so I was able to provide some samples from there. My samples are not on a professional level by any means, but I still got a pass from the AWS Programmer Writer team. I suppose this round was more about demonstrating your interest and to prove the team that I can write. My application was for an L4 position, so it was an entry-level anyway.

I heard there were certain forms of Writing Assessment, which must adhere to the Amazon Documentation Style Guide (e.g., 2 or 6 pages in length), but I do not think mine was one.

As said, a few days passed and I got a green light notification from the Recruiting Coordinator. I then made an appointment for the final loop round. However, there was an additional appointment about 1 week before the final interviews, and that date was intended for a Prep call.

Additional round: Prep call (10 minutes)

I found no information about this round during the preparation process. In short, this round was conducted by a Technical Recruiter. It was not an interview, and the call was only to confirm my logistics for the final rounds, provide information for preparation, and answer questions I had about the final round.

Final round: On-site (5 x 60 minutes)

In this round, the loop interview consists of 3 groups of people: the hiring manager, senior team members, and "outsiders". Each interviewer spent about 10 minutes at the end of the session answering my questions about the role.

• Loop 1: Hiring Manager

  This loop was fully behavioral. The hiring manager asked me about 5 STAR questions regarding my interaction with team members and my performance in stressful environments (3-4 different Leadership Principles). They were not fully unique questions though, some were essentially the same but at different complexity and angles. Each question was followed up by multiple questions so the hiring manager can understand more about my story context. Overall, I felt relatively positive about my answers in this loop.

• Loop 2: Senior team member, Programmer Writer

  This loop was 40% behavioral and 60% technical. The behavioral questions were regarding myself. I was not able to determine whether the question should be answered in STAR format so that caught me off-guard, and led me to misinterpret follow-up questions. In the technical section, the interviewer tested my knowledge of AWS. However, they were along the line of "What do you know about...?", very generic, so I was not able to frame my answer properly. Besides, although I have some experience with GCP, I had just a little experience with AWS so my answers were very shallow. Overall, I felt relatively negative about my answers in this loop.

• Loop 3: Senior team member, different position

  This loop was fully behavioral. The interviewer let me know ahead of which Leadership Principle would be discussed. Only 1 STAR question was asked, but the nature of this question directly represented technical writing ability, so it has several technical elements. The interviewer spent the rest of the session just dissecting my story using several follow-up questions. One huge downside was that the question was strictly related to the professional writing experience, which I do not have much of yet. That said, I managed to keep the story as linear as possible using blogging experience, so my overall experience was fairly neutral.

• Loop 4: Outsider - Manager of another AWS team (bar raiser?)

  This loop was fully behavioral. The question was essentially the same as loop 3 based on a different angle (different Leadership Principle) and required a much higher complexity in terms of story structure. I ended up reusing and adapting my story in loop 3, however, I was not able to satisfy the follow-up questions. Indeed, the interviewer asked for far more detail compared to the previous loop. In general, my answers were like running in a circle (non-linear), so I felt relatively negative about them.

• Loop 5: Outsider - Manager of another AWS team

  This loop was fully behavioral. The structure was relatively the same as loop 1 and focused on my interaction with customers. This time, it seemed like an interviewer just pulled up STAR questions from the bank, so they were all unique. Overall, I felt relatively positive about my answers.

Outcome

Based on my performance, I expected the chance was low. About 3 business days later, I saw my application status changed from "Active - Under consideration" to "Archived - No longer under consideration". This was not a good sign so I reached out to the Technical Recruiter for clarification. A few hours later, I received an (unexpected) phone call to notify me about the rejection. Although I expected a rejection would arrive, I did not expect it to be delivered via a 30-second phone call without any context. I wish there was a formal rejection letter that let me know more information about the rejection.

Key takeaways

What were my mistakes?

Let's summarize what my mistakes were so you can avoid them.

• In loop 2, I was not able to determine whether I should use the STAR format to answer the questions or not. Instinctively, I tried to enforce STAR format into my answers as a safe bet and they did not work in the end. Perhaps, the interviewer only wanted to initiate a regular conversation with me, but I was not able to catch that signal.
• I was underprepared for the AWS technical interview, both on the knowledge and presentation side. Even if I have little knowledge of the topic, I must make sure my abilities are presentable.
• I prepared multiple answers for different potential questions. However, they were all short and were only expandable for a few follow-up questions (not complex enough). These answers are usable in a traditional "multiple questions interview", but in the case of loop 3 and loop 4, both interviewers asked only 1 STAR question and spent the rest of the interview session elaborating on them. This showed the lackluster of my story.
• I supposed behavioral and technical questions were completely isolated, but loops 3 and 4 used only 1 question to test both aspects.
• I was actively trying to be conversational in the interview as an experiment (better than 1-way "interrogation"?). However, I suppose there are certain limits as something I said made me wonder if I just caused a potential red flag for the interviewer (e.g., the Interviewer replied with something along the line of "I am not allowed to discuss this with you").

Did I make any correct guess?

Even though I failed the interviews, I believe certain points still hold their ground. That said, feel free to treat these with a grain of salt.

• I prepared stories using STAR format, but it was not necessary to prepare for the whole 16 Amazon Leadership Principles. The more the better, but each position focuses on only specific principles. Analyze the job description or simply ask interviewers or recruiters to figure that out. In my case, there were 5 main leadership principles, and I was able to figure them all out. That said, this might change as seniority increases.
• Of 16 Leadership Principles, some like Customer Obsession and Ownership are fundamental, so every answer must embed them in some way. This also means certain stories can be adaptively used to answer different questions. After all, the point is to demonstrate Leadership Principles at the core of your answers.
• Each interviewer was assigned certain leadership principles to interview you. If you can learn the interviewers' names beforehand, you can search for their profiles and make an educated guess on what they will be responsible for in the loop. I made a correct guess.
• Treat everyone as bar raisers and hiring managers. Amazon interview requires you to impress them all, not just one specific person.
• Always try to actively question behind questions. Answering the question at hand is relatively simple given enough practice. However, whether you can clear all interviewers' doubts without needing them to ask several follow-up questions is another story. The follow-up questions are potential signs that you were missing something in the story.

Wrap up

Overall, I am not satisfied with my performance, but there is a lot to learn from this experience. On the other hand, it was a positive experience going through the interview process, that said, I still wish there were more information regarding the rejection. A month-long preparation was not a waste though. I figure Amazon Leadership Principles would be a great fundamental mindset going through behavioral interviews no matter where I applied to in the future. Certainly, I am not up to the bar at the moment, but I will keep trying until it becomes a reality. In the meantime, contributing to open-source documentation (e.g., AWS docs) or simply blogging should be a good way to start if you want to get into the field.

Interested in web development, GitHub Actions, and more? My other articles might be helpful to you!

• Amazon's culture in the Leadership Principles - Part 1
• How To Choose The Best Headless CMS For Your Blogfolio?
• Strapi vs Directus vs Payload, Headless CMS Comparison

Find more developer news at The Dev Report, and technology articles at my blog.

Also, let's connect!

• LinkedIn @hunghvu
• Dev: @hunghvu
• GitHub: @hunghvu
• Twitter: @hunghvu_dev
• Hashnode: @hunghvu
• HackerNoon: @hungvu
• Medium: @hunghvu_dev