How to answer interview questions about the Amazon leadership principle "Invent and Simplify"

The third Amazon leadership principle is “Invent and Simplify.” If you’re preparing for an interview there, you should practice answering questions based on this leadership principle.

If you don’t know about the Amazon leadership principles, you should read this article about interviewing at Amazon first.

How Amazon explains the “Invent and Simplify” leadership principle

Leaders expect and require innovation and invention from their teams and always find ways to simplify. They are externally aware, look for new ideas from everywhere, and are not limited by “not invented here." As we do new things, we accept that we may be misunderstood for long periods of time.

What does “invent and simplify” mean exactly?

The “invent” part of this leadership principle is that Amazon frequently does new things, whether “new” means new scale, new products, new platforms, or something else new.

The “simplify” part of this leadership principle is the idea that everyone, no matter what type of job they have, has the opportunity to simplify something, usually a process. Making something simpler is desirable because simpler usually equals greater efficiency, i.e., quicker or cheaper, and what company wouldn’t like that?

My clients sometimes worry that, if they’re not inventing new products or new technologies as part of their job, they won’t be able to answer questions about the Invent and Simplify principle. But that’s not true. You definitely don’t have to be “inventing” things to do well on this principle. Anyone in any type of role can have an impact on a process.

So besides wanting to know if you’ve invented or simplified, what is your interviewer looking for when she asks you to speak to this principle?

Amazon wants people who are curious and well informed and can be creative in thinking of solutions. They want people who can easily generate multiple ideas for problem solving. They want people who know how to find answers by looking into how other departments or other industries do things. Above all, they want people who will try to improve things, not just accept the status quo blindly.

How many examples do I need for this principle?

Most people say that you should have two examples for each principle. That’s a good benchmark, but what if you get asked four Invent and Simplify questions? Will you have enough stories to answer them all?

What if they ask one innovate question and one improve a process question? In the onsite interview the interviewers will divide the principles up and each take two or three, so in one interview you may have more than two questions about a principle. What will you do if that happens?

I suggest that you practice using some questions you’ve developed for other principles to answer the Invent questions. I think it’s a better idea to have a group of answers you can tailor for the different principles depending on what you get asked than preparing two answers for each principle.

Top five Amazon interview questions for “Invent and Simplify”

There are different questions your interviewer can use to ask about your “invent and simplify” skills. Based on my experience with clients, here are the top five questions:

• Tell me about a time when you invented something.

• What improvements have you made at your current company?

• Tell me about a time when you gave a simple solution to a complex problem.

• Tell me about a time you had to think outside the box (think creatively) to close a sale or sell your product.

• What is the most innovative project you’ve worked on?

Sample answers for Invent and Simplify questions

Question: “What improvements have you made at your current company?”

Answer given by a Data Engineer:

“We were using an Enterprise Service Bus in our project for SOA, and one of the functions we use it for is to record the time when a web service request arrives at our platform and when the response leaves the platform. Logging this information helps us measure response-time performance analysis for each web service. The response-time data were stored in a database which has grown very big as the platform has expanded over the years.

We needed to keep the growth of the database in check. Per project requirements, it was also necessary to keep data available for three months online and one year in an offline storage.

I developed a tool that met and automated the requirements. Once the user configures the tool, it automatically finds the table partitions in scope, backs up those partitions, zips up the backup, and then moves the backup to tapes. As the final step, it generates SQL script files to clean up the partitions that it had backed up.

As a result of this automation, we saved at least one to two days of effort per month. We are also using this tool to clean up the logs for provisioning history from customer records.”

Stories related to automation are well suited for “Invent and Simplify” questions. Note how this Data Engineer includes the results of his work - “two days of effort per month.” In your own stories related to “Invent and Simplify,” follow this example and include specific business outcomes.

Question: “Tell me about a time you had to think outside the box.”

Answer given by a Product Manager:

The phrase “outside the box” means “not the usual way of looking at things.” If your interviewer asks you this question, you need to provide evidence that you question assumptions.

“We had a SAAS product [note: SAAS is “software as a service”] that needed to integrate with our clients’ human resources platforms. We had two target markets – healthcare and academic. Both markets offered large opportunities, but, to me, the TAM [note: TAM is “total addressable market”] of the healthcare customers was much more attractive.

The problem was that healthcare customers tended to use one type of HR platform, and academic customers used all sorts of different types. The technical team struggled with an integration solution that would work in all situations. It became apparent that we would need to build several disparate solutions, not one as we had hoped, to service both markets.

The business owner of our unit was dismissive of these technical hurdles, but I spent time with the teams, and I knew this complexity was going to add months to the project, and even threatened the feasibility of the project. So I ran the numbers and put together a presentation, demonstrating to the business owner and several senior stakeholders that we should focus on the healthcare market and revisit the academic market in the following years. I had to do a lot of convincing because, as I said, the academic opportunity was large. Eventually I convinced the business that we needed to simplify our approach and focus on the larger market and build a solution that would work for those customers.

This interviewee questions assumptions, digs into the details, and is willing to stand up for the best solution for the business, even when his seniors thought otherwise. The solution presented wasn’t a small improvement to the existing business model; it was an entirely new idea for the company and one that wasn’t conventional wisdom of trying to make all customers happy so you don’t lose any of them.”

This story impressed the interviewer and the interviewee made it to the next round.

Let’s look at one more example for this principle.

Question: Tell me about a time you invented something.

Answer given by a Senior Software Engineer:

“Three days before a big release, my customer identified that the infrastructure testing had not been completed. They would not go ahead with the release without completing testing. Specifically, the customer wanted to test the firewall connectivity between servers, and they wanted to check if the health checks were all green on the load balancers. All APIs were already responding as expected.

I stayed at the office late that night and logged into each box and ran a set of telnet commands to complete the tests. It was simple but repetitive work. After doing this for about a quarter of the 100 servers, I had had enough and knew I had to automate the process. If I continued working in the same way, I’d never finish in time, and my approach was prone to human error.

Unfortunately, due to company policy, the client hadn’t granted me the level of access I needed to create script files on the servers and execute them. So I explored a method using Java-based shell API Jcraft JSch. I wrote the proof of concept in my own workspace, completed it on the same night, and sent the results to my client contact. He was impressed and thought the approach looked sound. Based on that exchange, I built my POC into a tool that was used by the entire team.

With the tool in place, productivity improved, and we were able to complete the testing in time for the release.”

When you’re trying to think of stories for “Invent and Simplify,” think back to the times in your career when you were under constraints but still got the job done. In the story, the Senior Software Engineer was under tremendous time constraints, and she had limited access to the server to automate in the way she normally would. To “Invent and Simplify,” you must do something in a new way, either new to you or new to your business. Try to capture that spirit of “newness” in your own “Invent and Simplify” stories.