I have been asked interview questions like these: "Tell me a technical project which was most challenging?" or "Tell me a technical project where you learned most?" or "Tell me about the hardest bug that you have solved?" This is also covered in the chapter "Behavioral Questions" topic "Know your Technical Projects" in the book "Cracking the Coding Interview by Gayle Laakmann McDowell"

What is the interviewer looking for? What are the data points or signals while evaluating this kind of questions?

Update: Behavioral Questions have a specific purpose. They are typically asked to gather data points from past behavior and predict future behavior. Although this is not an ideal solution but people or soft skills are very hard to evaluate. High Impact Interview questions explain this concept very well.

Many companies ask candidates to answer these questions in STAR format within 2-5 minutes (Tech recruiters of medium-big tech companies have shared this time limit in informal feedback).

Similarly, in Technical Behavorial questions, the guidelines are to structure the questions in challenges, architecture, tradeoff, tech stack, soft skill issues, hard bugs, etc.

What I am trying to understand is what behavior would be assessed?

(I am not a newbie in this area. I have many hit and misses in these kind of questions. Interviews are very short in time and Interviewers are always quick making judgement. I am trying to reduce failure by preparing as much as I can)

  • A logical reponse, clarity of timeline and speaking skills.
    – Solar Mike
    Commented Nov 27, 2020 at 18:27
  • 3
    Does this answer your question? How can I answer what was challenging about my last role without ruining my chances?
    – gnat
    Commented Nov 27, 2020 at 21:00
  • @gnat Thanks for giving pointer. I guess workplace.stackexchange.com/a/86787/10520 answers 1 part of my question. I am happy that it gives me 1 possible direction to look at. After reading the answer, I feel that there is certain technical behavior that is appreciated like learnability, understanding trade offs, driving technical consensus, troubleshooting, data driven decision making, etc. It does make sense to put more focus on these behavior and picking the right stories. I would love to have more structured answer around it. I am also trying to find some research paper or book.
    – mystic
    Commented Nov 27, 2020 at 22:17
  • somewhat related: workplace.stackexchange.com/questions/12040/…
    – Steve P
    Commented Nov 28, 2020 at 22:37
  • It is always Ok to ask an interviewer for clarity if you don't understand a question. In fact, doing so will be beneficial because it shows you are willing to ask questions when not clear. Commented Feb 6, 2023 at 23:40

5 Answers 5


What is interviewer looking for?

They are looking to understand more about you. For the specific questions you stated:

  • What challenges you
  • How you like to learn
  • The kinds of problems you have overcome and how you did it

Don't overthink these behavioral questions. Just answer honestly and thoughtfully. Trying to spit back the superficial answer you think the interviewer wants to hear is seldom effective. More often it leads to confusing, disjointed answers and failure if the interviewer asks follow-up questions.

Spend some time before the interview thinking about these kinds of questions and how you might answer them honestly, using actual specific instances from your past. Use the books you are reading as a source of potential questions, but not potential answers.

  • 1
    I don't want to spit superficial answer but I don't want to tell long and boring story. If I can know how would someone evaluate the answer then it would help structuring or picking the story in that way. Let me rephrase: How would you evaluate good vs bad example?
    – mystic
    Commented Nov 27, 2020 at 17:13
  • yeah but there is some underlying theme behind this madness or at least widely used evaluation criteria. Behavioural interview around team conflict make sense. Underlying theme is team conflict.
    – mystic
    Commented Nov 27, 2020 at 17:18
  • 2
    It's the interviewer's job to ask the right questions to get the right signal from your answer, if your story is not what they're looking for they'll tell you.
    – Egor
    Commented Nov 27, 2020 at 17:47
  • A good response - I was having a problem solving x, so I approached a team mate and asked for his assistance. Bad response - I was having a problem solving x - I spent three days going over it and was finally able to implement it. Commented Feb 6, 2023 at 23:50
  • It helps to have prepared answers, structured as SAR (Situation, Action, Results). That gives you a framework for creating a focused response. For some things you may want to go deeper and add a description of how and why you chose that set of actions.
    – keshlam
    Commented Feb 7, 2023 at 13:24

I think Joe's answer is great, but IMO one aspect is missing:

I like these kinds of questions because it tells me about the candidate ability to communicate complex technical problems.

Developers early in their career often think the most important skill is to write code. But the more your career proceeds, the more you will need to talk about code. You need to explain technical details to stakeholders, clients, or junior developers.

While listening to the answer, I can evaluate if the candidate can talk about a hard bug or a challenging tech issue in a way that allows me (who hears the story for the first time) to follow and understand it.

Plus: I can ask further questions and did deeper to understand more about the candidate and their ability.


So there are a few things to bear in mind. The first is that different interviewers will want to know different things. If you're applying for a consulting firm - say Mck or Deloitte - then they want to see that you've prepared for the interview, and at the very least know the format expected for the answer. Then they will want to see that you've displayed the necessary leadership, problem solving and requirements gathering skills.

Some recruiters might be "trying to catch you off guard", others might be screening for particular projects or see that you've done the type of work they're wanting to undertake. Having these (undisclosed) experiences under your belt will put you ahead of other candidates.

Learning the STAR (situation, task, action, result) method is really really essential for answering these questions in a clear, concise manner. Practice with a few examples. Also, go ahead and watch people answer these questions on youtube/consulting prep interviews. You'll get a feel for what a good solid answer looks like, which is really useful.

Generically, interviewers want to find people who

  • are smart and solve problems
  • can learn unsupervised
  • have leadership abilities
  • have communication abilities
  • can work well with others

So try to fit these into your answer. Pick 3 or 4 key points in your employment past, and work out how, in a long story, you can cover all these points. Then just trim the story down so that you definitely cover these points, and miss out anything that is extraneous.

Now work that story into the STAR format, and you're done.


I love the answers that have been voted up so far, but felt like they didn't really cover the boxes the interviewer may be trying to tick off with these questions.

CAVEAT - different companies do use the same question differently. So there's not a universal right candidate or right answer or even a right answer format.

So - #1 rule would be - know the company and assist yourself by trying to get information on what this company holds as important about it's own culture. This is helpful, also, since if they are particularly misaligned with what you think is important - it's probably not a great fit.

But, having asked these types of questions across multiple companies, here's some of the things I want to learn from questions like these:

  • What's the degree of complexity/difficulty of the types of problems you've had to solve? And what level of experience/skill did you use in solving them? It tells me both what the company trusted you with, and also what you consider hard/interesting - factors into what level of seniority I might recommend and/or if you have tackled anything similar to the types of problems this team has.

  • How does this person interact with others? Does it line up with what this company is going to expect? Does this person have enough social awareness to modify their behavior? Would they be happy doing so? This lines up with some of the cultural attributions like "Earns Trust" and "Dives Deep" - but how, say, AWS assesses this can be quite different from how a different company would assess the ability to meet the same pithy phrase.

  • One box I always look for on this - "is this person a jerk?" - if the reflection has a lot of "this was the other person's fault" in it, it will almost always throw red flags. Even if it was the other person's fault - most great candidates will have an idea for isolating or mitigating the problem that originated from someone else.

  • What happens when I ask for details? In most behavioral interviews, the interviewer is expected to dive in and ask for more. The idea here is partly that a candidate shouldn't have a memorized statement, they should be able to speak authentically about personal experience without a script. This is both a way to check off boxes the candidate may not have covered, and a way to check for authenticity. A person feeding me a story that isn't actually their own will usually lack the ability to make up credible details that hang together in a sensible way.

  • Can this person summarize but hit key points of the story in a way that a person who shares the skill set but not the context can understand - which is a pretty common skill to need in every team I've managed - engineers will always have more context on the thing they spent days working on that I (the manager) will. To be able to help and support them, I need them to sum stuff up, hitting the core of the problem and eliminating irrelevant details. If I can't understand the problem quickly in the interview phase, I don't feel confident that it will go better when the candidate is on the team.

STAR is a pretty good way to frame this stuff (situation, task, action, result) - since it helps focus on the candidate's work, and to keep the details as limited as possible to those 4 things.

It's worth noting that there's a LOT of variation here. Some companies have very formal methods for these types of interviews, and the interviewer (and even the recruiter prepping the candidate) may be VERY explicit about what aspects they are trying to assess. When I worked for (and interviewed with) AWS, for example, the interviewer was advised to say what AWS core competency they were interviewing for with a given question.

In other companies, a manager may be completely on their own to figure out what behaviors they are looking to see demonstrated, as well as what types of interviews to conduct to figure that out. They may or may not even have training on how to do a behavioral interview. And they may just not think it's a useful tool.


Those questions are just fishing attempts. On that point, I agree with Frank. They're designed to catch you off-guard. They might uncover lies that you made on your resume. They might uncover a perceived negative personality trait. Those interviewers using them are not looking for something specific.

The best way to prepare for them is to ask those questions of other job-hunters, and in turn, try to answer those same questions back yourself. I'd suggest you do that on http://pramp.com

Very recently, they added a section specifically for behavioral interviews. https://www.pramp.com/dev/uc-behavioral

Because Pramp has job-hunters in the programming field interview each other, it's an invaluable resource to see how well you measure up to your potential competitors. Personally, I've already gotten great insights from it that I simply couldn't have gotten any other way.

And once this pandemic is over, perhaps join a software-related job-hunting meetup, or create a mastermind group, and participate in practice interview sessions using those groups. Pramp is not the only way to do this.

"Tell me a technical project which was most challenging?" or "Tell me a technical project where you had most learning?" or "Tell me about the hardest bug that you have solved?"

And don't get hung up on the categorical phrasing of those questions. When they say "most challenging", it doesn't have to be the most challenging. It just has to be challenging. Or when they say "the hardest bug", it doesn't have to be the hardest one. Any hard memorable bug will do. I'm assuming you probably knew this already (but I'm just saying it in case there is someone else reading this who doesn't realize that).

  • All in all, this seems the voice of experience. I would not insist on asking interviewing questions to interviewers, or at least not much of them. Whilst interview is a 2-way street, some people do not take it well. Commented Dec 6, 2020 at 10:25
  • @RuiFRibeiro, Pramp recently just added a section for behavioral interviews. I'll update my answer accordingly later tonight. pramp.com/dev/uc-behavioral Commented Dec 8, 2020 at 2:52

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .