Bank Tech Internships: The 3 Things Your Lead Watches in the First 90 Days

Many new grads think probation is about how strong your code is.

After six years in bank technology and mentoring several cohorts of newcomers, here is the blunt truth: coding can be taught, and missing skills can be filled in. What your lead is really watching in the first three months is not your code quality. It is three other things.

None of those three things is about writing code. But they decide whether you get labeled as “worth coaching” or “still watching”—and that label usually shapes your first year on the team.

1. When requirements are unclear, can you resist deciding alone?

This trap catches a lot of people—especially developers who “have ideas,” not the ones who are weak at coding.

A new teammate once found a null value for a field in the test environment. The BA document never covered that case. He figured “this field probably won’t be empty in production,” so he added a default value.

Technically fine. No bug. Then QC flagged it after release.

The problem was not wrong code. He changed business logic without being asked. In banking systems, how data is handled is decided by the BA. Developers do not improvise. That default happened to conflict with a downstream system and nearly caused a consistency issue. QC logged it, and it hurt his probation review.

In bank tech, the requirements doc is the contract. Do what the BA wrote. If it is unclear, ask, confirm, then code. You can suggest options, but you cannot decide alone. Cross that line and any fallout is yours.

Many juniors think asking too much makes them look weak. The opposite is true. Guessing and shipping the wrong behavior is what looks weak. Leads are not afraid of questions; they are afraid of silence.

How you ask matters. Do not ask “How do I do this?” That is handing the work back. Ask “This case is missing from the doc—should we treat it as A or B?” That shows judgment and respect for process. Same action, totally different impression.

2. In the daily standup, can you explain progress in one minute?

Some people think probation means chasing the lead for private status updates. It does not.

You sit together every day. Your lead already has a sense of what you are doing. Running over for a private report may land as “can’t self-manage” instead of “so proactive.”

What you should do is spend one minute in standup on three things: what you finished yesterday, what you will deliver today, and what blockers need whose help.

Speak in outcomes, not activity logs.

“Yesterday I set up the environment, fixed bugs, read docs, wrote some code” is a diary. Your lead still does not know where you are.

“Yesterday I finished transfer-API integration testing; I’ll submit for QA this afternoon” is a checkpoint. Three seconds, clear status.

Another common failure: vague blockers. “Test data is a bit weird”—then what? Can you fix it, or do you need help? “Test data is broken; I need QA to create a batch this morning” is actionable. If you mumble “there’s an issue,” your lead assumes you can handle it—until it blows up at the deadline.

3. When something breaks, don’t blame first—diagnose, then bring options

Juniors will make mistakes. Leads expect that.

What they hate is the first reflex: blame-shifting.

One real case: a cross-system integration worked for days. Suddenly the other team said the API stopped responding and asked if we were rebuilding.

Our developer’s first reply was not to investigate. It was: “Are your request params wrong?”

The other side exploded: “I’ve sent this format for days and it worked. You didn’t even look, and you’re blaming me?”

Twenty minutes of argument later, the cause was on our side—a version switch during a freeze build.

One glance would have found it. Instead, the first move was dumping the problem on someone else. After that, trust on the collaboration team is gone. Your lead also files a mental note: avoids ownership.

Rule: when something fails, check your side first—even if you are 99% sure it is theirs. That is professionalism, not weakness. Ask after you checked; people respect that. Accuse first; people get angry.

After you stop blaming, the next bar is whether you can explain: how it happened, blast radius, and how you plan to fix it.

What drains a lead’s patience fastest is not a wrong line of code. It is “I don’t know why it failed,” “maybe data?,” “not sure.” If you cannot explain the cause, they assume you will repeat it. Code can be fixed; lost credibility costs far more.

The right move: diagnose, then bring options for a decision.

“Lead, here’s the issue: cause is XX, impact is XX. Option A is faster with risk XX; option B is safer but takes XX longer. Which do you want?”

Two options, not one. One option removes the lead’s choice. Two options with tradeoffs is what “bringing a plan” actually means.

The person who only apologizes makes the lead carry the anxiety. The person who brings options makes the lead pick A or B. Which junior would you rather coach?

Takeaway

In the first three months, leads watch three things:

1. When requirements are unclear, ask instead of deciding alone
2. In standup, make progress clear in one minute
3. After mistakes, don’t blame first—diagnose and bring options

Underneath is one question: are you reliable? Skills can be trained. Reliability sets the tone in the first 90 days. If you look reliable early, important work comes your way. If not, even strong code will not get you trusted ownership.

If you are preparing for bank-tech interviews, you can also run a resume diagnosis and mock follow-up on FinlaunchAI.