The reported loop is short and weighted toward conversation. The first stage is paperwork, the second is an HR screening, and the third is a single technical and behavioral interview. Candidates describe the technical difficulty as average and practical: questions about your own design decisions, databases and architecture rather than long algorithm puzzles. That makes the quality of your spoken answers the main thing you can improve, because the reported time per conversation is about 30 minutes and there is little room to recover from a rambling reply.
On the technical side the reported questions cluster around five subjects: object-oriented principles and how you use them day to day, schema design for a high-volume transactional system, the steps you take to secure a new API, ways to speed up a slow SQL query, and monolith versus microservices. Candidates also mention transaction integrity (ACID), database deadlocks and a step-by-step response to a system outage. The listed languages are Java, C# or C++, so prepare examples in whichever of those you have shipped, and be ready to name the concrete mechanism behind each claim: which index, which isolation level, which authentication scheme, which service boundary.
The behavioral side is large. Reported prompts cover why you want to join CITIC Group and what you know of its business areas, a disagreement with a senior stakeholder, a tight deadline, working on legacy systems, career direction inside a large organization, your most complex technical challenge, a failed deployment and learning something new quickly. Candidates also say they were expected to explain technical choices to non-technical department heads, so each story should end with what the outcome meant for the business, not only for the code.
Use the plan at the end to cover three things in order: paperwork and motivation answers first, then database, API and architecture fundamentals, then a bank of stories built so that one story can answer several prompts. Treat the stack candidates list as the limit of what to study; deep algorithm drills are the lowest priority here, though the practice library has coding and debugging drills if you want a safety net.
On-site Application Forms
reportedCandidates report that the on-site visit starts with physical application forms, filled in on arrival and before any conversation. Nothing technical is reported for this stage. The advice candidates give is practical: the details you write by hand should agree with the resume you already submitted, because a mismatch can raise questions with HR before the interview begins. Treat it as a consistency check and a first impression of how organized you are.
What to demonstrate
- Whether the details you write match your submitted resume
- Preparedness on arrival: documents, a pen, and time to finish the forms
- Care with formal process, in a setting candidates describe as traditional
How to prepare
- Build a one-page fact sheet from the exact resume you submitted: employer names, job titles, dates, degrees and certifications, so you copy rather than recall.
- Bring a printed copy of that resume and a pen, and plan to arrive early enough that the forms do not eat into your preparation time.
- Decide beforehand how you will write any detail you are unsure of, and correct your resume copy at home if you spot an error, not at the desk.
HR Screening
reportedCandidates describe an HR conversation of about 30 minutes that mixes behavioral questions with a high-level screen of your background. It is reported as a real gate on professionalism and attitude rather than a formality. The reported topics for this kind of conversation are motivation for CITIC Group, handling conflict, adapting to changes in scope, career goals in a large organization, and prioritizing when different department heads ask for different things. Prepare short, specific answers, with each story told in a couple of minutes.
What to demonstrate
- Motivation for CITIC Group and awareness of its business areas
- Professional communication and attitude toward hierarchy and process
- Career direction and stability within a large organization
- How you handle conflict, shifting scope and competing requests
How to prepare
- Write and say aloud your answer to why you want to join CITIC Group, naming at least two of the business areas candidates describe: financial services, intelligent manufacturing, advanced materials and engineering projects.
- Prepare a disagreement-with-a-senior story and a story about prioritizing conflicting requests, each with the decision you made and the result.
- Rehearse a two-minute walk through your career and a two-sentence answer on where you want to be in a large enterprise, so neither runs long.
Technical Interview
reportedCandidates report a 30-minute technical and behavioral interview with a Department Head or a Senior Technical Engineer. The technical questions they describe are practical and architecture-flavored: object-oriented principles, schema design for a high-volume transactional system, securing a newly built API, slow SQL queries, and monolith versus microservices, plus experience questions about complex problems, failed deployments, quality before release and deadlines. Candidates also say the audience may be a non-technical head, so state each decision and the business reason together.
What to demonstrate
- Working knowledge of OOP, relational databases and SQL, and secure REST APIs
- Reasoning about architecture trade-offs, such as monolith versus microservices
- Judgment on past decisions: deadlines, quality, deployments and legacy code
- Clarity when explaining technical choices to a non-technical listener
How to prepare
- Prepare a spoken answer for each of the five reported technical questions, using real examples in the Java, C# or C++ you have shipped, and name the concrete mechanism behind each claim.
- Practice the database set together: a transactional schema, a slow query you tuned with its execution plan, and how you would handle a deadlock.
- Build two or three experience stories (a complex challenge, a deployment that went wrong, a deadline) that can each be told in about two minutes and end with the business outcome.
- Rehearse explaining the monolith versus microservices choice for a specific system you know, so the answer is a decision, not a definition.
PracHub editorial advice for the preparation topics above.
Handwritten application details that differ from the resume you submitted
Candidates warn that mismatches draw attention from HR before the interview starts. Keep a fact sheet copied from the exact submitted resume, bring a printed copy and a pen, and copy from it instead of writing from memory.
Treating the HR screening as a formality and answering why CITIC Group in generic terms
Candidates describe this conversation as a real gate. Prepare a specific reason tied to a business area and a type of software work, plus a short, concrete answer on career direction in a large organization.
Giving a technical answer as a definition, such as listing OOP principles or reciting what a microservice is
For each reported topic, prepare a decision you made: which index you added, which transaction boundary you drew, how the API authenticated callers, or why a system stayed a monolith. Finish with what that choice protected for the business.
Telling long behavioral stories in a conversation of about 30 minutes that also has to fit technical questions
Structure each story as situation, task, action and result and hold it to about two minutes, a figure candidates repeat. Put the decision and the result up front and leave details for follow-up questions.
Disparaging the legacy system, the senior stakeholder or a colleague in a disagreement or failure story
Describe the other side's constraint fairly, explain what you did with evidence, and accept your part in any failure. Candidates describe a formal culture that values respect for hierarchy and process, so tone matters as much as content.
Choose a category, try a prompt, then open its approach, worked solution or follow-up when you need it.
Track a rolling failure rate per destination for circuit decisions
The egress service delivers about 1,500 webhooks per second across roughly 40,000 destinations, each call bounded by a 10 second timeout. Maintain, per destination, the failure rate over the trailing 60 seconds so a caller can ask before dispatch whether the circuit should open. Attempts arrive as (destination_id, finished_at_ms, outcome). Requirement: amortised O(1) per attempt, with total memory bounded by the destination count rather than by traffic. Give the structure, its exact memory, and the rule that stops a destination with three attempts from opening a circuit.
Approach
- Name the exact-deque version and then reject it as the default. Holding timestamps and advancing a tail pointer past anything older than now minus 60 seconds is a correct two-pointer window at amortised O(1) per attempt, but its memory tracks in-window traffic, so one destination in a retry storm holds hundreds of thousands of entries while thousands of quiet destinations hold none.
- Use a ring of 60 one-second buckets per destination, each bucket a pair of counters for attempts and failures. On an attempt, advance the ring by the elapsed whole seconds, zeroing at most min(elapsed, 60) buckets, then increment the head. That is amortised O(1) with a fixed footprint per destination.
- State the footprint: 60 buckets times two 4-byte counters is 480 bytes of payload per destination, so 40,000 destinations is roughly 20 to 25 MB with per-entry overhead, bounded by the catalogue rather than by the rate. The cost is granularity, since the oldest bucket ages out in whole seconds, which is far tighter than the decision needs.
- Require a minimum sample before the circuit may open. A destination with three attempts and three failures reads as 100 percent and is not evidence; a floor of roughly 20 attempts in the window makes the ratio meaningful, and below that floor use a run of consecutive failures as the trigger instead.
Follow-up
- The fleet is 30 instances and each sees roughly a thirtieth of a destination's traffic. Where does the rate actually live, and what does a per-instance answer get wrong?
- A destination answers in 9.5 seconds and succeeds. It is not failing but it is consuming your per-destination concurrency. What signal should open the circuit here?
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?
Diff a projection against the primary without per-row point reads
The listing projection has drifted and some rows show a stale version. The primary holds 40,000,000 resource rows across 12,000 tenants while serving 1,200 writes and 14,000 reads per second. The obvious repair, reading each resource row and comparing its version against the projection, is correct and would eventually finish. Explain precisely why it is unacceptable here, then give a diff that finds the differing rows, state its complexity, and make it safe to run against a live primary. Replication lag is usually under 100 ms and is not bounded.
Approach
- Quantify the naive cost rather than calling it slow: 40,000,000 point reads at even 0.5 ms each is over five hours serialised, and the only lever is concurrency, which is exactly what you cannot spend. The primary's pool is sized for the write path, and 40,000,000 random reads evict the buffer cache that sustains the 85 percent cache hit rate, so the audit degrades the system it is auditing.
- Replace random access with one ordered pass per side. Both sides can be read in (tenant_id, resource_id) order, which is a sequential scan on each and a merge join in O(n) time and O(1) memory. For a dense diff that is the whole answer, and it reads the primary once instead of 40,000,000 times.
- For the expected sparse case, compare range hashes instead of rows: partition the key space, compute per range an order-independent aggregate over hash(resource_id, version), compare aggregates, and descend only into ranges that differ. With d differing rows and branching factor B, at most d ranges mismatch per level, so the drill-down examines O(d log_B(n/d)) ranges and reads full rows only in mismatching leaves.
- Aggregate with a sum modulo 2^64 or a multiset hash, never XOR. XOR is order-independent but self-cancelling, so two rows wrong in the same way, or a row duplicated on one side, leave the range aggregate matching and the range is declared clean.
Follow-up
- The diff reports 900 stale rows. How do you decide between patching those rows and rebuilding the projection from resource_revision?
- Same job, but the projection lives in a search index that cannot be scanned in key order. What changes?
What strategies do you use to optimize a slow SQL query?
What strategies do you use to optimize a slow SQL query?
Approach
- Measure before changing anything: get the actual execution plan (EXPLAIN ANALYZE in PostgreSQL, the actual plan in SQL Server, EXPLAIN/EXPLAIN ANALYZE in MySQL 8) and note that EXPLAIN ANALYZE executes the statement, so wrap DML in a transaction and roll back.
- Read the plan for the expensive node: full scans on large tables, nested loops over many rows, sorts spilling to disk, and estimated row counts far from actual ones (stale statistics: run ANALYZE / UPDATE STATISTICS).
- Fix sargability: a function or implicit cast on an indexed column (WHERE YEAR(created_at) = 2025, or comparing a VARCHAR column to a number), or LIKE '%term', prevents an index seek; rewrite as a range predicate on the raw column.
- Design the index for the query: in a composite index put equality columns first and the range or ORDER BY column after them; add included columns to make it covering so the table lookup disappears; remember each new index slows writes.
- Then reduce work at the query level: select only needed columns, filter before joining or aggregating, replace OFFSET pagination with keyset pagination (WHERE id > last_seen ORDER BY id LIMIT n), and fix N+1 query patterns in the application code.
Follow-up
- The query is fast in testing but slow in production with the same plan shape. What do you check?
- When would an index make a query slower or be ignored by the optimiser?
- How would you find which queries to optimise first on a busy database?
Explain why the owner filter ignores the listing index
The only index on resource is (tenant_id, status, updated_at DESC, resource_id DESC). A new endpoint returns one user's resources across all statuses, newest created first: WHERE tenant_id = $1 AND owner_user_id = $2 ORDER BY created_at DESC LIMIT 20. On a tenant with 2M rows it takes 900 ms and EXPLAIN shows a sort above a large scan. Explain precisely why the existing index cannot serve it, give the index that can, and state which of these the new index still will not help: owner_user_id alone across tenants; the same query ordered by updated_at. PostgreSQL 16.
Approach
- Separate the two jobs an index does. For filtering, a composite btree is seekable only on a left prefix, so with no predicate on status the scan can at best range over tenant_id and test owner_user_id per row; PostgreSQL 16 has no btree skip scan to jump the unconstrained column.
- For ordering, the index is sorted by (status, updated_at) within a tenant and not by created_at, so the LIMIT cannot stop early: every matching row is read and then sorted. That is the 'Sort Method: top-N heapsort' line, and it is why the plan reads 2M rows to answer with 20.
- Derive the replacement from the access path — equality, equality, then the ordering column: CREATE INDEX CONCURRENTLY ON resource (tenant_id, owner_user_id, created_at DESC). The scan seeks to the (tenant, owner) range and walks 20 entries in order, so the Sort node disappears along with the row-read.
- Treat INCLUDE (title, status) as conditional, not free. An index-only scan still visits the heap for any row whose page is not marked all-visible, so on a table taking 1.2k writes/second the win depends on autovacuum keeping the visibility map current, and the wider index costs more on every insert.
Follow-up
- 90% of rows are status='active'. Would a partial index WHERE status = 'active' change your answer, and for which of the three queries?
- A dashboard runs this for 40 owners in one page load. What changes about the design?
Explain the principles of Object-Oriented Programming and how you apply them in your daily work.
Explain the principles of Object-Oriented Programming and how you apply them in your daily work.
Approach
- Define the four pillars in one line each, with what each one buys you: encapsulation (state is changed only through methods that keep invariants), abstraction (callers depend on an interface, not an implementation), inheritance (reuse of a base type), polymorphism (one call site, behaviour chosen by the runtime type).
- Ground each in a real Java or C# example from your own code: a PaymentProcessor interface with card and bank-transfer implementations shows abstraction and polymorphism; a private balance field with a debit() method that rejects overdrafts shows encapsulation.
- Say where inheritance goes wrong and why you prefer composition: deep hierarchies couple subclasses to base-class internals, and a subclass that strengthens preconditions breaks the Liskov substitution principle (the Square extends Rectangle case).
- Connect to SOLID as the daily practice: single responsibility keeps classes small, dependency inversion (inject interfaces through constructors) is what makes the code unit-testable with mocks.
- Close with a trade-off: abstraction added before a second implementation exists is speculative; I add the interface when the second case appears or when I need a test seam.
Follow-up
- When would you choose an abstract class over an interface in Java or C#?
- Show me a design-pattern you used recently (strategy, factory, decorator) and what problem it removed.
- How do you refactor a legacy class with 3,000 lines and no tests without breaking it?
How do you design a database schema for a high-volume transactional system?
How do you design a database schema for a high-volume transactional system?
Approach
- Start from the transactions: name the entities (account, transaction, ledger entry), the write rate, the hot read queries and the retention period before drawing tables.
- Normalise the write path to third normal form and keep money exact: DECIMAL/NUMERIC or integer minor units, never FLOAT; for balances, an append-only ledger of entries (double-entry: each transaction's entries sum to zero) with the current balance derived or maintained in the same transaction.
- Enforce integrity in the database, not only in code: foreign keys, NOT NULL, CHECK constraints, and a UNIQUE constraint on a client-supplied idempotency key so a retried request cannot insert a second payment.
- Index for the known reads only, because every index adds cost to every insert; prefer a monotonically increasing key (identity/sequence) over random UUIDv4 for clustered B-tree indexes to avoid page splits, and partition large tables by date so old partitions can be archived or dropped.
- Cover concurrency: pick the isolation level deliberately (READ COMMITTED plus SELECT ... FOR UPDATE or a version column for optimistic locking), and lock rows in a consistent order to avoid deadlocks.
Follow-up
- How would you handle a deadlock between two transfers that touch the same two accounts in opposite order?
- Reporting queries are slowing down the transactional tables. What do you change?
- How do you add a NOT NULL column to a table with hundreds of millions of rows without downtime?
Walk me through your process for securing a newly developed API.
Walk me through your process for securing a newly developed API.
Approach
- Walk the request path in order: TLS everywhere (HTTPS only, HSTS), then authentication, then authorization, then input handling, then the response and the logs.
- Authentication: OAuth 2.0 / OpenID Connect with short-lived access tokens; when validating a JWT, verify the signature with an allow-listed algorithm (reject alg=none), and check exp, iss and aud.
- Authorization on every object, not just every endpoint: check that the caller owns or may access the specific record ID, since broken object-level authorization is the first item in the OWASP API Security Top 10; apply least privilege to service accounts and database users.
- Input and output: validate against a schema, use parameterized queries (bind parameters) to prevent SQL injection, cap payload sizes, return generic error messages, and never log tokens, passwords or full account numbers.
- Operational controls: rate limiting per client, secrets in a vault rather than config files, dependency scanning in CI, an audit log of who accessed what, and a penetration test or DAST scan before go-live.
Follow-up
- A user changes the account ID in the URL and sees another customer's statement. Where did the design fail and how do you fix it?
- How do you rotate a signing key or API secret without breaking existing clients?
- What changes when the API is called by another internal service instead of a browser?
Describe the differences between monolithic and microservices architectures. When would you choose one over th
Describe the differences between monolithic and microservices architectures. When would you choose one over the other?
Approach
- Define the difference by deployment and data: a monolith is one deployable unit sharing one database and in-process calls; microservices are independently deployable services, each owning its data, talking over the network (REST, gRPC or messaging).
- List what microservices cost: network latency and partial failure (timeouts, retries, circuit breakers), no cross-service ACID transactions (sagas with compensating actions, the transactional outbox pattern), distributed tracing, and more infrastructure to run.
- List what they buy: independent deployment and scaling, fault isolation, and teams owning a service end to end; these pay off only when boundaries are stable and several teams step on each other in one codebase.
- State a decision rule: start with a well-modularised monolith when the domain or team is small or boundaries are unclear; extract a service when a module has a different scaling profile, release cadence, or compliance boundary.
- For an existing legacy system, describe the strangler fig approach: put a routing layer in front, move one capability at a time behind it, and keep data synchronised until the old path can be switched off.
Follow-up
- How do you keep an order and its payment consistent when they live in two services?
- What would make you merge two microservices back together?
- How would you migrate a legacy monolith without a freeze on new features?
How do you balance the need to write perfect code with the need to meet business deadlines?
How do you balance the need to write perfect code with the need to meet business deadlines?
Approach
- Reframe the question: the goal is code that is correct and maintainable enough for its risk, so I first sort the work into non-negotiables and deferrables.
- Non-negotiables for systems handling money or regulated data: correctness of calculations, security controls, data integrity (constraints, migrations that can be rolled back), and automated tests on the critical path.
- Deferrable: generalisation for hypothetical cases, performance tuning without a measured problem, cosmetic refactors; I decide by reversibility, because a public API contract or a schema is far harder to change later than internal code.
- Make shortcuts explicit: record the debt as a ticket with an owner and a trigger for paying it back, tell the stakeholder what was traded, and ship behind a feature flag where possible so scope can be cut without a rollback.
- Back it with one concrete example: the deadline, what I cut, what I refused to cut and why, and when the debt was paid down.
Follow-up
- Tell me about a shortcut that came back to cost you. What would you decide differently?
- A manager asks you to skip tests to hit a release date. What do you say?
- How do you convince a non-technical department head to fund paying down technical debt?
How do you ensure quality and minimize bugs before pushing code to production?
How do you ensure quality and minimize bugs before pushing code to production?
Approach
- Describe layered checks from cheapest to most expensive: compiler and static analysis (linters, SonarQube or similar), many fast unit tests, integration tests against a real database (for example with Testcontainers), and a few end-to-end tests on critical flows.
- Make the pipeline enforce it: every change goes through code review and CI, and merging is blocked on failing tests or analysis; add a regression test for every bug fixed so it cannot return.
- Treat data changes as code: database migrations are reviewed, tested on a production-like copy, and written backward-compatible (expand then contract) so the previous application version still works during rollout.
- Reduce release risk: deploy to staging first, then a canary or a feature flag to a small share of traffic, watch error rate and latency, and keep a tested rollback path.
- Name the trade-off: end-to-end tests catch integration bugs but are slow and flaky, so they cover only the paths where a failure is most expensive.
Follow-up
- How do you deal with a flaky test that blocks the pipeline?
- Which metrics would tell you within minutes that a release is bad?
- How do you add tests to legacy code that was never designed to be testable?
Exports duplicate a row range about once a week
Roughly once a week an export writes a file containing a duplicated range of rows. The affected job_run rows show attempt = 1, status = succeeded, one started_at, and a lease_owner naming a different host from the one whose logs show the job starting. Leases last 30 seconds and are heartbeated every 10 from inside the handler; lease_expires_at is computed on the worker and compared against the database's now(). Find the mechanism, and give a fix that holds even if you cannot fix the clocks.
Approach
- Start from the fact that eliminates the obvious answer. attempt = 1 means no retry was recorded, so this is not a re-run after failure; two workers ran the same row concurrently and the takeover path never touched the counter. lease_owner naming a host other than the one that started the job is the same statement from the other side.
- Enumerate the mechanisms that cause a premature takeover, then find the signal that separates them. Either the lease genuinely expired because the heartbeat did not fire, which is what happens when the heartbeat runs on the handler's own thread and the handler makes a long blocking call, or it only appeared expired because two clocks disagree, since lease_expires_at is written from the worker's clock and evaluated against the database's. The discriminator is the distribution: incidents clustered on the longest exports indict the heartbeat, incidents clustered on one host indict skew. Measure both, and measure each host's offset against the database directly.
- Read the reclaim query precisely. In PostgreSQL now() is transaction start time, not statement time, so a reclaimer holding a long transaction compares against an older timestamp than expected; clock_timestamp() is the statement-time function. This is worth ruling in or out before you redesign anything, because it changes which rows look expired.
- Remove the second clock rather than trying to synchronise it. Issue and extend the lease in the database, with lease_expires_at = now() + interval '30 seconds' in both the claim and the heartbeat, so exactly one clock is ever compared and worker skew stops mattering to this predicate.
Follow-up
- The displaced worker has already streamed half the file to object storage. What makes that side effect safe to repeat?
- You now count takeovers. What alert fires on that counter, and at what threshold?
The plan follows the three reported stages: paperwork and motivation first, then the database, API and architecture questions candidates report, then a story bank and a full run-through. Practice drills from the PracHub library sit on the days where they support the same skills.
Prepare, practise & reflect
One practical outcome each day. Spend longer where you need it.
0 / 7 done01Map the loop and prepare the paperwork
- Write the three reported stages in order (on-site forms, HR screening, technical interview) and note for each what you must have ready.
- Build a one-page fact sheet from your submitted resume with employers, titles, dates, degrees and certifications, exactly as written there.
- List the business areas candidates describe (financial services, intelligent manufacturing, advanced materials, engineering projects) and one software-related fact you can say about each.
Deliverable: A one-page loop map, a resume-matching fact sheet to copy onto the forms, and a four-line business-areas note.
02Motivation and career answers
- Write and speak a two-minute answer to why you want to join CITIC Group, naming one business area and one kind of software work from your own experience.
- Write a three-step career path answer for a large enterprise, with one action you have already taken toward it.
- Record both answers, cut anything that sounds like praise rather than evidence, and re-record.
Deliverable: Two scripted and recorded answers, each under two minutes.
Practice prompt ↗Practice prompt ↗03Databases, transactions and slow SQL
- Sketch a schema for a high-volume transactional system with tables, keys, constraints and the transaction boundary, and say what ACID guarantees each part needs.
- Take a slow query you have seen or write one, read its execution plan, and list the changes you would make in order: index, rewrite, statistics, data volume.
- Work through the PracHub SQL drill on a filter that ignores an index, then explain a deadlock and how consistent lock ordering and short transactions reduce it.
Deliverable: A schema sketch with a transaction-boundary note, a before-and-after query plan write-up, and a spoken one-minute deadlock explanation.
Practice prompt ↗Practice prompt ↗Practice prompt ↗04OOP, API security and architecture
- Explain encapsulation, inheritance, polymorphism and abstraction using one class hierarchy from your own code in Java, C# or C++, including one place composition served better than inheritance.
- Write a security checklist for a new REST API serving a financial reporting dashboard, covering authentication, authorization, input validation, transport encryption, rate limiting and audit logging.
- Make a decision table for monolith versus microservices, with team size, deployment independence, data consistency and operational cost, and decide it for one system you know.
Deliverable: A one-page OOP example, an API security checklist and a monolith-versus-microservices decision table.
Practice prompt ↗Practice prompt ↗Practice prompt ↗05Quality, deadlines and incident troubleshooting
- Write your pre-release quality routine: tests by level, code review, static checks, staging, and how you decide what ships when time is short.
- Write a step-by-step response to a critical system going down in business hours: detect, contain, communicate, diagnose, fix, review.
- Do the PracHub debugging drill about an export that repeats a row range, narrating your steps aloud as you would to a department head.
Deliverable: A quality routine, a numbered outage runbook and a spoken debugging narration.
Practice prompt ↗Practice prompt ↗Practice prompt ↗06Build the story bank
- Pick four real experiences and write each as situation, task, action and result: a senior-stakeholder disagreement, a tight deadline, a legacy migration and a deployment that failed.
- Add a fifth story on your most complex technical challenge and a sixth on learning something new quickly.
- Map every story to the prompts it can answer and cut each to about two minutes.
Deliverable: A table of six stories mapped to the six behavioral prompts, each timed to about two minutes.
Practice prompt ↗Practice prompt ↗Practice prompt ↗Practice prompt ↗Practice prompt ↗Practice prompt ↗07Full run-through
- Run the day as the candidates describe it: write the forms from your fact sheet, then give the HR answers aloud without notes.
- Do a 30-minute mock mixing technical and behavioral questions, with a friend playing a non-technical department head, and have them stop you when you use jargon.
- Review the recording and list three things to fix, ending each answer with its business outcome.
Deliverable: A recorded mock session and a three-item fix list.
Practice prompt ↗Practice prompt ↗Practice prompt ↗Practice prompt ↗Practice prompt ↗Expand any day for tasks and deliverables. Your progress is saved on this device.
Candidates report that both the HR screening and the technical interview carry behavioral questions, and that professionalism, conflict handling and career stability come up. For a Software Engineer, strong answers are short stories about decisions on legacy code, deadlines, deployments and disagreements, finishing with the effect on the business.
Why are you interested in joining CITIC Group, and what do you know about our business domains?
Why are you interested in joining CITIC Group, and what do you know about our business domains?
Approach
- Open with a reason tied to the kind of work, not the size of the name. Candidates describe trading platforms, ERP systems, engineering-contract tools, legacy modernization and cross-border data integration; pick the one that overlaps with something you have built and say so in one sentence.
- Show you did homework by naming the business areas candidates report: financial services, intelligent manufacturing, advanced materials and global engineering projects. Say which one you would be closest to and what that implies for the software, such as transaction integrity in finance or integration with plant or project systems.
- Mention the location or hub you are interviewing for only if you can say something true about it. Candidates describe offices in Hong Kong, Dubai and mainland China, and a one-line reference to working across them is enough.
- Keep it under two minutes and end with what you offer: a specific skill from your resume that fits the work above. Do not recite the company's history or flatter it; vague admiration is the usual weak version of this answer.
Follow-up
- Which of those business areas would you most want to work near, and why?
- What attracts you to a large conglomerate rather than a company with a single product?
- What would you want to learn first about our systems if you joined?
Tell me about a time you had a disagreement with a senior stakeholder. How did you resolve it?
Tell me about a time you had a disagreement with a senior stakeholder. How did you resolve it?
Approach
- Choose a real disagreement where the senior person had a legitimate concern, such as budget, risk or a deadline, and state both positions fairly in two sentences. A story where the other person was simply wrong tends to read as poor judgment.
- Spend most of the time on what you did: you gathered evidence (a load test, an incident record, a cost estimate), restated their goal in your own words, and brought two or three options with the trade-off of each rather than a single objection.
- Show how it ended. Either your option was accepted because of the evidence, or the decision went the other way and you committed to it and made it work. Both are good endings; going around the stakeholder is not.
- State the result and what changed in how you work with that person afterward. Candidates report that respect for hierarchy and process matters in this loop, so show that you disagreed through the right channel and in private where appropriate.
Follow-up
- What if they had still said no after seeing your evidence?
- How did you describe the decision to your own team afterward?
- Did the relationship change, and what did you do to keep it working?
Describe a situation where you had to deliver a critical project under a very tight deadline.
Describe a situation where you had to deliver a critical project under a very tight deadline.
Approach
- Set the scene briefly: what the project was, why the date could not move, and what was at risk if it slipped. Make clear that you owned a decision, not just overtime.
- Describe the scoping you did: what you cut or deferred, what you refused to cut (for example tests and review on code that moves money or data, or security checks) and who agreed to those choices. This is the core of the answer.
- Show how you kept risk visible: an early warning when a milestone slid, a short status format for stakeholders, and a rehearsed rollback plan for release.
- Close with the outcome and the debt: the date was met or renegotiated, and the shortcuts you took were logged and paid back. A hero story with no trade-offs and no cleanup is the weak version of this answer.
Follow-up
- What exactly did you cut, and who signed off on cutting it?
- What would you have done if the date had slipped anyway?
- How and when did you pay back the shortcuts?
How do you handle working on legacy systems that may not use the latest technologies?
How do you handle working on legacy systems that may not use the latest technologies?
Approach
- Start with a stance, then prove it with a story: legacy code is a running system that carries business rules nobody wrote down, so you read and understand it before changing it. Say this in one sentence rather than complaining about old technology.
- Describe the safety work: write characterization tests that pin current behavior, map dependencies and data flows, and add logging or reconciliation reports before touching anything.
- Explain how you modernize without a big-bang rewrite: wrap the old component behind an interface, move one slice at a time to new code, migrate data in stages with row-count and checksum comparisons, and keep a rollback path. Candidates report that migrating data safely and refactoring old codebases is part of the role.
- Close with a result from your own history: what you replaced or documented, what broke or did not, and how the team could maintain it afterward.
Follow-up
- When would you rewrite a legacy component instead of refactoring it?
- How do you confirm migrated data matches the source?
- How would you convince a manager to fund the modernization work?
Where do you see your career progressing within a large enterprise organization?
Where do you see your career progressing within a large enterprise organization?
Approach
- Give a path in two or three concrete steps rather than a title: deepen ownership of a system or domain, then take on design decisions across teams, then mentor or lead where the organization needs it. Keep each step tied to a skill you are already building.
- Connect the path to what a large enterprise offers, such as many business units, cross-border systems and regulated data, without making claims about CITIC Group's promotion paths that you cannot know.
- Show that the answer is backed by action: name one thing you did in your last role toward this direction, like taking on an on-call rotation, leading a migration or learning a business domain.
- Avoid two extremes: naming the interviewer's job as your goal, or saying you have no plans. Candidates report that career stability and long-term goals come up, so a measured, specific answer fits.
Follow-up
- What would you need from the company to get there?
- What would you do if that path was not available in your team?
- What skill is the biggest gap between you and that goal?
Tell me about the most complex technical challenge you have solved in your career so far.
Tell me about the most complex technical challenge you have solved in your career so far.
Approach
- Pick a problem that was hard because of constraints, not just size: data integrity, availability, a deadline, an unclear requirement or a legacy dependency. State the system, your role and the constraint in two sentences.
- Walk through the options you weighed and why you rejected the others. This shows technical judgment better than a list of technologies. Name the actual mechanism, for example a change to indexing, a queue to decouple a slow dependency or a locking strategy.
- Explain how you verified it: tests, load numbers, a staged rollout, or comparison of old and new results. Use only numbers you really measured.
- Separate your contribution from the team's, and finish with the effect on the business or users. Candidates report that security, availability and data integrity are the themes to emphasize on this loop, so tie the story to one of them if it is true.
Follow-up
- What alternative did you reject, and why?
- What would you do differently if you faced it again?
- How did you explain the problem and your fix to someone non-technical?
Describe a time when a deployment went wrong. What was your immediate reaction, and how did you fix it?
Describe a time when a deployment went wrong. What was your immediate reaction, and how did you fix it?
Approach
- Say plainly what your immediate reaction was: restore service first, diagnose second. Name the action, such as rolling back, switching a feature flag off or failing over, and what signal told you something was wrong (an alert, an error rate, a user report).
- Describe communication during the incident: who you told, how often you gave updates, and how you kept the stakeholders informed without speculating about the cause.
- Walk the diagnosis in order: what changed in the release, what the logs and metrics showed, how you reproduced it, and whether you fixed forward or rolled back and why. If a database migration was involved, say how you handled data that had already been written.
- End with the follow-through: a blameless review, and a concrete control you added afterward, like a canary stage, a rehearsed migration, a release checklist or a smoke test. Avoid blaming a colleague or claiming the failure was nobody's fault.
Follow-up
- How did you decide between rolling back and fixing forward?
- Who did you tell first, and what did you say?
- What change to the release process came out of it?
Tell me about a time you had to learn a completely new technology or domain on the fly to complete a project.
Tell me about a time you had to learn a completely new technology or domain on the fly to complete a project.
Approach
- Choose a real case where the deadline forced fast learning, ideally a domain such as a financial or compliance concept or a technology new to you. State what you did not know at the start; honesty here is more convincing than a smooth story.
- Describe your method: define the minimum you needed to be useful, read primary sources, ask a domain expert targeted questions, and build a small throwaway spike to test your understanding before touching the real system.
- Show how you checked yourself: a review by someone experienced, tests written from the domain rules, or a pilot on a small slice. Name one thing you got wrong at first and how you caught it.
- Finish with the delivery and what you kept: the project shipped, and you left notes or a short document so the next person starts further ahead.
Follow-up
- How did you know you understood it well enough to ship?
- Whom did you ask for help, and what did you ask?
- What did you get wrong initially?
- 01
Why are you interested in joining CITIC Group, and what do you know about our business domains?
- 02
Tell me about a time you had a disagreement with a senior stakeholder. How did you resolve it?
- 03
Describe a situation where you had to deliver a critical project under a very tight deadline.
- 04
How do you handle working on legacy systems that may not use the latest technologies?
- 05
Tell me about the most complex technical challenge you have solved in your career so far.
- 06
Describe a time when a deployment went wrong. What was your immediate reaction, and how did you fix it?
How formal is the CITIC Group interview?
Candidates describe it as formal and traditional. They advise business attire, a printed copy of your resume and a pen, and early arrival so the physical application forms are finished before the first conversation. Keep your answers polished and your tone respectful.
CITIC Group Software Engineer candidate reports ↗How hard is the technical interview?
Candidates describe it as average in difficulty and practical, with questions on OOP, database schema design, SQL tuning, API security and architecture rather than long algorithm puzzles. Prepare to give examples from your own projects and explain the reason behind each design choice.
CITIC Group Software Engineer candidate reports ↗How long does the process take?
Candidates report about 3-5 weeks overall, and say a decision or offer can take a further two to three weeks after the on-site interviews while internal approvals happen. Ask the recruiter what the next step is when you finish.
CITIC Group Software Engineer candidate reports ↗Which languages and tools should I be ready to discuss?
Candidates list Java, C# or C++, strong SQL and relational database design, and experience building secure REST APIs. Cloud platforms such as AWS, Azure or Alibaba Cloud and familiarity with compliance standards are described as extras, and so is bilingual English and Mandarin or Cantonese. Prepare examples in the language you have actually shipped.
PracHub Software Engineer practice ↗Is there an extra round beyond the three stages?
Candidates say the three stages are typical, but an additional technical deep-dive or business alignment round can appear depending on the office, such as Dubai, or on seniority, for example a Senior Contracts Engineer. Ask your recruiter what to expect for your specific role.
PracHub Software Engineer practice ↗Are the roles on-site or remote?
Candidates describe the roles as mostly on-site at major offices such as Hong Kong or Dubai, with hybrid arrangements sometimes possible depending on the department. Confirm the working arrangement for your team with the recruiter before you accept.
CITIC Group Software Engineer candidate reports ↗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.
- 01CITIC Group 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.
Shopify Software Engineer Interview Guide
Timed practice for Shopify 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.
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.