Candidates describe a loop of four stages that can stretch over several weeks, with gaps between rounds. It starts with a screening that is often a video call, moves to technical assessments, then to interviews with managers or team panels, and ends with behavioral interviews centred on professional presentation and consistency. The process is reported to vary by location and by team, so ask your recruiter in writing what each stage covers and which language it will run in.
The technical topics candidates report are network security (including the kinds of attacks seen against banking systems), programming, data structures, technical problem solving and walkthroughs of past projects. The reported question list is made of knowledge and experience questions: attack types, whether you have used Angular, your system administration and IT security background, how you manage a project, and the hardest problem you have solved. Candidates also mention coding challenges and design scenarios, so keep one session for data structures and code you can write cleanly. The requirements candidates describe also list database management, and the role involves integrating with legacy systems, so be ready to talk about SQL, schema decisions and safe changes to code you did not write.
Communication carries as much weight in the reports as technique. Candidates describe resume-based questioning in which every line of the CV can be examined, impromptu speech tasks on a topic you are handed, and interviews conducted in Mandarin in some regions. That makes the preparation spoken: rehearse a self-introduction, a reason for choosing banking and two project stories out loud, in the language of the interview, and keep the facts identical from round to round because consistency is the stated focus of the final stage.
Initial Screening
reportedCandidates report that the process opens with an initial screening, often held over a video call. It is the first time your CV and your motivation for banking are heard, so approach it as a clear, composed account of who you are, what you have built and why you want this role in a bank rather than any software job. Test your camera, audio and connection beforehand, and keep a one-page summary of your CV within reach so every date, employer and technology you state matches the document you submitted.
What to demonstrate
- Clear, professional self-presentation over video
- A spoken account of your background that matches your CV line by line
- A reasoned motive for working in banking and in this role
How to prepare
- Write and rehearse a spoken self-introduction and a reason for choosing Bank of China, in the language the screening will use.
- Reread every line of your CV and prepare one sentence of detail for each project, tool and course it lists.
- Ask the recruiter in writing which stages follow, their format and the interview language, since candidates report variation by location.
Technical Assessments
reportedCandidates report technical assessments meant to test your skills. The topics they list for the loop are network security and attacks on banking systems, programming, data structures, technical problem solving and the technologies in your past projects, with coding challenges and design scenarios also mentioned. Expect depth on how and why you chose a technique, so prepare explanations with a defence for each point (an attack paired with a countermeasure, a data structure paired with its cost), and treat anything on your CV as something to explain in detail.
What to demonstrate
- Working knowledge of network security and the attacks seen against banking systems
- Programming and data-structure fundamentals applied to a problem
- Hands-on detail about the frameworks and tools in your projects
How to prepare
- Write a one-page table of attack classes against a bank (phishing, credential stuffing, man-in-the-middle, DDoS, SQL injection, session hijacking) with how each works and one defence.
- Practise a few data-structure problems in your strongest language, using PracHub's practice set on streams, graphs and ordered data, and explain complexity aloud.
- For each framework on your CV, such as Angular, prepare what you built, a component or data-flow decision you made and a bug you fixed.
Manager Interviews
reportedCandidates report multiple rounds of interviews with managers or team panels. These are described as resume-based, covering project management, the projects you completed in studies or work, and how you collaborate with project managers, security teams and business analysts. Prepare two projects you can narrate end to end, with your own contribution separated from the team's, and a short method for running a project that you can describe with a real example.
What to demonstrate
- Ownership and detail on the projects listed on your CV
- Ability to explain technical ideas to non-technical colleagues
- Handling several streams of work at once while keeping quality
How to prepare
- Write a project story using situation, your decisions, the result and what you would change, for two projects, and say which parts were yours.
- Prepare a project-management answer with a concrete sequence: scope, breakdown, tracking, risk handling and how you report progress.
- Practise explaining one technical concept, such as TLS or database indexing, to a business analyst without jargon.
Behavioral Scrutiny
reportedCandidates describe the final stage as behavioral interviews focused on professional presentation and consistency, sometimes with an intense, semi-structured feel. Impromptu speech tasks, where you speak on a topic you are given, are also reported in the process. Approach this stage as a test of staying composed and coherent: keep the same facts and the same story you gave earlier, and organise any unprepared answer into an opening, a few supporting points and a closing line.
What to demonstrate
- Consistency between your answers here, your CV and earlier rounds
- Professional presentation and a respectful, composed tone
- Structured thinking when speaking on a topic you did not prepare
How to prepare
- Keep a one-page fact sheet of your stories (dates, roles, numbers, outcomes) and check every answer against it.
- Practise impromptu speeches on general topics such as a current industry trend, using an opening, a few points and a closing line.
- Rehearse the career-goals, hardest-challenge and why-this-bank answers until they agree with each other and with your self-introduction.
PracHub editorial advice for the preparation topics above.
Listing a framework or tool on the CV (Angular, a database, a security tool) that you cannot explain beyond its name
Candidates report line-by-line CV questioning. Remove anything you cannot defend, and for each item you keep, prepare what you built, one design decision and one bug you fixed.
Answering the network attacks question with a list of names and no defences
Pair each attack with how it works against a bank and one control that stops it, for example credential stuffing with rate limiting and multi-factor authentication. Practise saying it aloud, not just reading it.
Telling project stories entirely in the team's voice, so your own decisions are invisible
For each project say what you owned, what you decided, what went wrong and what the result was. Prepare this for the project walkthrough, the project-management question and the hardest-challenge question.
Giving a why-this-bank or career-goals answer that could be given to any employer
Name concrete reasons tied to banking engineering and this role, use the scale and reputation of the institution as only one of them, and link each goal to something the job offers.
Contradicting yourself between rounds, or freezing on an impromptu topic
Keep a fact sheet of dates, roles and outcomes and check every story against it. For impromptu speaking, use an opening, two or three supporting points and a closing line, and practise on random topics aloud.
Choose a category, try a prompt, then open its approach, worked solution or follow-up when you need it.
Identify the heaviest tenants in a five-minute window under memory pressure
The edge service handles about 3,000 requests per second across roughly 50,000 tenants, peaking near 9,000. Expose the 50 heaviest tenants by request count over the trailing five minutes so limits can be tightened before one tenant's backfill starves the fleet. You may not retain five minutes of raw records. Give the exact solution and its memory, then the bounded-memory approximation with its error stated as a formula, and say which you would ship and at what tenant cardinality that choice changes.
Approach
- Do the exact version first, because it is affordable at this cardinality: a ring of 300 one-second counters per tenant, advanced lazily, is 1,200 bytes of counters per tenant and roughly 60 to 90 MB for 50,000 tenants with overhead. Carry a running total and subtract the bucket you overwrite so a window read is O(1) rather than 300 adds.
- Extract the top 50 with a size-k min-heap over the tenant sums: O(d log k) for d tenants, against O(d log d) to sort them all. Maintaining the heap continuously instead of on query requires a tenant-to-heap-index map, because incrementing a count already inside the heap means sifting from a known position, and without that map you rebuild the heap on every request.
- State the approximation precisely rather than gesturing at sketches. Misra-Gries with m counters retains every item whose true count exceeds N/(m+1), and each retained count underestimates the truth by at most N/(m+1). With m = 1,000 and N = 900,000 requests in the window the error is roughly 900 requests, which is fine for spotting a tenant sending 50,000 and useless for ranking two tenants 200 apart.
- Say what breaks when the window slides: Misra-Gries and Space-Saving are insert-only and cannot be decremented as records age out. The workable construction is one summary per sub-window, say ten seconds, with 30 summaries merged at query time, and the merged error is the sum of the per-summary errors, so the bound degrades linearly in the number of sub-windows.
Follow-up
- The heaviest tenant is heavy because of one export job rather than user traffic. Should the limiter treat those as the same tenant?
- Two tenants sit tied at the boundary of the top 50. Does your answer flap, and does the flapping matter?
Merge partitioned event streams into one ordered feed with bounded lateness
The read-model service consumes 64 log partitions carrying about 4,000 events per second in total. Each partition is ordered within itself, but partitions drift by up to 30 seconds, and the activity feed must present a tenant's events in occurred_at order. Produce the merge. State its complexity, the buffer it requires in events and in bytes, what happens when one partition is idle, and what you do with an event that arrives after you have already emitted its position. Payloads average 1 KB.
Approach
- Merge with a min-heap over the 64 partition heads keyed on (occurred_at, event_id): O(log P) per event and O(n log P) overall. The tie-break on event_id is what makes the output deterministic when two partitions carry the same millisecond, which matters because the feed is paginated and a non-deterministic order reorders pages under the reader.
- Emitting the heap head is only correct once every partition has produced everything up to that timestamp, so the emit condition is a watermark: the minimum across partitions of the highest occurred_at seen, less the allowed lateness. Events are held until the watermark passes them, which is what turns individually ordered streams into a jointly ordered one.
- Size the buffer from the lateness rather than guessing: 4,000 events per second times 30 seconds is 120,000 buffered events, and at 1 KB each about 120 MB of heap. That number is the real price of the ordering guarantee and belongs in front of whoever asked for it.
- Handle the idle partition explicitly, because it fails the feed rather than corrupting it: a partition with no traffic never advances its own maximum, so the watermark freezes and output stops entirely. Either every partition emits a periodic idle marker carrying the broker's current time, or the watermark falls back to wall clock for a partition silent beyond a threshold.
Follow-up
- The lateness budget is raised to five minutes. What is the new buffer, and what besides memory changes?
- The consumer restarts. Where does it resume from, and what does the feed look like for the first 30 seconds?
Archive a resource graph without breaking live references or recursing
Resources reference other resources within a tenant; for the largest tenant the reference table holds up to 2,000,000 nodes and 8,000,000 edges. Archiving a resource must archive everything reachable from it that nothing outside the set still references, refuse when a live external referrer exists, and terminate when references form cycles, which they legitimately do. Produce the archive order and the refusal list, targeting O(V+E). Say what stops the traversal crossing a tenant boundary, and why recursion is the wrong control structure at this size.
Approach
- Load the subgraph with the tenant predicate on both endpoints of the edge, not only on the side you started from. Scoping the left table alone is the classic cross-tenant leak: one mis-entered edge then pulls another tenant's resources into the traversal and, worse, into the archive.
- Traverse iteratively with an explicit stack. A 2,000,000-node graph can hold a chain deep enough to exhaust a native stack in the low tens of thousands of frames, and that failure is a process crash rather than an error you can return.
- Treat cycles as data rather than corruption: compute strongly connected components with Tarjan in O(V+E) using its own explicit stack, then condense. The condensation is a DAG, so a topological order over it gives the archive order, and every member of a component archives in one transaction because no order within a cycle is valid.
- Decide refusals with reverse edges. A candidate is archivable only if every in-edge originates inside the candidate set, so build the transpose or count in-degrees restricted to the visited set, and emit each blocked resource with the id of the external referrer, which is the only part of the answer an operator can act on.
Follow-up
- The graph is read in one query and the archive writes a minute later. What can change in between, and how do you make the write safe?
- The candidate set is 400,000 resources. Is that one transaction, and if not, what does a half-finished archive look like to a reader?
Stop tag and share joins from fanning out a page
resource_tag is (resource_id, tag_id) with PK (resource_id, tag_id); resource_share is (resource_id, shared_with_user_id, permission). The tagged-and-shared listing inner-joins resource to both, filters tenant_id, tag_id = ANY($2) and shared_with_user_id = $3, orders by updated_at DESC and takes 50. Pages come back with fewer than 50 distinct resources and the total in the header is far too high. Explain the row multiplication, rewrite both the page query and the count query so each is correct, and name the index each one needs. PostgreSQL 16.
Approach
- Do the arithmetic against the predicates that are actually there. An inner join emits one row per matching child row, and both joins are filtered: tag_id = ANY($2) admits only the requested tags, shared_with_user_id = $3 admits one user's share rows. So a resource holding three of the requested tags and shared with $3 once yields three rows, not one — the multiplier is its count of matching tags times its share rows for that single user, and that second factor is 1 unless the table admits duplicate (resource_id, shared_with_user_id) pairs. LIMIT 50 then limits rows rather than resources, and COUNT(*) counts pairs — the header is the product, not the population.
- Reject DISTINCT as the fix. It deduplicates after the product has been built, so the planner must materialise and sort the fanned-out set before the LIMIT can apply, and it leaves any SUM or AVG in the same select list wrong.
- Rewrite both filters as semi-joins, keeping resource as the only row source: AND EXISTS (SELECT 1 FROM resource_tag rt WHERE rt.resource_id = r.resource_id AND rt.tag_id = ANY($2)) and the same shape against resource_share. A semi-join stops at the first match per resource and preserves the driving index order, so ORDER BY updated_at DESC, resource_id DESC LIMIT 50 still stops after 50 rows.
- Count with the same predicates and no join at all: SELECT count(*) FROM resource r WHERE r.tenant_id = $1 AND r.status = 'active' AND EXISTS (...) AND EXISTS (...). Nothing multiplies a resource, so the number is the population.
Follow-up
- The filter changes from 'any of these tags' to 'all of these tags'. Rewrite it and state what it costs relative to the ANY form.
- A resource can be shared with the same user twice under different permissions. Does your count change, and should it?
Write the update path that detects a concurrent edit
resource carries version INT NOT NULL DEFAULT 1. resource_revision holds revision_id, resource_id, version, actor_user_id, change_kind, patch JSONB, request_id, created_at with UNIQUE (resource_id, version). outbox_event holds aggregate_type, aggregate_id, aggregate_version, event_type, payload, status. A PUT carries the version the client read. Write the exact statements for the single transaction that applies the edit, records the revision and enqueues 'resource.updated', and give the handler's branch on zero affected rows. Then say what PostgreSQL 16 does under READ COMMITTED when two of these updates hit one row at once.
Approach
- One transaction, three writes, no network call inside it: UPDATE resource SET title = $3, version = version + 1, updated_at = now() WHERE resource_id = $1 AND tenant_id = $4 AND version = $2; then INSERT the resource_revision row at version $2 + 1; then INSERT the outbox_event row at the same aggregate_version. The event goes to a table rather than a broker because no transaction spans both.
- Branch on the affected-row count before doing anything else. Zero has three causes — stale version, wrong tenant, row gone — so re-read once and map to 409 carrying the current version, or 404 for an id outside the caller's tenant, which also stops the endpoint confirming that another tenant's id exists.
- State the engine behaviour instead of assuming it. Under READ COMMITTED the second UPDATE blocks on the row lock, and when the first commits PostgreSQL re-evaluates the WHERE clause against the newly committed row, so the version predicate now fails and the statement reports zero rows. Under REPEATABLE READ the identical collision raises SQLSTATE 40001 instead, so the handler must fold both shapes into one conflict response.
- Keep UNIQUE (resource_id, version) even though the predicate already serialises writers. It is what makes a lost update unwritable if any other path ever reaches the revision table, and it converts a logic bug into 23505 rather than into a silently missing history row.
Follow-up
- A client sends the version it read ten minutes ago and the resource has moved three versions. What is in your 409 so it can resolve the conflict without a full re-fetch?
- Two editors, two disjoint fields, no overlap. Does your answer still refuse the second write, and should it?
What types of network attacks are commonly seen in banking systems?
What types of network attacks are commonly seen in banking systems?
Approach
- Organise the answer by layer so it doesn't turn into a random list. Network: DDoS (volumetric UDP floods, SYN floods, application-layer HTTP floods). Transport and session: man-in-the-middle, TLS stripping, session hijacking. Application: SQL injection, XSS, CSRF. Identity: phishing and credential stuffing that lead to account takeover.
- Give each attack its mechanism and a matching control. SYN cookies and upstream scrubbing for SYN floods. Rate limits and a WAF for HTTP floods. TLS 1.2+ with HSTS (plus preload, which covers the first visit) against stripping. Parameterised queries for injection. Output encoding and a Content-Security-Policy for XSS. SameSite cookies or anti-CSRF tokens for CSRF.
- Treat credential stuffing as the attack aimed most directly at bank customers: attackers replay leaked username/password pairs at the login endpoint. The defences are MFA, checks against breached-password lists, rate limits per account and per source IP or ASN, device fingerprinting, and step-up authentication for risky logins or transfers.
- Cover the internal side as well: lateral movement after one host is compromised, ARP or DNS spoofing inside the network, and insider access. Controls are network segmentation, mutual TLS between services, least-privilege service accounts, and IDS/IPS plus central logging that alerts on unusual east-west traffic.
- Finish with the trade-off. Every control adds friction or latency: aggressive rate limits lock out real customers, and MFA on every action hurts usability. Say how you would tune that, for example risk-based step-up only on new devices or high-value transfers.
Follow-up
- How would you tell a credential-stuffing attack apart from a real traffic spike at the login endpoint?
- TLS is meant to stop man-in-the-middle attacks. Where can it still fail (certificate validation bugs, a compromised CA, users clicking through warnings), and what does certificate pinning add?
- Walk through the defences you would put on a funds-transfer API, from the network edge to the database.
Do you have any experience with Angular?
Do you have any experience with Angular?
Approach
- Answer honestly and specifically. Name the Angular version range you used, what you built (screens, forms, data volume) and which parts you owned. If you haven't used it, say so, then map what you know from React or Vue onto Angular concepts and mention a small Angular app you built to close the gap.
- Show you know the core model. Components with templates and data binding. Services provided through dependency injection. Routing with guards for authenticated pages. Standalone components versus NgModules. TypeScript throughout.
- Talk about RxJS, because HttpClient returns Observables. Explain switchMap versus mergeMap (switchMap cancels the previous inner request, which is right for a search box). Explain avoiding subscription leaks with the async pipe, takeUntilDestroyed or unsubscribing in ngOnDestroy. If you used signals (added in Angular 16), say where.
- Cover change detection. Default checks the component tree on each cycle. OnPush re-checks a component when an input reference changes, an event fires in it, or it is explicitly marked for check, so it needs immutable inputs. Mention trackBy on long lists to avoid re-rendering every row.
- For a banking frontend, add security. Angular sanitises values bound to innerHTML by default, and bypassSecurityTrust* turns that off, so use it sparingly. Its HttpClient has built-in XSRF token support. An HTTP interceptor is the usual place to attach auth tokens and handle 401s centrally.
Follow-up
- When would you choose OnPush change detection, and what bug appears if you mutate an input object in place?
- How would you build a typeahead search that doesn't fire a request per keystroke and ignores stale responses?
- Reactive forms or template-driven forms for a multi-step account-opening form, and why?
What was the most difficult challenge you have faced, and how did you solve it?
What was the most difficult challenge you have faced, and how did you solve it?
Approach
- Choose a technical challenge where you made the key decisions: a production bug, a performance problem, a data migration or an integration that kept failing. Avoid a challenge that was mainly interpersonal unless you can show the technical work too.
- Tell it as a debugging sequence. What the symptom was and how you measured it. How you reproduced it. Which hypotheses you listed and how you ruled each out (logs, profiler, bisecting commits, isolating one component). What the root cause turned out to be.
- Explain why you chose that fix over the alternatives you considered, for example adding an index versus caching versus rewriting the query, and what each would have cost in complexity or risk.
- Show how you verified it worked: a before-and-after number (latency, error rate, failed jobs), a regression test that reproduces the original failure, and monitoring or alerting added so it can't silently return.
- Use 'I' for your own actions and credit others by name of role. Don't blame colleagues, and keep any lesson concrete: what you now do differently in code review, testing or design.
Follow-up
- How did you confirm that your change, rather than something else deployed at the same time, fixed the problem?
- If the same issue happened in a system holding customer financial data, what would you do differently before deploying the fix?
- What did you try first that didn't work, and what did it teach you?
How do you manage a project?
How do you manage a project?
Approach
- Describe a concrete lifecycle from a real project rather than naming a methodology. Agree scope and acceptance criteria with the requester. Split the work into milestones small enough to demo. Estimate each one. Find the critical path and the external dependencies (other teams, environments, approvals).
- Explain how you track risk and progress: a short risk list with an owner and mitigation for each item, a visible board or tracker, regular status updates that state what slipped and why, and an early warning when a date is at risk rather than on the day.
- Cover engineering controls as part of project management: version control with a branching strategy, mandatory code review, automated tests in CI, separate test and production environments, and a rollback plan for every release.
- Discuss the methodology trade-off. Iterative sprints suit changing requirements. A phased plan with sign-off gates suits fixed requirements, such as compliance-driven changes or a release that needs formal approval. Say which you used and why.
- Close with how you handle change: when scope grows, you re-estimate and make the trade-off explicit (cut scope, move the date or add people) instead of absorbing it silently.
Follow-up
- A stakeholder adds a requirement two weeks before release. What exactly do you do?
- How do you estimate a task you have never done before, and how did your last estimate compare with the actual time?
- How would you manage a project that depends on another team that keeps missing its deliveries?
Can you walk us through a significant project you completed during your studies or previous employment?
Can you walk us through a significant project you completed during your studies or previous employment?
Approach
- Open with the problem and the users in two sentences, then the constraints: data size, latency, security, deadline and team size. Say clearly which parts you built yourself, since candidates report line-by-line CV questioning.
- Walk through the architecture as components and data flow: client, API layer, services, database, external integrations. For each major choice (database, framework, sync versus async processing), name the alternative you rejected and why.
- Spend most of the time on the hardest technical decision or bug. What made it hard, the options you weighed, the trade-off you accepted, and evidence it was the right call.
- Cover quality and security: how you tested it (unit, integration, load), how authentication and input validation worked, and how you handled sensitive data such as passwords, which should be hashed with bcrypt or Argon2, never encrypted or stored as plain text.
- End with measurable results (users, performance, grade, adoption) and one thing you would redesign now, with the reason. Be ready to explain any technology on your CV from first principles.
Follow-up
- Why did you choose that database or framework, and what would have broken at ten times the load?
- Which part of this project did a teammate own, and how did you integrate with it?
- If an attacker targeted this system, where is the weakest point and how would you fix it?
p99 jumped on one listing filter while p50 stayed flat
After a release that added an owner_user_id filter to the resource listing, p99 rose from 90 ms to 1.9 s while p50 stayed at 40 ms. Traffic and row counts are unchanged. resource carries the index (tenant_id, status, updated_at DESC, resource_id DESC). The new query filters tenant_id and owner_user_id, orders by updated_at DESC, resource_id DESC, and takes 20 rows. On PostgreSQL, explain the shape of the regression, prove it from a query plan, and give the index you would add.
Approach
- Start from the shape. A flat p50 with a moved p99 means a subset of requests changed cost, not all of them, so the first job is naming the subset. Bucket the endpoint's latency by the tenant's row count; the natural hypothesis is that large tenants are a small share of requests and all of the tail.
- Get the plan for the new query on a large tenant with EXPLAIN (ANALYZE, BUFFERS). Expect an index scan over the tenant's range, a filter discarding most of it, then a Sort feeding the Limit, possibly reporting Sort Method: external merge Disk. Read actual rows on the scan node, not estimated.
- Explain why the existing index cannot serve it. A composite B-tree is seekable only as a left prefix, and with no equality predicate on status the scan cannot treat updated_at as an ordering, because rows in the tenant's range are ordered by status first. Everything matching must be read and sorted before LIMIT 20 can apply, so a tenant with 400,000 rows pays 400,000 rows to return 20.
- Add (tenant_id, owner_user_id, updated_at DESC, resource_id DESC). Equality on the first two columns leaves the index ordered by updated_at within that pair, so the plan becomes an index scan that stops after 20 rows with no Sort node. PostgreSQL can scan a B-tree backwards, so the DESC markers matter only if the two sort columns ever disagree in direction; keeping them explicit documents the order the keyset cursor depends on.
Follow-up
- The endpoint paginates with OFFSET. What does page 500 cost with your index, and what does the keyset version cost?
- How would you have caught this before release, given that a 10,000-row seed database produces the same plan shape at an unnoticeable cost?
The plan follows the four reported rounds and their reported topics: security and networking, programming and data structures, databases and debugging, project narratives, and the spoken answers on motivation and career goals. Practice questions marked as PracHub practice are general preparation, not Bank of China material.
Prepare, practise & reflect
One practical outcome each day. Spend longer where you need it.
0 / 7 done01Map the loop and inventory your CV
- Write the four reported rounds (Initial Screening, Technical Assessments, Manager Interviews, Behavioral Scrutiny) on one page with what each is reported to cover and the language it will run in.
- List every project, tool, framework and course on your CV, and mark each one you could not explain in detail for several minutes.
Deliverable: A one-page loop map and a CV inventory that marks every item you can and cannot defend.
02Network security and attacks on banking systems
- Build a table of attack classes against a bank (phishing, credential stuffing, man-in-the-middle, DDoS, SQL injection, session hijacking) with how each works and one control.
- Write your system administration and IT security experience as a short account with one real episode, and say it aloud twice.
Deliverable: An attack-and-defence table plus one rehearsed security-experience answer.
Practice prompt ↗Practice prompt ↗03Programming and data structures
- Solve the PracHub practice problems on the heaviest tenants under memory pressure, merging partitioned event streams and archiving a resource graph without recursion, writing working code in your strongest language.
- State time and space complexity for each solution aloud and list the edge cases you tested.
Deliverable: Three working solutions with complexity statements and a list of edge cases for each.
Practice prompt ↗Practice prompt ↗Practice prompt ↗04Databases and debugging
- Work the PracHub practice problems on stopping join fan-out and writing an update that detects a concurrent edit, then explain why each query shape is correct.
- Work the PracHub practice problem on a latency spike on one filter, and write the debugging sequence you followed.
Deliverable: Two corrected queries with explanations and a written debugging sequence for the latency problem.
Practice prompt ↗Practice prompt ↗Practice prompt ↗05Project narratives and the frameworks on your CV
- Write two project stories covering the problem, your decisions, the result and what you would change, and mark which parts were yours alone.
- Prepare your answer to the Angular question, the project-management question and the hardest-challenge question from those stories, then say each aloud.
Deliverable: Two project stories and spoken answers to the Angular, project-management, hardest-challenge and project walkthrough questions.
Practice prompt ↗Practice prompt ↗Practice prompt ↗Practice prompt ↗06Self-introduction, motivation and impromptu speaking
- Write and time a three-minute self-introduction, then record yourself and trim anything you could not discuss in depth.
- Write your answers to why you chose Bank of China and how your career goals fit the role, in the interview language, and check that they agree with the introduction.
- Give three impromptu talks on random topics using an opening, a few points and a closing line.
Deliverable: A timed self-introduction, two written motivation answers and three recorded impromptu talks.
Practice prompt ↗Practice prompt ↗Practice prompt ↗07Full mock loop and consistency check
- Run a mock of all four rounds in order, answering the security, project and behavioral questions aloud without notes.
- Check every story against your CV fact sheet and fix any date, role or number that changes between answers.
Deliverable: A recorded mock loop and a corrected fact sheet with a short list of weak answers to redo.
Practice prompt ↗Practice prompt ↗Practice prompt ↗Practice prompt ↗Expand any day for tasks and deliverables. Your progress is saved on this device.
Candidates describe the behavioral and manager stages as built around professional presentation, consistency and resume-based detail. The reported prompts below cover your self-introduction, why you chose the bank, your career goals and your project record, so prepare each as a short story you can check against your CV and your other answers.
Can you explain your experience with system administration and IT security protocols?
Can you explain your experience with system administration and IT security protocols?
Approach
- State your real scope first: which systems you administered (Linux or Windows servers, a lab network, a cloud account, a database) and which you only used. CV scrutiny is reported, and an overstated claim fails on the first detailed question.
- Group the protocols and controls you actually touched by purpose: authentication and access (passwords, multi-factor authentication, SSH keys, role-based access, least privilege), data protection (TLS, VPN, disk and database encryption) and hygiene (patching, backups, logging and audit trails, firewall rules).
- Anchor the answer in one episode told in situation, action, result form: a mis-set permission, an expired certificate, a suspicious login or a patch rollout. Say what you changed, how you confirmed the fix, and what you put in place so it would not recur.
- Link it to software work: parameterised queries, secrets kept out of source control, least-privilege database accounts and audit logging, so the answer shows the habit carried into code.
- If your experience is academic, say so plainly and describe the lab you built, such as a server with key-only SSH and a certificate on a local site, then what you would learn next.
Follow-up
- A customer account shows logins from two countries within an hour. What do you do first?
- What is the difference between authentication and authorization, and where does each usually fail in a web application?
- How would you rotate a leaked credential without taking the service down?
Introduce yourself in 3 minutes.
Introduce yourself in 3 minutes.
Approach
- Use a present, past, future shape: what you do or study now, two or three milestones that support a Software Engineer role in a bank (a project, security or database coursework, a measurable result), then what you want next and why this role.
- Write it as a script for three minutes, say it aloud against a timer and end on your own concluding sentence so the close is not cut off.
- Only mention what is on your CV and what you can discuss in depth. Each project or tool you name is something you may be asked to expand, and candidates report line-by-line CV questioning.
- Include one concrete result with your own part in it, using what I did and the outcome, rather than a list of duties or team achievements.
- Rehearse it in the language of the interview. Candidates report Mandarin interviews in some regions, so prepare the technical terms in both languages if that applies to you.
Follow-up
- Which project from that introduction would you like to go into in more depth?
- Why did you move from your last role or course to this one?
- Which skill you mentioned is your strongest, and what is the evidence?
Why did you choose to pursue a career at Bank of China?
Why did you choose to pursue a career at Bank of China?
Approach
- Give two or three reasons specific enough to check: something you learned from public information about the bank's services or products, the engineering you expect (security-sensitive systems, regulated environments, new digital services alongside legacy platforms) and how your own background fits.
- Separate banking from software in general. Candidates are advised to show interest in the banking industry specifically, so say what draws you to money-moving software: correctness, security, reliability and accountability.
- Treat scale and reputation as one reason, as candidates are told to, and back it with substance. A reputation-only answer fits any large employer and is easy to challenge.
- Research before you answer and name one real thing precisely, such as a service you have used or read about. Do not state facts about the bank you cannot source.
- Keep pay and convenience out of the answer, and prepare a version in Mandarin if the interview may run in it.
Follow-up
- Why banking rather than a technology company?
- Why Bank of China rather than another bank?
- What do you know about the bank's digital services, and what would you improve in one of them?
What are your personal career goals and how do they align with this role?
What are your personal career goals and how do they align with this role?
Approach
- Answer on two horizons: the first couple of years, naming skills this role gives you (writing, testing and debugging production code, working with security teams and analysts, integrating with legacy systems), and a longer-term direction such as deeper security expertise, architecture or technical leadership.
- Make the alignment explicit. For each goal, say what in this job moves you toward it, such as exposure to regulated systems for a security-minded goal or large codebases for an architecture goal.
- Show a trail of action: a certification, a course, a side project or a skill you picked up in the last year. Goals with no evidence sound rehearsed.
- Avoid goals that leave the role (starting a company, switching field) or that assume promotion paths you cannot know about, and do not claim to know the bank's career ladder.
- Keep the answer consistent with your self-introduction and your reasons for choosing this bank, since consistency across answers is the reported focus of the behavioral stage.
Follow-up
- If you spent your first year maintaining legacy code, how would that fit your goals?
- Which skill do you most want to build in your first year, and how will you do it?
- Does the technical path or the management path appeal more, and why?
- 01
Can you explain your experience with system administration and IT security protocols?
- 02
Introduce yourself in 3 minutes.
- 03
Why did you choose to pursue a career at Bank of China?
- 04
What are your personal career goals and how do they align with this role?
- 05
What was the most difficult challenge you have faced, and how did you solve it?
- 06
How do you manage a project?
How many rounds are there and how long does the process take?
Candidates report four rounds: Initial Screening, Technical Assessments, Manager Interviews and Behavioral Scrutiny, over roughly 3-5 weeks. Feedback between rounds can be slow, and the process varies by location and team, so use the gaps to review your CV and keep practising out loud.
PracHub Software Engineer practice ↗Will the interviews be in English or Mandarin?
Candidates report that, depending on the region, many interviews are held in Mandarin. Ask the recruiter in advance which language each stage will use, and rehearse your self-introduction, project stories and technical terms in that language.
PracHub Software Engineer practice ↗How do I prepare for the impromptu speech?
Candidates report impromptu speech tasks where you speak on a topic you are given. Practise with random topics aloud and use the same shape each time: an opening sentence, two or three supporting points with an example and a closing line. Aim for a calm, professional tone even when the topic is unfamiliar.
PracHub Software Engineer practice ↗What technical topics should I review?
The reported topics are network security and attacks on banking systems, programming, data structures, technical problem solving and project experience. The requirements candidates describe also mention IT security and database management. Review attack types with defences, core data structures and SQL, and be ready to explain any framework on your CV, such as Angular.
PracHub Software Engineer practice ↗How much will my CV and education be examined?
Candidates describe an interrogation-style review of the CV, with questions about your educational history, previous work and final-year or research projects. Know every line you have written, including dates, your role, the technologies used and the outcomes, and remove anything you cannot defend.
PracHub Software Engineer practice ↗Do I need banking experience?
Candidates describe financial-services experience and knowledge of banking compliance as a plus, not a requirement. What they are asked for is an explanation of why you want to work in banking specifically, so prepare a reason grounded in public information about the bank and in the kind of secure, regulated software you want to build.
PracHub Software Engineer practice ↗Sources & methodology 3 sources ↗
No official company page is cited. Rounds and questions come from candidate reports and PracHub editorial material; each source shows the date it was read.
- 01Bank of China Software Engineer candidate reports ↗
Company-reported rounds, questions and FAQ.
Candidate reports · Accessed 2026-09-22 - 02PracHub Software Engineer practice ↗
PracHub practice material, not company-reported.
PracHub page · Accessed 2026-09-22 - 03PracHub preparation framework ↗
PracHub preparation guidance.
PracHub page · Accessed 2026-09-22
Explore related engineering environments and compare the preparation focus.
Vercel Software Engineer Interview Guide
Debugging practice for Vercel software engineer prep built on a reproduction you trust, narrowing to the smallest failing input, and changing one variable per run so the result stays attributable.
Spotify Software Engineer Interview Guide
Timed practice for Spotify software engineer candidates who lose time to the clock: short problems taken end to end, then reviewed against a written rubric rather than a passing test run.
Scale Ai Software Engineer Interview Guide
Data structures and algorithms practice for Scale Ai candidates, where stating a bound means stating its precondition: constant-time hash lookup is an average case over keys that spread.
Ramp Software Engineer Interview Guide
Systems practice for Ramp software engineer candidates, weighted toward payments and lending work: the load that actually arrives, the failure modes that matter there, and the invariants a partial outage must not break.