Were the improvements proposed in a retrospective actually carried out afterwards? Did each one have an owner, a date, and a way to verify it? For those not carried out, why not?

Question-specific analysis · reviewed

This question has an edited analysis. Use it as a prompt for evidence, not as an automatic score.

Objective problem to resolve or clarify

Verify whether retrospective improvements entered an execution loop and how decisions changed when work was incomplete or ineffective.

What it examines

See whether your retrospectives turn into plans that can be executed and checked, rather than ending at conclusions.

Signals worth noticing

Each improvement has an owner, a date, and a verification signal
Says which were done and which were not afterwards, and why
Separates a well-made plan from one carried out, and does not treat "written in the retrospective" as "already changed"
Says how it was checked whether the improvement really made a difference

Context worth asking for

How were owners, dates, and priority assigned to each action?
What metric and baseline checked the action, and when?
How were incomplete or ineffective items recorded, escalated, or closed?
What share of your retrospective improvements ended up finished?
When one fails to get done, how do you keep it from quietly being forgotten?
What goal, baseline, constraints, and responsibility boundary applied?
What options were available, and what evidence or dependencies shaped the choice?
Who was affected, what changed, and over what time window?
How was the result verified, and what alternative explanation or downside was considered?

What else the answer may imply

Tracking owners, dates, and validation may show that the retrospective mechanism connects to everyday work. Alternative interpretations to check: A task may be marked complete because the paperwork or process step was done. Observed change may have come from another concurrent intervention.

Comparisons to consider

Commitment and completion

Compare retrospective notes, actual changes, and user behavior; creating a ticket does not resolve the issue.

Completion and effectiveness

Compare baseline, observation window, and other changes occurring at the same time.

Decision after context

Give each action an owner and review date; separate completion status from effect, and keep observing or adjust when evidence is insufficient.

Examine the trade-offs

Benefits created

Which recurring event, rework, or delivery variance did the improvement reduce?
Who observed a behavior or metric change, and for how long did it last?

Costs and risks

What ongoing maintenance does follow-up require, and can the team sustain it?
Did the metric improve at the cost of quality, speed, or added burden elsewhere?

Assessment guide

Use these as evidence anchors for this capability, not as an automatic score or an overall judgment of a person. Calibrate expectations to the role, level, and scope. A score of 2 is the usual baseline; excellent evidence in one or two dimensions is meaningful, while exceptional evidence is rare.

1 · Not passing

Core concepts or basic facts are unclear; the reasoning or account of events cannot be followed. For experience questions, the person cannot distinguish their own actions and responsibility. Confirmed deliberate fabrication is not passing; inconsistency or missing detail alone is a reason to verify, not proof of dishonesty.

Treats “written in the retrospective” as “already improved” and cannot name ownership or status.

2 · Passing

Explains the basic concepts and approach clearly and gives credible evidence of having done the work or being able to reason through it.

Explains an owner, timing, and an actual improvement or reason it was not done.

3 · Excellent

Gives a structured account, reflects clearly on what worked and what did not, weighs benefits against costs or risks, and offers an insight or practice above the ordinary expectation for the role and level.

Separates completion from effect, tracks adverse effects, and reprioritizes using evidence.

4 · Exceptional

Shows an outcome or practice at an exceptional, field-leading level for the relevant scope. The impact is measurable, independently supportable, and credibly attributable to the person’s decisions and work.

Builds a sustainable closed loop that reduces recurrence across periods with reasonable attribution.

Evidence that could make a contribution visible

Action log, owner confirmation, change records, review dates, and before-and-after observations.

Question context and related views

RoleGeneral software engineering · Frontend · Backend · Mobile · AI engineering

Responsibility scopeIndividual work · A project or team

Career trackIndividual contributor · Team manager · Senior manager

Select questions for the responsibility you actually hold or seek. These labels are not universal stage requirements. Stage expectations

Same question, different stage expectations

The question stays the same. Choose a target to compare responsibility, reasoning, and evidence. This changes the reading framework, not the question’s difficulty or your score.

Loading stage model…

Target roleTarget responsibility

These are rule-based reading prompts, not separately reviewed stage-specific answers or a verdict that this question applies to every stage. Use your actual role and authority.

View the full role and stage model →

Compare expectations across stages

This table compares responsibility lenses, not mandatory question coverage or a ranking of people.

Stage	Responsibility	Result evidence

Want deeper feedback? Generate a prompt with this question’s evidence framework, then choose an AI tool yourself.

AI analysis prompt

# Interview Compass response analysis
Analyze the candidate response using only evidence provided. Do not invent facts.

## Question and review status
Question: Were the improvements proposed in a retrospective actually carried out afterwards? Did each one have an owner, a date, and a way to verify it? For those not carried out, why not?
Analysis review status: Question-specific analysis · reviewed. This question has an edited analysis. Use it as a prompt for evidence, not as an automatic score.
Objective problem: Verify whether retrospective improvements entered an execution loop and how decisions changed when work was incomplete or ineffective.
Assessment intent: See whether your retrospectives turn into plans that can be executed and checked, rather than ending at conclusions.
Possible inference (a hypothesis to verify): Tracking owners, dates, and validation may show that the retrospective mechanism connects to everyday work. Alternative interpretations to check: A task may be marked complete because the paperwork or process step was done. Observed change may have come from another concurrent intervention.

## Evidence framework
Observable signals:
- Each improvement has an owner, a date, and a verification signal
- Says which were done and which were not afterwards, and why
- Separates a well-made plan from one carried out, and does not treat "written in the retrospective" as "already changed"
- Says how it was checked whether the improvement really made a difference
Context worth asking for:
- How were owners, dates, and priority assigned to each action?
- What metric and baseline checked the action, and when?
- How were incomplete or ineffective items recorded, escalated, or closed?
- What share of your retrospective improvements ended up finished?
- When one fails to get done, how do you keep it from quietly being forgotten?
- What goal, baseline, constraints, and responsibility boundary applied?
- What options were available, and what evidence or dependencies shaped the choice?
- Who was affected, what changed, and over what time window?
- How was the result verified, and what alternative explanation or downside was considered?
Comparison dimensions:
- Commitment and completion: Compare retrospective notes, actual changes, and user behavior; creating a ticket does not resolve the issue.
- Completion and effectiveness: Compare baseline, observation window, and other changes occurring at the same time.
Decision after context: Give each action an owner and review date; separate completion status from effect, and keep observing or adjust when evidence is insufficient.
Benefits to examine:
- Which recurring event, rework, or delivery variance did the improvement reduce?
- Who observed a behavior or metric change, and for how long did it last?
Costs and risks to examine:
- What ongoing maintenance does follow-up require, and can the team sustain it?
- Did the metric improve at the cost of quality, speed, or added burden elsewhere?

## 1–4 evidence anchors
- 1 · Not passing: Core concepts or basic facts are unclear; the reasoning or account of events cannot be followed. For experience questions, the person cannot distinguish their own actions and responsibility. Confirmed deliberate fabrication is not passing; inconsistency or missing detail alone is a reason to verify, not proof of dishonesty. Question-specific reference: Treats “written in the retrospective” as “already improved” and cannot name ownership or status.
- 2 · Passing: Explains the basic concepts and approach clearly and gives credible evidence of having done the work or being able to reason through it. Question-specific reference: Explains an owner, timing, and an actual improvement or reason it was not done.
- 3 · Excellent: Gives a structured account, reflects clearly on what worked and what did not, weighs benefits against costs or risks, and offers an insight or practice above the ordinary expectation for the role and level. Question-specific reference: Separates completion from effect, tracks adverse effects, and reprioritizes using evidence.
- 4 · Exceptional: Shows an outcome or practice at an exceptional, field-leading level for the relevant scope. The impact is measurable, independently supportable, and credibly attributable to the person’s decisions and work. Question-specific reference: Builds a sustainable closed loop that reduces recurrence across periods with reasonable attribution.

## Analysis instructions
1. Separate explicit evidence, missing context, and hypotheses. Cite exact words or facts from the response.
2. List the most important follow-up questions first. If there is not enough evidence, state “insufficient evidence; do not score.”
3. Assess each relevant signal against the 1–4 anchors only when supported; explain evidence and uncertainty.
4. Discuss comparison choices, causal reasoning, trade-offs, and the candidate’s actual participation where relevant. Identify strengths, unsupported conclusions, and one concrete next practice.
5. Do not provide a sample answer, rewrite the response as a script, diagnose personality, infer dishonesty from inconsistency alone, combine scores into an overall score, or recommend hiring/rejection.

If the response is not provided, ask the candidate to paste their response first; do not analyze or score the question alone.
Do not write a sample answer.