Bank Software Development Interview Guide: Java, MySQL, Thread Pools, HTTP, TCP/UDP, and Database Indexes

This article compiles common technical interview questions for bank software positions, covering Java fundamentals, MySQL storage engines and indexes, thread‑pool parameters, HTTP GET/POST differences, TCP vs UDP characteristics, session and cookie handling, Redis data types, and C++ memory management, providing concise explanations and examples for each topic.

IT Services Circle
IT Services Circle
IT Services Circle
Bank Software Development Interview Guide: Java, MySQL, Thread Pools, HTTP, TCP/UDP, and Database Indexes

Previously a student asked how to prepare for a bank software development interview and what the difficulty level is. Bank interviews differ from internet companies by adding structured and leaderless discussion rounds to assess soft skills, while the technical part still focuses on Java, MySQL, and networking basics.

Postal Savings Bank

Abstract Class vs Interface

Similarities:

Both cannot be instantiated directly; a subclass must implement all abstract members before it can be instantiated.

Differences:

Implementation keyword: implements for interfaces, extends for abstract classes. A class can implement multiple interfaces but extend only one abstract class.

Method definitions: Interfaces (pre‑Java 8) have no method bodies, while abstract classes can contain both abstract and concrete methods.

Access modifiers: Interface members are implicitly public static final (variables) and public abstract (methods). Abstract class members have default package visibility and can be overridden.

Variables: Abstract classes can have instance and static variables; interfaces can only have constants.

Thread‑Pool Parameters

A thread pool reduces the overhead of creating and destroying threads. It consists of core threads, a maximum size, and a work queue. When a task is submitted, a new thread is created if the core pool is not full; otherwise the task is queued, and if the queue is full a new thread is created up to the maximum size, after which a rejection policy is applied.

The constructor has seven parameters:

corePoolSize : number of core threads.

maximumPoolSize : maximum number of threads.

keepAliveTime : idle time before excess threads are terminated.

unit : time unit for keepAliveTime.

workQueue : queue that holds waiting tasks.

threadFactory : creates new threads (e.g., naming).

handler : rejection policy when the queue is full.

GET vs POST

According to RFC, GET retrieves a resource and places parameters in the URL (ASCII‑only, length limited by browsers). Example: opening an article triggers a GET request.

POST sends data in the request body, allowing any format and no length restriction. Example: submitting a comment at the bottom of an article.

HTTP Statelessness

HTTP itself is stateless; it does not maintain session state. State management is typically achieved with cookies and server‑side sessions.

Session vs Cookie

Scope: Cookie stored on client, Session stored on server.

Data type: Cookie only ASCII, Session can store any object.

Lifetime: Cookie can be long‑lived; Session expires when the browser closes or after a timeout.

Privacy: Cookie is client‑side and easier to steal; Session is server‑side and more secure.

Size: Cookie ≤ 4 KB, Session size is only limited by server memory.

MySQL Storage Engines

MySQL mainly provides MyISAM and InnoDB.

Transaction support: InnoDB supports transactions, MyISAM does not.

Foreign keys: Only InnoDB supports them.

Index & data storage: InnoDB uses clustered B+Tree indexes; MyISAM stores data and indexes in separate files.

Crash recovery: InnoDB can recover from crashes; MyISAM cannot.

Indexes

An index is a data structure that speeds up data retrieval, essentially a “catalog” of the table.

By data structure: B+Tree, Hash, Full‑text.

By physical storage: Clustered (primary) and secondary indexes.

By field characteristic: Primary, unique, normal, prefix.

By field count: Single‑column and composite indexes.

Industrial and Commercial Bank

Procedural vs Object‑Oriented

Abstraction: Procedural focuses on functions, OOP on objects.

Encapsulation: OOP bundles data and methods with access modifiers.

Inheritance & Polymorphism: OOP provides these for reuse and flexibility.

TCP vs UDP

1. Connection

TCP is connection‑oriented; UDP is connection‑less.

2. Service object

TCP is one‑to‑one; UDP supports one‑to‑many and many‑to‑many.

3. Reliability

TCP guarantees reliable delivery; UDP provides best‑effort delivery.

4. Congestion & flow control

TCP has both; UDP has none.

5. Header overhead

TCP header = 20 bytes (more with options); UDP header = 8 bytes.

6. Transmission mode

TCP is stream‑oriented; UDP is packet‑oriented.

Typical TCP use cases: FTP, HTTP/HTTPS. Typical UDP use cases: DNS, SNMP, video/audio streaming, broadcast.

Database Consistency

Consistency means that a transaction transforms the database from one valid state to another, preserving all integrity constraints.

How Consistency Is Achieved

Persistence via redo log.

Atomicity via undo log.

Isolation via MVCC or locks.

Consistency is the combination of the three.

Transaction Isolation Levels

Read Uncommitted : dirty reads possible.

Read Committed : no dirty reads, but non‑repeatable reads and phantom reads may occur.

Repeatable Read (default in InnoDB): no dirty or non‑repeatable reads, phantom reads possible.

Serializable : prevents dirty, non‑repeatable, and phantom reads.

Ordering from weakest to strongest: Read Uncommitted → Read Committed → Repeatable Read → Serializable.

MySQL Default Isolation

Repeatable Read.

Redis Basic Data Types

String, Hash, List, Set, Sorted Set (Zset).

Redis Newer Types

Bitmap (2.2)

HyperLogLog (2.8)

GEO (3.2)

Stream (5.0)

China CITIC Bank

C++ Heap vs Stack

Allocation method

Stack: automatically allocated (e.g., int b).

Heap: manually allocated via malloc or new (e.g., p1 = (char *)malloc(10); or p2 = new char[20];).

Response after allocation

Stack: allocation succeeds if enough space remains; otherwise stack overflow.

Heap: OS finds a free block, splits it if larger, and returns the address; excess space is returned to the free list.

Size limits

Stack: limited to a few MB; overflow if exceeded.

Heap: limited by virtual memory; generally larger and more flexible.

Lifecycle

Stack memory is released automatically when the variable goes out of scope.

Heap memory must be released manually with delete / delete[] or a memory‑leak detector.

C++ Compilation Process

The process consists of preprocessing, compilation, assembly, and linking.

Preprocessing: expands macros, handles #include, removes comments.

Compilation: converts preprocessed source to assembly, performs lexical, syntax, and semantic analysis.

Assembly: turns assembly into object files.

Linking: resolves symbols, combines object files and libraries into an executable.

Preventing Memory Leaks

Use smart pointers ( std::shared_ptr, std::unique_ptr) which follow RAII, or employ tools like Valgrind to detect leaks.

MySQL Hash Index vs B+Tree Index

Structure: Hash uses a hash table; B+Tree uses a balanced tree.

Lookup: Hash O(1) exact match; B+Tree O(log N) range and exact queries.

Range queries: Supported by B+Tree, not by hash.

Different storage engines support different index types (InnoDB, MyISAM, Memory). InnoDB (default since 5.5) uses B+Tree indexes.

Index Invalidations

Six common cases that cause an index to become unusable:

Leading wildcard LIKE %xx or LIKE %xx%.

Applying a function to an indexed column.

Using expressions on an indexed column.

Implicit type conversion (e.g., comparing a numeric column with a string literal).

Violating the left‑most prefix rule on composite indexes.

Using OR where one side uses an indexed column and the other does not.

Row‑Level Lock Implementation

InnoDB supports row‑level locks; MyISAM does not. Locking reads ("lock‑in‑share" or "for update") must be executed inside a transaction.

// Shared lock on read
select ... lock in share mode;

// Exclusive lock on read
select ... for update;

Locks are released when the transaction commits.

Record Lock: locks a single row (S‑type shared, X‑type exclusive).

Gap Lock: locks a range between rows, used to prevent phantom inserts.

Next‑Key Lock: combination of Record Lock + Gap Lock.

Record Lock

S‑type locks are compatible with other S‑type locks but not with X‑type.

X‑type locks are exclusive.

Example:

mysql> begin;
mysql> select * from t_test where id = 1 for update;
Gap Lock

Exists in Repeatable Read isolation to prevent phantom reads. Example: a gap lock on (3,5) prevents insertion of id = 4.

Next‑Key Lock

Locks both the record and the surrounding gap; prevents both updates to the record and inserts into the gap.

Thus, row‑level locking in InnoDB is achieved through a combination of Record, Gap, and Next‑Key locks, each with its own compatibility rules.

Original Source

Signed-in readers can open the original source through BestHub's protected redirect.

Sign in to view source
Republication Notice

This article has been distilled and summarized from source material, then republished for learning and reference. If you believe it infringes your rights, please contactadmin@besthub.devand we will review it promptly.

JavaThreadPoolTCPmysqlHTTPC++DatabaseIndex
IT Services Circle
Written by

IT Services Circle

Delivering cutting-edge internet insights and practical learning resources. We're a passionate and principled IT media platform.

0 followers
Reader feedback

How this landed with the community

Sign in to like

Rate this article

Was this worth your time?

Sign in to rate
Discussion

0 Comments

Thoughtful readers leave field notes, pushback, and hard-won operational detail here.