Mentoring, Knowledge Sharing & Code Reviews — Interview Questions

How to use this lesson

Seniors are judged by how much better the team gets because they're there. The strong answers:

• show systems (onboarding plans, review guidelines, rotations), not only personal heroics;
• tie them to measurable outcomes (time to first PR, review turnaround, fewer incidents);
• include a short story about one person you grew.

Q1. How do you onboard a new team member effectively?

Short answer:

• Before day 1: access, hardware, accounts and a buddy assigned. An onboarding doc: the architecture overview, service map, glossary, how to build, test and deploy locally, and who owns what.
• Week 1: set up the environment (it should be scripted: one command, or a dev container), then a small, real first task (a bug fix, a documentation improvement) shipped to production. That builds confidence and exercises the whole pipeline.
• Weeks 2 to 6: a progressively bigger scope; pairing on a feature; shadowing on-call before joining the rotation; walkthroughs of key flows by their owners.
• 30/60/90-day goals, with regular check-ins.
• Ask every new joiner to fix the onboarding doc where it was wrong. It keeps the doc current.

Metrics: time to first PR, time to first production deploy, time to independent on-call, and the new joiner's own feedback.

Q2. What's your approach to mentoring junior developers? How do you mentor juniors?

Short answer:

• Understand the person: their goals, strengths and gaps, and how they like to learn. Agree a growth plan with 2 or 3 concrete goals (for example "own a small service end to end", "lead a design review").
• Regular 1:1s (weekly or fortnightly), led by their agenda.
• Learning by doing: stretch tasks with a safety net; pairing (let them drive); design discussions where you ask questions instead of giving answers ("what happens if this call times out?").
• Feedback: specific, timely, balanced, and focused on behaviour and code, never on the person.
• Exposure: invite them to design reviews, incident retros and stakeholder meetings; give them credit publicly.
• Gradually hand over ownership, and step back.

Learn it in depth → Unblock, Don't Solve

Q3. Describe a time you coached someone who was struggling with a concept.

Short answer: Structure: diagnose → adapt → practise → confirm. For example: "A junior developer kept introducing race conditions in our async order processing. Explaining it in the abstract didn't work, so I wrote a tiny test that reproduced a lost update with two threads, and we debugged it together. Then we fixed it three ways (synchronized, an atomic class, an optimistic-locking version column) and compared the trade-offs. I gave them a follow-up task with a similar pattern and reviewed it closely. Within a month they were catching concurrency bugs in other people's PRs."

The key points: find the root misunderstanding; use concrete, runnable examples; let them do the work; check understanding with a new problem; be patient.

Q4. How do you mentor someone on architecture-level thinking?

Short answer:

• Widen the lens gradually: from "does this code work?" to "how does it fail, scale, get deployed, observed and changed?"
• Involve them in design: ask them to write a small design doc or ADR for a feature, with at least two options and their trade-offs. Review it with them.
• Ask non-functional questions: load, latency, failure modes, data consistency, security, cost, and operability.
• Study real systems: walk through your system's architecture and its history (why we made each choice), incident postmortems, and published case studies.
• Practice system design exercises together.
• Give them ownership of a component's evolution, with you as a reviewer.

Q5. How do you balance being helpful with micromanaging?

Short answer:

• Agree on the outcome and the constraints, not the steps. Let them choose the how.
• Match the support to the person's experience with that task (situational leadership): more guidance for a new area, more autonomy for a familiar one.
• Agree the check-in points up front (design review, first PR, demo), rather than asking for status constantly.
• Be available, not intrusive: "ping me if you're stuck for more than an hour".
• Coach with questions instead of dictating solutions; accept different but valid approaches.
• Step in directly only when the risk is high (production, security, a deadline).

Q6. How do you ensure knowledge sharing across the team, and prevent knowledge silos?

Short answer:

• Rotate work: rotate the owners of features and components, and pair on critical systems.
• On-call rotation with runbooks: everyone learns the production behaviour.
• Documentation as part of done: READMEs, ADRs, architecture diagrams and runbooks, kept close to the code.
• Spread reviews: require reviewers beyond the usual expert (CODEOWNERS with groups, not single people).
• Sessions: tech talks, brown-bags, demos, and incident-review readouts.
• Track the bus factor: list the critical areas and how many people can work on each; target at least 2 or 3 each.
• Record design discussions and important walkthroughs.

Q7. What metrics do you track for mentoring success? (And how do you measure success in general?)

Short answer:

• For the mentee:
  • progress on the goals agreed in their growth plan;
  • scope handled independently (the size and ambiguity of tasks they own);
  • the quality signals (fewer review rounds, fewer defects);
  • time to autonomy (first PR, first on-call, first design led);
  • promotions and role changes;
  • their own feedback.
• For the team: onboarding time, bus factor, review participation, and retention.
• Success in general: outcomes over output (the business metrics the work moved), quality (incidents, change failure rate), delivery predictability, and the team's growth and engagement.

Numbers help, but also use qualitative evidence (what they can now do that they couldn't before).

Q8. How do you build a mentorship culture within the team?

Short answer:

• Make mentoring part of the senior role: include it in the expectations and career ladder, and recognise it in reviews.
• Buddy system for every new joiner; pairing as a normal practice.
• Everyone teaches: rotating tech talks, and juniors presenting what they learned.
• Psychological safety: asking questions is encouraged, and "I don't know" is fine.
• Reverse mentoring: juniors often know newer tools, and can teach them.
• Time is budgeted: mentoring counts as real work in planning.

Q9. Have you had a mentee who outperformed expectations? What did you do right?

Short answer: Tell a real story, and credit them first. The factors you should mention:

• high expectations, with support (stretch work plus a safety net);
• trust and visibility: gave them ownership, and let them present their work to leadership;
• fast, honest feedback loops;
• removed obstacles, and connected them with the right people;
• stepped back at the right time.

An example: "A graduate owned our retry-and-idempotency library after I paired with them for two weeks. They presented it in the engineering all-hands, and three teams adopted it. They were promoted in 14 months."

Q10. What is your code review strategy? How do you ensure quality without blocking delivery?

Short answer:

• Automate the objective things: formatting, linting, static analysis (SpotBugs, Sonar, Error Prone), tests, coverage thresholds and security scans all run in CI before a human looks. Reviewers focus on design, correctness and maintainability.
• Small PRs (ideally under about 400 lines); stacked PRs or feature flags for bigger work, so incomplete features can merge safely.
• Fast turnaround: agree on a review SLA (for example, first response within 4 working hours), and treat reviews as priority work.
• Clear priority levels in comments: must fix (bug, security, data loss), should (design), nit (optional, non-blocking).
• Approve with suggestions when the remaining comments are minor.
• Pair or mob on risky changes, which makes the review almost instant.
• Protect the quality gates that matter (tests for critical paths, security) and relax the rest.

Q11. What red flags do you look for in code during a review?

Short answer:

• Correctness: unhandled nulls and edge cases; wrong equals/hashCode; mutable shared state without synchronisation; swallowed exceptions; resources not closed (use try-with-resources).
• Transactions and data: missing or wrong @Transactional boundaries (including self-invocation that bypasses the proxy); N+1 queries; missing indexes for new queries; non-idempotent consumers and retries.
• Security: SQL built by string concatenation; secrets in code or logs; personal data in logs; missing authorisation checks; unvalidated input.
• Resilience: remote calls with no timeouts; unbounded retries; unbounded queues, caches or thread pools; loading an entire table into memory.
• Design: god classes, deep inheritance, copy-paste duplication, leaky abstractions, and business logic in controllers.
• Operability: no logs, metrics or tracing on new flows; breaking API or schema changes with no versioning or migration.
• Tests: missing, testing only the happy path, or brittle (heavy mocking of implementation details).

Q12. How do you give constructive feedback on code?

Short answer:

• Comment on the code, not the person: "this method could throw on an empty list", not "you forgot again".
• Explain why, and link to evidence or a guideline; suggest a concrete alternative (a code suggestion).
• Ask questions when you're unsure: "what happens if the payment call times out here?"
• Label the severity (blocking vs nit), and don't block on personal preference.
• Praise good things specifically.
• Move to a call after two rounds of back-and-forth in comments.
• For a pattern of issues, give feedback privately in a 1:1, not in public threads.

Q13. How do you review code from someone more experienced than you?

Short answer: Review it with the same rigour: experience doesn't make code immune to bugs, and reviews are about the code. Ask questions where you don't understand ("why did you choose X over Y?"). You either find an issue, or learn something. Point out concrete issues confidently, with evidence (a failing case, a benchmark). Stay respectful and curious. A good senior welcomes it, and it improves everyone's shared understanding.

Q14. What tools and checklists do you use for code reviews? How do you encourage self-review?

Short answer:

• Tools: the Git platform (GitHub or GitLab PRs, with CODEOWNERS and branch protection); CI checks (tests, coverage via JaCoCo, SonarQube quality gates, SpotBugs, PMD, Checkstyle or Spotless, Error Prone); dependency and security scanning (OWASP Dependency-Check, Snyk, Dependabot, CodeQL); and optional AI review assistants as a first pass.
• A lightweight checklist in the PR template: what and why, linked ticket, tests added, migration or rollback plan, config or flag changes, observability, security implications, documentation updated.
• Self-review:
  • make the PR template ask the author to confirm the checklist;
  • review your own diff before requesting review (catch debug code and leftovers);
  • write a good description with test evidence;
  • run the same checks locally (pre-commit hooks);
  • leave comments on your own PR to guide reviewers to the tricky parts.

Q15. What's your take on enforcing coding standards versus flexibility?

Short answer: Enforce automatically what can be automated (formatting, lint rules, banned APIs, architecture rules with ArchUnit), so there's no debate in reviews. Keep a short, agreed style guide for things that matter (error handling, logging, API conventions, package structure), decided by the team, and changed through a lightweight proposal process. Allow flexibility in implementation choices where the trade-offs are genuinely equal. Consistency matters more than any specific rule, because it reduces cognitive load across a codebase.

Q16. How do you address recurring mistakes in code reviews?

Short answer: Treat them as a system problem first:

• automate the check (a lint rule, an ArchUnit test, a Sonar rule, a custom Error Prone check);
• add it to the PR template or checklist;
• improve the shared library or template so the wrong way is harder (for example, a base HTTP client with timeouts by default);
• document it, with an example, and share it in a team session.

If it's one person, raise it privately and supportively in a 1:1. Pair with them on the next similar task, and check whether the cause is a knowledge gap, time pressure or unclear standards.

Q17. What do you do if someone submits a large PR just before a deadline?

Short answer:

• Don't rubber-stamp it, and don't just block it either. First assess the risk: what does it touch (payment, data migration, a shared library)?
• Options:
  • split it into smaller PRs and merge the safe parts first;
  • ship behind a feature flag (off by default), so the risk is controlled;
  • do a synchronous walkthrough review with the author (much faster than async comments on 2,000 lines);
  • focus the review on the risky areas, and rely on tests for the rest;
  • add targeted tests;
  • if the risk is still too high, negotiate the scope or date, with transparency.
• Afterwards: a retro on why the work arrived so late in one piece; agree on small, frequent PRs and early drafts.

Q18. How do you handle a team member who consistently rejects feedback?

Short answer:

1. Private 1:1: understand their perspective. Maybe the feedback was unclear or inconsistent, or felt personal, or they disagree for valid reasons.
2. Anchor the discussion in objective criteria: agreed standards, data, incidents, test results. Replace "I think" with "our guideline says" or "this failed in production last month".
3. Agree on the rules of engagement: how disagreements in reviews are resolved (a call, a tech lead decision, an ADR), so it doesn't turn into a battle of wills.
4. Recognise the times they do take feedback on board.
5. If the behaviour continues and affects quality or the team, escalate it to their manager, with specific examples, as a performance and behaviour matter.

Q19. Follow-up: what's the goal of a code review?

Short answer: Mainly knowledge sharing and maintainability, plus catching defects and design issues early. It is not a gatekeeping ritual or a place to show off. Healthy teams see reviews as collaboration: the author and reviewer share responsibility for the change.

Follow-up questions this topic invites — and their answers

Q: What is a reasonable PR size? A: Small enough to review thoroughly in one sitting, usually 200–400 changed lines. Research on reviews shows defect detection drops sharply for larger diffs. Split by refactor-first, then feature, or use stacked PRs.

Q: Should juniors review seniors' code? A: Yes. It's one of the fastest ways for juniors to learn, spreads knowledge, and often catches clarity problems. Seniors should still get at least one experienced reviewer for high-risk changes.

Q: How do you handle a disagreement in a PR that doesn't converge? A: Move to a short call. If it's still unresolved, refer to the agreed standards, or let the code owner or tech lead decide, and record significant decisions in an ADR. Don't let PRs stall for days.

Q: What's the "bus factor"? A: The number of people who would have to leave before a project stalls because nobody else understands a critical part. A bus factor of 1 is a risk to fix with pairing, rotation and documentation.