Explain a past project and critique a prior team

Interview prompts

1. Project deep dive: Choose something you built in the past and take the interviewer through it from beginning to end. Plan to draw the architecture on a whiteboard and talk through the trade-offs and the parts you personally owned.
2. Team reflection: What issues did you notice in your previous team or org (process, collaboration, code quality, ownership, and so on)? What would you change, and how would you drive that change while still a junior engineer?

What to cover

• Your role, scope, and impact.
• The main technical choices and the reasoning behind them.
• A difficulty or disagreement and the way you dealt with it.
• What you took away and what you would redo.

Overview: This question assesses how clearly you communicate technical ownership, how you reason about system design, and leadership abilities such as collaboration, conflict resolution, and pushing change forward in a Software Engineer role.

See the complete LinkedIn Software Engineer interview write-up this question came from

Solution

1) Structure your project deep dive (clear, technical, and scoped)

Follow a repeatable outline so the answer stays on track:

1. Problem & goal
   • Who needed it and why (user/business impact).
   • Success metrics (latency, cost, adoption, revenue, reliability).
2. Context & constraints
   • Timeline, team size, dependencies, compliance/security constraints.
   • Limits of the system that already existed.
3. High-level design (whiteboard-friendly)
   • Main components, data flow, and APIs.
   • Storage choices and why (SQL vs NoSQL; indexing; schema).
   • Critical paths and failure modes.
4. Key decisions & trade-offs Examples:
   • Consistency vs availability (if distributed).
   • Batch vs streaming.
   • Build vs buy.
   • Latency vs cost.
5. Your contribution (make it concrete)
   • “I implemented X” is weaker than “I owned X end-to-end: design doc → rollout → on-call.”
   • Call out reviews you led, migrations you carried out, dashboards you built.
6. Results
   • Quantify: “reduced p95 from 400ms to 120ms”, “cut costs by 20%”, “improved crash-free rate to 99.8%”.
7. What went wrong + learning
   • Demonstrate engineering maturity: test gaps, unclear ownership, missing runbooks.
   • Close on what you would change next time.

Common pitfalls

• Staying too high-level (sounds like you didn’t do it).
• Going too low-level (line-by-line code) without tying to goals.
• Not explaining trade-offs (interviewer can’t gauge judgment).

2) Answer “What was wrong with your prior team?” professionally

This question probes judgment, collaboration, and ownership—not gossip.

Safe framing

• Focus on process/system issues, not personal attacks.
• Use neutral language: “I noticed…”, “The trade-off was…”, “Given constraints…”.
• Show you attempted to improve things within your scope.

A strong template (STAR-ish)

• Situation: “Team shipped quickly; quality regressions increased.”
• Task: “As a junior, I wanted to improve reliability without slowing delivery.”
• Action:
  • propose small, low-friction changes (e.g., PR checklist, mandatory tests for critical modules)
  • add tooling (linting, formatting, CI gates)
  • improve observability (dashboards, error budgets)
  • run a lightweight retro and document action items
• Result: “Reduced rollback rate; fewer Sev2s; improved onboarding.”
• Reflection: “Next time I’d align earlier with EM/PM on quality bar and set explicit SLOs.”

Examples of “problems” you can cite (pick 1–2)

• Code quality: inconsistent patterns, lack of tests, unclear module boundaries.
• Operational maturity: no runbooks, weak on-call handoff, missing alerts.
• Planning: too many interrupts, unclear priorities, poor requirement definition.
• Ownership: ambiguous service ownership leading to slow incident response.

What interviewers like to hear (especially for junior)

• You’re respectful and not blaming.
• You identify root causes (incentives, unclear priorities, lack of tooling).
• You propose incremental improvements and ways to influence without authority.

3) Quick checklist before the interview

• Prepare 1 “main” project + 1 backup.
• Have 2 diagrams ready: architecture + data flow.
• Bring 3 metrics (latency, reliability, cost/adoption).
• Prepare 1 failure story and what you learned.
• Prepare 1 example of improving code quality (tests/CI/refactor) to address “code quality” feedback.