Almost every interview includes some scenario-based questions. Tell me about a time when you solved a problem for a customer. Tell me about a time when you had to deal with a difficult stakeholder. These are just a few examples of these types of questions you are likely to face.

While good interviewers will ask more pointed questions, you will also encounter open-ended questions about your experience and the positions listed on your resume. So, you worked at company XYZ? That is an invitation to tell the person about your role and contributions there. You will also get open-ended questions of the form, “I see here you are familiar with Java (or SQL, or insert any other technology here)”.

Scenario-based questions are a key part of Amazon’s interview process, as they are with many other tech companies. When you interview at smaller and medium size companies, you are apt to see more open-ended questions. In either case, this gives you the opportunity to showcase your capabilities, on your terms.

You have the opportunity to convey three different aspects of your experience. When you decide what scenarios to use, think about these three dimensions and how they bring out the best in you.

1. Your role and responsibilities. This is what you were hired to do and thus, sets a framework for the story.
2. Your contributions. This is what you were able to achieve. You may have met the bar for your role, or you may have exceeded expectations. You may even have had some minor failures or lessons learned along the way. In any case, make it as tangible as possible.
3. Things you learned that apply to your future position. This does not have to be technical. It could be that you learned how to better interact with customers or identify their pain points. Keep in mind, there are many people out there with some degree of technical skills and experience. However, only a subset has the ability to learn, adapt, and contribute at a high level. Show how your experience brought you to this point and prepared you for this role.

The five scenarios to prepare

You should have stories ready to go for at least these five scenarios:

1. Tell me about a time when you solved a difficult technical problem
2. Tell me about a time when you had to deal with a difficult customer, co-worker, or manager
3. Tell me about a time when you faced a tough deadline or had to make a decision with limited information
4. Tell me about your role and responsibilities at your current employer
5. Tell me about your role and responsibilities at your employer previous to that

The last two are simply a prepared story that highlights the best of your work experience at your previous two employers (or less if applicable). Many of the same points highlighted below apply to general questions regarding your current job.

Ideally, these are five unique stories but it's fine if a few of them overlap. If your solving-a-difficult-problem story is at your current or previous employer, that is fine. When you go through an interview loop (a number of interviews with the same company), you may get asked the same question multiple times. If you can use different examples, it provides more data to the company. However, retelling the same story a few times is okay if you don’t have a better example.

Try to choose examples that are fairly recent. A story from 10 or 15 years ago doesn’t tell the interviewer that much about you today. If there are high degrees of similarity, then go ahead and use it. Generally, very old stories should be the exception to the rule.

You should also have a fairly good recollection of the details of the scenarios that you pick. You will likely be asked further detailed questions about why you chose a particular path or handled the situation as you did. Details can be important, and it would be bad if you used a scenario but didn’t remember key aspects of it.

---

How to tell stories about your experience in an interview

Earlier we said that scenario-based questions give you the opportunity to showcase your skills on your terms. Why do we say that?

In a problem-solving scenario, the interviewer is driving the interaction. You are limited in what you can showcase. You can’t solve a different problem, one that you like better. You have to work with what you are given. However, in experiential questions, you drive the narrative. You control the storytelling, at least to a large degree. At some point, the interviewer will almost certainly start asking questions about your experience and why you made particular choices.

In general, you are in control. Now, what is the best way to tell the story?

First, don’t include too much detail. You want to sketch a few key details to give context. You want to frame the scene and let them ask for more specifics if they choose. Essentially, don’t take forever to explain the background. This story is another data point for the employer on how well you can communicate summary information. Thus, manage your time on these questions.

What details should you use to sketch out the situation? This is similar to crafting a description that goes on your resume. Be sure to read the job description so you can tailor your story to the specific role. Include metrics when possible that highlight your capabilities or experience. If I was a tech lead, I might include how many engineers were on the team. Thus, instead of saying people on the team would come to me for advice, you can say there were six other engineers who came to me with their design questions for help.

For technical examples, include the key technologies or development stacks that you used. For example, a Spring web application with a Postgres database. If the technology stack was standard, use enough information to identify it but don’t spend all day listing the technologies. However, if there are technologies that stand out, then include those. If you use Redis as a cache in your project, definitely include that detail. If there was an object-oriented database instead of a relational or NoSQL database, mention that.

Now that you have set the context, you want to highlight the responsibility that you had and how you met or exceeded expectations. I recommend calling out any decision-making processes that you went through. If you evaluated alternatives for a COTS product or different design options, then discuss your evaluation methodology. Include why you chose one option over another.

One of the most important things that many candidates forget to discuss is the results. Based on the actions that you took, what were the results? After deploying the system, did those decisions turn out to be good ones? If not, why?

While I wouldn’t necessarily choose an example where the project ended in failure, it is certainly fine to include some of the negative outcomes. Almost every technology decision has some tradeoff, so show that you learned from that or things worked out on balance. If you describe the outcome as all sunshine and roses, just be aware of how your answer is perceived.

For example, let’s say I am discussing a previous project with strict API performance requirements. Thus, I included the use of Redis in the design because it provided the highest possible throughput and lowest latency. That is great, the project met the performance requirements. However, what were the drawbacks of that? Was the operational burden higher? Did I have any issues with cache invalidation? Were there occasions or issues with data in Redis getting stale and the system returning incorrect or outdated information?

It's okay if the experience wasn’t perfect. Hardly any system is perfect. Almost all of them have operational issues after launching, and it can take a while to get a new system running smoothly. But that is invaluable experience, and it can come across as such in an interview when you explain the lessons learned along the way. It's also important to discuss how your system behaved in production. This shows an attention to detail and commitment to the effort. Many engineers like going straight to what they perceive as the next engineering problem after they finish a coding project. However, in many scenarios, engineers have some responsibility in supporting operations because they are the ones who know the system best.

At Amazon and many other places, each development team owns its service and goes through an on-call rotation. No one really looks forward to it, but you learn a tremendous amount about your service, your customers, and how systems behave when placed into uncontrolled environments, i.e. production. These are great points to focus on when telling your story if you were able to support operations. You don’t need to be concerned about pigeon- holing yourself into a DevOps role. That is a separate conversation. It is valuable to have team members who have seen firsthand how these different design decisions work in reality vs. on paper. It will improve your standing in the interview process to convey that as much as possible.

There are a lot of things to consider here about your experiential stories to tell in a technical interview. Fortunately, all of the details of these stories are things you already know. They come from your experience, so you can have prepared your answers in large part ahead of time. You may get a slightly different “tell me about a time” question than exactly what you planned, but many of them carry over in some way. Cover the basics and feel good about what you have accomplished. The pride in your work will show when you tell others about it.

A structured approach to your stories

Thus far, we have been informally describing what is formally known as the STAR method.

STAR stands for:

• Situation
• Task
• Action
• Results

When you are preparing your stories, use this pattern if you get lost a little bit or aren’t sure what to talk about next. Sketch the details of the situation. If you provide a little context, an experienced interviewer will fill in the rest. Explain the task, or what you were responsible for. Talk about what action you took or the decision you made. Then explain the results. Talk about how it turned out, and what worked well and what didn’t. Include any lessons learned so it's clear that you can apply the knowledge from this situation to your potential work for the company in question.

What if you have very little or no industry experience?

Don’t panic if you don’t have five scenarios to use. Always keep in mind that the goal of the interview is to project how you would perform in the future position. Your first job in tech will not be based on industry experience, because you don’t have any at that point. You are projecting your ability to excel in the environment at an entry-level position.

Thus, in cases where you are short on stories, find analogous stories from other professions or your student career. If you go this route, I would not spend an inordinate amount of time on them. Rather, simply highlight how you have the foundational skills and capability to meet the target criteria.

If the interview question is about solving a technical problem, tell them how you did this in a group project at school. You may even talk about the most challenging side project or open-source effort in which you have participated. Whatever you choose, think about the transferable skills that apply to this new job and be sure to include that information in your story.

An example using the STAR pattern

Here is an example of using the STAR technique to tell a story about a previous project.

Situation

On my previous project, I was the technical lead for a four-person development team. Our service retrieved data from a legacy source system and provided high-speed APIs for downstream systems to access the data. I created the architecture and had it reviewed by the senior architects. We used a Spring service running on containers in AWS ECS. I implemented key Java components and also reviewed designs and code written by other engineers on the team. I helped them whenever they needed it, and also worked with the project managers on task planning and estimation.

Task

The goal of our system was to isolate legacy systems from all downstream systems. A design goal was to make the APIs agnostic of the source system. They should not carry forward any legacy concepts. There was also a large volume of data to be processed downstream that required the use of our data access APIs. Thus, performance was a major consideration in defining the architecture. We had a requirement to notify consumers when new or modified data was available. I came into the project at the beginning of the year, and we needed to be ready for production by the end of Q2.

Action

I started by evaluating different architectural options. The corporate architecture already heavily used Spring Boot Java-based services, so that was a starting point. We wanted to avoid any cold start issues given our latency requirements, and the company was not heavily using Lambda at that point, so we chose to run our services on containers in AWS ECS. The choice of data store got the most attention. I led a proof of concept that evaluated Postgres and Redis, and Redis provided much better performance. It gave us some headroom on our strict latency requirements, so we used it as an LRU cache sitting in front of the Postgres database. We chose Amazon SNS to send change notifications. These were published from our data ingest component.

Result

The project was a success and we delivered on time. We met our performance requirements and the downstream systems were successfully able to use our APIs. The use of Redis made our API extremely fast. We did have a few issues at first with the timing of notifications and the data being available in Redis replicas, so we included a version token in our notifications that clients could echo back to make sure they were getting the latest data. That was an issue we did not anticipate given the very small time window during replication, but we were able to adjust quickly and the system has been extremely reliable. The stakeholders were very happy with the results.

An analysis of this STAR example

Now let's analyze this story. It begins by setting the stage with a few key details to give context. Although a tech lead has many responsibilities not mentioned here, the information provided is noteworthy. The size of the team is mentioned, so we know how many developers are being guided by the lead. It also gives the interviewer a sense of the size and scope of the project.

One important responsibility noted was the role of defining the architecture. This shows technical acumen and leadership. By including the fact it was reviewed by senior engineers, it shows this project was not done in a vacuum. The architecture would have gone through some level of scrutiny. This gives it a greater sense of quality. It also demonstrates that the candidate knows how to communicate technical information and accept feedback. While the story doesn’t say how much positive or negative feedback was received during the review, it is assumed it was mostly positive because the project goes to completion and is well received. An astute interviewer may ask what type of feedback was received, or what did you learn or improve from the review? Be sure to recollect these types of details in case the interviewer wants to drill down on a certain area.

In the task section, the driving requirements are noted. The candidate chose the most important elements that went into the decision-making process to follow. There are many other requirements not mentioned. There are also many other metrics not discussed, such as error rate or uptime. This is an important skill for engineers. Some candidates provide too much detail and lose the main point of the story. This example here focuses on what was important to the stakeholders and the criteria that went into defining the architecture and subsequent implementation.

The action taken highlights that the candidate took a proactive approach. They conducted a proof of concept to obtain more data on the performance of the options. This shows multiple characteristics a potential employer would value. One, the candidate is hands-on and did not rush into an option. Because both the database and Redis options appeared to be valid, more data was gathered to make a final decision. It is good for a technical lead to be hands-on in these types of scenarios. Thus, the candidate can also point to a data-driven decision-making process. These are valuable skills in the engineering world.

The results were kept short and sweet. The work was delivered on time and the key requirements were met. Results from both a technical and people perspective were included. The system did what it was supposed to do, and the stakeholders were happy. One criticism would be that more detail or specifics could be included on the stakeholder's acceptance of the system. Another criticism would be to include a key performance metric to make the story more concrete. This would also add validity and credence to what the candidate is describing.

In general, this is a well-rounded story with a good starting level of detail. There are plenty of opportunities for the interviewer to ask detailed follow-up questions, but the foundation of the candidate’s role, responsibilities, and contributions was presented very clearly.