How to prepare for interviews that ask you to critique someone else’s work

Some interviews ask you to evaluate or critique existing work: code to review, a product to assess, or a marketing campaign to audit. These rounds test judgment, communication, and how you balance criticism with constructive next steps.

If you haven't seen this format often, it can feel like walking into a trap. In reality, interviewers want to see your reasoning, empathy, and ability to prioritise—not a perfect answer. This article gives a clear framework you can use in the room, scripts to borrow, and a short checklist to practice before the interview.

Understand what they’re really assessing

Start by remembering the goals behind this interview task. Interviewers usually want to know how you: identify risk and opportunity, communicate trade-offs, prioritise fixes, and collaborate with people who built the work. They aren’t expecting you to rewrite everything on the spot.

Before you dive into the details during the interview, surface the meta-skills you’ll illustrate: problem-framing, cause analysis, quick prioritisation, and an ability to propose clear next steps that fit the team’s likely constraints.

• Risk identification (what could break or go wrong)
• Root-cause thinking (why the issue exists)
• Trade-off awareness (time, impact, and team capabilities)
• Communication style (how you phrase criticism and recommendations)

Quick prep checklist to practice beforehand

You can get a lot better at critique interviews with focused practice. Build a short routine you run through before any loop that might include a critique: familiarise yourself with common artifacts, rehearse a 3-step vocal framework, and prepare fallback questions to ask the interviewer.

Do a few mock critiques of public examples (open-source code, product pages, or design screenshots). Timebox yourself to 20–30 minutes so you learn to surface the high-impact issues rapidly.

• Pick 3 artifact types you might be given and study one real example each
• Practice a 3-step verbal structure (observe → judge → propose) in 60–90 seconds
• Prepare 6 clarifying questions to ask the interviewer (constraints, goals, success metrics)
• Record one practice critique and listen for leaps in logic or unclear language

A simple framework to use in the interview

Use a short, repeatable framework to keep your critique structured and clear. I recommend: Context → Observations → Impact → Recommendation → Next steps. Say the framework aloud at the start so interviewers follow your thinking.

Example script starters help you sound composed: “Before I dive in, could I confirm the primary goal for this work? I’ll then share quick observations, the likely impact, and a few practical next steps.” That sets expectations and buys you permission to ask clarifying questions mid-critique.

• Context: ask goals, constraints, and who the primary users are
• Observations: list 3–5 concrete, evidence-backed points
• Impact: explain why each observation matters (user, business, technical risk)
• Recommendation: propose 1–3 actionable changes, with time/effort estimates
• Next steps: propose who should do what and what they’d measure

What to say — and what to avoid

Language matters. Use neutral, specific phrasing instead of blanket statements. Replace “This is terrible” with “This causes X and makes Y harder to measure.” Be specific about what you saw and why it matters.

Avoid personal attacks, absolute language, and premature optimization. Don’t try to solve everything; prioritise. If you spot something you can’t fully assess from the artifact, flag the uncertainty and ask what additional info exists.

• Say: “I noticed X; that could lead to Y because…”
• Don’t say: “This is wrong” or “They should’ve done Z” without backing it up
• Say: “Assuming the goal is A, a small change that would test our hypothesis is…”
• Don’t invent constraints—ask instead: “Do we have two-week sprints or ad-hoc fixes?”

How to prioritise your recommendations

Interviewers want to see sensible trade-offs. Rank suggestions by impact and cost—high impact/low cost first. Use rough time and resource estimates: minutes, days, or weeks; single engineer/designer or cross-functional effort.

If you can, present a quick A/B list: quick wins vs strategic work. That shows you can deliver value now while thinking longer term.

• High impact, low effort — list 1–2 items to do immediately
• Medium impact, medium effort — list 1–2 items to plan into the next sprint
• High effort, strategic — note as roadmap items with clear success metrics

How to handle follow-ups and pushback

Interviewers often press or play devil’s advocate. Stay calm and treat pushback as a chance to show reasoning. If a critic says your fix is too costly, explain alternatives and trade-offs; mention assumptions and how you’d validate them.

If you don’t know, say so. Offer a hypothesis and a way to test it. For example: “I’m not sure about X; a quick experiment to test this would be Y, and we’d measure Z.” That’s better than fabricating confident-sounding but unsupported claims.

• When challenged, restate the constraint they gave and how your suggestion fits
• If you change position, explain the new evidence or assumption that led you there
• Offer a tiny experiment or metric to validate your recommendation

Critique interviews reward clear structure, measured language, and realistic prioritisation. Practice the framework (context → observations → impact → recommendation → next steps), rehearse quick clarifying questions, and learn to prioritise high-impact, low-effort changes first.

Go into the room with the mindset that you’re helping the team make a better decision, not proving you’re smarter. That approach keeps your feedback constructive and memorable—exactly what interviewers want to see.