What specific signals and evidence did you gather (technical execution, scope, influence, leadership)?
How did you calibrate with peers and leadership to ensure fairness?
What conversations did you have with the engineer throughout the process?
How did you document your recommendation and rationale?
Sample Answer (Junior / New Grad) Situation: During my first six months as a tech lead at a fintech startup, one of the junior engineers I mentored, Sarah, expressed interest in moving from L3 to L4. Our company had recently formalized leveling criteria, and L4 required demonstrating ownership of medium-sized features and mentoring newer team members. Sarah had been performing well on her assigned tasks but hadn't yet taken on larger scope.
Task: As her tech lead, I was responsible for providing input to her manager about her readiness for promotion. I needed to objectively assess whether Sarah was consistently operating at L4 level or if she needed more time to demonstrate those competencies. My role was to gather concrete evidence of her work and provide a clear recommendation with supporting examples.
Action: I reviewed Sarah's work over the past six months, looking at code reviews, project deliveries, and team interactions. I noticed she had successfully delivered three medium-complexity features with minimal guidance, which was promising. However, I also observed she was still working mostly on clearly-scoped tasks rather than identifying and driving initiatives independently. I scheduled a 1:1 to discuss her promotion goals and understand her perspective on her growth. I also reached out to two other engineers who had worked closely with her to gather additional feedback on her collaboration and technical skills.
Result: After my assessment, I recommended Sarah wait one more quarter before submitting for promotion, as she was trending toward L4 but needed to demonstrate consistent performance at that level. I shared specific examples with her manager and created a development plan with Sarah focusing on taking ownership of a larger feature end-to-end and mentoring our newest intern. This was a valuable learning experience for me in understanding how to gather evidence systematically and deliver constructive feedback. Sarah appreciated the clear roadmap and successfully promoted the following cycle.
Sample Answer (Mid-Level) Situation: As an engineering manager at a mid-sized SaaS company, I was preparing for our annual promotion cycle and evaluating whether Marcus, one of my senior engineers, was ready for a staff-level promotion. Marcus had been at senior level for 18 months and had been increasingly taking on technical leadership responsibilities. The staff engineer level at our company required demonstrating impact beyond a single team, driving technical strategy, and elevating the skills of engineers across the organization. The promotion committee consisted of three engineering directors and required substantial evidence of sustained impact.
Task: I needed to make a thorough and evidence-based assessment of whether Marcus was operating at staff level. This required gathering concrete examples across multiple dimensions: technical execution, architectural influence, cross-team collaboration, and mentorship impact. My responsibility was to either sponsor his promotion with a strong packet or provide honest feedback about what gaps remained and help him build a plan to close them.
Action: I conducted a comprehensive 360-degree review, collecting structured feedback from eight engineers across three teams who had worked with Marcus. I documented specific examples of his technical contributions, including his design of our new caching layer that reduced API latency by 40% and his leadership of our migration to microservices. I also gathered evidence of his mentorship—he had been running our monthly architecture review sessions and had mentored two engineers through their senior promotions. I calibrated with two other engineering managers who had recently promoted engineers to staff level to ensure my assessment aligned with company standards. I met with Marcus to review the evidence together and discuss his readiness, and we agreed he had strong evidence across all dimensions.
Result: I sponsored Marcus's promotion to staff engineer, and he was approved by the promotion committee. My promotion packet included 12 specific examples across technical leadership, organizational impact, and people development, with quantified impact where possible. Marcus has thrived in his staff role, now leading our platform architecture guild and mentoring three senior engineers. This experience taught me the importance of gathering evidence continuously throughout the year rather than scrambling during promotion season. I now maintain promotion-tracking documents for all engineers on my team who are approaching the next level, making the evaluation process much more objective and less stressful for everyone involved.
Common Mistakes
- Relying on gut feel instead of evidence -- Use concrete examples of work products, impact, and behaviors rather than general impressions or likability
- Comparing to yourself rather than the level -- Evaluate against documented leveling criteria, not whether someone works the way you did at that level
- Waiting until promotion season to assess -- Gather evidence continuously and have regular career development conversations throughout the year
- Not calibrating with peers -- Different managers may interpret levels differently; calibration ensures consistency and fairness across the organization
- Avoiding difficult feedback conversations -- If someone isn't ready, specific feedback about gaps is more valuable than delaying the conversation or lowering the bar
- Ignoring scope and impact -- Promotion isn't just about working hard or being technically strong; it requires demonstrating impact at the next level's scope
- Promoting based on potential rather than performance -- The promotion should reflect someone already operating at the next level, not a bet on future performance
Result: I sponsored Marcus's promotion to staff engineer, and he was approved by the promotion committee. My promotion packet included 12 specific examples across technical leadership, organizational impact, and people development, with quantified impact where possible. Marcus has thrived in his staff role, now leading our platform architecture guild and mentoring three senior engineers. This experience taught me the importance of gathering evidence continuously throughout the year rather than scrambling during promotion season. I now maintain promotion-tracking documents for all engineers on my team who are approaching the next level, making the evaluation process much more objective and less stressful for everyone involved.
Result: I recommended both engineers wait another review cycle, but with very different development plans—Elena needed to expand her scope by leading a cross-team technical initiative, while Dev needed to deepen his technical skills by driving architecture decisions on his next project. While neither was promoted immediately, both appreciated the specific feedback and clear growth paths. More importantly, this process established our organization's first formal calibration framework, which we documented and rolled out across all teams. Six months later, both Elena and Dev were promoted after demonstrating growth in their target areas. The calibration process I established reduced promotion-related attrition by 30% over the next year and created much more transparent career pathways for the entire engineering organization. I learned that the short-term discomfort of delivering a "not yet" decision is far better than lowering the bar, which would have degraded our standards and created inconsistency.
I initiated a formal calibration process by bringing together all five engineering managers for a series of leveling workshops where we reviewed anonymized examples of work at each level and discussed what "good" looked like. For Elena and Dev specifically, I asked their managers to prepare promotion packets using our STAR format, documenting specific examples of scope, impact, technical execution, and collaboration. I personally reviewed their code contributions, design documents, and peer feedback from the past year. I discovered that Elena's technical contributions were undeniably staff-level quality, but her scope was limited to infrastructure work within one team—she hadn't yet demonstrated the cross-team influence expected at senior level. Dev had strong breadth and collaboration skills, but his technical decision-making still required significant guidance from his tech lead on complex problems. I conducted skip-level 1:1s with both engineers to understand their self-assessment and career goals, then worked with their managers to deliver clear, evidence-based feedback.22