The reported topic list is concrete and narrow: C++, SQL, Linux command line, algorithmic problem solving, and the design patterns Builder, Decorator and Factory, with Python also named among the languages. That makes preparation less about breadth and more about being fluent in a small set. You should be able to write a linked-list reversal, a two-sum solution and a binary search in C++ without hesitation, explain how you would speed up a slow SQL query, and show each of the three patterns in code rather than recite their definitions.
The reported questions also reach beyond coding. Candidates mention designing a notification system for a trading application, comparing microservices with a monolith, designing a database schema, preparing a dataset for machine learning, and evaluating a new trading algorithm. These sit close to the work described for the role, where engineers support quantitative analysts and traders. Prepare them as short, structured answers: state assumptions, name the components, and call out the failure modes (duplicate or late messages, ordering, look-ahead bias in a backtest, leakage in preprocessing).
Three of the reported questions are behavioral: a challenging project and what you learned, prioritising several projects, and handling conflict in a team. A fourth, debugging a complex C++ issue, is a technical story. Candidates also say the HR stage centres on past experiences and the technical stage on coding challenges and experience, so the same few projects will be discussed twice, once as a story and once at code level. Pick two or three projects you can describe in both ways and know their details cold.
Coding Assessment
reportedCandidates report that the first stage is a coding game, with CodinGame named as an example of the platform. It is an online, problem-solving exercise rather than a conversation, so the working code you submit is what counts. Because the loop's topic list names C++, Python and algorithmic problem solving, treat it as a puzzle-style coding test: read the statement carefully, choose a data structure, and handle edge cases before you submit.
What to demonstrate
- Working code for algorithmic problems under a time limit
- Command of core data structures and algorithms such as sorting, searching and graph traversal, which candidates list as topics
- Comfort in the language you pick, with C++ and Python both named in the requirements
How to prepare
- Solve a few puzzle-style problems on a game-based platform with a timer you set yourself, in the language you will use on the day.
- Rehearse the reported coding questions in C++: reverse a linked list, find two numbers that add up to a target, and implement binary search, including empty input and off-by-one boundaries.
- Refresh the STL containers you will reach for (vector, unordered_map, set, priority_queue) and their complexity, so that you do not look them up mid-problem.
HR Interview
reportedCandidates describe the HR Interview as a conversation about cultural fit and past experiences, with behavioral questions. The reported behavioral questions concern a challenging project, prioritising several projects, and conflict within a team, and the C++ debugging story fits this stage's focus on experience. Go in with a short list of real stories and a plain account of why this kind of work interests you.
What to demonstrate
- Your account of your own role and decisions in past projects
- How you describe working with colleagues, prioritising and handling disagreement
- Communication and motivation for the role
How to prepare
- Write one story each for: a challenging project, a prioritisation trade-off, a team conflict and a hard C++ bug, each in first person with a measurable result.
- Prepare a concise explanation of why you want to work on software close to trading and quantitative research, based on your own experience rather than guesses about the firm.
- Have a few questions ready about the team, the codebase and how engineers work with quantitative analysts.
Technical Interviews
reportedCandidates report technical interviews in which managers and team members discuss coding challenges and your experience in depth. Expect to talk through code you have written and problems you would solve, which makes this the stage to be fluent in C++, SQL, Linux command line and design patterns. The system design and case-study questions that were reported (the trading notification system, microservices versus a monolith, schema design, data preprocessing, evaluating a trading algorithm) are good practice for this kind of discussion.
What to demonstrate
- Depth in the listed technologies: C++, SQL, Python and the Linux command line
- Reasoning about algorithms and data structures, spoken aloud
- Design choices, including patterns such as Builder, Decorator and Factory, and system trade-offs
- Technical depth in your own past work
How to prepare
- Practise explaining a SQL optimisation end to end: read the plan, check indexes and join order, rewrite, and measure.
- Write a small Builder, a Decorator and a Factory in C++ and be able to say what each one would let you change later without editing existing code.
- Prepare two or three designs aloud: the trading notification system, a schema for a new application, and a monolith versus microservices comparison for a trading system.
- Rehearse how you would assess a trading algorithm: out-of-sample testing, transaction costs, risk-adjusted metrics and the ways a backtest misleads.
PracHub editorial advice for the preparation topics above.
Treating the coding game as a warm-up and reading it for the first time on the day
Do puzzle-style problems under your own timer in the language you will use. Practise reading a long statement, extracting the input limits, and choosing a data structure before typing.
Giving linked-list reversal, two-sum or binary search as an outline without the edge cases
Write each in C++ and test empty input, a single node, a repeated value, using the same element twice, and an index calculation that overflows. For binary search, state the loop invariant and whether the bounds are inclusive.
Reciting definitions of object-oriented principles or of Builder, Decorator and Factory with no code
Keep a small C++ example of each and say what it lets you change later without editing existing code. For the principles, tie each (encapsulation, inheritance, polymorphism, abstraction) to a class hierarchy you have actually written.
Telling project, conflict and debugging stories as "we", with no decision of your own and no method
Prepare each story with your role, the options you considered, the choice and the result. For the C++ bug, give the sequence: reproduce, minimise, hypothesise, confirm with a tool, fix, add a test.
Answering the trading-application design and algorithm-evaluation questions generically
For the notification system, cover delivery guarantees, duplicates, ordering and what happens when a consumer is down. For evaluating a trading algorithm, cover out-of-sample data, look-ahead bias, transaction costs and risk-adjusted measures, not just total return.
Choose a category, try a prompt, then open its approach, worked solution or follow-up when you need it.
Write a function to reverse a linked list.
Write a function to reverse a linked list.
Approach
- Write the iterative three-pointer version: prev = nullptr, curr = head. In the loop, save next = curr->next, set curr->next = prev, then advance prev = curr and curr = next. Return prev. It runs in O(n) time with O(1) extra space.
- Mention the recursive version (reverse the rest, then head->next->next = head and head->next = nullptr). Its O(n) call depth can overflow the stack on a long list, so the iterative version is the safer default.
- Walk the edge cases: an empty list returns nullptr, a single node returns itself, and with two nodes the old head's next must end up null so no cycle is left behind.
- In C++, say who owns the nodes. Raw-pointer relinking allocates nothing. If nodes are held by std::unique_ptr, move ownership explicitly at each step. For a doubly linked list, swap prev and next on every node.
- Test it by building a list, reversing it, printing it, and reversing it again to check that you get the original order back.
Follow-up
- Reverse only the nodes between positions m and n, in one pass.
- Reverse the list in groups of k nodes.
- Check whether a linked list is a palindrome using O(1) extra space.
Given an array of integers, find two numbers such that they add up to a specific target.
Given an array of integers, find two numbers such that they add up to a specific target.
Approach
- Clarify the contract: return indices or values, whether exactly one answer is guaranteed, whether one element can be used twice, whether negatives and duplicates appear, and whether the input is sorted.
- Give the brute force first: check every pair in O(n^2) time and O(1) space.
- Use a single-pass hash map from value to index. For each x, look up target - x before inserting x. That ordering handles duplicates such as [3, 3] with target 6 and never pairs an element with itself. The cost is O(n) average time and O(n) space, since std::unordered_map is O(1) on average but O(n) in the worst case.
- Offer the alternative: sort, then move two pointers inward, which is O(n log n). It uses O(1) extra space only if you can sort in place and lose the original indices. Keeping the indices means sorting (value, index) pairs. It is the better choice when the input is already sorted.
- Flag numeric edge cases in C++: target - x can overflow int, so compute in long long. Also state what to return when no pair exists.
Follow-up
- Return all unique pairs that sum to the target, without duplicates.
- Extend it to three numbers that sum to the target, and give the complexity.
- Design a structure with add(number) and find(target) when one of the two operations is much more frequent.
How would you implement a binary search algorithm?
How would you implement a binary search algorithm?
Approach
- State the precondition (sorted input, or more generally a monotonic predicate) and choose one interval convention. With half-open [lo, hi), loop while lo < hi and set either lo = mid + 1 or hi = mid.
- Compute mid = lo + (hi - lo) / 2 so lo + hi cannot overflow. Each step halves the range, giving O(log n) time and O(1) space when written iteratively.
- Separate the variants: exact match, lower_bound (first index with a[i] >= target) and upper_bound (first index with a[i] > target). C++ std::lower_bound and std::upper_bound and Python bisect_left and bisect_right follow these definitions, and upper_bound - lower_bound counts the occurrences.
- Walk the edge cases: an empty array, a target below the minimum or above the maximum, runs of duplicates, and the infinite loop you get if you set lo = mid with a closed interval when hi = lo + 1.
- Generalise to binary search on the answer: if feasible(x) is monotonic, search for the smallest feasible x, as in the minimum capacity to ship within D days or an integer square root.
Follow-up
- Find the first and last positions of a target in a sorted array with duplicates.
- Search for a target in a rotated sorted array.
- How do you binary search for the smallest value that satisfies a monotonic condition?
How would you evaluate the performance of a new trading algorithm?
How would you evaluate the performance of a new trading algorithm?
Approach
- Define performance as return against risk: annualised return and volatility, the Sharpe ratio (mean excess return over its standard deviation, annualised by the square root of periods per year under an i.i.d. assumption), maximum drawdown, turnover and hit rate, compared with a benchmark or a simple baseline strategy.
- Make the backtest honest. Use point-in-time data so no decision sees future information, include delisted instruments to avoid survivorship bias, and charge realistic transaction costs, slippage, market impact and execution delay.
- Guard against overfitting. Keep an untouched out-of-sample period, use walk-forward validation, and count how many parameter sets were tried, because the best of many backtests has an inflated Sharpe ratio.
- Test significance. With per-period Sharpe S over n independent periods, the t-statistic of the mean return is about S times the square root of n. Check that the result holds across sub-periods and market regimes, not only in one window.
- Validate beyond the backtest with paper trading or small live capital. Compare live fills against the simulated ones, monitor for decay, and estimate capacity: how much capital the strategy can trade before its own impact erodes the edge.
Follow-up
- The backtest Sharpe ratio is high but live results are flat. What do you check first?
- How do you judge whether a Sharpe ratio is meaningful when many variants were tested?
- How would you model transaction costs for a strategy that trades very frequently?
How would you optimize a SQL query for performance?
How would you optimize a SQL query for performance?
Approach
- Measure before changing anything. Run EXPLAIN ANALYZE (PostgreSQL) or the engine's equivalent and look for sequential scans on large tables, estimated row counts far from the actual ones, nested loops over big inputs, and sorts or hashes spilling to disk.
- Index the filter and join columns. In a composite B-tree, put equality columns before the range column, and consider a covering index (INCLUDE) so the query can run as an index-only scan.
- Keep predicates sargable. Wrapping the column in a function (WHERE DATE(ts) = ...), a LIKE pattern that starts with a wildcard, or an implicit type cast all stop the index from being used, so rewrite them as a range on the raw column with the column's own type.
- Reduce the work: select only the columns you need, filter before joining and aggregating, replace correlated subqueries with a join or EXISTS, and page with keyset pagination (WHERE id > last_id) rather than a deep OFFSET.
- State the trade-offs and confirm the gain. Every index slows inserts and updates and takes storage. Stale statistics call for ANALYZE. Partitioning a large time-keyed table lets the planner prune partitions. Re-run the plan afterwards and compare time and buffers.
Follow-up
- The plan shows a sequential scan although the filter column is indexed. Why might the planner choose that?
- How would you speed up a query that pages thousands of pages deep with OFFSET?
- What does an extra index cost on a table that takes heavy insert traffic?
What considerations would you take into account when designing a database schema for a new application?
What considerations would you take into account when designing a database schema for a new application?
Approach
- Start from entities and access patterns. List the main reads and writes, their volumes and their latency needs, because those decide normalisation, keys and indexes.
- Normalise to roughly third normal form to avoid update anomalies. Denormalise only for a measured read path, and say how the copy is kept in sync (a trigger, an application write path or a rebuilt materialized view).
- Choose keys, types and constraints deliberately: surrogate or natural keys, foreign keys with explicit ON DELETE behaviour, and NOT NULL, UNIQUE and CHECK constraints. Store money and prices as DECIMAL/NUMERIC rather than floating point, and timestamps in UTC with a time zone type.
- Plan indexes from the query predicates and composite column order, and accept the write cost each one adds. Partition large time-series tables by date, and decide how history is kept: an append-only table or valid_from/valid_to rows.
- Plan for change. Make migrations backwards compatible by adding a nullable column, backfilling it in batches and only then adding the constraint. Decide early on soft delete versus hard delete and on how retention is enforced.
Follow-up
- How would you store every change to a record and query its state as of a past date?
- When would you denormalise, and how would you keep the copy correct?
- How do you add a NOT NULL column to a large live table without downtime?
Explain the principles of Object-Oriented Programming.
Explain the principles of Object-Oriented Programming.
Approach
- Name the four principles and give each a C++ anchor: encapsulation (private data whose invariants only member functions can change), abstraction (a pure virtual interface that hides the implementation), inheritance (public derivation for an is-a relationship) and polymorphism (a virtual call resolved at runtime through the vtable).
- Separate compile-time polymorphism (function overloading, templates, CRTP) from runtime polymorphism (virtual functions). Runtime dispatch costs one indirection and a vptr per object, and it usually blocks inlining.
- Cover the C++ pitfalls: a base class used polymorphically needs a virtual destructor, or deleting through a base pointer is undefined behaviour. Passing a derived object by value to a base parameter slices it, so pass by reference or by smart pointer.
- Argue for composition over deep hierarchies and state the Liskov substitution principle. A Square deriving from a mutable Rectangle breaks callers that set width and height independently.
- Tie the principles to patterns: a Factory returns std::unique_ptr so callers depend only on the interface, a Decorator wraps an object behind the same interface to add behaviour, and a Builder separates step-by-step construction from the finished object.
Follow-up
- Why must a base class destructor be virtual when objects are deleted through a base pointer?
- When would you choose templates or composition instead of a virtual interface?
- What is object slicing, and how do you prevent it?
How would you design a notification system for a trading application?
How would you design a notification system for a trading application?
Approach
- Fix the scope: which events (order acknowledgements, fills, rejections, price-threshold alerts), which channels (in-app over a WebSocket, mobile push, email), what latency each event type needs, and whether order-related messages must arrive in sequence.
- Lay out the components. Producers (order handling and an alert evaluator) publish events to a durable log such as Kafka, partitioned by account id so each account's events stay ordered. A notification service applies user preferences and deduplication, then hands off to per-channel workers. A WebSocket gateway serves connected clients, and a persisted inbox table keeps history.
- Choose delivery semantics. Use at-least-once delivery with an idempotency key (the event id) so a retry does not show a fill twice. Give each account's events a sequence number so a reconnecting client asks for everything after the last number it saw.
- For price alerts, keep two sorted structures of thresholds per symbol (above and below) so each tick checks only the thresholds it crossed instead of scanning every alert. Fire once, then disarm or re-arm according to the user's setting.
- Handle failure and bursts: retries with exponential backoff and a dead-letter queue, per-user rate limits that coalesce a burst of alerts into one summary, a fallback channel when push fails, and an end-to-end latency metric per event type.
Follow-up
- A burst at market open produces many times the usual alert volume. What do you queue, coalesce or drop?
- How does a client that was offline get exactly the notifications it missed, in order?
- A consumer crashes after sending a message but before committing its offset. How do you avoid a duplicate notification?
Discuss the trade-offs between microservices and monolithic architecture.
Discuss the trade-offs between microservices and monolithic architecture.
Approach
- Define both. A monolith is one deployable unit with in-process calls, usually over one database. Microservices are independently deployable services that each own their data and talk over the network.
- Monolith strengths: simple deployment and debugging, ACID transactions across modules, cheap in-process calls and easy refactoring. Its costs: coupled releases, scaling the whole process for one hot module, growing build times, and one faulty module able to take the process down.
- Microservices strengths: independent deploys and scaling, fault isolation and team autonomy. Their costs: network latency and partial failures, cross-service consistency handled through sagas or a transactional outbox, versioned APIs, distributed tracing, and more operational work.
- Make the decision from concrete drivers: the number of teams that need to release independently, components with very different scaling or latency profiles, and how stable the domain boundaries are. A modular monolith is often the right middle step, and latency-sensitive paths stay in-process.
- Describe migration as incremental. Use the strangler fig pattern to extract one bounded context at a time behind a stable interface, and move data ownership with each extracted service.
Follow-up
- How do you keep data consistent when one business operation spans two services?
- When would you merge services back into one?
- How would you find which service made a request slow?
Given a dataset, how would you approach cleaning and preprocessing it for machine learning?
Given a dataset, how would you approach cleaning and preprocessing it for machine learning?
Approach
- Profile first: column types, value ranges, missing rate per column, duplicate rows and the label distribution. Pin down what is being predicted and at what point in time the prediction is made.
- Split before fitting any transformation. Use a time-based split when rows are ordered in time, and fit imputers, scalers and encoders on the training split only, for example inside an sklearn Pipeline, so validation scores are not inflated by leakage.
- Handle missing values and outliers explicitly. Impute with the median or mode and add a missing-indicator column when missingness may carry signal. Separate data errors from genuine extreme values (returns data often has real fat tails), then clip, winsorise or use robust scaling.
- Encode and scale to suit the model. Use one-hot encoding for low-cardinality categoricals and out-of-fold target encoding or hashing for high-cardinality ones. Distance-based and gradient-based models need scaling, tree ensembles do not.
- Check for leakage and imbalance. Every feature must be available at prediction time (no look-ahead), duplicates must not straddle splits, and class imbalance is handled with class weights or resampling applied only to the training data.
Follow-up
- One feature predicts the label suspiciously well. How do you check whether it leaks?
- How would you handle a categorical column with tens of thousands of distinct values?
- How do you build validation folds when rows are ordered in time?
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 reported loop: it starts with the coding game format, covers the languages and topics candidates list, rehearses the reported design and case-study questions, and ends with the behavioral stories.
Prepare, practise & reflect
One practical outcome each day. Spend longer where you need it.
0 / 7 done01Map the loop and set up timed coding practice
- Write down the three reported stages and the topics candidates list (C++, SQL, Python, Linux command line, algorithms, design patterns), and mark the two you are weakest in.
- Solve two puzzle-style problems in the language you will use for the coding game, with a timer you set yourself, and note where you lost time reading or debugging.
Deliverable: A one-page loop map with your two weakest topics marked, and a short note on where time went in the two timed puzzles.
02Core algorithms in C++
- Write the linked-list reversal iteratively and recursively, and test the empty list and the one-node list.
- Solve the two-numbers-to-a-target problem with a hash map, then with sorting and two pointers, and compare time and memory.
- Implement binary search with inclusive and half-open bounds, plus a lower-bound variant, and test duplicates and missing targets.
Deliverable: Three tested C++ functions with a note of the complexity and edge cases for each.
Practice prompt ↗Practice prompt ↗Practice prompt ↗03SQL performance and schema design
- Take a slow query on a table you build locally, read its plan, add or change an index, rewrite the join, and record the before and after plans.
- Sketch a schema for a new application with keys, constraints, normalisation choices and the indexes the main queries need.
Deliverable: A before-and-after query plan comparison and a schema sketch with its main queries.
Practice prompt ↗Practice prompt ↗04OOP, design patterns and Linux command line
- Write a short explanation of encapsulation, inheritance, polymorphism and abstraction, each with a C++ class example.
- Implement a Builder, a Decorator and a Factory in C++ and write one sentence on when each is the wrong choice.
- Use grep, sort, uniq, awk and xargs to answer five questions about a large log or CSV file on the command line.
Deliverable: One C++ file with the three patterns, and five saved shell one-liners with their outputs.
Practice prompt ↗05Design and case-study answers
- Design the trading-application notification system out loud: producers, queue, delivery, deduplication, ordering and failure handling.
- Prepare a two-column comparison of microservices and a monolith for a trading system, ending with a recommendation.
- Write your approach to preparing a dataset for machine learning and to evaluating a new trading algorithm, naming leakage, look-ahead bias and transaction costs.
Deliverable: Three structured spoken answers, each with its assumptions and failure modes written down.
Practice prompt ↗Practice prompt ↗Practice prompt ↗Practice prompt ↗06Debugging in C++
- Write up your best C++ debugging story using the sequence reproduce, minimise, hypothesise, confirm with a tool, fix, add a test.
- Work through the debugging practice question in PracHub's practice set, stating your hypotheses before you open any file.
Deliverable: A written debugging story and a short log of the hypotheses you tested on the practice question.
Practice prompt ↗Practice prompt ↗07Behavioral stories and a full run-through
- Rehearse the challenging-project, prioritisation and team-conflict answers aloud, in first person, and cut each to a clear structure.
- Run a full mock: one timed coding problem, one design question, then the three behavioral prompts, and write down what to fix.
- Prepare three questions about the team, the codebase and working with quantitative analysts.
Deliverable: Three rehearsed stories, a list of fixes from the mock run, and your list of questions.
Practice prompt ↗Practice prompt ↗Practice prompt ↗Expand any day for tasks and deliverables. Your progress is saved on this device.
Candidates describe the HR stage as a conversation about cultural fit and past experiences, and the technical stage as returning to experience in more depth. For this role, prepare stories that show your own decisions, how you work with colleagues and quantitative users, and how you handle a difficult bug in production-style code.
Describe a time when you had to debug a complex issue in a C++ application.
Describe a time when you had to debug a complex issue in a C++ application.
Approach
- Choose a bug that was hard to find, not one that was only urgent, and state its symptom in a sentence or two, for example a crash that appeared only in release builds or only under load.
- Walk through your method in order: reproduce it reliably, shrink the input or the code path, form a hypothesis, then confirm it with a tool such as gdb or a core dump, AddressSanitizer, UndefinedBehaviorSanitizer, Valgrind, or ThreadSanitizer for races. Say why you chose that tool.
- Name the root cause precisely, for instance a dangling reference, iterator invalidation, use after free, uninitialised memory, a data race, or an integer overflow, and explain how it explains every symptom you saw.
- Close with the fix, a regression test that fails without it, and what you changed to prevent the class of bug (smart pointers, sanitizers in CI, a code review rule). Keep the story about your decisions, not the team's.
Follow-up
- The bug only appeared in the optimised build. How would you have narrowed it down?
- How did you know the fix addressed the cause rather than hiding the symptom?
- What would you have changed in the code or tooling so a colleague would have caught it earlier?
Describe a challenging project you worked on. What was your role, and what did you learn?
Describe a challenging project you worked on. What was your role, and what did you learn?
Approach
- Pick a project where the difficulty was technical or organisational and real, and state your role in the first sentence: what you owned, what the scope was, and who else was involved.
- Use a situation, task, action, result structure but spend most of the time on actions: the options you weighed, the one you chose and the trade-off you accepted. For this role, a project involving data volume, performance or correctness is a natural fit.
- Say what made it hard in concrete terms (an unclear requirement, a performance target, a legacy system) and what you did when the first approach failed.
- End with a measurable result and a specific lesson that changed how you work afterwards. Say "I" for your decisions and name teammates for theirs; a story told entirely as "we" hides your part.
Follow-up
- Which decision on that project would you now make differently, and why?
- What was your part, and what did colleagues do?
- How did you know the project had actually succeeded?
How do you prioritize tasks when working on multiple projects?
How do you prioritize tasks when working on multiple projects?
Approach
- Answer with a method and then a real example. Method: list everything you owe, estimate the impact and deadline of each, identify dependencies and blockers, then order by impact and deadline and agree the order with the people affected.
- Describe a concrete moment when two projects collided, say what you chose to do first, and what you deliberately delayed or dropped.
- Show the communication step: whom you told, how you reset expectations or negotiated scope, and what you did when a request was marked urgent by someone else.
- Show how you check in afterwards, for example by re-ranking when new information arrives, and give an outcome, such as a deadline met or a risk avoided. A generic claim of using a task list without a trade-off shows no judgement.
Follow-up
- Two stakeholders both say their request is the top priority. What do you do?
- Tell me about something you decided not to do, and how you told the person.
- What happens to your ordering when a production issue arrives mid-week?
Can you give an example of how you handled conflict within a team?
Can you give an example of how you handled conflict within a team?
Approach
- Choose a genuine disagreement about work, such as a design choice, a code review comment or a deadline, not a personality clash, and describe both positions fairly without casting the other person as the problem.
- Show how you moved it forward: you listened for the reason behind their view, found the actual point of difference, and used evidence such as a benchmark, a prototype or a test case to settle it.
- Say whether you compromised or held your position, and what you did when it stayed unresolved, such as bringing in a manager after trying to settle it directly.
- Finish with the outcome for the project and for the working relationship, and one thing you now do earlier to avoid that kind of conflict. A story with no tension, or one where you simply won, shows little.
Follow-up
- What if the other person still disagreed after you showed the data?
- When would you take a disagreement to your manager?
- Would you handle it differently if the colleague were more senior than you?
- 01
Describe a challenging project you worked on. What was your role, and what did you learn?
- 02
How do you prioritize tasks when working on multiple projects?
- 03
Can you give an example of how you handled conflict within a team?
- 04
Describe a time when you had to debug a complex issue in a C++ application.
- 05
What design patterns have you used in your projects, and why?
- 06
How do you make sure your code is good before it is deployed?
What stages do candidates report for the Software Engineer loop?
Candidates report three stages: a Coding Assessment taken as a coding game (CodinGame is named as an example of the platform), an HR Interview about cultural fit and past experiences, and Technical Interviews with managers and team members about coding challenges and experience. Treat this as a candidate-described sequence rather than a published process.
PracHub Software Engineer practice ↗How long does the process take?
Candidates report roughly 3-5 weeks across the three stages, and another report in the same material puts it at 4-6 weeks depending on scheduling. Plan for the longer end, and keep your practice going between stages instead of preparing everything at the start.
PracHub Software Engineer practice ↗Which technologies should I prepare?
The requirements candidates describe list C++, Python and SQL, plus experience with Linux and its command-line tools, and an understanding of algorithms and data structures. The topics reported for the technical stage are C++, SQL, Linux command line, algorithmic problem solving and the design patterns Builder, Decorator and Factory. Cloud services, microservices and financial software experience are described as extras.
PracHub Software Engineer practice ↗How should I prepare for the coding game?
Practise puzzle-style problems on a game-based coding platform with a timer you set yourself, in the language you will use. Rehearse the classic problems reported, reversing a linked list, finding two numbers that add up to a target and binary search, until you can write them correctly with edge cases. Check how the platform reads input and prints output before the day.
PracHub Software Engineer practice ↗Do I need to prepare system design and case-study questions?
Candidates report questions on a notification system for a trading application, microservices versus a monolith, database schema design, preparing a dataset for machine learning, and evaluating a new trading algorithm. Prepare each as a structured spoken answer with assumptions, components and failure modes, which also helps in the technical discussions.
PracHub Software Engineer practice ↗Is on-site work or finance knowledge required?
Candidates report that most positions are on-site in Paris, and that the policy may change, so ask during the process. Basic familiarity with financial concepts is reported as helpful, not required; reading about how trading systems and quantitative research use software is enough to follow the conversation.
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.
- 01Capital Fund Management 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.
Recursion Pharmaceuticals Software Engineer Interview Guide
What Recursion Pharmaceuticals asks Software Engineer candidates, from reported rounds and questions.
Overjet Software Engineer Interview Guide
What Overjet asks Software Engineer candidates, from reported rounds and questions.
Landing Ai Software Engineer Interview Guide
What Landing Ai asks Software Engineer candidates, from reported rounds and questions.
Brain Software Engineer Interview Guide
What Brain asks Software Engineer candidates, from reported rounds and questions.