Citi Coding Interview Questions: Engineering for a Global Bank

Citi is the brand of Citigroup Inc., and for an engineer its defining feature is geography. It operates in far more countries than most US banks, and much of its business serves multinational companies, financial institutions, and public-sector clients that need to move and manage money across borders - alongside markets businesses and, in the US, a large cards and retail banking franchise.

For an engineer, that means systems where "today", "a dollar", and "the end of the day" all depend on where you are standing. Amounts arrive in many currencies with different decimal rules, payments have cut-off times in local time zones, business days follow national holiday calendars, and the teams building one system can be spread across several continents. Candidates commonly describe a fundamentals-based coding bar; the follow-ups worth preparing for are the ones where a global assumption quietly breaks your solution. This guide covers those assumptions, the institutional and markets context, what to know when interviewing at a hub outside the US, and the problem types to prepare - patterns, not invented leaked prompts.

Citi and Citigroup: one firm, many countries

You will see Citi, Citigroup, and sometimes Citibank used in job listings and the news. Citigroup Inc. is the parent company, Citi is the brand it operates under, and Citibank, N.A. is its principal US bank subsidiary. The technology work spans broad, publicly described areas like these - a simplification, not an org chart:

Area and what the technology handles	The global wrinkle
Treasury, payments, and trade for institutions. Cash management, cross-border payments, liquidity, and trade finance for corporate and institutional clients - the territory of Citi's Treasury and Trade Solutions business.	Many currencies, local clearing systems and cut-offs, and message standards such as ISO 20022
Markets. Trading, pricing, and risk across products such as foreign exchange, rates, and equities.	Positions in many currencies, market data from many venues, and end-of-day in several time zones
Securities services. Custody, fund services, and the records of who holds what.	Reconciling records with other firms and with markets that settle on different schedules
US personal banking. Cards, retail banking, and the digital channels customers use.	Volume, fraud controls, and availability, mostly within one country's rules
Enterprise platforms. Infrastructure, data, security, and controls shared across the firm.	Multi-region deployment, access control, and where data is allowed to live

Currencies, time zones, and borders: the assumptions that break

This is the part of Citi preparation most worth rehearsing, because the mistakes are invisible from a single-country point of view. You do not need to be a payments specialist; you need to ask the right clarifying question before you write code.

Currencies are not all the same shape

Not every currency has two decimal places. Under the ISO 4217 standard, the Japanese yen has no minor unit and the Kuwaiti dinar has three, so code that assumes cents is wrong for both. Keep amounts in integer minor units or a decimal type, never binary floating point; know which exchange rate you are using, in which direction, and as of when; and ask where rounding happens, because rounding each line and rounding the total can give different answers.

Time zones, cut-offs, and business days

Store timestamps in UTC and convert at the edges. A payment's processing date can depend on a cut-off time in local time, weekends are not the same days in every country, and each country has its own holiday calendar - a foreign-exchange transaction usually needs a settlement date that is a business day for both currencies. Daylight saving time also changes on different dates in different countries, so "London is five hours ahead of New York" is only usually true.

Data that has to stay put

Some jurisdictions restrict where certain customer data can be stored or processed. In a design conversation, that turns "replicate everything to every region" into a real trade-off: which data can move, which must stay in-country, and how a combined global view is assembled without copying what it should not.

Many languages and formats

Names, addresses, and free-text fields arrive in many scripts, so treat text as Unicode and never assume ASCII. Number and date formats differ too: 1.234,56 and 1,234.56 can be the same amount, and 03/04 is a different date in New York and London. Parsing problems are an easy place to show you have thought about this.

Teams across time zones

A system built by engineers in several regions depends on handoffs, clear written communication, and documentation someone can act on while you are asleep. Behavioral stories about collaborating across locations and time zones are worth preparing, and our STAR examples guide can help you structure them.

Institutional and markets technology

Much of Citi's business serves institutions rather than individuals: companies managing cash across many countries, banks and asset managers, and trading clients. Individual transactions can be very large, clients often connect their own systems directly to the bank, and a single error can be expensive, so the bar for correctness, auditability, and reconciliation is high. Topics worth preparing for this world:

• Reconciliation. Two systems, two regions, or the bank and a counterparty each hold a record, and every item must match or be explained.
• Message processing. Payment and trade instructions arrive as structured messages that must be validated, routed, and never processed twice.
• As-of reporting. What a balance or position was at a specific moment, in a specific currency, using the rates that applied then.
• Latency where it matters. Some markets roles care about speed down to individual data structures, while many institutional roles care more about throughput and correctness. Ask which kind of team you are joining.

A design scenario that fits this world well is a consolidated cash view for a multinational client: balances held in many countries, shown in one reporting currency. The dashboard is the easy part. The interesting questions are which exchange rates to use and from what time, what to show when one region's data has not arrived yet, how to label figures that are stale, and which data is allowed to leave its country for the combined view. For the underlying building blocks - replication, caching, queues, and consistency - our system design reference is a compact review.

How the process tends to run

Reported processes vary by country, business, and level, but they tend to include stages like these:

• Application and recruiter or HR screen. Background, motivation, location, and logistics.
• Online assessment. More common in early-career hiring and used in some experienced pipelines: timed coding problems, sometimes alongside other question formats.
• Technical interviews. Coding in a shared editor or a conversation about code, plus your primary language, SQL, and the projects on your resume.
• Design and hiring-manager conversations. For experienced roles, a design discussion scaled to your level and a conversation about how you work, often with the hiring manager.
• Decision. Feedback is gathered and the recruiter follows up.

Interviewing for a technology hub outside the US

Citi's technology workforce is spread well beyond the US. It has long-established technology centres in places such as Belfast and the Indian cities of Pune and Chennai, and its careers site lists technology roles in many other cities, including Dublin, across Europe, Asia, and the Americas. Locations and team mix change, so rely on current postings rather than any list, including this one. If you are interviewing for a role outside the US, a few things are worth confirming:

• Which pipeline you are in. Early-career hiring in particular tends to run by country, with its own program names, timelines, and stages, so check the careers site for your region.
• What the title means. Citi listings have often used titles such as Applications Development Programmer Analyst for software engineering roles - with words like Intermediate, Senior, or Lead signalling level - alongside plainer titles such as Software Engineer. Read the responsibilities, not just the title.
• Where the team sits and who it works with. A team in one city may work daily with colleagues in other regions, which shapes both the job and the interview conversation.
• The time zone for every interview. Confirm each slot in writing, including the time zone, especially if interviewers join from another region.

What to study for a Citi software engineer interview

• Arrays, strings, and hash maps. Still the highest-yield block: grouping, matching, and deduplication.
• Sorting and two pointers. Matching two sorted record sets is the core of many reconciliation problems.
• Intervals and time. Overlapping windows, cut-offs, and conversions between time zones.
• Graphs. Traversal and path-finding - converting between currencies through available rate pairs is a classic graph problem.
• Heaps and top-K. Largest exposures, most active accounts, or the next deadline.
• SQL and data modelling. Amount and currency stored as a pair, rate tables with effective dates, as-of joins, and totals by region and business date.
• Your primary language. The one the posting names, including its decimal and date-time libraries, which matter more here than in most interviews.
• Distributed systems basics (experienced roles). Replication across regions, failover, consistency trade-offs, and data residency constraints.

Representative problem types

Described as categories so you prepare the pattern rather than a single prompt:

• Multi-currency aggregation. Total positions held in several currencies into one reporting currency, with the right decimal rules and a stated rounding policy.
• Cut-offs and business dates. Assign each transaction to a processing date given a UTC timestamp, a local cut-off, weekends, and a holiday calendar.
• Reconciliation. Match records from two sources and report what is missing, duplicated, or mismatched in amount or currency.
• Currency conversion paths. Given exchange rates between some currency pairs, compute the rate between two currencies that are not directly quoted.
• Check-digit validation. Validate an identifier with a checksum, such as the mod-97 check used by IBANs.
• Locale-aware parsing. Parse amounts and dates written in different regional formats, rejecting ambiguous input rather than guessing.
• SQL on multi-currency data. The latest rate for each currency pair as of a timestamp, totals by region and business date, or records present in one table but not another.
• Practical design. The consolidated cash view above, a cross-border payment status tracker, or a service deployed across regions with data that must stay in-country.

Here is the flavour of problem that fits a global team - totalling amounts held in different currencies into one reporting currency, without the silent errors that come from assuming every currency has cents.

from decimal import Decimal, ROUND_HALF_EVEN

# ISO 4217 minor-unit digits for the currencies used here
MINOR_DIGITS = {"USD": 2, "EUR": 2, "GBP": 2, "JPY": 0, "KWD": 3}

def total_in(report_ccy, amounts, rates):
    """amounts: list of (currency, integer amount in that currency's minor units).
    rates: currency -> Decimal units of report_ccy per 1 unit of that currency.
    Returns the total in report_ccy minor units, rounded once at the end."""
    total = Decimal(0)
    for ccy, minor in amounts:
        major = Decimal(minor).scaleb(-MINOR_DIGITS[ccy])      # 1234 JPY stays 1234; 1234 USD cents -> 12.34
        rate = Decimal(1) if ccy == report_ccy else rates[ccy]  # missing rate: KeyError, never a silent skip
        total += major * rate
    digits = MINOR_DIGITS[report_ccy]
    rounded = total.quantize(Decimal(1).scaleb(-digits), rounding=ROUND_HALF_EVEN)
    return int(rounded.scaleb(digits))

The strong answer explains the choices. Amounts arrive as integer minor units and are converted using each currency's own exponent, so 1,234 yen stays 1,234 yen rather than becoming 12.34. All arithmetic uses decimals rather than floats, the rate direction is documented, and a missing rate raises an error instead of being skipped - a silently dropped currency is the worst kind of wrong total. Rounding happens once, at the end, with banker's rounding, and the candidate says out loud that the business owns that rule and that rounding each line instead could produce a slightly different total. Then name what is missing: every rate should carry a source and a timestamp so the result can be reproduced later, and a production version would read minor-unit rules from reference data rather than a hard-coded table.

What interviewers actually score

• Clarifying global assumptions. Which currency, which time zone, and whose business day - asked before writing code.
• Correctness with money and time. Decimal or integer amounts, UTC storage, and explicit rounding.
• Completeness. Every record accounted for, with mismatches reported rather than dropped.
• Resilience across regions. What happens when one region's data is late, a link between regions fails, or a feed arrives twice.
• Clear communication. Precise spoken and written explanations, since colleagues may review your work from another continent.
• Collaboration. Stories about working across teams, locations, and time zones, told with a clear structure.

A note on integrity: prepare thoroughly and reason honestly in the room. Global edge cases are exactly where a memorised answer falls apart, and "I would confirm the rounding rule with the business" earns more respect than a confident guess.

Citi versus other large-bank interviews

Each large bank has a different centre of gravity. At JPMorgan Chase, the first question is which line of business and track you are joining, which our JPMorgan guide covers. Morgan Stanley candidates often divide their prep between markets technology and wealth-management platforms, with a lot of language depth - see our Morgan Stanley guide. The distinctive thing to prepare for at Citi is the global footprint: currencies, time zones, and borders built into everyday systems, institutional clients who need precise answers, and teams that are often spread across regions.

A realistic two-week prep plan

1. Days 1-2: Confirm the business area, where the team is based, and what each stage covers. Reread the posting for the language and domain, and note the time zone of each interview.
2. Days 3-6: Core patterns - arrays, strings, hash maps, sorting, two pointers, and intervals - with deliberate clarifying questions about currency, time zone, and format.
3. Days 7-8: Money and time in your language: decimal types, rounding modes, time-zone conversion, and business-day logic. Then SQL with as-of joins and effective-dated rate tables.
4. Days 9-11: Graph and reconciliation problems, then design rehearsal: the consolidated cash view and a service deployed across regions, each explained with failure cases and data residency in mind.
5. Days 12-14: Behavioral STAR stories about working across locations and teams, then a timed mock that ends every problem with "what changes if this runs in three regions and five currencies?"

FAQ

How hard are Citi coding interview questions?

Candidates generally describe a fundamentals-based bar, with most reported coding problems in the LeetCode easy-to-medium range. The follow-ups that set candidates apart tend to involve global assumptions: currencies with different decimal rules, time zones and cut-offs, and data that must reconcile across systems. A correct, clearly explained solution that handles those cases usually matters more than a rare algorithm.

Is Citi the same company as Citigroup?

Yes. Citigroup Inc. is the parent company and Citi is the brand it operates under, while Citibank, N.A. is its principal US bank subsidiary. You will see all three names in job listings and the news, and they all refer to the same group of companies.

What topics should I study for a Citi software engineer interview?

Cover core data structures and algorithms first: arrays, strings, hash maps, sorting, two pointers, intervals, heaps, and basic graphs. Then add SQL and data modelling, including effective-dated tables and as-of queries, plus decimal arithmetic and time-zone handling in the language named in the posting. Experienced candidates should also prepare multi-region design, reconciliation, and data residency trade-offs.

How does Citi's global footprint show up in technical interviews?

Mostly through the assumptions your solution makes. Be ready to handle currencies that do not have two decimal places, cut-off times in local time zones, different weekends and holiday calendars, international text and number formats, and systems that span regions with rules about where data can be stored. Asking about these before you code is a strong signal.

Can I interview for Citi technology roles outside the US?

Yes. Citi's technology workforce is spread well beyond the US, with long-established technology centres in places such as Belfast, Pune, and Chennai, and its careers site lists technology roles in many other cities, including Dublin, across Europe, Asia, and the Americas. Processes, program names, and timelines vary by country, so check the listing for your region and confirm each stage with your recruiter.