[techinterviewmastery] Master the coding interview - part 4

Popular Behavioral Questions w/ Example Answers

Sometimes interview candidates focus all their time on preparing for technical questions that they forget interviewers ask behavioral questions as well. Usually, interviewers ask behavioral questions to get a feel for the candidates background and to “fill in the blanks” of their resumé. This is typically done in the beginning of the interview where it will feel like a casual conversation, this is a technique interviewers use to ease the candidate before asking technical questions. However, most candidates struggle to answer behavioral questions and usually fumble responses, doing poorly with behavioral questions usually doesn’t play out well for the candidate and often results in losing employment opportunities, even if they did well on the technical portion of the interview.

This section of the course offers a selection of common behavioral questions a prospective candidate might encounter during their interviews. The goal here is to familiarize the candidate with potential answers one could give to these questions, each question is really asking for something more and once you can determine what the interviewer is really asking of you it will be easier to draw from your experiences and come up with the appropriate response.

Behavioral questions are so much more than just answering the question, it’s also how you answer it. A useful technique to use is to follow the Situation, Task, Action, Result ( STAR ) approach. First, describe the circumstances of a situation that presented a difficult challenge. Then explain the task that became necessary in that scenario, followed by the action taken to mitigate the issue. Finally, highlight the improvement resulting from that action. It is ideal to show clear resolution with a quantified outcome. For example, stating that “the build time was reduced by 30% after my change” gives the interviewer a more concrete picture than simply asserting that “the build time was significantly reduced after my change”. It is highly beneficial to mentally prepare a list of relevant projects and successfully resolved crises prior to the interview. This allows for the candidate to more easily describe the events from memory and avoid repeating the same story. Elaborating on a previously mentioned project is acceptable as long as the candidate explains to the interviewer how this alternate aspect gives further insight into the new question. Otherwise, the interviewers in the debriefing might interpret this over reliance on a single story to imply that the candidate lacks experience with varied projects.

1. Tell me about one of the most technically challenging projects you have done.

  • Try to be specific about the project and about your contribution within the project.
  • The interviewer wants to know about the challenge you have faced, as well as your problem-solving skills. Not knowing a specific language/technology is NOT a good technical challenge.
  • For each project, think about what the biggest technical challenge was, and elaborate on that. It has to be a situation in which you learned something in the end.

Examples:

i. I have recently designed and implemented a project involving a new form of test in our test execution framework. What the customer wanted was to have the framework automatically spin up VMs to run some tests remotely on those VMs. The way our framework worked, though, was that all the VMs had to be accounted for up front, and only one VM could spin up per test execution. So, the challenge was to enable our system to run master-slave tests, and also to involve 2 different teams in the process; I was the owner of the project and worked with both teams to ensure delivery and also keep everything aligned with requirements and priorities. In summary, what I did was to introduce a new type of test execution based on the master-slave scheme which I created; the master started up the new VMs and had an event bus where the slave could post its statuses to it, so the master would know when it’s time to do the next step. I worked closely with the customer on the project and the end result satisfied all three of our teams.

ii. Frequently we encountered situations where some of our services were unresponsive and when we’d dig down, we’d realize that the problem was rooted in a subservice that was communicating with an external API that had stopped working; this situation would have escalated, leaving the whole fleet of services unresponsive. So, I came up with the idea of deephealth-check where the sub-service of each service reports its health to the parent service. This enabled the service to report its own health, based on the overall health status. Then I aggregated these for all of our services into a dashboard where it would call the APIs periodically. If an anomaly was detected, I had scripts in place for the more common scenarios to alleviate the problem. For the less common scenarios, it would notify the team to take an action. This was a very delicate project because it touched parts of every service we had and I had to get buy-in from all the teams and owners of the services to implement the behavior for their own services. Eventually, it paid off very well by reducing our down time from 8 hours/month to 1 hour/month.

2. Tell me about the project that you are most proud of?

  • Choose a project related to the position you are interviewing for. For example, you developed a large-scale application, a complex bug fix, or an innovative approach.
  • Think about your recent experiences. The accomplishment can be something technical (e.g. reducing latency by x percent, reducing cost x$ per year), or enhancing customer experience, or improving company culture or even learning a new skill that you have applied somewhere.
  • If you cannot single out one accomplishment, it’s ok to mention several, or an upward trend during your career that you can cite.

Examples:

i. Technical: As several outages rolled around our system recently, we felt the need to make our services highly available. I wanted to do it for a few of our services, and after finishing one, I observed some similarities in the pain points for the two services. So, I took the initiative to add high availability in our Java framework as a new feature. What was challenging about this project was determining how to abstract away most of what the services needed down the line, while still keeping this feature generic. I was able to make all our Java services highly available in the timeframe of a week, and moved us from 95% availability to 99.9%.

ii. Leadership: When our company moved from a developer/tester paradigm to all hybrid engineers, some previous SDETs had a hard time ramping up in their new role. So, I volunteered to mentor them and held some pair-programming sessions with them. I went through code reviews with them and kept giving them one-on-one feedback to help them get comfortable and become effective software engineers. As a result, I came up with a well-documented ramp-up plan for on-boarding new developers, which then was used widely by 4 other teams in the company.

iii. We had recently taken the ownership of a package from another team. The package was still heavily dependent on other packages owned by that same team. As a result, we experienced frequent package build failures due to conflict between our code changes and those within the dependencies. Sometimes, it took days for the on-call engineer to determine the root cause and fix the build failure. I voluntarily created a plan on my own time to decouple our package from the huge legacy dependency. Using statistics, I had compiled from the documented failures, I convinced my manager that it would be in our best interest to perform the decoupling and asked for authorization to take this on as a project. I proposed numerous code changes, communicated with dozens of clients, and wrote the onboarding docs. The successful project took 3 months, saving about 10 hours per week of on-call time, and eliminating build failure caused by legacy dependencies. Furthermore, the build time was reduced from 1 hour to 15 minutes, which led to more deployments. Since we were using continuous deployment, the average time to production was reduced from 3 days to less than 24 hours. This project significantly contributed to my promotion as well.

iv. When I joined Amazon my first project was to classify feedback on packaged items in order to determine possible trends in reported packaging failures. After trying different algorithms, I developed one that was successful in isolating package failure patterns. This was a very high impact project, because it helped us identify several issues with packaging that we never knew before. For example, several geographical locations had received melted chocolate in the summer. My team took the findings and made changes to the delivery procedures that had been used, resulting in fewer complaints in those particular scenarios.

3. Tell me about one of your failed projects. What did you learn? What could you have done differently?

  • Try to focus on the part of the project that you missed.
  • Think about what you learned from that project, and talk about how, if you do the project again, in what ways you would apply your new understanding from the beginning.
  • Talk about the preventative measures, processes and mechanisms you put in place to prevent the situation from happening again.
  • Try not to give examples showing significant financial losses to the company as a consequence of your mistake.

Examples:

i. When I was designing and developing a project to add a new feature to our platform, I had two designs: A clean approach or a “hacky” approach. The clean approach would have taken a few more days to finish, so after talks with the team, I chose the hacky approach to meet the deadline. However, it actually needed a lot more hacking than anticipated. This resulted in some tech debt which eventually required much more work than the proper approach. My lesson: Workarounds seldom go as planned! When estimating work needed for completing a project, always give the clean solution more weight, and avoid adding to tech debt at all costs.

ii. We were planning to migrate billions of live records from a SQL database owned by a team in India to a DynamoDB (NoSQL database) owned by our team in Canada. My task was to design and develop a migration plan to ensure that data consistency would be preserved between the two databases during migration. I also had to ensure that customers would not notice any performance degradation. The project failed to meet the deadline, taking more than twice the expected time. The reasons for this included a lack of team expertise in such large-scale migrations, communication barriers between both teams, lack of proper resource planning, and different priorities for both teams. What I took from this situation is that when you are highly dependent on another team (especially one in a different time zone), you have to establish consistent communication protocols between the two teams to ensure that nobody is blocked. Also, both teams need to establish mutual priorities before starting on the technical side.

4. Tell me about a time that you were behind on a project and you knew that you could not meet the deadline.

  • This question assesses your judgment skills in making difficult tradeoffs.
  • You need to elaborate on the rationale behind your decision to rearrange priorities and the positive impact of your decision.
  • The ideal answer should include ‘communication’. When you think you cannot meet the deadline, communicate ASAP with your managers and stakeholders.
  • Your example should show your approach on how to mitigate the issue. It may be through focusing on delivering only the highest priority features by the deadline, or by increasing the velocity through adding more engineers to the project.

Examples:

i. We were developing a simulator for external developers so that they would be able to test their application on our platform. As part of the simulation, our tool was validating the developers’ applications to ensure they were aligned with our policy. After all validations, users were able to see all the results with fail/pass status. I was responsible for assessing onboarding to another internal service in order to expand our validation capacity. After a discussion with the other service owners, I noticed that the other service was just returning failed validations (vs. both passed and failed). Unfortunately, it would require at least two months of work for them to add passed validations to the response. I shared my findings with my manager and we decided to still onboard them to our platform in order to expand the validation as soon as possible but I also created a detailed development plan to work with the other service owners to expand their API response to both failed/pass validations.

ii. We had decided on a deadline and everyone on the team was working hard to reach it, but we kept getting extra feature requests from the product team as sprint injections. After a few weeks, I realized that even though our capacity was high, we were not on time according to the roadmap, so I communicated this to the team and our manager immediately. That caused our manager to push back harder against unnecessary feature requests that were sprint injections. He also had to cut off some of the promised features as well. However, since we caught this early on, fortunately it wasn’t very difficult to do.

5. Why do you want to leave your current job?

  • This is a tricky question to answer but a popular one too. There may indeed be many negative things about your current job, but it is crucial to show a positive attitude about your work despite the difficulties.
  • If you face some issues in your current job, you are expected to take actions to resolve/mitigate the issue first, instead of simply leaving it behind. For example, if you have issues with your manager, have you tried to improve the communication?
  • Think about the skills you want to improve or challenges you would like to attempt, but due to the limited scope of your role, the relevant opportunities are fewer.

Examples:

i. I’ve been at my current job for 3 years and I feel very comfortable with our products and our team. In order to keep learning, I’d like to move to work on a different team and product. This challenge can refine my technical skills, helping me grow in my career goals and providing versatility to the company.

ii. Over the past few years, I have had the opportunity to work with talented people and to take ownership of some great and challenging problems. This has led me to learn more about designing real-world scalable systems. Now I would like to take an opportunity to work on new challenges, particularly in a deep learning domain, in order to expand my scope while still continuing to learn.

6. Why do you want to join us? What do you know about our company?

  • Even if you are applying for large companies like Google, Facebook, Amazon, etc., you have to do some research about the company. Areas like open source projects as well as the history and culture of the company should be considered in your list for research along with the description of the role.
  • Express your passion and excitement about the company and the product. They would rather hire someone who is excited to work at their company than someone who’s only after “a” job.
  • Don’t talk about salary and compensation as your motivation to join the new company (You can talk about it in the negotiations happening after you get an offer).

Examples:

i. I’d like to work at Amazon, firstly, because I can tackle a lot of unique and interesting problems that will challenge me as an engineer. Secondly, I believe I can make an impact working on the Alexa team as I can leverage my extensive experience with training machine learning models to improve customer interaction with the product, such as expediting faster voice recognition and processing times.

7. What is your strength?

  • Think about strengths that are related to the position you are interviewing for.
  • Bring 2-3 strengths with concrete and clear examples instead of bringing a long list of simple adjectives (good team player, hard worker, approachable, etc.) with no supporting proof.

Examples:

i. I try to improve the painful processes (even small) as much as I can. One recent example was a time when our team needed to make frequent changes on our AWS infrastructure on multiple accounts. Previously, each person had to make the same change multiple times on different accounts, which was inevitably prone to mistakes. I created CloudFormation templates for my team (infrastructure and code) so that it became more maintainable and easier to change on multiple accounts. Now, to make an infrastructure change, we just update the code and upload the template to multiple accounts.

ii. I always try to bring the team together. I keep advocating for teamwork, trying to emphasize how important it is that every project has a team working on it rather than just one individual. And my colleagues really appreciate that. As a scrum master I have observed that this has increased team velocity and kept people from feeling siloed. It also helps to create a sense of ownership and spread the knowledge of each project among multiple members of the team.

8. What is your weakness?

  • Don’t be tempted to say you don’t have any weaknesses - everybody has one (or a few).
  • Avoid giving generic answers like “I’m a perfectionist” or “I work too hard and it can harm my personal life.”
  • Avoid answers that disqualify you for the job that you are applying for like “I usually cannot work in a team.”
  • Try to respond by acknowledging a type of weaknesses that can be managed and resolved.
  • A good way to describe your weakness is to say something like “I sometimes [weakness] but over the past few years I have done [some actions] to improve it.”

Examples:

i. It happened on one or two occasions that I became impatient and wanted to push my code as soon as possible. The outcome was that I missed some edge cases in my tests, leading my code to break the system and I had to devote extra time to repair the damage. This reinforced the lesson that spending a little more time on testing prevents unnecessary wasted hours in the long run.

ii. I used to get distracted when I had multiple ongoing tasks, and kept jumping between them. In order to handle this, I came up with a system to prioritize my tasks; every day I had a to-do list, which was always sorted based on priority, and when a new task was to be added to my list, its priority had to be evaluated. This significantly reduced my stress levels and made it much easier for me to maintain focus. I could then finish my tasks one by one, while always giving priority to the ones that were more important.

9. Describe a situation in which you were faced with a major obstacle in order to complete a project. How did you deal with it? What steps did you take?

  • You can mention a technical or a human-factor obstacle.
  • It’s important to mention how you identified the obstacle and how you either worked around it or solved it.

Examples:

i. We needed a major refactoring in our service code that would require a certain feature to no longer be supported. However, that feature was widely used by many clients and it was not possible to remove it from the service right away. I was responsible for performing the refactoring while clients were still able to take the advantage of the feature. First, I identified all clients using the feature and cut them a ticket asking about their use cases. More than half of them were not using all the functionality of the feature and it was easy to migrate them out of that feature. The rest had to make changes in their service to call other services to address their needs. However, considering their other priorities, they offered different timelines which added up to months. As a workaround, I added a piece of code in our service for certain whitelisted clients (the ones that could not make the change in a short time) to call the external service on their behalf. Then I removed the feature and completed refactoring. On the other side, I gradually removed the clients from the whitelist once they had finished their change.

ii. Our team was redesigning the whole accounting portal to make it easy for accountants to enter their data and automatically get generated ledgers. When designing the portal, we realized that the way we were keeping the data would not be scalable to this use case. To address this, I proposed redesigning our database, which would first require talking extensively with accountants to properly understand the data. After several meetings and outlining the nature of the data, I realized that a tree database would be a much better option for us compared to our current database. However, the team was resistant to taking this route. It was only after returning with data, comparing the pros and cons of each of the two database designs and several ensuing discussion sessions, that I was able to convince the team that this was indeed the best choice.

10. Describe one of the biggest mistakes you’ve made in your job, and what did you learn?

  • Mention a mistake that is not too drastic to disqualify you from the position, such as using the company’s resources to work on your own personal projects.
  • Think about the mistake that you noticed, fixed, and by which you learned a lesson that helped you progress in your career.

Examples:

i. During the implementation of a data migration solution under a shortened time frame, I didn’t write unit tests but instead limited myself to manual tests. After adding a new feature (that accidentally broke some of the previous functionalities), I didn’t do manual testing for the previous feature. The broken code went to production and corrupted the data during migration. The defect was not caught until we got an unexpected API response on an edge case. Consequently, we had to redo the whole migration (worth one week of work) after fixing the code and writing unit tests. Now, for any new code change, I make sure to add enough unit tests to cover the change.

ii. I designed a job scheduler that was the core part of our ecosystem. We onboarded it and put it into production, and it was working well. After a few months, though, we needed to double our capacity and the scheduler needed to handle more traffic but it was not resilient enough for that. This made it necessary for me to change it to handle the higher capacity. Because of the way that I had designed the scheduler with entwined logic, it was very difficult to expand. Eventually I just had to write it all over again from scratch in order to make it more flexible, which was a very draining process. After that, I made sure to break my services into the smallest pieces possible and to always consider scalability early in the design process.

11. How do you solve ambiguous problems?

  • It’s important that you demonstrate that you deal with the ambiguity of the problem first, before starting to solve it.
  • This question is meant to identify whether you are well versed in your field and whether you communicate effectively with all stakeholders of the project. Also, interviewers want to see that you account for all the use-cases before coming up with a generic solution.
  • It’s valuable to show that you get constant feedback from the stakeholders to account for changing priorities/requirements.

Examples:

i. At first, I try to understand the problem as much as I can by talking to the people involved and reading related documents. Once I understand the problem and its scope, I try to find out how similar problems have been mitigated. Afterwards, I bring up multiple potential solutions to address the scope of the problem, including the pros/cons of each with my recommended approach and its impact. I might also confirm my understanding and proposed solutions with people who would be directly/indirectly affected by my approach.

ii. If something is unknown, it’s impossible to propose a solution for it. Therefore, it is vital to clarify the problem before trying to solve it. The way I deal with ambiguity is that I try to divide the problem into the smallest functional chunks that are possible. Then for each chunk, I’d bring in the stakeholders and come up with a definition of done. If that isn’t doable for a certain chunk, I’d mark it as uncertain. Ultimately, I would bring every chunk to review with stakeholders and raise awareness on the ambiguous chunks, with the goal of getting as much clarity on them as possible. Once everything is reviewed and confirmed with stakeholders, I’ll start the project, making sure to communicate if there are any further ambiguities or changes along the way.

12. How do you see yourself in five years?

  • Be sure to have clear goals in mind, whether that would be to improve technically, or to move into managerial positions. It is best to indicate your desired direction and provide some reasons why you want that.
  • It’s ok if you don’t want to climb the corporate ladder rapidly, but it’s dangerous to appear completely uninterested. Show passion and engagement when talking about how you envision your future.
  • Think about the skills that can help you reach your career goals and/or can be gained in the position. For example, if you are most interested in learning skills for working with big data and the company you are interviewing with is not involved with big data, you are not great matches for one another.
  • Be prepared for questions about the reasons why you want to improve those specific skills.

Examples:

i. I want to improve my data science skills. With the growth of available data and the essential tools for their proper analysis, I think even software engineers have sufficient knowledge of data science to propose innovative solutions.

ii. I’m seeking the role of principal engineer in order to have the opportunity to address more complex challenges and to powerfully contribute to the success of the company.

13. Tell me about a time when you took the initiative?

  • This question is designed to gauge how much of a selfstarter you are. So, you should talk about a situation when you took on a task that nobody else was willing to do, or when you solved a problem that spanned several areas of expertise.
  • As this is a leadership question, you can also talk about when you successfully led a project.
  • Attending to technical debt is another good showcase of taking initiative, as even though it is very important to the technical team, it is often neglected due to other priorities.

Examples:

i. We were moving our services from Openstack to AWS; in addition to regular services, there were some legacy services that were working directly with Openstack which the team thought would need to be duplicated in AWS. I began to research the matter and learned about a middle layer library API called Cloud4j that could connect services with multiple cloud providers. When I proposed using this library to the team, we were able to cut our workload in half by focusing on incorporating this middle layer API.

14. How will you adjust yourself in a fast-paced environment?

  • You should talk about how you assess trade-offs in a fast-paced environment.
  • Be aware that you should never trade accuracy and tested code in order to deliver the task faster.

Examples:

i. In a fast-paced environment, we have to implement new features as soon as possible and many times there isn’t much knowledge about the problem space or the technology involved. In these scenarios, I try to understand the problem as soon as I can by talking to people and reading related docs. If I don’t have much knowledge regarding the technical aspect of the problem, I try to learn enough to be able to solve it and then gradually increment my knowledge over time. Also, I try to communicate with my colleagues as much as I can in circumstances where I’m blocked by something or I am facing complex obstacles.

ii. In a fast-paced environment, it is critically important to thoroughly understand the problem you are trying to solve because you cannot afford to make changes afterwards. Therefore, planning is an important step that is often overlooked. However, planning should not only be done at the beginning of the project, but needs to be verified (and revised if necessary) every step of the way. Through this process, the team can efficiently produce the most viable product in the least amount of time.

15. Describe a time when you made a suggestion to improve something within the project that you were working on?

  • Find an example from your experience where your suggestion made an impact on the flow of a project.
  • Try to be quantitative about how your suggestion impacted the flow; “my proposed change improved the performance of the data structure by X%”.

Examples:

i. As part of a new feature development, I had to test my changes with a different user account (with a new token) using different preferences (e.g. locale, marketplace, etc.). The manual account creation was very time consuming. I spent some time writing a script to accept the preferences as input and call internal APIs to generate new test accounts addressing my needs. After finishing my own project, I made some improvements to the script and demoed the tool to the rest of the team. My tool is now being used internally for automated account creation for testing purposes.

ii. Our team was working on making one of our services’ logic distributed, and they proposed using GraphQL to aggregate the data. We had a design session scheduled for this work but before the session I did some research to compare what would be gained from using GraphQL as opposed to leveraging the services we currently had. There was a new service being proposed as part of the distributing plan, and I devised a solution piggybacking on that service (because it was already being done). My plan required fewer resources and less work, and it achieved everything that this project needed. On the other hand, I argued that most of the benefits provided by GraphQL were not useful for us and in fact just introduced an additional level of complexity. The team accepted my proposal and we did use the other service instead of GraphQL.

List Of Popular Interview Questions From Big Companies

Leetcode is my favorite website for practicing algorithms. If you want some extra practice, I’ve compiled a list of top interview questions for you to do.

These questions below have been asked in various large companies, like Amazon, Google, Microsoft and more. Great if you have an interview coming up at one of these companies.

#344 Reverse String

#412 Fizz Buzz

#136 Single Number

#104 Maximum Depth of Binary Tree

#283 Move Zeroes

#371 Sum of Two Integers

#206 Reverse Linked List

#171 Excel Sheet Column Number

#169 Majority Element

#13 Roman to Integer

#237 Delete Node in a Linked List

#122 Best Time to Buy and Sell Stock II

#242 Valid Anagram

#217 Contains Duplicate

#387 First Unique Character in a String

#108 Convert Sorted Array to Binary Search Tree

#268 Missing Number

#350 Intersection of Two Arrays II

#121 Best Time to Buy and Sell Stock

#21 Merge Two Sorted Lists

#202 Happy Number

#118 Pascal’s Triangle

#70 Climbing Stairs

#101 Symmetric Tree

#53 Maximum Subarray

#326 Power of Three

#191 Number of 1 Bits

#198 House Robber

#66 Plus One

#1 Two Sum

#38 Count and Say

#26 Remove Duplicates from Sorted Array

#172 Factorial Trailing Zeroes

#20 Valid Parentheses

#141 Linked List Cycle

#234 Palindrome Linked List

#88 Merge Sorted Array

#155 Min Stack

#14 Longest Common Prefix

#160 Intersection of Two Linked Lists

#28 Implement strStr()

#69 Sqrt(x)

#190 Reverse Bits

#125 Valid Palindrome

#189 Rotate Array

#204 Count Primes

#7 Reverse Integer

#94 Binary Tree Inorder Traversal

The Amazon Interview In-Depth (Video)

Below is an extra reference and links to resources that will help you get a better idea on what to expect, how to properly prepare for and be successful at the Amazon interview.

Examples questions for each leadership principle:

  • CUSTOMER OBSESSION: Walk us through a time when you helped a customer through a difficult process and what that looked like.
  • OWNERSHIP: Give me an example of when you took a risk and it failed.
  • INVENT AND SIMPLIFY: Tell me a time when you created an innovative product.
  • ARE RIGHT, A LOT: Tell me about a time when you observed two business opportunities to improve ROI, and how did you determine that they were connected.
  • LEARN AND BE CURIOUS: How do you find the time to stay inspired, acquire new knowledge, innovate in your work?
  • HIRE AND DEVELOP THE BEST: Tell me about a time when you had to deal with a poor performer on your team.
  • INSIST ON THE HIGHEST STANDARDS: Tell me about a time when you could have stopped working but persisted.
  • THINK BIG: Tell me about a time when you proposed a new business.
  • BIAS FOR ACTION: Describe how you would handle a busy situation where three people are waiting for help from you.
  • FRUGALITY: Tell me about a time where you thought of a clever new way to save money for the company.
  • EARN TRUST: Tell me a time when you earned trust of a group.
  • DIVE DEEP: Tell me about a time when you had to dive deep into the data and the results you achieved.
  • HAVE BACKBONE, DISAGREE AND COMMIT: Tell me about the most difficult interaction you had at work.
  • DELIVER RESULTS: Tell me about a time where you overcame an obstacle and delivered results.

Resources:

https://interviewgenie.com/blog-1/category/Amazon+interviews