Definition
- Teach thinking – Transfer the reasoning behind the rule, not just the rule itself.
- Side-by-side demo – Show the buggy code and the correct code together so the lesson is concrete.
- Junior drives – Let the mentee do the fix while you review, building their confidence and skill.
- Psychological safety – Normalize questions and share your own past mistakes to reduce fear.
- Measurable independence – Success is the junior catching similar issues on their own.
- Specific story – Name the junior, the gap, your coaching actions, and the improvement.
Think of a senior bank officer at National Bank of India training a new teller. The new teller can count cash but does not yet know how to handle a disputed transfer on Rajesh's savings account. The senior does not just do it for them; they stand beside the teller, explain why each step protects the customer's money, let the teller try, and give feedback.
Understanding the Concepts
What is this question really testing?
The interviewer is evaluating leadership, communication, and your ability to multiply your impact through others. They want evidence that you can grow a less-experienced engineer and improve the team's overall capability.
package com.bank.interview;
public class MentoringTest {
enum Signal { MULTIPLIER, SOLO }
public static Signal evaluate(boolean taughtThinking, boolean juniorGrewIndependent) {
return (taughtThinking && juniorGrewIndependent) ? Signal.MULTIPLIER : Signal.SOLO;
}
public static void main(String[] args) {
System.out.println(evaluate(true, true)); // MULTIPLIER
}
}
What was the specific gap?
A junior developer at National Bank of India used Java's double type for the monthly interest calculation on savings accounts. The tiny floating-point rounding errors added up across thousands of accounts and broke end-of-month reconciliation.
package com.bank.service;
import java.math.BigDecimal;
import java.math.RoundingMode;
public class DoubleProblem {
public static void main(String[] args) {
// Wrong: double for money
double balanceDouble = 280000.0;
double rateDouble = 0.04 / 12;
double interestDouble = balanceDouble * rateDouble;
System.out.println("double interest: " + interestDouble); // imprecise
// Correct: BigDecimal for money
BigDecimal balance = new BigDecimal("280000.00");
BigDecimal rate = new BigDecimal("0.04").divide(new BigDecimal("12"), 10, RoundingMode.HALF_EVEN);
BigDecimal interest = balance.multiply(rate).setScale(2, RoundingMode.HALF_EVEN);
System.out.println("BigDecimal interest: " + interest); // exact
}
}
double interest: 933.3333333333334
BigDecimal interest: 933.33
How did you teach the principle, not just the rule?
I explained the why: money needs exact decimal arithmetic because tiny rounding errors compound across thousands of accounts. "Use BigDecimal" is a rule the junior forgets; "money needs exact arithmetic" is a principle they apply everywhere.
package com.bank.interview;
public class PrincipleVsRule {
public static void main(String[] args) {
System.out.println("Rule: 'Use BigDecimal for money' -> forgets in 2 weeks");
System.out.println("Principle: 'Money needs exact decimal arithmetic because "
+ "tiny errors compound across 100K accounts' -> applies everywhere");
}
}
How did you show the error concretely?
I ran the double calculation next to the BigDecimal calculation on Rajesh's and Priya's balances. The junior could see with their own eyes that double produced rounding noise.
package com.bank.service;
import java.math.BigDecimal;
import java.math.RoundingMode;
public class SideBySideDemo {
public static void main(String[] args) {
double rajeshDouble = 280000.0 * (0.04 / 12);
BigDecimal rajeshBD = new BigDecimal("280000.00")
.multiply(new BigDecimal("0.04").divide(new BigDecimal("12"), 10, RoundingMode.HALF_EVEN))
.setScale(2, RoundingMode.HALF_EVEN);
System.out.println("Rajesh (double): " + rajeshDouble);
System.out.println("Rajesh (BigDecimal): " + rajeshBD);
System.out.println("The difference is tiny per account but catastrophic across 100K accounts.");
}
}
How did you let the junior drive the fix?
I let the junior rewrite the interest calculation using BigDecimal while I reviewed. Teaching is not doing it for them; it is standing beside them while they do it.
package com.bank.interview;
public class JuniorDrives {
public static void main(String[] args) {
System.out.println("Step 1: I explained the principle and showed the error");
System.out.println("Step 2: Junior rewrote the calculation using BigDecimal");
System.out.println("Step 3: I reviewed and gave feedback on scale and rounding mode");
System.out.println("Step 4: Junior submitted the fix with confidence");
}
}
How did you create psychological safety?
I shared my own past mistake with double arithmetic so the junior knew this was a common trap, not a personal failing. Normalizing mistakes makes juniors ask questions earlier.
package com.bank.interview;
public class PsychologicalSafety {
public static void main(String[] args) {
System.out.println("I said: 'I made the exact same mistake early in my career.'");
System.out.println("Effect: junior stopped hiding confusion and started asking earlier.");
System.out.println("Result: fewer bugs caught late, more bugs caught at review time.");
}
}
How did you measure success?
The junior caught two other places in the codebase where double was being used for money before I even reviewed them. That independent detection is the proof of successful mentoring.
package com.bank.interview;
public class MentoringSuccess {
public static void main(String[] args) {
System.out.println("Before mentoring: junior used double for money without question");
System.out.println("After mentoring: junior independently found 2 more double-money bugs");
System.out.println("Measurement: the junior can now catch this class of issue without me");
}
}
What are common interview follow-up questions?
Expect: "How did you handle it if the junior pushed back?" (use data, not authority), "Did you mentor anyone else?" (show a pattern), and "What did you learn from mentoring?" (teaching forces you to clarify your own understanding).
package com.bank.interview;
public class MentoringFollowUps {
public static void main(String[] args) {
System.out.println("Pushback? -> Showed the numbers; data convinced them");
System.out.println("Others? -> Yes, I mentor 1-2 juniors per quarter");
System.out.println("What I learned? -> Teaching clarifies my own understanding");
}
}
Visual Overview
┌────────────────────────────────────────────────────────┐ │ Mentoring Method │ ├────────────────────────────────────────────────────────┤ │ │ │ ┌──────────────────┐ │ │ │ 1. IDENTIFY GAP │ Junior used double for money │ │ └────────┬─────────┘ │ │ │ │ │ ▼ │ │ ┌──────────────────┐ │ │ │ 2. SHOW ERROR │ Side-by-side: double vs │ │ │ (concrete) │ BigDecimal on real balances │ │ └────────┬─────────┘ │ │ │ │ │ ▼ │ │ ┌──────────────────┐ │ │ │ 3. TEACH WHY │ "Money needs exact arithmetic │ │ │ (principle) │ because errors compound" │ │ └────────┬─────────┘ │ │ │ │ │ ▼ │ │ ┌──────────────────┐ │ │ │ 4. JUNIOR DRIVES │ Junior rewrites, I review │ │ │ (ownership) │ │ │ └────────┬─────────┘ │ │ │ │ │ ▼ │ │ ┌──────────────────┐ │ │ │ 5. VERIFY │ Junior independently found │ │ │ INDEPENDENCE │ 2 more double-money bugs │ │ └──────────────────┘ │ └────────────────────────────────────────────────────────┘
Key Takeaway
At National Bank of India, a junior developer on my team built the monthly interest calculation for savings and current accounts. He used Java's double type to multiply the balance by the interest rate, which looked perfectly reasonable, but over thousands of accounts the tiny floating-point rounding errors added up and broke our end-of-month reconciliation for customers like Rajesh and Priya.
Instead of silently correcting his code, I sat with him and showed him the actual numbers. I ran the double calculation next to a BigDecimal calculation, and he could see with his own eyes that double produced rounding noise. Seeing the error made the principle stick far better than me just saying "use BigDecimal."
Then I let him do the fix himself while I reviewed. I explained the why : money needs exact decimal arithmetic : and framed it as a reusable principle so he could apply it to interest, fees, and currency conversion later. The result was that reconciliation came out clean the next month, and more importantly he caught two other double-money bugs before I even reviewed them.
That is what good mentoring looks like to me: I teach the reasoning, the junior becomes self-sufficient, and the whole team gets stronger. The measure of mentoring is not that the junior needs me less, not more.
Remember one sentence: Good mentoring teaches the principle behind the rule, lets the junior drive the fix, and measures success by their growing independence.
---