Standard Chartered Interview Guide (2026)

1Snapshot, read this first#

The one thing to understand about Standard Chartered: it is a bank first.

• They are not hunting for the person who can invert a binary tree fastest.
• They want careful, maintainable code, adult communication, and no compliance headaches.
• Steady beats flashy every single time here.
• Read every answer you give as evidence for one question: can we let this person near production.

2Getting the call (the part most guides skip)#

The careers portal is a filter, not a fast lane.

• It runs an ATS that scores keyword overlap against the posting before a human sees your file.
• A resume that reads well to a person but misses the stack words can die silently.
• Apply through it, but do not count on it to carry you.

Referrals matter more than people admit.

• SC is a huge org with a strong internal-referral culture, especially out of the India tech centers and London.
• Know anyone inside, even loosely? Ask them to drop your profile through the internal referral tool.
• A referred resume gets a human look, usually within a week. A cold one often gets auto-filtered.
• The gap in response rate is the gap between an interview and silence.

On the resume, write bullets a non-engineer recruiter can still understand. Numbers do the work. Compare:

• Weak: "Worked on backend APIs for a payments service."
• Strong: "Built and shipped 12 REST endpoints for a payments reconciliation service in Java/Spring Boot, cutting daily settlement-mismatch tickets by 40% and handling ~2M requests/day."

Why the second one wins:

• It names a stack, a scope, and a result with a number.
• The recruiter now knows what you touched, how big it was, and that it mattered.
• Aim for that shape on every bullet: verb, what you built, the stack, the measurable outcome.

ATS keywords to mirror from the job description:

• Java, Spring Boot, Microservices, SQL, REST APIs, CI/CD, and whatever stack the posting names (sometimes Python, React, Kafka, or PL/SQL for Oracle-heavy teams).
• Put in the "Agile" or "DevOps" words only where they are honestly true for you.
• Do not keyword-stuff things you cannot defend, because they will ask.
• A single "tell me more about the Kafka work" unravels a padded resume in thirty seconds, and at a bank that reads as a character flag, not a knowledge gap.

3The loop at a glance#

Not everyone gets all five.

• Experienced hires often skip the aptitude and get two technicals plus the HM round.
• Grads almost always start with the OA.
• The managerial round is the one people under-prepare: a strong coder who cannot explain a trade-off or talk about a past conflict quietly loses the offer there.
• Treat it as a real round, not a formality.

4The coding or technical rounds#

The honest truth about SC coding rounds: easy to medium, rarely hard.

• Not a competitive-programming gauntlet. No segment trees, no hard DP with state compression.
• You get a clean problem with an obvious optimal pattern.
• The real test is whether you reach it calmly and explain it.

The patterns that come up again and again:

• Arrays and strings: two pointers, sliding window, frequency maps, in-place reversals.
• Hashing: anagrams, two-sum variants, first non-repeating character, counting.
• Searching and sorting: binary search and its "find first/last" variants, basic sort reasoning.
• Linked lists: reverse, detect cycle, find middle, merge two sorted lists.
• Trees: traversals (in/pre/post, level order), height, lowest common ancestor.
• Recursion and basic DP: Fibonacci, climbing stairs, simple subsequence problems.
• Strings and parsing: palindrome checks, valid parentheses with a stack.

The grad OA adds aptitude, and you cannot blow it off.

• Logical reasoning, number series, basic quantitative work.
• Strong coders fail here because they never practiced timed aptitude.
• The OA often gates on a combined score, so weak aptitude sinks perfect coding.
• Treat it like a separate exam with its own practice.

Here is the shape of a clean answer. Two-sum with a hash map, narrated the way you would say it out loud:

// "I'll use a hash map so each lookup is O(1).
//  One pass: for each number, check if its complement is already seen."
int[] twoSum(int[] nums, int target) {
    Map<Integer, Integer> seen = new HashMap<>();
    for (int i = 0; i < nums.length; i++) {
        int need = target - nums[i];
        if (seen.containsKey(need)) {
            return new int[]{ seen.get(need), i };  // found the pair
        }
        seen.put(nums[i], i);
    }
    return new int[]{};  // "no pair, I'd confirm this is the expected empty case"
}
// O(n) time, O(n) space. Brute force is O(n^2), I avoided that.

The comments are the things you say, not decoration. That running narration is what gets scored.

How to actually win the coding round. This is 80% of the score:

1. Clarify first. Restate the problem. Ask about input size, edge cases, empty input, duplicates. A candidate who asks "can the array be empty or have negatives?" before touching the keyboard has already half-convinced me. It signals you think about the inputs that break code in production, which at a bank is the whole job.
2. Think out loud. When I run a loop here, what I am really checking is whether you can explain why. Narrate the approach before you code: "hash map so lookups are O(1), then one pass." Silence kills candidates. I cannot score a brain I cannot hear, and ten minutes of quiet typing followed by a finished solution tells me nothing about how you reason.
3. State complexity. Say time and space out loud, honestly. "This is O(n) time, O(n) space. I could do O(1) space if I sort first, but that costs O(n log n) time." That trade-off sentence is gold: it shows you know there is more than one answer and you chose one on purpose.
4. Test your own code. Walk one small input (say a two-element array) through it line by line, tracking each variable. Catch your own off-by-one before I do. That one habit separates the offers from the rejects, because calmly debugging your own work is exactly what the job looks like.

Practice plan:

• Grind LeetCode easy/medium by pattern, not randomly. Do 2 to 3 per pattern until the shape is automatic, so a new problem reads as "this is a sliding window" in the first fifteen seconds.
• For aptitude, do timed sets on IndiaBix or similar.
• Code in the language you are fastest in, usually Java or Python for SC.

5CS fundamentals (the round that quietly decides it)#

At SC, especially the junior-heavy India pipelines, fundamentals carry more weight than fancy system design.

• This is where a lot of "good coders" get sunk.
• The pattern is predictable: someone grinds 300 LeetCode problems, walks in confident, and cannot explain what a database index actually does under the hood.
• Expect rapid-fire questions across four areas.

OOP: the four pillars, but with real examples.

• Do not recite "encapsulation, inheritance, polymorphism, abstraction."
• Explain overloading vs overriding, abstract class vs interface, and when you would pick one.
• A clean answer: "I use an interface when I only need a contract and unrelated classes will implement it, an abstract class when I have shared state or default behavior to hand down."
• Be ready for "explain SOLID with an example from your own code," and have one real example, not a textbook definition.

DBMS: this is big at a bank.

• Normalization (1NF to 3NF), ACID properties, indexes and when they hurt, joins, and writing a query live.
• Know the real answer on indexes: a B-tree index makes lookups fast but slows writes and costs storage, so you do not index every column.
• Practice a few SQL problems: second-highest salary, group-by with having, a self-join.
• They love SQL here because the job is full of it.

A worked second-highest salary answer you can write from memory:

SELECT MAX(salary) AS second_highest
FROM employees
WHERE salary < (SELECT MAX(salary) FROM employees);

• Be ready to explain the edge case: fewer than two distinct salaries returns NULL, and say why that is correct behavior.

Operating systems:

• Process vs thread, deadlock and the four conditions (mutual exclusion, hold and wait, no preemption, circular wait), scheduling basics, mutex vs semaphore, what a context switch costs.
• Know that a thread shares memory with its process while a process does not, and why that makes threads cheaper but race conditions possible.

Networking:

• TCP vs UDP (TCP guarantees order and delivery, UDP trades that for speed), what happens when you type a URL and hit enter, the TCP three-way handshake (SYN, SYN-ACK, ACK), HTTP vs HTTPS, status codes.
• Know the common ones cold: 200, 301, 400, 401, 403, 404, 500, 503.

For senior roles you will get real design. The framework I would use in the room:

1. Clarify requirements and scale. Functional and non-functional. Ask numbers: how many users, reads vs writes, latency target.
2. Sketch the high-level boxes: client, API, services, data store, cache, queue.
3. Pick the data model and storage, and justify SQL vs NoSQL. At a bank, default to SQL and have a reason to leave it, not the other way round.
4. Handle the hard parts: consistency, failure, idempotency. At a bank, say the words "audit log" and "idempotent payments" and watch the interviewer nod.
5. Talk scaling and trade-offs last.

The SC-favorite design prompt is payments-flavored.

• Classic prompts: URL shortener, rate limiter, notification service, and the house favorite, a money-transfer / ledger service.
• For the ledger one, lead with correctness, double-entry bookkeeping, and idempotency, not with "I'll shard the database."
• A candidate who opens a payments design with sharding has told the interviewer they do not understand what the system is for.
• Lead with "every transfer is two entries, a debit and a credit, that must commit atomically," and you have already passed.

6Behavioral and culture fit#

SC is serious about its values, and interviewers genuinely probe for them.

• The real ones: Do the right thing, Never settle, Better together.
• They map to integrity/compliance, continuous improvement, and collaboration.
• The brand promise, "here for good," is not just marketing to them.
• Interviewers are often given a scorecard that rates you against these, so a story that clearly lands on one does real work.

Prepare STAR stories (Situation, Task, Action, Result) for:

• A conflict with a teammate.
• A time you made a mistake.
• A tight deadline.
• A time you pushed back on something wrong.
• Your proudest project.
• Put a number in every Result, and write them out beforehand. A story you have said out loud once is twice as crisp as one you invent live.

One full worked example, for "tell me about a time you caught a serious problem":

• Situation: Two days before a release, I noticed our payment-retry logic could double-charge a user if the gateway timed out but actually succeeded.
• Task: I had to prove it was real, fix it, and not blow the release date.
• Action: I reproduced it in staging with a forced timeout, then added an idempotency key tied to the transaction ID so retries were safe, and wrote tests for the timeout path. I flagged it to my lead the same morning instead of quietly patching it.
• Result: We shipped on time with the fix, and over the next quarter we had zero duplicate-charge incidents, down from an estimated 6 to 8 per month on the old path.

Why that story works:

• It hits "do the right thing" (flagged it openly) and "never settle" (did not ship a known bug).
• It shows real engineering, not a vague feelings story.
• It happens to be a payments correctness story, exactly the judgment they want near their systems.
• The shape to copy: a concrete situation, a decision that shows character, a result with a number.

Also prepare the two questions you will ask them, and make them real.

• "What does the first six months look like for this role," or "how does the team handle a production incident," both signal you are picturing the job.
• A candidate with no questions looks like they want any paycheck, and that is a quiet ding.

7Your prep plan#

4-week plan:

• Week 1: DSA patterns 1 to 4 (arrays, strings, hashing, linked lists). 3 to 4 problems a day.
• Week 2: Trees, recursion, basic DP, binary search. Start SQL practice.
• Week 3: CS fundamentals grind (OOP, DBMS, OS, CN) + timed aptitude sets. One mock interview.
• Week 4: Design basics, behavioral STAR stories written out, two full mock loops, review SC values.

2-week plan:

• Week 1: Top patterns + SQL + CS fundamentals, 4 problems/day.
• Week 2: Aptitude timed sets, STAR stories, one mock, re-read the job description and mirror keywords.

2-day crash plan:

• Day 1: Re-solve 15 of your bookmarked medium problems. Drill SQL (second-highest salary, joins). Skim OOP + DBMS + OS + CN flashcards.
• Day 2: Write 5 STAR stories with numbers. Memorize the three SC values. Do one timed aptitude set. Sleep.

8Why people get rejected at Standard Chartered#

1. Coding in silence. Solved it but never explained it, so the interviewer could not score the thinking. Fatal. A correct answer the interviewer could not follow is a no-hire, because they cannot vouch for how you got there.
2. Weak CS fundamentals. Great on LeetCode, could not explain an index or ACID. At a bank this is disqualifying, because the whole job sits on databases and transactions.
3. Faking it. Claiming Kafka or microservices on the resume, then crumbling on a basic follow-up. Interviewers here dig, and dishonesty reads as a compliance risk, the one flag a bank will not overlook.
4. No SQL fluency. The job is data-heavy and people who freeze on a live query get cut. If writing a three-table join under mild pressure scares you, fix that before the loop.
5. Zero culture signal. A cold, purely technical interview with no sense of teamwork or ethics. SC weights fit heavily, and a brilliant engineer who seems like they would cut corners is a pass.
6. Asking nothing. No questions about the team or the role reads as wanting any paycheck. Have two real questions ready.

9The offer, comp and negotiation#

Rough 2026 ranges, base plus typical bonus. Treat these as ballpark and verify for your city and level:

• US: SWE base roughly $95k to $150k, senior above that, plus an annual bonus. Concentrated in NY/NJ.
• UK (London): SWE base roughly £45k to £80k, senior £90k+, plus bonus and solid benefits.
• India (Bengaluru/Chennai): SWE total comp roughly ₹8L to ₹28L depending on level, senior/lead higher.
• Canada: smaller presence, roughly CAD $80k to $120k base where they hire.

Banks pay fair but not FAANG-topping, and they know it.

• They compete on stability, benefits, work-life balance, and global mobility.
• Do not walk in expecting them to match a big-tech number, and do not sign expecting one either.
• What the slightly lower base buys you: a steadier job, a real pension or provident fund match, and the option to move between global offices.

Negotiation tips specific to SC:

1. Negotiate the band, not a dream number. SC uses structured salary bands. Ask the recruiter what band the role sits in and push toward the top of it with evidence (competing offer, current comp, specialized skill). You will not jump two bands by asking, but moving from the middle to the top of yours is very doable.
2. Use total comp, not just base. Bonus, pension/provident fund match, and benefits are real money here. Get the full picture before you counter, because the base can look modest until you add the match and the bonus target.
3. Be calm and specific. This culture rewards the right thing, not aggressive posturing. A polite, data-backed ask ("based on my current comp and the London market for this skill, I was hoping for X") lands better than a hardball. The same values they interviewed you on apply to how you negotiate, and a recruiter remembers the candidate who was reasonable.

10FAQ#

Is the Standard Chartered coding round hard? No. It is mostly easy to medium LeetCode. The difficulty is in communicating cleanly and nailing CS fundamentals, not in cracking hard algorithms. Nobody is going to ask you a hard dynamic-programming puzzle.

Do they ask system design? For senior roles, yes. For grads and junior SWEs, it is light or skipped in favor of CS fundamentals and DBMS/SQL. When it does come up, the payments and ledger flavor is the one to prepare.

What language should I code in? Java is the safest bet given their stack, Python is fine too. Use whatever you are fastest and cleanest in. The interviewer cares that your code is correct and readable, not which language it is in.

How long does the process take? Usually 2 to 5 weeks. Grad pipelines with an OA and a panel can run longer. If you go quiet for a week between rounds, that is normal for a bank, not a bad sign.

Do referrals really help? Yes, a lot. A referral gets your resume a human read instead of dying in the ATS. Ask anyone you know inside, even loosely.

Want this turned into a personalized, dated plan around your interview date? Map these rounds onto your calendar and work backward from day one.