Explain a past project and critique a prior team

Interview prompts

1. Project deep dive: Pick a past project you worked on and walk through it end-to-end. Be ready to use a whiteboard to explain architecture, trade-offs, and your specific contributions.
2. Team reflection: What problems did you observe in your previous team/org (process, collaboration, code quality, ownership, etc.)? What would you change, and how would you influence that change as a junior engineer?

What to cover

• Your role, scope, and impact.
• Key technical decisions and why.
• A challenge or conflict and how you handled it.
• Lessons learned and what you would do differently.

Solution

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

Use a repeatable outline so you don’t ramble:

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.
   • Existing system limitations.

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 less strong than “I owned X end-to-end: design doc → rollout → on-call.”
   • Mention reviews you drove, migrations you executed, dashboards you created.

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

   • Show engineering maturity: test gaps, unclear ownership, missing runbooks.
   • End with what you’d 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 tests 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.