I've copied this from my Medium post and am posting it here as I believe more visibility and attention should be paid to this part of the interview that is often overlooked and could potential help someone get the leg up among a large pool of applicants.

https://medium.com/@carlyslemcnaught/how-to-pass-the-software-engineering-interview-7a56966666b

When people interview for software engineering positions most of their preparation places emphasis on some variant of doing 200 leetcode questions and picking up whatever system design blog or book is out there. Coding and design are only one piece of the pie to nailing the interview. Today, I want to talk about the behavioral portion of the interview which is often overlooked and can make or break you for the position and level you are interviewing for. Sometimes people wonder why they knock out the technical portion of the interview but still don’t land the job or why they didn’t get the level they were hoping for. “Someone must have coded up the optimal solution faster”. Maybe. Or maybe there’s another reason.

First, what qualifies me to talk about this subject? This is afterall my first Medium post and who trusts strangers with advice? I have a B.S. in Meteorology and Math. Oh you don’t have a C.S. degree? Nope. I’ve worked at NASA and currently at Amazon as a software engineer. I’ve interviewed 70+ candidates for software engineering roles.

Caveat: My opinions on this subject are my own and don’t reflect the views of my employer.

The behavioral portion of the interview can be used to assess:

1. What type of problems the candidate is exposed to
2. How the candidate dealt with a particular situation
3. What was the impact and perception of the candidate’s handling of the situation to those around them and to the customers

All three of these things speak to the level to which you are being hired for and can be judged in your response. Let’s take a look at an example:

Interviewer: Tell me about a time you noticed an issue on a project. What was the issue and how did you resolve it?

Mid level Engineer: At company Foo, I was looking over our metrics dashboards and noticed that the disk usage on our hosts was increasing by 5% every month and we would run out of space on the host in 6 months. I did some research and tracked it down to a deployment that started populating new data to a new table to our database. I came up with solution to trim the data records and upload them to an external storage system after the table had reached a certain threshold to free up the space on disk. I tested the solution in a mock environment to ensure its functionality. After this change was deployed, our metrics for disk usage dropped back down near the levels we had before introducing the new table.

Interviewer: How was this missed?

Mid level Engineer: At the time of scoping the project, we weren’t anticipating such a large volume of data into the table from our customers based on our outreach. To prevent this issue from happening again, I added metrics for all existing tables and current tables to track the rate of change of disk usage so that we can be more alert at an earlier time.

Interview: Did you receive any push back on your solution?

Mid level engineer: There were questions around whether or not trimming would disrupt the customer workflows. To mitigate this, I extended my design to copy the data over to the external system first before deleting the records on the host so the data would always exist either on the host or in the external storage system.

In this example, there is a Situation, Task, Action and Response. This provides structure that an interviewer can easily follow:

• The engineer noticed an issue with a project, did research, and owned the solution to the problem.

• The solution was tested before it was deployed.

• The solution had a positive outcome which could be tracked through their metrics dashboard.

• The engineer hardly uses “we” and instead uses “I” so it’s clear to the interviewer what role he played in problem and driving its solution.

The interviewer can now ask follow up questions such as “How was this missed?”, “What would you do to prevent this from happening again?”, and “Was there any push back in your solution by your peers?”. These follow up questions are opportunities to shine by showing what mitigations were put in place even after a solution was in place. This shows that the candidate is forward thinking. The candidate was receptive to feedback about a customer impacting concern and modified the solution to drive consensus. There are more questions that an interviewer can ask to truly be sure the candidate is exceeding expectations for this question but this gives you the general gist of what an interviewer would be looking for a mid level engineer.

The higher the position you are interviewing for, the more both the problem and solution should reflect the level. The problem may involve working cross-functionally among many teams were there could be problems around cooperation, dependencies, and complexity among interrelated systems (or disjoint systems that could come together) and how you were the leader in resolving those issues. In these cases, it may be less about how you wrote the code for the fix and more so how you were able to influence teams or individuals on teams on a decision that they would then implement. Some deep dive questions for consideration from an interviewer for any given question would be along the lines of:

• How did you influence your team(s) around you? What was the impact?

• What was the complexity of the problem(s) and what considerations did you have to make?

• How did you develop the team(s) to be better?

• If you have spent some time on the technical portion of studying for the interview. Take a break, look up the company that you are interviewing for, and look up their company values. This can help you frame your response in addition to the considerations mentioned above.

I hope this helps someone pass their next behavioral interview.