Skip to main content

Tech Lead Manager Interview Playbook

Use this as a point-to-point interview guide. Keep answers concise, specific, and evidence-based.

Core Managerial Philosophy​

My management style is high clarity, high support, and increasing autonomy.

High clarity​

People should know:

  • What success looks like
  • Why the work matters
  • Who owns the decision
  • What quality bar applies
  • When and how feedback will be given

High support​

When someone takes on new scope, I provide:

  • Context
  • Coaching
  • Feedback
  • Stakeholder connections
  • Air cover
  • Resources

Increasing autonomy​

Manager decides
      ↓
Manager proposes / engineer executes
      ↓
Engineer proposes / manager reviews
      ↓
Engineer decides
      ↓
Engineer teaches others

Interview line​

I don't measure my effectiveness by how many decisions come through me. I measure it by whether the team can make good decisions without me.

1. Grow and Promote a High Performer

STAR Story​

Situation​

I had a strong engineer who had primarily focused on UI work. I saw that to reach the next level, she needed broader ownership across backend/application work, architecture, cross-team leadership, and mentoring.

Task​

My goal was not simply to give her more tasks. I wanted to intentionally create opportunities where she could demonstrate senior-level behavior end-to-end.

Action​

I worked with her on a growth plan around four areas.

1. Broaden technical scope​

She moved beyond UI into application and data-platform work.

2. Own ambiguous projects end-to-end​

I created opportunities for her to lead substantial pieces of work such as:

  • Model Registry → Grafana
  • Model Catalog
  • Weekly Dashboard → MySQL
  • Model Foundry features

3. Increase leadership visibility​

I encouraged her to:

  • Drive design discussions
  • Make technical tradeoffs
  • Own delivery quality
  • Present progress and decisions to stakeholders
  • Build cross-functional relationships

4. Multiply others​

She took on mentoring responsibilities and improved team operating practices such as on-call documentation.

My role was to:

  • Create the opportunities
  • Give frequent feedback
  • Remove blockers
  • Provide air cover
  • Make sure her impact was visible
  • Help her connect her work to the next-level expectations

Result​

She was promoted to Senior Software Engineer.

More importantly, after promotion she continued operating at that level by owning larger features, mentoring engineers, and driving increasingly ambiguous work.

Interview takeaway​

For high performers, my job is not to reward them with more work. It is to deliberately expand their scope, increase decision-making authority, create visibility, and help them build evidence for the next level.

2. Turn Around a Struggling Engineer

STAR Story​

Situation​

I had an engineer who was technically capable, but their performance was inconsistent.

They could solve problems, but:

  • Work frequently required follow-up
  • Delivery timelines slipped
  • Debugging sometimes stopped at symptoms instead of root cause
  • Risks were surfaced too late
  • Other engineers were beginning to compensate for the gaps

Task​

I needed to determine whether the issue was:

  • Skill
  • Motivation
  • Role clarity
  • Workload
  • Confidence
  • Prioritization
  • Role mismatch

Then I needed to help the engineer return to consistent performance.

Action​

I started with diagnosis rather than immediately labeling it as a performance issue.

I gave specific examples:

In the last two projects, we agreed on a delivery point, but I had to follow up several times. In the incident investigation, the initial analysis stopped at the symptom instead of reaching the root cause.

Then I made expectations observable.

Expectations​

  • Independently drive assigned work
  • Surface risks before deadlines
  • Take debugging to root cause
  • Produce a clear design before implementation for ambiguous work
  • Communicate blockers without manager prompting
  • Provide predictable status updates
  • Ask for help early instead of late

Then I created shorter checkpoints.

Expectation
   ↓
Weekly checkpoint
   ↓
Specific feedback
   ↓
Adjustment
   ↓
Increasing independence

I also asked what was getting in the way.

Some of the issue came from unclear priorities and lack of confidence when making decisions independently.

So I provided more structure initially, then deliberately reduced that support as the engineer improved.

Result​

The engineer became more independent and predictable.

I needed fewer follow-ups, and they began surfacing risks proactively instead of waiting for me to discover them.

Interview takeaway​

My goal in performance management is not to keep someone permanently dependent on me. Coaching should gradually decrease as ownership increases.

3. What If Performance Does Not Improve?

Do not invent a firing story if you do not have one.

A strong response is to explain your process and willingness to act.

Framework​

Problem observed
      ↓
Specific feedback
      ↓
Understand root cause
      ↓
Clear expectations
      ↓
Coaching + support
      ↓
Frequent checkpoints
      ↓
Is performance improving?
   /              \
 yes               no
 ↓                  ↓
restore autonomy   formal performance process
                    ↓
               final assessment
                    ↓
           role change / separation

Interview answer​

I distinguish coaching from formal performance management. My first responsibility is to make sure the employee has received clear feedback, specific examples, measurable expectations, sufficient support, and a reasonable opportunity to improve. If they still consistently cannot meet the expectations of the role, I am willing to move into the company's formal performance process.

Principles​

  • Feedback must be specific
  • Expectations must be measurable
  • Timelines must be clear
  • Support must be real
  • Progress must be documented
  • Consequences should not be surprising

Strong lines​

One mistake managers make is allowing a performance issue to continue indefinitely because the conversation is uncomfortable. That is not fair to the employee or the rest of the team.

By the time termination happens, it should not be a surprise. Expectations, gaps, support, timelines, and consequences should already have been communicated clearly.

4. Rewarding Top Performers

Do not simply give top performers more work.

Instead, focus on:

Top performer
     ↓
What motivates them?
     ↓
Scope | Mastery | Influence | Career | Rewards

1. Scope​

Give ownership of increasingly ambiguous and important problems.

2. Authority​

Do not give responsibility without decision-making authority.

3. Visibility​

Make sure leadership understands the engineer's impact.

4. Multiplication​

Create opportunities to:

  • Mentor
  • Review designs
  • Influence outside the immediate team
  • Lead cross-team initiatives
  • Improve engineering practices

5. Recognition​

Be specific.

Bad:

Great work.

Better:

Your redesign reduced latency from 12–15 seconds to under four seconds, and you aligned several partner teams to make that happen.

6. Sponsorship​

Mentorship and sponsorship are different.

Mentorship is helping someone develop. Sponsorship is using my organizational credibility to create opportunities for them.

5. Managing Different Performance Levels

SituationManager approach
High performerIncrease scope, autonomy, visibility, sponsorship
Solid performerGrow strengths and expose them to next-level skills
Developing engineerStructured stretch opportunities and frequent feedback
Struggling engineerDiagnose, clarify expectations, coach, checkpoint
Persistent underperformanceFormal expectations, documented progress, consequences
Burned-out performerReduce load, understand motivation, restore sustainability
New hireStructured onboarding, early wins, context, relationships
Future leaderDelegation, mentoring, decision-making, organizational influence

Interview line​

Fairness does not mean managing everyone identically. It means everyone has clear expectations, consistent standards, and support appropriate to their situation.

6. Attracting Talent

Think about talent management as a lifecycle:

Attract
 ↓
Select
 ↓
Close
 ↓
Onboard
 ↓
Grow
 ↓
Retain

1. Interesting problems​

Strong candidates want to understand what they will actually own.

Weak pitch:

We are building an ML platform.

Better pitch:

You will own how hundreds of model owners understand model health, lineage, freshness, and production failures.

2. Strong engineering culture​

Candidates are evaluating the company too.

I want interviewers who:

  • Understand the role
  • Respect the candidate
  • Explain engineering challenges accurately
  • Show healthy decision-making
  • Demonstrate technical credibility

3. Growth opportunity​

Explain:

What you own now
       ↓
What you could own in 12–18 months

4. Credible leadership​

Candidates want confidence that:

  • Priorities are clear
  • Strong work is recognized
  • Underperformance is managed
  • Engineers have autonomy
  • Technical quality matters

7. Hiring Talent

Do not optimize only for the strongest individual candidate.

Optimize for the capabilities the team needs.

Example​

Existing team:

2 strong backend engineers
2 infrastructure engineers
1 staff architect

Current gaps:

Product thinking
Frontend ownership
Operational leadership

The question becomes:

What capability does this team need six to twelve months from now?

Hiring scorecard​

Evaluate:

  • Technical ability
  • Problem solving
  • Ownership
  • Communication
  • Collaboration
  • Learning velocity
  • Role-specific strength
  • Decision-making
  • Values and working style

Avoid vague feedback:

"Seems senior"
"Good culture fit"
"I liked them"

Prefer:

Evidence
   ↓
Signal
   ↓
Level expectation

Example:

During system design, the candidate identified failure modes without prompting, quantified scale assumptions, and changed the architecture when requirements changed. That is evidence of senior-level technical judgment.

8. Retaining Talent

Core idea​

Retention is usually not one conversation when someone resigns. It is the result of what happened during the previous twelve months.

I monitor four areas:

Growth
Meaning
Manager relationship
Team environment

Growth​

Ask:

Where are you?
Where do you want to go?
What's missing?
What opportunity builds that skill?

Create evidence of progress.

Meaning​

Connect engineering work to user and business impact.

Instead of:

Build this pipeline.

Explain:

This lets model owners detect data-health problems before they become production incidents.

Manager Relationship​

Do not turn 1:1s into status meetings.

Project status
→ team/project mechanisms

1:1
→ career
→ feedback
→ motivation
→ conflict
→ organization concerns

Useful questions:

  • What work gives you energy?
  • What work is draining?
  • Where do you want more ownership?
  • What am I doing that is getting in your way?
  • What skill do you want to build next?
  • Is there anything you are worried about that we are not discussing?

Team Health​

Top performers notice when low performance is ignored.

Managing underperformance is also a retention strategy for high performers. Strong engineers notice very quickly when expectations are not applied consistently.

9. Managerial Style Answer

30-Second Version​

My management style is high clarity, high support, and increasing autonomy. I make sure engineers understand what success looks like and why their work matters. I provide coaching, context, stakeholder support, and air cover when they take on new scope. As they grow, I deliberately reduce my involvement and increase their decision-making authority. My goal is not to have every decision come through me; it is to build a team that can make strong decisions without me.

10. "How Do You Manage Talent?"

30-Second Answer​

I think about talent management as attract, hire, onboard, grow, and retain. Once someone joins, I calibrate my management to what they need. For high performers I focus on autonomy, scope, visibility, and sponsorship. For developing engineers I create deliberate stretch opportunities with frequent feedback. For struggling engineers I diagnose the root cause, give specific feedback, define measurable expectations, and establish checkpoints. If performance does not improve despite clear expectations and support, I am willing to move into formal performance management. My goal is to build a team where people grow and the organization does not depend on me for every decision.

11. High Performer vs Struggling Performer

High Performer​

High performer
    ↓
Understand motivation
    ↓
Expand scope
    ↓
Increase authority
    ↓
Create visibility
    ↓
Sponsor
    ↓
Multiply through others

What not to do​

  • Give them every difficult task
  • Make them the permanent firefighter
  • Assume they do not need feedback
  • Delay promotion because they are "too important"
  • Reward them only with more responsibility

Struggling Performer​

Gap
 ↓
Specific example
 ↓
Root cause
 ↓
Expectation
 ↓
Support
 ↓
Checkpoint
 ↓
Measure improvement

What not to do​

  • Give vague feedback
  • Wait until performance review season
  • Make everything subjective
  • Constantly rescue their work
  • Hide the issue from them
  • Allow the issue to continue indefinitely

12. Performance Conversation Example

Instead of:

You need to be more proactive.

Say:

On the last two projects, risks were surfaced after the committed date was already at risk. At your level, I expect you to identify those risks earlier, propose options, and communicate them before they affect delivery. For the next project, I want you to send a weekly risk assessment and escalate any blocker that could move the milestone by more than two days.

The structure is:

Observed behavior
      ↓
Expected behavior
      ↓
Impact
      ↓
Specific next action
      ↓
Checkpoint

13. Promotion Conversation Framework

For someone targeting the next level:

Current level
     ↓
Next-level expectations
     ↓
Evidence gaps
     ↓
Growth opportunities
     ↓
Frequent feedback
     ↓
Demonstrated consistency
     ↓
Promotion case

Ask:

  • What next-level behavior are they already demonstrating?
  • What evidence is missing?
  • What projects can create that evidence?
  • Who needs visibility into the work?
  • Is the behavior sustained across multiple projects?

Promotion should not be:

Time in role
   ↓
promotion

It should be:

Demonstrated next-level impact
             ↓
Consistency
             ↓
Evidence
             ↓
Promotion

14. Interview Question: "How Do You Motivate a Low Performer?"

Strong Answer​

I do not start by assuming it is a motivation problem. I first diagnose whether the issue is skill, clarity, workload, confidence, engagement, or role fit. Then I give specific feedback and define observable expectations. I provide enough support to help them succeed, but I also establish checkpoints and gradually expect more independence. If the problem is motivation, I try to reconnect the work to ownership, impact, and growth. If performance still does not improve despite clear expectations and support, then I move into formal performance management.

15. Interview Question: "How Do You Keep High Performers?"

Strong Answer​

High performers usually want some combination of growth, meaningful ownership, autonomy, recognition, and strong peers. I try to understand which of those matters most to the individual. I make sure they are not simply rewarded with more execution work. I give them meaningful decision-making authority, create visibility for their impact, sponsor them for larger opportunities, and protect them from becoming the team's permanent firefighter. I also make sure the overall team maintains a high bar, because strong engineers are often demotivated when persistent underperformance goes unmanaged.

16. Interview Question: "How Do You Handle Firing?"

Strong Answer​

Separation should be the end of a clear process, not the first time the employee learns there is a serious problem. I make sure feedback is specific, expectations are measurable, support is available, checkpoints are documented, and the employee understands the consequences if performance does not improve. If they are still unable to meet the role expectations after that support, then I am willing to make the difficult decision to separate. Delaying indefinitely is unfair both to the employee and to the rest of the team.

17. Interview Question: "How Do You Build a Strong Team?"

Framework​

Clear mission
    +
Strong hiring
    +
Complementary skills
    +
High standards
    +
Psychological safety
    +
Frequent feedback
    +
Growth opportunities
    +
Accountability

Answer​

I try to create a team with a clear mission, complementary skills, strong ownership, and consistent standards. Hiring is only one part of that. Once people join, I invest heavily in onboarding, context, feedback, and growth. I want engineers to feel safe challenging ideas while still being accountable for outcomes. I reward people who multiply the effectiveness of others, not only people who individually produce the most code.

18. STAR Answer Checklist

Before answering a behavioral question, make sure you cover:

Situation​

  • What was happening?
  • Why did it matter?
  • What was the risk?

Task​

  • What were you responsible for?
  • What decision did you need to make?

Action​

Spend most of your time here.

Explain:

  • What you personally did
  • Why
  • What tradeoffs you considered
  • How you communicated
  • How you handled disagreement
  • How you measured progress

Result​

Include:

  • Business outcome
  • Team outcome
  • Individual outcome
  • What you learned

19. Recommended Answer Length

Initial answer​

Aim for roughly:

Situation: 15%
Task:      10%
Action:    55%
Result:    20%

Do not spend three minutes explaining context before getting to what you did.

20. Staff/TLM Language

Prefer:

I created the conditions for...

I clarified the expectations...

I gave them ownership of...

I deliberately reduced my involvement as they grew...

I sponsored them for...

I used specific examples rather than generalized feedback...

I differentiated coaching based on what the individual needed...

I balanced empathy for the individual with accountability to the team...

Avoid:

I told them what to do.

I just gave them more work.

They were not motivated.

They were a bad performer.

I handled everything myself.

I protected the team by taking over the project.

Final Leadership Philosophy

I differentiate management rather than manage everyone identically. High performers need leverage and sponsorship. Developing engineers need opportunities and feedback. Struggling engineers need clarity and coaching. Persistent underperformance requires decisive action. Fairness does not mean treating everyone exactly the same—it means giving everyone clear expectations, consistent standards, and the support appropriate to their situation.