Image from here

How a common interview question from hiring managers reveals a lot about current career stage

One common interview question I’ve seen is:

“Tell me about a time when a project wasn’t as successful or didn’t go as smoothly as you had hoped. What did you learn from the experience?”

For years, I never understood the point of those types of questions. It was only recently that I realized how you answer this particular question reveals a lot about where you are in your career.

As a product engineer, three years ago, my answer would have fallen something along the lines of:

“It took me longer to deliver a feature than I had expected. After I submitted the code for code review, I ended up having to change a lot of code to adhere to the codebase standards. What I learned is that it’s important to have a good picture of how the existing system is set up before working with it to add new functionality.”

What this shows is that I was still very early in my career, working on my first few projects. I had no understanding of coding best practices. I was mostly working on small projects by myself with guidance and mentorship from more senior engineers.

Two years ago, my answer would have grown to:

“I had trouble collaborating with a team member because we had differences in opinion on how to architect a certain design. We disagreed on the tradeoffs. The system we ended up choosing had XYZ problems. I learned that it’s important to put more thought in ABC when thinking about tradeoffs.”

This shows that I now worked on much bigger projects where collaboration with as well as buy-in from other team members was needed. I was a growing individual contributor. However, my area of responsibility and expertise was still very much constrained to the code itself. My interaction with product and design was limited. I was viewing my work solely from the engineering lens.

Today, when asked this question, I would give a more all-encompassing answer that reveals greater experience handling inter-departmental collaboration as well as product development best practices.

“I worked on a month-long feature that had very little adoption. Our customers did not know how to use it, did not see any value in it, and it did not solve the original problem it was supposed to solve. What I learned is that it’s critical to be problem-oriented in the product development process. Never lose sight of the goal when thinking about features and solutions.”

Being an effective engineer is about so much more than writing good code. It’s about delivering high impact end user workflows. The ability to prioritize high impact activities requires an understanding of the customer and the problems they are facing. The ability to choose well between a slower, more complicated design for long-term scale versus a faster, but less scalable solution requires foresight into user need. This, in turn, is acquired through a good understanding of the problem you’re trying to solve.

I’m still early in my career. I don’t entirely know how my answer to this question will change in the years to come. If I had to guess, it could very well become something along the lines of failure in communicating or managing expectations amongst team members. It could also be choosing a wrong design because of incomplete context or wrong understanding of how customers value the product.

After all, the next step for my career development is leadership.