Explain a past project and critique a prior team
Company: LinkedIn
Role: Software Engineer
Category: Behavioral & Leadership
Difficulty: medium
Interview Round: Technical Screen
## 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.
Quick Answer: This question evaluates communication of technical ownership, system architecture reasoning, and leadership competencies such as collaboration, conflict resolution, and influencing change within a Software Engineer role.
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.