Interviewing at AWS: Advice and tips from 250 interviews

I just hit a few personal milestones at AWS — 5 years, 250 interviews, and going through bar raiser training, which is a specific internal interview training. I spend a good deal of time helping people understand the Amazon interview process and also helping other interviewers, so I thought it would be worth writing it all out. I’m certainly not an interviewing expert, but I’ve been able to pick up a few things and tips from some experts here (some with 1000+). I’ll start with how interviewing works here, and then cover both how to interview for a position at AWS and some of the interviewing perspectives I’ve learned.

Note: The use of AWS and Amazon in this post are pretty interchangeable despite one being a mighty sock-seller and the other a mighty storage-seller. Though, most of my interview experience has been for customer-facing positions in AWS. Other positions like software development are similar but typically have requirements such as code samples and live coding which I don’t cover here but are generally in the ‘functional’ category. Also stuff changes all the time, so it’s very likely you can experience something different than what’s in this post. Try to focus on the things you can do as a candidate or interviewer rather than the process details.

How it works: Interview process

The interview process is pretty standard at AWS. First you apply, or maybe a recruiter encourages you to apply, or someone refers you to a position. Recruiters will do a resume review and maybe chat with you. I know the least about this part since I only get pulled in once the recruiting team decides to do a phone screen.

The phone screen is a phone call or video chat with someone close to or on the team. The phone screens are looking for any major risks and a functional fit. There may be 1 or 2 phone screens, depending either on the first interview outcome or the team’s processes. Generally, the interviewer is trying to assess how likely it is you will make it through a loop of 4–6 people. They’re looking for your functional skills — are you good at your current job, do you know the relevant technology, a rough behavioral consideration, and can you do the more unique things for this particular role — technical, skills, experience, industry, etc. You may get 1–2 very long scenario-based questions, such as ‘Tell me about the most complex architecture you’ve worked on” or a peppering of smaller technical questions. The interviewer puts their feedback in, it’s looked at by the hiring team, and next steps are typically provided in 24–48 hours or so. If they’re inclined, you’ll come in for a more intensive in-person or video call for the loop (we’re all video during COVID).

This is also a good time to call out two pizza teams. We work under the mantra that if the team tackling a problem can’t be fed with two pizzas, the team is too big. Realistically that’s something like 5–10ish people. It gives teams a lot of autonomy on how to work, their culture, and their processes. So what may look like a giant corporate spaceship is more accurately a bunch of ships with their masts loosely tied together. What that means as an interviewing candidate is that every team you interview will have their own ways of doing things. I’d recommend asking about the team-level details you may care about in every interview. But it also means that what I write about here isn’t always going to be the case, but should be close. It’s also why it’s desperately hard to answer “what’s it like to work at AWS” nor should you trust any single answer you’re given unless it’s for your direct team.

Phone screens are a check if we think a candidate could make it through a loop, so in theory you want to send a candidate to a loop if you think they’re between some arbitrary percentage of making it through, e.g. greater than 50%. There’s an always-changing compromise between how many hours of work it takes for 4–6 people to do a loop versus the risk of losing a good candidate. Most of this will be decided by the associated two pizza team and is the most subjective part of the hiring process.

The loop is a panel of 4–6 folks and for 45–60 minutes. Everyone is given 2–3 areas to focus on. Expect a lot of Tell Me About a Time questions… where you explain a situation you’ve been in related to one or more leadership principles. The interviewers will be mostly related to your team, but probably includes 1–2 people from outside the team. One will be the bar raiser, which I’ll cover later. There are a few outcomes of a loop: hire (yay!), no hire and not a general fit for Amazon, or no hire and a fit for somewhere else in Amazon. In most cases, any future interviews at Amazon can see feedback from your previous interviews, so they can carry weight. In some cases, recruiters may not consider applications for new roles if you weren’t an Amazon fit for months to years. The difference between the last two is based on leadership principles, which I’ve now mentioned twice..

How it works: Leadership principles

Most company have a mission, corporate values, or corporate posturing things that sound good in an executive meeting but mean squat to people doing actual work. At AWS the leadership principles share the same cheesy appearance as corporate values, but they’re pretty core to daily life — and are most pronounced in hiring (and promotions). If you haven’t looked at them, take a look, it’s a quick read.

The more I’ve worked with them and had to measure them in others, I think it's better to think about them as a framework for how to make decisions when there isn’t authority around. If we’re a thousand ships tied together, it’s a method for making good decisions personally or for your little ship. They’re a large part of why we can have so many ships moving at the same time moving in so many directions. If you like a lot of top-down direction, have difficulty making decisions yourself, want someone else to tell you what to learn, struggle knowing what the right things to do for customers are, or need someone else to set deadlines for you to get moving, you may find the culture and leadership principles challenging. It’s worth saying that we also hire people for their strengths, so fret not if some of these sound scary.

And the leadership principles are also like any mature principle structure — depending on the context they contradict each other. When do you use Bias For Action and Deliver Results (get-er-done) vs Dive Deep and Insist on the Highest Standards (dig in and improve)? Is that feature good enough to ship, or should we dive in?

Each leadership principle has an associated scale, complexity, or impact for you to wield. Think Big can start off as sharing an idea from a 1:1 conversation to your larger team, to taking the idea to maybe dozens of customers, to understanding how to get buy-in to scale it into a new product or feature combined with other ideas, or how to iteratively take the ambiguous concept through multiple stages of development and creation to the ends of scalability. During the interviews folks will ask you more questions to try and understand that depth. Each team will generally decide the most important leadership principles before the interview so that everyone knows what is important. Beyond the scale/complexity/impact and finding a balance between them, there’s a complex interaction between leadership principles that’s beyond this post. Such as: which ones you can easily learn, which ones you need to practice, and which ones are more related to personality. For example, Frugality is fairly easily learned on the job, but Think Big is much harder to learn. Deliver Results is often a positive indicator of the other principles working, as opposed to being a standalone principle.

Either way, you should expect to be asked a bunch of questions about your past behavior and know the interviewers are comparing your work to either functional requirements or leadership principles.

How it works: ‘Raising the?bar’

One of the more unique Amazon interview processes is the Bar Raiser (BR). As a candidate, this section may help you understand a bit of how our decision-making sausage is made.

A Bar Raiser is someone outside of the direct team that has a certain amount of both interviews and mentored training. The BR is there to help the team determine if that candidate is better than 50% of the current people in the current role. The core concept is that sometimes hiring managers and teams are really motivated to hire people, even if it means making compromises. After all, managers are often judged at AWS if they can actually hire all the people they asked for. The growth can be a bit crazy to manage. It is the mechanism we use to make sure that our teams don’t become complacent over time or chase growth over quality.

What do they teach you in this training? More than a few things. One of the first things is well-written feedback. AWS is a very writing-intensive company. And the first thing everyone does before making a decision on a candidate is to take time to read everyone’s feedback. As a candidate, you’ll hear and see lots of notes being taken during your interview (sometimes to a fault).

It’s critical that the feedback is detailed, uses examples to back up claims, and is objective. It’s harder to be objective than you think when you instinctively want to like or dislike people, which comes with all types of potential bias. Objective feedback also helps guard against nasties like “this person isn’t a cultural fit”, which isn’t related to either a leadership principal or functional requirement. It's worth noting that everyone has to submit their own written objective feedback before they can see anyone else's, so we get an unbiased view from the group before making a decision.

The BR is also responsible for the preparation of the candidate experience. You need to make sure not too many people are shadowing, the important things the hiring manager are looking for are in the assignments, push for more diverse interview panels, that interviewers have the right context before interviewing, that the timing is appropriate for the candidate, and that you’ll have enough information after the interview to make a fair decision. For AWS, we treat every candidate like a customer (and likely are). This also extends to how the Bar Raiser conducts the interview with the candidate and what the interview experience is like.

The other responsibility pushed to bar raisers is building consensus. It’s the hairy-hard part. You have a group of people that will work with this candidate every day, and you have to help the team come to the conclusion of whether that’s a good idea or not. It can be heated. Hiring managers may have buddies they’ve worked with before. Technical people may doubt the candidate’s skills because it doesn’t resemble their own. Likable people are dangerously easy to hire even if they don’t have the right skills. Hiring managers may lose their headcount if someone isn’t hired. Some senior leader may be really opinionated. The hiring manager may want to change the definition of what they’re looking for in order to make this candidate fit. But bringing in the wrong person can sink a team, and spread issues to other teams.

Some of the major techniques for consensus revolve around consistency. Setting expectations, calling out objective issues associated with the role, and finding ways to identify bias. Some of the questions I ask folks when we’re trying to hire someone include:

Is this person better than 50% of the people in the role that you work with today?

Do we think the candidate could simply do the job? Or really drive it, show ownership, and excel in this position?

After a year, do you think this person would be successful here? Or are the risks too high?

What is their superpower? Would you admire them?

Do we have the right supports for their current gaps? Do we have the right mentors or learning resources?

When is the timeline where you need this person to be executing, and will they be ready by that time?

Do we think the actions we have seen are driven by their surrounding culture? If given a different environment, would they adapt?

If we didn’t hire this person, would we be making a mistake?

No matter how you slice it, there are hard decisions when you hire. And given the choice, AWS will turn down a potentially good candidate rather than make a bad hire. And these hard decisions never get easier. If there is no way to come to consensus, the bar raiser can also veto the hiring manager and decline a hire, so there’s a checks-and-balances system for hiring (it’s rare). It’s not perfect, but that’s probably also a different post. I’ve put more about what I’ve learned in the interviewing tips below.

In general, most interview loops are aligned. Often the loop will hone in on 1–3 common gaps. It ranges from communication, functional requirements, or a few leadership principles. There are less gloves-off standoffs than you might imagine. The bar raiser is also responsible for preventing the opinions of a singular interviewer from controlling the outcome for a candidate. Particularly with experienced interviewers, you see common concerns and less disagreement.

Personally, I’ve found that I use the consensus building from bar raising in day to day skills, such as trying to make product decisions. You get initial buy-in on what’s important, collect opinions and data, and then try to measure those the best you can. You’ll still get punched in the mouth and have to try again with a less-formed plan, but you get a little used to it. It gives this role a sort of double-duty.

Advice for candidates, tips and?hints

I’m going to experiment here, and give very specific advice to folks that may interview with me after reading this. I suppose if you find this and read this far, good for you.

Either way, here are some of the most common things I wish I could help candidates with more:

• Phone screen preparation is difficult. You generally won’t know what direction the interviewer will go. I suggest researching or reading about the types of things you may do in the role based on the job description so you can align your answers and thoughts towards that direction. Thinking about a few projects/products/architectures you may want to go describe could be helpful as well. If you don’t have an AWS account, create one and play around a bit and try to build something (if you’re applying to a builder role).
• For the loop, it’s worth your time to write or think about your resume as a set of stories, likely tagged or oriented to leadership principles. Think about some of the hardest scenarios, largest failures, biggest lessons, and most scale/impact you’ve had around the leadership principles. When you’re asked 30 questions recalling your past, you’ll have a better chance of picking good examples. I’ve had to interview internally a few times, and even knowing the entire process, I was still vulnerable to all the memory recall and nervousness issues that interviewing brings along with it. I was actually saved by internal interviewers helping me recall my own stories. Practicing your interviewing fairly regularly is another way to build this narrative, but if that’s not your thing, at least coming up with a mentally fresh set of stories can help emulate it.
• Focus on impact over mental recall convenience. When someone asks a Tell Me About a Time question, really focus on the example that you want to show off. Commonly the interviewer will only get through 2–3 of these questions. If you’re asked about a time dealing with a difficult coworker and you tell me about when Tony wouldn’t share the salt shaker so you had to reason with him, and there’s not other examples, the conclusion is you haven’t worked hard on more impactful relationships. Or you have an awesome example from 2 years ago, or the good example that happened last week. Whatever choice you made, now you only have 1–2 more stories to show off your virtual resume for this interviewer.
• But, don’t go overboard with preparation. The most prepared candidates have a cheat sheet of stories they want to tell. It can backfire if you’re bent on telling a story that isn’t aligned to the question:

Q: “Tell me about a difficult product management situation”?

A:?… “Well.. if you consider a salt shaker a product, let me tell you about Tony and how difficult he is”.?

<facepalm.jpg>

• The ‘we’ problem. If you’re humble, that’s great. However, for interviewing it can cause some issues, since we’re looking for your specific contributions. Getting over this can stem from some-part-of-the-world culture, company culture, or your personality and can be difficult to balance for folks. But if someone asks you about a project and everything is ‘we’ there’s not a great way to determine if you were just on a good team at the right point in time versus someone that helped drive that project. Ask yourself, and explain “If you weren’t on this large project, what would have been different? What did you bring?” I don’t like being on the decision-making end trying to guess what someone’s impact was. I’ve certainly been on teams and projects driven by other people that look good on my resume and sound nice. But, if your interviewer is worth their salt, they’ll dig into that and expose it. Not making your impact clear is taking time away from talking about the rest of your stories.

• The situation-task-action-result (STAR) format isn’t a secret. Do the interviewer a favor and try to orient around it. The biggest issues I see are:?

1) Too much context. Sure, show off your knowledge, but honestly, we’re evaluating your behavior and not your ability to perceive the situation around you. Get to what you did or what you changed.

2) Not coming to a result. You fixed a bug? Ok, great. If you spent 100 hours, was it worth? Was it worth 2 hours? How did you know? Do you reason about your time and effort? How? Walk through your thought process. Exclusion of this implies you didn’t think about the result.?

3) The ‘why’. Not mentioning how this project got to you, why it mattered, what your role was, or why it was particularly notable.

4) Not exposing the good technical details. For example, the example below makes it sound like someone else did the hard parts, and you were along for the ride:

“I was able to work with the team and vendors, talk about requirements and come to a few options. We evaluated the options, did some research and came up with our plan. Then, I worked with the team to do validation analysis in the lab, and we had some results to use architecture B. We worked with management on some cost issues and got approval. We pushed the project to production with some issues, but we fixed them.”

An example of digging into the hard parts instead:

“I did a combination of talking peers in division X, researched options from analysts, found out our corporate-approved options, and read whitepapers and blogs on topics A, B, and C. I chose to start with architecture B because it had the multi-threaded scaling we needed, since back of the napkin math said we needed Y nodes based on requirement for X scale. My management wanted option A since it had a lower cost per node, but I was able to show that we could use B in a similar way but with this feature to come to an equivalent cost but still provide feature Z. I used tool T to do verify this using a theoretical workload that looked like Z, and found the results to be within Y% of our original estimation. When the deployment team put the code into production it caught on fire, because that’s what technology does, and we fixed it with this type of code change. Even then we still had an impact of X% more users over the next year.”

Hint: This style also applies to your writing sample, and more widely to how we communicate here.

• Don’t try to be the candidate you think you need to be. Unless the role specifically asks for you to be an AWS expert, don’t try to be one. You’ll rarely win that battle. For most roles, we’re looking for your strengths today. Example: I had almost no AWS experience before starting. In every interview, I’m going to ask questions that push you to say “I don’t know” at some point. If you give a wrong answer, that’s four times worse than saying I don’t know. Don’t try to google something and answer it live, it’s dead obvious and eight times worse than a wrong answer. If you have a lot of complex data center experience but two surface-level AWS projects, you’re probably better off with your deeper data center experience. Look at the job role or ask the interviewer for help.
• Also if you’re curious, please ask the questions you want to ask, even if they may seem obvious. This ranges from role/job questions, company, and particularly clarifications about the questions asked. The question I’m surprised I’m not asked more is “What are you looking for from this question?” since many are quite broad and I’m happy to share what I’m looking for. In fact, many questions I ask can be answered in a myriad of ways, each of which explains a bit about the candidate’s thought process. A common technical question is “Explain to me what happens after I type amazon.com in the URL bar”. I’m curious where they take it (OS, L3, browser details, load balancing, DNS, web architecture, etc). So I’m looking for a combination of breadth and depth, but nobody really asks to clarify that giant question. If it’s confusing, just ask. I’m also happy to answer the hard-hitting or more controversial questions if they are things that are something that concern you, this job would be a significant part of your life and answers to your questions matter. The only exception is “how did I do?” at the end — it’s a bit of a legal minefield providing feedback to candidates, so I tend to defer and say “I enjoyed our conversation” which doesn’t really help anybody.
• Communicate as clearly as you can. One note about our writing and communication style is that if you can say it simply, you should. There are no extra bonus points for jargon, corporate business-isms, or posturing through hiding via generalisms, unsubstantiated adjectives, or generally sounding like a buzzword machine. And getting to your most impressive actions and impacts quickly, without flooding the story with context that doesn’t necessarily add to your character. (I have some examples below in the interviewing section.)
• If you’re given a writing sample, spend time on it. I’ve had numerous interviews where the consensus mostly wanted to hire someone, but the writing sample was the deal-breaker. We understand there are relatively few strong writing communities in the enterprise world. But particularly for more senior positions or writing-heavy positions (you’ll know because they require a writing sample) a bad writing sample but good interview can make or break your offer. Though I haven’t often found the opposite — most great writing samples have been candidates we wanted to hire. At AWS we value structure, clarity, logic, and a narrative over the PowerPoint skills and presentation slickness. (Though there times and places for that.)
• Each role has it’s own functional intricacies. SDE’s have ambiguity, coding, and system design. Solutions Architects are usually around tech depth, tech breadth, industry, or other specialized domain knowledge. Product management is around prioritization, strategy, inbound/outbound, and pricing. Account management is often around executive skills, long-term sales planning, and customer interaction. You may want to read the job description and make sure your stories line up with it. Which leads me to..
• Understand the role. One of my first questions is usually “do you understand the role?”. Please, please tell me an honest answer. See “Don’t try to be the candidate you think you need to be.” I’ve had to interview folks for some odd roles, and even then half of candidates would say it was totally clear to them. Either ask the interviewer to expand or ask questions up front, because it will make it more clear why certain questions are being asked.
• For video conferencing: Please don’t stress out about it. Things are never perfect. Do whatever you can to make yourself more comfortable. You almost certainly don’t need a tie. And my interview feedback would be 100% the same if you were holding a cat, dog, toddler, or your favorite stuffed bunny. My kids have proudly explained their pooping habits on interviews, shit happens. And if you need a water break or a few minutes, just say it.
• If you want to be in the system as an internal recommendation, wait for an employee to put you in the system. It’s kind of a bummer to try and refer someone for a position and the system says they’ve already applied and not eligible. Candidates tend to have a slightly better chance if they come in as a referral, plus the employee is then eligible for benefits if you get through. But if they’re slow or not responsive, don’t wait for it.

I’m not sure how useful this is, but here are some of the most common reasons we don’t hire candidates:

• During the phone screen, it’s usually skills. Either breadth/mapping of skills or depth in those skills (complexity/impact/scale). It’s rarely a single bad answer or two, but indicators of depth or breadth across multiple questions. Even then, we look for compensating abilities like how quick the candidate has adapted to new roles/skills, ability to ‘look around the corner’, or work through difficult situations before.
• During the phone screen there are some common issues. Communication issues are common, particularly for customer-facing roles. Being able to succinctly answer questions, with the right information, can be tough. Providing context without going off the rails, or providing too high-level hand-wavy information without connections to the building process, or answering the wrong question — e.g “Tell me about a difficult relationship with a coworker”: “Well, I found this protocol very hard to work with..”.
• Earning trust, in general. This can be manifested in a few variations: the used-car salesman with surface-level relationship building but no backing, the name-dropping elitist, the over-promise under-deliver resume bloater, and all types of cultural and inclusion red flags. If there are issues here, there’s few chances there’s a fit anywhere.
• The scope and impact of the candidate. AWS has unique scaling requirements and history, and finding people with behaviors and skills that similarly scale can be hard to find. This is often a challenge for people that can pass the functional requirements, and could probably do the job, but don’t have the examples of pushing the complexity, scale, and impact levers in their current job so they don’t raise the bar. So they could be a fit, but maybe at a lower level. But the team needs someone to execute at a higher level, now. Or, they’re too senior to accept a lower role.
• Job mismatches. We’ll consider someone with a different job role than what they’re applying for, but it’s not always a fit, since our format focuses less on what you could be versus what we saw in the interview. Definitely depends on the two pizza team thing here.
• Great functional fit, but have a few key leadership principal gaps. This could be your industry expert that knows everything but never questions how to come up with new ideas and doesn’t seek new input. Or the phenomenal trust-earning sales person who struggles with creating big sales strategies outside of hitting their quarterly number. Or the architect that knows their technology, but doesn’t understand how to get executives on-board or hasn’t learned anything new in ten years. Or the senior engineer that is hyper-smart, but doesn’t take the time to be curious or question themselves.

Advice to interviewers, and some things I’ve?learned

I like interviewing people. I get the awesome opportunity to really listen to folks as they open up. Even for the candidates which were definitely not a fit for the role, I’ve been able to learn something them. As a big-company perspective-thing, it’s also humbling to see so many people that want to come join what you’re working on. You also get to learn about other ships in the fleet and broaden your perspective.

Undeniably, interviewing is a privilege. Particularly the privilege to interview so many people is an indicator of the growth which isn’t normal. And it’s crazy that we struggle to hire enough people (we have thousands of open jobs), even with so much interest. I’ve interviewed 1 person a week at AWS over 5 years, turning down probably just as many interviews.

Although it’s probably not standard practice, I don’t look at resumes. I’ve think there’s potential bias I have about companies, locations, titles, or other metadata. Instead, I ask “introduce yourself in 3–4 minutes” which both gives me the context and an indicator if they can contain their excitement/mental framework to concisely answer the question. I’ve found that checking a resume after an interview doesn’t give me much more information than what I’ve already collected. I’ll use the resume in certain situations, but it’s optional. I try to give each candidate the same experience regardless of their history. I don’t like the feeling of looking at a resume and having the option of thinking the candidate will be a fit or not before we’ve even spoken. I don’t believe in this so strongly to tell others to do this, but I would challenge folks to try it for a few interviews and see if it makes a difference.

I’ve already said I think interviewers should help the candidate be their best self. A lot of this starts with candidate comfort. I try to do this in a few ways. One, ask if this time still works for them. Particularly these days, stuff changes. You’d be surprised how often some comes up for them or these was miscommunications. And life stuff should outweigh an interview slot but candidates are “trying to be the candidate you think they should be” and may make life trade-offs that don’t help them in the interview. We take months to hire someone, waiting a few days is usually fine. See if they want a water break. Try to break up the monotony, or go back and forth between questions that spike the brain CPU to 100% and something more comfortable.

Make sure the candidate understands the context of the role but also a chance to openly introduce themselves without judgement. I’ve found I would rather give up 5–10 minutes of question time for additional intro and context to get information that helps me make a decision and ask better questions.

Also I find the questions candidates ask matter. This was an insight I learned recently and have liked the results, so I’ve introduced asking questions as part of my introduction. I initially left questions towards the end, as my main task was to collect information. It serves a few purposes 1) It extends the relationship-building and comfort 2) Introduces extra context you can use for probing questions 3) Is a mild indicator for curiosity and what the candidate wants to learn about, and how much preparation they’ve done 4) Avoids the shitty we-have-135-seconds-left-do-you-have-any-questions-question-mark problem. Asking questions up front prioritizes the candidate experience over your own interviewing task, as long as you keep an eye on time. Sometimes folks are more comfortable asking questions at the end, which is also fine.

You own providing a good experience to the candidate. I think too many people view interviewing as a battle of sorts.

Interviewers sometimes believe you have to push hard, test them, wield your particular expertise, see how they riposte, and test the candidate by fire. There’s probably a time and place for this, like if they’re going to do that every day in their job. It took me some time to figure this out, but it’s better to try and help the candidate expose the best things about themselves.

Let’s all say it together: Interviewing sucks

It’s like having an uncomfortable session with a psychotherapist, which along with the uncomfortable agony of self-reflection, you get to second-guess all your life decisions with a stranger. And if you don’t do it well, it can impact long-term income, livelihood, happiness, and quality of life. Not fun.

So people understandably get nervous, make abnormal judgement calls, blank out, or forget how to build some binary-tree thing. I’ve forgotten very burned-in protocol details because I was simultaneously honored by the interviewer and terrified of them. This is all the more reason to hire for strengths. This Abraham Lincoln quote describes hiring for abilities rather than lack of faults:

After the failure of his first experimental explorations around Vicksburg, a committee of abolition war managers waited upon the President and demanded the General’s removal, on the false charge that he was a whiskey drinker, and little better than a common drunkard. “Ah!” exclaimed Honest Old Abe, “you surprise me, gentlemen. But can you tell me where he gets his whiskey?” “We cannot, Mr. President. But why do you desire to know?” “Because, if I can only find out, I will send a barrel of this wonderful whiskey to every general in the army.”

To me, this means giving candidates all the chances to expose their best strengths. I’ll often ask things like:

“Anything else you’d like to brag about yourself in this situation?”

“If you got to present for 4 hours on anything at all, what would be your area to shine?”

“Are there any other questions I can ask that would help you show off your particular skills?”

I prefer to keep the technical parts of the interview in their self-described comfort zones. I’ll ask fairly naive questions like “What were the alternatives?”, “What was the hard part?”, “What did this impact?”, “What did you give up in order to pursue this?”, “Who stood in your way and why?”, and “If you did this again today, what would you change?”. Though sometimes you’ll need to dig into specific areas for specialty positions, so it’s a guideline rather than a rule.

AWS is also a very broad place, from augmented reality, blockchain, 15 databases, networking, 20 types of security, development practices, storage, programming interfaces, storage, ‘the devops’, serverless-that-has-servers, and all types of industries. You can try to steer the technical conversation by keeping it scenario and experience focused, but at some point you’re going to be in a technical discussion you don’t understand. I’ve found one of the benefits of interviewing customer-facing roles is they’re expected to explain their knowledge to uninformed people. So, I use some of these examples to “tell me what that means to someone that isn’t familiar with this area”, and I work through the example in a customer-facing way.

You have to be really careful with trivia questions, where the interviewer picks some topics and plays poke-the-candidate with their pet topics. One of the most awesome things about AWS is the insurmountable breadth of our services. But it also means you don’t get to pick your pet topics, because you’re not doing anyone justice except your fragile little mindset of architectural knowledge that’s propped up with toothpicks and crazy glue. Even if you try to pick 10 generic topics you’re probably going to miss. The only way I’ve found to counter this is to allow the candidate to select their own topics and stay within those domains. Even then, you need to give them a chance to show their best in those topics.

Your more senior interviewers should ideally be doing the phone screening. I find phone screens way more taxing than loop interviews, since one person is holding a large amount of another person’s fate rather than a consensus mechanism. The costs are high: either passing on a good candidate due to poor interviewing, or putting a candidate through with very low chances of getting through a loop and putting a time burden on 5–7 people including the candidate isn’t a great outcome. Which brings me to another point, if you aren’t fully confident in your phone screening, you should be trying to actively improve it..

So, always be shadowing. This means passively listening in to other people’s interviews, or allowing others to run the interview and listening in. No matter how junior or senior you are, there’s value in doing both. This allows you to view other styles, get more diverse feedback on your style, help get a better perspective on you judge candidates, and improve your interviewing.

I also believe you should structure part of your questions and follow-ups by thinking about the consensus process you’ll have to run. As much as possible, I keep the structure the same for a role. However, follow up questions vary based on answers and candidate. Around halfway through the interview, I ask myself, “What other information would I need to be more confident in my decision?” and “what concerns would others come up with, and can I find some data points on that?” and steer towards missing data. For the candidate that is too-cool-for-school, I like to ask questions involving humility and learning from failure. For the super-deep-tech person, can they also influence with that knowledge, and do they know why they do things? Can the sales-leader break away from quarterly deals to truly do the right thing? Can the data-driven product pricing person make choices in ambiguous areas? Can the industry expert close deals if they have to work outside their network of contacts? Can the SOW-driven consultant proactively think about bigger projects? Can the pretty-good individual contributor see around corners, help other groups, help scale their work, or dig into really complex issues?

Then you have the folks that say a lot, without saying anything at all. There seems to be a corporate incentive structure for people to learn a specific type of business talk of saying what you want to hear without taking any risks or conveying anything meaningful. If the candidate is saying:

“I helped the team to.. create the synergy for..?

lead a workshop involving stakeholders?.. so I oriented the team around the business problem?..

focused on the business value while we discovered value for the stakeholders..

we listened and then we took action while..?

created a framework for the business to execute on while focusing on the most important customer needs while keeping a pulse on key metrics and providing a holistic view to stakeholders with a team-value based approach to success..

I aligned our technology portfolio to customer desires in high margin businesses to create a sustainable business that is propped up with customer success and measured in business outcomes by doing the right thing, listening, and working together to mutually create beneficial technical and business architectures with KPIs that are repeatable across a multitude of customer segments and partner categories which operate within a global ecosystem of platforms and integrations in a self-service and reusable architecture of innovation..

..took the requirements from the customers to the engineers so they didn't have to..”

Ugh. I’ll ask something like “If I watched your computer, saw you speak in meetings, and generally followed you — what would I actually see? Unless your job is literally to create unintelligible processes, let’s get more specific. What types of things do you do with your keyboard?” What is it you would say you do here?

There’s also the lessons of what I’ve learned to appreciate through interviewing. I am super appreciative of the diversity of people we interview. I mean diversity in two primary ways. The first type is the typical inclusion, diversity, and equity perspective (or the preferred nomenclature from HR or the twitterverse today). I’ve seen a noticeable difference in diversity in the last year or two, and hope that continues. The teams at AWS are taking it really seriously. If you’re part of a group not well represented in white-and-Asian-guy-tech, seriously think about just applying to interesting jobs and see what’s out there — folks are probably more eager to hear from you than you expect. Obviously there’s a lot of progress to make here.

The second aspect is the technical diversity. I absolutely love the fact I can interview and work with people with completely different skill sets and we’re all in adjacent boats. You can sit down with someone that deployed the first streaming audio setups, helped invent CAP-theorem extensions to databases, or deployed satellite networks to oil rigs in the sea.

As one aside, I’ve considerably picked up my interviewing during COVID. I’ve found it an escape from the confines of the teams, problems, people, and life I live in every day and each conversation is an inspiration in some way. I think it’s an awesome way to think differently. In theory, each interview is also some sort of self-reflection questioning your own judgement against the candidates. If you mock the answers you would give to your own questions and judge yourself against your own framework, how would you do? Do you have a fair perspective of the many ways to be successful in any given role? Are you holding others, or yourself, to an unrealistic expectation? Do you do the things you expect from others? Is it possible the candidate is way smarter than you but just in a different area? How would you determine that?

Closing thoughts

The more you interview people, the more you’ll peer into both the role and other people, and the more it will teach you things you don’t know. And if that’s not the truth, you’re probably not being intellectually honest with yourself.

And if you’re not interviewing people, maybe you should spend more time interviewing for internal jobs or at other companies. It takes practice, even just recalling all the stories that would make up a resume in story-form.

I don’t think interviewing on either side really ever gets easier. I think it gets more comfortable, and you can have more approaches to common problems. I think you can start to have higher degrees of confidence over time. However, the roles, candidates, expectations, and your biases will continue to change. What doesn’t change is your impact on the person you’re talking to, and how much a job opportunity can change their life. I would feel uneasy if the combined unknowns and the impact was simple.

Whether you’re interviewing or interviewing, I hope this gave you some perspective, tips, or hints to think about.

If you’re interested, AWS is perpetually hiring. Hopefully, most of the advice I normally give to folks 1:1 on phone calls is in this post. Ping me anyways if you’re curious.

Some AWS job roles I’d recommend currently:

• Well-Architected networking lead (US virtual)
• Software development manager, VPN (Seattle)
• Software development engineer I, VPN (Virginia)
• Systems development engineering, VPN (Virginia)
• Product manager, Virtual Private Cloud (Seattle)
• Front end engineering, VPN (Virginia)