Join 14K readers and level up you AWS game with just 5 mins a week. Every Monday, I share practical tips, tutorials and best practices for building serverless architectures on AWS.
STAR Interview Method Explained with Example
|
This edition of the newsletter is written by Raj Saha, Principal Solutions Architect working at AWS where he designed multiple world-scale systems. He has trained students to get SA jobs through his bootcamp, and runs a YouTube channel "Cloud With Raj" with over 114K subscribers. Since all of you Yan’s readers are pretty savvy technically, let me go over how to represent your technical knowledge in the (in)famous STAR format, to get hired at high paying jobs. All big tech companies, including Amazon, strictly follow this STAR method. In this newsletter, we will go over what that is - common mistakes, a bad answer, why it is a bad answer, and then a good answer. But first things first - what if you give a great answer but NOT in STAR format? Unfortunately, Amazon (and other big tech companies) are pretty clear about this. The interviewers are expected to take notes in STAR format, and recruiters are expected to set expectations for candidates to give the answer in this format. Henceforth, candidates who answer in this STAR format will be prioritized over others who don't. The rules of the game are laid out; you either blame the game and sit on the sidelines or jump in and win, which is what we will do. The word STAR stands for S (Situation), T (Task), A (Action), and R (Results). Situation is the context or background of the project. Tasks are the goals that you need to achieve. Actions are the steps that you took. Results are the output of your actions and what you have achieved. One of the biggest mistake people make in behavioral interviews is, they keep on saying "we" - "we did this task", "we came up with a plan", "we completed step X". This may sound weird - in Amazon we expect you to be a team player, but in interview we want to know precisely what YOU did. Think of this as a player selection in your superbowl team. Yes, we want the receiver to play well with the team, but while selecting, we only care about his stats and his abilities. So make sure to clarify what part YOU played in your answers. Next biggest mistake people do is they talk in hypotheticals. When a question starts with "Tell me a time when you..", you must give example from your past projects. If you just answer in hypotheticals such as "I will do this, that..", you will fail the interview. Okay, now let's look at a sample question and answer. Q: Tell me about one difficult project that you delivered. What was the difficulty, and how did you determine the course of action? What was the result? A: I migrated our project to AWS Serverless after considering K8s and EC2. We coded the lambda, tested it, implemented DevOps then deployed into prod and it was a huge success. Is the above answer good or bad? It's quite bad, why?
A good answer may look like this: Situation - We have 20 Microservices running on-prem on PCF. PCF license needed to be renewed in 6 months, leadership wanted the project to migrate to AWS before that to save cost and increase agility. Task - As a lead architect/developer/techlead, I was tasked to find out suitable AWS solution, within the timeframe given. Action - I researched possible ways to run Microservices on AWS. I narrowed it down to three options - run each microservice on vanilla EC2, or run on K8s using EKS, or Serverless. I took one of the microservices and did POC on Vanilla EC2, EKS and Lambda-API Gateway. While they all did the job, I found that with EC2 I have to take care of making it HA by spinning multiple EC2 in multiple AZs, and there is overhead of AMI rehydration. EKS seems to be a valid solution. However, given the traffic patterns, we have to pay more than necessary. There is also an overhead of training the team on K8s. Lambda-API Gateway is inherently HA, scalable, and pay what we use and no server to manage at all. This simplifies our day 2 operational overhead and let us focus on delivering business value. Result - Based on all the POC data of performance, cost and time to deploy, I selected Serverless solution. We converted rest of the microservices to Lambda and implemented in production within 3 months. It resulted in over 90% cost savings over EC2 and K8s. I shared my project learnings with other teams and showed them how to code Lambda so they can utilize it as well. I got recognized by CIO for this effort. Why is this answer good?
Note that you will get follow-up questions on the answer to understand your depth and to make sure you are not just copying and pasting a generic answer from the Internet 😅. Hopefully this clarified the mystery of STAR Q/A for you. We at Amazon are hiring, check out the open jobs, apply, and use your newfound STAR knowledge! SA Bootcamp Jan Cohort Launch 🚀AWS SA Bootcamp is a program, where you learn everything to get a high paying SA job in live classes - hands-on, executive communication, technical, behavioral, LinkedIn/Resume improvement, getting recruiter attention, mock interviews, expert guest input, and more. SA Bootcamp's new cohort enrollment will launch on Jan 4th, 12 noon EST, with a livestream on my YouTube channel. I will reveal the details, curriculum, success stories from past cohorts, price, and answer questions. Students from last cohort made into top companies, including into AWS as Sr. SA! Like previous cohorts, spots are limited. I hope to see you all in the livestream. Please waitlist at https://www.sabootcamp.com/ to receive webinar details. |
Master Serverless
Join 14K readers and level up you AWS game with just 5 mins a week. Every Monday, I share practical tips, tutorials and best practices for building serverless architectures on AWS.
During this week's live Q&A session, a student from the Production-Ready Serverless boot camp asked a really good question (to paraphrase): "When end-to-end testing an Event-Driven Architecture, how do you limit the scope of the tests so you don't trigger downstream event consumers?" This is a common challenge in event-driven architectures, especially when you have a shared event bus. The Problem As you exercise your system through these tests, the system can generate events that are consumed...
I recently helped a client launch an AI code reviewer called Evolua [1]. Evolua is built entirely with serverless technologies and leverages Bedrock. Through Bedrock, we can access the Claude models and take advantage of its cross-region inference support, among other things. In this post, I want to share some lessons from building Evolua and offer a high level overview of our system. But first, here’s some context on what we’ve built. Here [2] is a quick demo of Evolua: Architecture This is...
"High cohesion, low coupling" is one of the most misunderstood principles in software engineering. So, let's clear things up! TL;DR Cohesion is about the internal focus of a thing - how well its components work together to fulfil a single purpose. Coupling is about the external relationships between things - how much they depend on one another. Cohesion When applied to a code module, cohesion measures how closely related its functions are. An Authenticator module will likely have high...