Beyond the Whiteboard: The Most Common Behavioral Interview Questions

algodaily, slow

Table of Contents

This article will go through the most common behavioral interview questions that software engineers tend to face. We'll also dive into detail on how to answer them.

These questions can be mastered. With sufficient preparation, you can anticipate many of things you'll be asked, and prepare for them. Lazlo Block, former SVP of HR at Google, wrote an amazing article on how to win any interview. Here's a summary of what he has to say below:

You can anticipate 90% of the interview questions you’re going to get. Three of them are listed above, but it’s an easy list to generate. (AlgoDaily: This is your list below!)

For EVERY question, write down your answer. Yes, it’s a pain to actually write something. It’s hard and frustrating. But it makes it stick in your brain. That’s important. You want your answers to be automatic. You don’t want to have to think about your answers during an interview. Why not? Keep reading.

Actually, for every question, write down THREE answers. Why three? You need to have a different, equally good answer for every question because the first interviewer might not like your story. You want the next interviewer to hear a different story. That way they can become your advocate.

So that'll get you the "what" to answer, but you'll still need to know the "how". You'll want to demonstrate organized thought, strong communication skills, and an ability to tell a narrative.

In general, you want to focus on the STAR approach, which is outlined below.

STAR Method

I'd highly recommend you follow the STAR method in answering behavioral interview questions. STAR stands for the following: 1) Situation, 2) Task, 3) Action, 4) Result:

  • Situation: This is a description of the event, project, or challenge you encountered.
  • Task: What were YOUR assignments and responsibilities for the task?
  • Action: What were the steps taken to rectify or relieve the issue?
  • Result: A description of the outcome of actions taken.

You'll want to answer all the questions in this format, as it allows for best clarity of thought. Now onto the questions themselves. But real quick, a word on body language:

Your Body Language

Your body language is important in conveying to the interviewer that you are comfortable, happy to be there, and focused. Here's a few things to keep in mind:


  1. Sit up straight.
  2. Slow down your movements.
  3. Stay loose around your shoulders and neck.
  4. Breathe.
  5. Keep your hands visible.
  6. Maintain an open stance.


  1. Touch your face or hair too frequently
  2. Pick at things
  3. Slouch

The commonality between these things is how they demonstrate (or don't demonstrate) your level of ease. Remember, they're not just evaluating you as a software engineer, they're also seeing how you'd be as a coworker and teammate. A little bit of nerves is to be expected, but generally portraying yourself as someone with nothing to hide and a high degree of confidence will help you fare much better.

If the above is too much to remember, a simple rule is stay open and relaxed.

You and Your Goals

This category of questions allows the interviewer to get to know you. They're looking for for an overview of your history and how you ended up at the interview.

Note that this is a warm up question and probably not the time to go into detail. A short 2-4 sentence answer does the trick.

  • Which roles do you enjoy the most?
  • What’s one trait in a coworker you want to emulate?
  • Where do you see yourself in five years?
  • What would you see being the biggest problem when engaging with partners?
  • Are you more technical or business oriented?
  • What would you like to focus on in your job?

Successful Past Projects

A tip for talking about your accomplishments is to demonstrate a diverse number of skills. Ideally you can show strong technical ability, as well as leadership, critical thinking, collaborative skills, etc.

Something else to consider is brushing up on the technical details of older projects. Interviewers may learn about a project you mention and ask several follow up questions about it. Be sure you can give a high level overview of the architecture of the project, and any technical decisions you might have made.

  • Give an example of an important project goal you reached and how you achieved it.
  • Can you describe a project that was successful and why was it a success?
  • Have you ever had to "sell" an idea to your project team? How did you do it? Did they "buy" it?
  • Give me an example of a time when you were faced with a complex project related matter and you had no say on the best way to deal with. What did you do?
  • How did you go about making the decision – lead me through your decision process? If you could make the decision once again, would you change anything?
  • Give me an example of a time you had to take a creative and unusual approach to solve coding problem. How did this idea come to your mind? Why do you think it was unusual?

Teamwork and Collaboration

These questions are meant to gauge you as a teammate. Conflicts will always happen in a team, but the key is to have a story about how YOU took action to resolve it.

  • Tell me about a time you had to conform to a policy you did not agree with.
  • Give an example of a time when you didn’t agree with other programmer. Did you stand up for something that you believed was right?


Talk about projects you've led, engineers you've mentored, or changes you've initiated on the team. Be careful here, you want to modify your answer to fit the company's values around how to lead.

  • Describe a time when you took the lead on a project.
  • Tell me about a time when you took ownership of a project. Why did you do this?
  • What was the result of you taking the challenge? What could have happened if you did not take ownership?
  • Can you tell me about a time you demonstrated good judgment or logic?
  • How have you leveraged data to develop a strategy?
  • Can you tell me about a time you had to scale?

Past Failures

Engineer interviewees who don't have stories around failures simply don't have much experience. Building software is a hard and usually open-ended problem, and mistakes are not only common but expected.

With these questions, it's important to be able to concretely answer what the problem was, how you fixed it, and what you learned from it. You should also be able to speak to how you fixed it, and using what tools.

  • Have you ever made a mistake?
  • Tell me about a software design decision you regret.
  • Tell me about a time when you were faced with a problem that had multiple potential solutions. How did you determine the course of action? What was the outcome of that choice?
  • When have you ever taken a risk, made a mistake or failed? How did you respond and how did you learn from that experience?


This is for more senior candidates, and very much company dependent. Read up on the company and see what their core values are, and what kind of managers tend to succeed in the organization.

  • How would you describe your style of management?
  • Give me an example when you had a problem with an out-performer.
  • What would you do to keep an out-performer motivated?
  • Give me an example of when you have to take a decision against the members of your team.
  • What have you done in the past when you needed to motivate a group of individuals?
  • What have you done in the past when you needed to encourage collaboration during a particular project?

Difficult Situations

Interviewers also love these questions because the way an interviewee answers them reveals a lot about their personality. People who own up to their mistakes without being too emotionally attached to them are likely to be able to face similar issues in the future. Those who have their egos attached will not do as well.

  • Tell me about how you worked effectively under pressure.
  • Describe a time you faced a stressful situation.
  • Tell me about a time you had to work with a difficult client.
  • Give me an example of a time you faced a conflict while working on a team. How did you handle that?
  • Tell me about a past miscommunication you had with your supervisor. How did you solve it? What was the reason for that? How did you deal with that situation?
  • Tell me about an instance when you had to communicate a bad piece of news to your supervisor or team members. How did you handle it? What was the outcome?
  • What is the most difficult issue you ever faced in life and work?
  • Tell me about another time you dealt with a difficult manager.

Sign up for our newsletter list and join others to get lessons and daily coding challenges sent to your inbox!