← Back to companies
[ OK ] Loaded —
[ INFO ]
$ cd
$ ls -lt
01
02
03
04
05
$ ls -lt
01
02
03
04
05
user@intervues:~/$
What concrete steps did you take to address the areas identified?
How did you measure your progress or hold yourself accountable?
Did you follow up with the person who gave you feedback?
Sample Answer (Junior / New Grad) Situation: During my first software engineering internship at a fintech startup, I was three weeks into the program when my mentor pulled me aside after a code review. She mentioned that while my code worked functionally, I was writing overly complex solutions that would be difficult for teammates to maintain. I had been trying to impress everyone with clever algorithms, but I wasn't thinking about readability or team collaboration.
Task: I needed to shift my coding style from "impressive complexity" to "simple and maintainable." My responsibility was to write code that other engineers could easily understand, debug, and extend. This was challenging because I initially equated simplicity with lack of skill, and I had to reframe my understanding of what good engineering actually meant in a team environment.
Action: I started by asking my mentor for specific examples of where my code was unnecessarily complex, and I studied the codebase to understand the team's conventions. For my next feature, I deliberately broke down my solution into smaller, well-named functions with clear comments explaining the "why" behind key decisions. Before submitting each pull request, I would read through my code pretending I was seeing it for the first time and asking myself if it was immediately clear. I also started participating more actively in code reviews to learn from how senior engineers balanced elegance with simplicity.
Result: Within two weeks, my code review feedback shifted from "this is hard to follow" to "nice, clean implementation." My average PR approval time dropped from 2 days to under 4 hours because reviewers could quickly understand my approach. My mentor specifically called out my improvement in my mid-internship review, and I received a return offer partly based on my coachability. Most importantly, I learned that the best code isn't the cleverest—it's the code that helps your team move faster, and this principle has guided my approach to engineering ever since.
Sample Answer (Mid-Level) Situation: Two years into my role as a product manager at a healthcare technology company, I received feedback during my performance review that surprised me. My director told me that while I was excellent at execution and shipping features on time, I wasn't effectively communicating the "why" behind my decisions to stakeholders. Several engineers and designers had mentioned feeling like they were just receiving orders rather than being part of the strategic thinking process. I realized I had been so focused on velocity that I was treating people like task executors rather than collaborators.
Task: I needed to transform my communication style from directive to inclusive, ensuring my team understood not just what we were building, but why it mattered and how I arrived at those decisions. My challenge was to maintain our shipping velocity while adding this extra layer of context and collaboration. This meant finding the right balance and creating space for input without slowing down our execution rhythm.
Action: I immediately scheduled one-on-ones with key team members to apologize and understand their perspectives better. I restructured how I ran sprint planning meetings, starting each session with a 10-minute "strategy context" where I shared user research, business metrics, and how our upcoming work connected to company goals. I created a shared document for each major feature that outlined the problem, the alternatives I considered, and why I recommended the chosen approach—inviting feedback before finalizing decisions. I also started ending my project updates with "what I'm uncertain about" to explicitly invite challenge and discussion rather than presenting everything as decided.
Result: Within one quarter, our team engagement scores increased from 6.2 to 8.4 out of 10, with communication specifically called out as improved. More importantly, the quality of our solutions improved because engineers and designers started proactively suggesting alternatives I hadn't considered—we caught three potential usability issues before development that would have required significant rework. My director noted that two engineers specifically mentioned feeling more invested in the product vision during their reviews. This feedback fundamentally changed how I view leadership: it's not about having all the answers, it's about bringing people along on the journey of finding them together.
Sample Answer (Senior) Situation: As a senior engineering manager leading a 25-person organization at a cloud infrastructure company, I received pointed feedback from my skip-level manager after a major product launch didn't meet revenue targets. She told me that while I was excellent at building and shipping technology, I was treating the business side as "someone else's problem" and not developing sufficient commercial awareness in myself or my teams. During skip-level meetings, several of my direct reports had mentioned they didn't understand how their work connected to company revenue or why certain projects were prioritized over others. I had been proud of shielding my team from "business concerns," but I was actually creating a disconnect.
Task: I needed to develop a much stronger business acumen and, more importantly, embed commercial thinking throughout my engineering organization. My responsibility was to ensure every engineer understood not just how to build great technology, but how that technology created value for customers and revenue for the company. This required me to fundamentally expand my definition of what a successful engineering leader should know and teach.
Action: I immediately enrolled in a three-month financial literacy program for tech leaders and started having monthly coffee meetings with our CFO and sales leaders to understand unit economics, customer acquisition costs, and revenue modeling. I restructured our quarterly planning process to start with business objectives rather than technical initiatives, and I required every project proposal to include a "business impact" section quantifying expected revenue or cost savings. I created a monthly "Engineering Business Review" where teams presented not just what they shipped, but the customer adoption metrics and business outcomes. I also started rotating engineers through week-long stints shadowing sales calls and customer success meetings, and I embedded P&L discussions into my staff meetings so my direct reports learned this framing.
Result: Over the next year, our engineering organization delivered $12M in identified cost savings and our feature adoption rates increased by 40% because we were building things more aligned with actual customer needs. Three of my engineers were promoted to staff level, with their business impact narratives being cited as key factors in the promotion decisions. My skip-level manager noted that our engineering org had transformed from "brilliant executors" to "strategic business partners," and I was asked to present our approach at the company's leadership offsite. Personally, this feedback was humbling but transformative—it showed me that technical excellence alone isn't leadership, and the best engineering leaders are bilingual in both technology and business.
Sample Answer (Staff+) Situation: As a Staff Engineer and technical lead for our platform architecture at a Series C startup scaling from 200 to 800 employees, I received difficult feedback from our CTO during a leadership retreat. He told me that my technical decisions, while sound, were increasingly creating bottlenecks because I was personally involved in too many critical path decisions and hadn't built sufficient leverage through systems and people. Multiple engineering managers had privately expressed that their teams felt blocked waiting for my review or input, and I was becoming a single point of failure for architectural decisions. I had prided myself on being hands-on and maintaining high standards, but I hadn't recognized that my involvement style wasn't scaling with the organization.
Task: I needed to transition from being the company's primary architect who reviewed everything to building an architecture function and decision-making framework that could scale without me. My challenge was maintaining our technical quality and consistency while distributing architectural decision-making authority and developing other technical leaders. This required me to let go of control in a way that felt uncomfortable and trust others to make decisions that I might have made differently.
Action: I spent the following month conducting an honest audit of every meeting and decision I was involved in, categorizing what truly required my unique expertise versus what could be delegated with proper frameworks. I created a comprehensive Architecture Decision Record (ADR) system and documented our technical principles, design patterns, and decision-making criteria so others could make consistent choices. I identified three senior engineers with architectural potential and created a "platform architecture council" that could make binding decisions without my involvement for defined categories of technical choices. I ran weekly office hours instead of being in every design review, and I published monthly written technical strategy updates rather than being in constant meetings. Most importantly, I explicitly told teams "you don't need my approval for this" and created clear swim lanes for different types of architectural decisions.
Result: Within six months, my meeting load decreased from 35 hours to 18 hours per week, freeing me to focus on longer-term technical strategy and cross-functional initiatives. The three engineers I mentored grew significantly—two were promoted to staff engineer and began leading major architectural initiatives independently. Our architecture decision velocity increased by 60% as measured by time-to-decision, and our engineering satisfaction scores around "clarity of technical direction" improved from 6.8 to 8.9. The CTO specifically highlighted this transformation in my performance review, noting that I had successfully transitioned from individual contributor to force multiplier. This feedback taught me the most important lesson of my career: at senior levels, your impact isn't measured by what you personally build, but by the capacity and capability you create in others.
Common Mistakes
- Being defensive or dismissive -- avoid framing the feedback as wrong or unfair; show genuine reflection on why it was valuable
- Choosing trivial feedback -- don't pick something minor like "my desk was messy"; choose feedback that required real behavior change
- Not showing actual change -- avoid vague statements like "I worked on it"; provide specific actions and measurable improvements
- Blaming circumstances -- don't explain away why the feedback happened; focus on what you learned and how you grew
- Skipping the follow-up -- failing to mention how you closed the loop with the person who gave you feedback shows lack of accountability
- Making it seem easy -- authentic answers acknowledge that change was challenging; being too casual suggests you didn't take it seriously
Result: Over the next year, our engineering organization delivered $12M in identified cost savings and our feature adoption rates increased by 40% because we were building things more aligned with actual customer needs. Three of my engineers were promoted to staff level, with their business impact narratives being cited as key factors in the promotion decisions. My skip-level manager noted that our engineering org had transformed from "brilliant executors" to "strategic business partners," and I was asked to present our approach at the company's leadership offsite. Personally, this feedback was humbling but transformative—it showed me that technical excellence alone isn't leadership, and the best engineering leaders are bilingual in both technology and business.
Result: Within six months, my meeting load decreased from 35 hours to 18 hours per week, freeing me to focus on longer-term technical strategy and cross-functional initiatives. The three engineers I mentored grew significantly—two were promoted to staff engineer and began leading major architectural initiatives independently. Our architecture decision velocity increased by 60% as measured by time-to-decision, and our engineering satisfaction scores around "clarity of technical direction" improved from 6.8 to 8.9. The CTO specifically highlighted this transformation in my performance review, noting that I had successfully transitioned from individual contributor to force multiplier. This feedback taught me the most important lesson of my career: at senior levels, your impact isn't measured by what you personally build, but by the capacity and capability you create in others.