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)


4 Answers 4


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
    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
    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
    Nov 27, 2020 at 17:47

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 ofter think the most important skill is to write code. But the more your career proceeds there 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 get observe 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.


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. 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 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 .