The reported questions fall into four groups. Technical and domain questions cover frontend state management, higher-order components, a multi-table SQL aggregation, CI/CD with automated test coverage, and the choice of frameworks for a scalable full-stack project. System design questions centre on integrating legacy platforms with microservices, resilient cloud architecture, data privacy and compliance, and troubleshooting a performance bottleneck in a distributed environment. Coding questions ask for a live-coding walkthrough in C# or Python with complexity reasoning, unit and integration testing, and a walkthrough of a home task. The behavioral group covers a hard technical problem, competing deadlines in an agile team, explaining technical material to a non-technical partner, and a technical disagreement.
Candidates describe a mixed loop: an online coding test on a platform such as Code In Game, a take-home assignment or live coding in some loops, a project discussion with system design, and a final conversation with engineering managers or group heads. The requirements candidates describe list a modern language (Python, JavaScript or C#), relational databases and SQL, version control and CI/CD. They list insurance or fintech experience, cloud familiarity and enterprise integration patterns as nice-to-haves. That mix means breadth matters: you need working code, a defensible architecture and a clear account of your own past projects.
Spend preparation time in proportion to how much of it you can already do cold. Write SQL and a short coding solution from a blank file, rehearse two or three architecture stories you can defend decision by decision, and prepare behavioral stories that name your own actions. The rest of this guide gives a concrete approach and likely follow-ups for each reported question, then a seven-day plan that cycles through them.
Recruiter Screening
reportedCandidates describe an opening phone or video conversation covering your professional background, any visa or location considerations, and why you want to join AXA. Nothing technical is reported for this stage, so treat it as a clean, rehearsed summary of your experience that also gives you a chance to ask what the later rounds will look like.
What to demonstrate
- How clearly you summarise your background and recent work
- Whether your location or visa situation fits the role
- Your stated motivation for joining AXA
How to prepare
- Write a short spoken summary of your career that ends with the stack you want to work in (Python, JavaScript or C#, SQL, cloud).
- Prepare a specific, truthful reason for applying that refers to the kind of work the role involves, such as platform modernisation or enterprise integration.
- Ask which language the coding stage uses and whether a take-home or an online coding test comes first.
Technical Evaluation
reportedThe Technical Evaluation is reported as one or more rounds that can include a take-home assignment, a coding assessment (platforms such as Code In Game are mentioned) and a live technical interview with senior engineers. This is the stage where the coding, SQL, testing and CI/CD question types are practised. Expect to produce working code, explain its complexity and defend your choices aloud.
What to demonstrate
- Working code with sensible error handling in your chosen language
- Data structure and complexity reasoning during a live exercise
- SQL fluency across several relational tables
- Test coverage and how your work reaches deployment
How to prepare
- Solve two timed problems in C# or Python from a blank file, say the brute-force complexity first, and finish with tests.
- Write an aggregation across three or more joined tables and check the join cardinality before trusting the totals.
- Prepare a clear account of a pipeline you have worked with: its stages, its test layers and what blocks a release.
- Complete one small take-home-style project and write a short note on your architectural choices, so you can walk through it.
Project Deep Dive
reportedCandidates describe the Project Deep Dive as a discussion of past projects together with system design. The design side is reported to centre on connecting legacy platforms with modern services, API design, microservices, cloud and CI/CD, and relational schemas. Choose projects where you made real decisions and can explain what you would change now.
What to demonstrate
- Your depth on projects you list on your CV
- System design for integration across legacy and modern services
- Handling of data privacy and security within an architecture
- Trade-off reasoning about frameworks, databases and cloud choices
How to prepare
- Pick two projects and write the architecture, your own contribution, the hard decision, and what you would change.
- Practise the design of an integration pipeline between a legacy core system and a cloud service, including the migration path.
- Prepare a security and privacy pass for any design you give: data classification, encryption, access control and audit trail.
- Be ready to justify a full-stack framework choice for both frontend and backend with at least one rejected alternative.
Behavioral Interview
reportedThe Behavioral Interview is reported to focus on problem-solving style and workplace values. Reported prompts include a hard technological problem, prioritising under competing deadlines in an agile team, explaining technical information to a non-technical partner and handling a technical disagreement. Prepare stories where your own decision is visible.
What to demonstrate
- The way you break down a difficult technical problem
- Prioritisation and communication inside an agile team
- How you handle disagreement and feedback
- Clarity when talking to non-technical colleagues
How to prepare
- Write four STAR stories, one per reported prompt, each with the situation in two sentences and the remainder on your actions and result.
- Add a number or an observable outcome to every story, such as an incident rate, a release date or a latency figure.
- Rehearse one story that includes agile ceremonies, such as how a sprint commitment changed after you raised a risk.
- Practise saying each story aloud, because the reasoning is hard to deliver cleanly the first time.
Final Interview
reportedCandidates describe the Final Interview as an onsite or video panel conversation with engineering managers or group heads. The reports do not say which topics the panel covers, so prepare to revisit anything from earlier rounds: project decisions, a design under changed constraints, a troubleshooting scenario and your collaboration style. Ask the recruiter beforehand who will be on the panel.
What to demonstrate
- Consistency between what you said in earlier rounds and what you say now
- Breadth across design, delivery and teamwork in a panel setting
- Your questions about the team's stack and ways of working
How to prepare
- Review your notes from every earlier round and list the follow-ups you were unsure about, then prepare answers for each.
- Rehearse the troubleshooting of a performance bottleneck in a distributed system as a repeatable sequence you can say aloud.
- Prepare questions for engineering managers about the team's delivery model, release process and use of C#, Python or JavaScript.
- Practise one answer that connects an engineering decision to a business outcome, in plain language.
PracHub editorial advice for the preparation topics above.
Describing a pipeline or cloud setup as 'we used CI/CD and AWS' without saying what you built or owned
Prepare one concrete pipeline or deployment from your own work: its stages, the tests at each stage, what blocked a release and one thing you changed. Say 'I' for your part and name the evidence.
Writing a multi-table SQL aggregation that joins first and sums later, which inflates totals when a join is one-to-many
State the grain of the result, check the cardinality of each join, and aggregate the many-side in a subquery before joining if needed. Check the result against a hand-counted row or two.
Giving a system design for legacy integration with no mention of security, data privacy or migration path
After the main flow, run a fixed pass: what personal data moves, how it is encrypted and who can read it, how you audit it, and how you cut over from the legacy system with a rollback.
Being unable to explain decisions on a project or take-home you list, such as why that framework, schema or test strategy
Before each round, reread your own repositories and write down two rejected alternatives and the reasoning for each project. Be honest about what you would change.
Giving behavioral answers where the group did everything, or where the outcome has no number and no stake
Select stories where your decision is visible, state the result with a figure or date, and rehearse each aloud. Name what you would change, which shows reflection rather than defensiveness.
Choose a category, try a prompt, then open its approach, worked solution or follow-up when you need it.
Walk me through a live-coding exercise in C# or Python, explaining your time and space complexity consideratio
Walk me through a live-coding exercise in C# or Python, explaining your time and space complexity considerations.
Approach
- Restate the problem with a small example, ask about input size, value ranges, duplicates and empty input, then name the brute force with its cost (for a pair-sum, nested loops: O(n^2) time, O(1) extra space) before improving it.
- Improve it by choosing the data structure from the access pattern. A Python dict or set, or a C# Dictionary<TKey,TValue> or HashSet, gives average O(1) lookups, so a single pass is O(n) time and O(n) space. Sorting plus two pointers is O(n log n) time with little extra space. Say which one you pick and why.
- Know your language's costs. Python's sorted() is Timsort: stable, O(n log n). In C#, Array.Sort and List.Sort are not stable, while LINQ OrderBy is. Building a string with += in a loop can cost O(n^2); use ''.join in Python and StringBuilder in C#. Python ints never overflow; a C# int is 32-bit, so use long or a checked block for large sums.
- Write it in small, named pieces, then trace it by hand on your example. Test the edges out loud: empty input, one element, all duplicates, negative values, the largest input size. Finish by restating the final time and space complexity.
Follow-up
- The input no longer fits in memory. How would you change the solution?
- What is the worst case for your hash-based solution, and when could it happen?
- Can you get the extra space down to O(1), and what does that cost in time?
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?
How would you write an SQL query to aggregate transaction data across multiple relational tables?
How would you write an SQL query to aggregate transaction data across multiple relational tables?
Approach
- Fix the output grain first, for example one row per customer per month. Then write down the cardinality of every join (customer 1:N account, account 1:N transaction) before writing SQL.
- Aggregate at the transaction grain before joining anything else that is one-to-many. Example: WITH t AS (SELECT account_id, date_trunc('month', txn_date) AS m, SUM(amount) AS total, COUNT(*) AS n FROM transactions GROUP BY 1, 2), then join t to accounts and customers. If you join two one-to-many tables first and then SUM, the totals are multiplied.
- Choose join types on purpose. Use customers LEFT JOIN t with COALESCE(t.total, 0) when customers who have no transactions must still appear. Filter rows in WHERE and filter groups in HAVING. A condition on the right-hand table belongs in the ON clause, otherwise the LEFT JOIN quietly becomes an inner join.
- Cover the data edge cases: NULL amounts (SUM skips them, COUNT(amount) does not count them, COUNT(*) does), refunds stored as negative amounts, mixed currencies (join a rates table on currency and date before summing), and duplicates (COUNT(DISTINCT txn_id)).
- Talk about performance: a composite index on transactions (account_id, txn_date) supports the join and a date-range filter. Wrapping the indexed column in a function inside WHERE stops the index being used, so write the filter as a range: txn_date >= :start AND txn_date < :end.
Follow-up
- Add a running monthly balance per account. Which window function would you use, and how would you partition and order it?
- The query is slow on a very large transactions table. What would you check in EXPLAIN ANALYZE first?
- How would you rank each customer's top three months by spend, keeping ties?
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?
Can you explain how high-order components work in modern frontend frameworks?
Can you explain how high-order components work in modern frontend frameworks?
Approach
- Define it precisely: in React, a higher-order component is a function that takes a component and returns a new component, for example withAuth(Profile). It renders the wrapped component with extra props or behaviour; it does not change the original. react-redux connect() is a well-known example.
- Show the shape in code: const withLoading = (Wrapped) => (props) => props.loading ? : <Wrapped {...props} />. Spread the props you do not use so the wrapped component still receives them, and set a displayName such as withLoading(Profile) so it is easy to find in DevTools.
- Name the pitfalls. Never create the HOC inside render: each render then produces a new component type, so React unmounts the subtree and loses its state. Static methods are not copied to the wrapper (hoist-non-react-statics does that). Before React 19, refs need React.forwardRef because ref is not passed as an ordinary prop.
- Compare with hooks. For logic that is about state or effects, a custom hook (useAuth, useFetch) is now the usual choice: it avoids wrapper nesting and prop-name clashes between stacked HOCs. HOCs still suit cases that wrap rendering, such as error boundaries, permission gates or library integrations.
Follow-up
- Two HOCs both inject a prop called data. What happens, and how would you avoid it?
- Rewrite this withSubscription HOC as a custom hook. What do you gain and what do you lose?
- How would you type a HOC in TypeScript so the wrapped component's own props stay checked?
Which frameworks and libraries would you choose for developing a scalable full-stack project involving both fr
Which frameworks and libraries would you choose for developing a scalable full-stack project involving both frontend and backend components?
Approach
- Say the criteria before naming any tools: what the team already knows, typing and refactoring safety, the size of the ecosystem, how easy it is to test, and how the system has to scale. The languages candidates report for this role are Python, JavaScript and C#, so ground your choices in those.
- Give a concrete stack and justify each layer. Frontend: React with TypeScript, with a server-state library such as TanStack Query for API data and a small store only for client state. Backend: ASP.NET Core (C#) or FastAPI/Django (Python). Data: PostgreSQL behind an ORM (Entity Framework Core or SQLAlchemy) with versioned migrations.
- Keep the frontend and backend contract in sync: publish an OpenAPI spec from the backend and generate typed client code from it, so a breaking change shows up as a compile error.
- Explain what makes it scale: a stateless API behind a load balancer, sessions in tokens or a shared store, caching for hot reads, a queue and workers for slow jobs, plus CI with tests and containerised deploys. Start as a modular monolith and split out services only when there is a real reason to.
- State the trade-offs: SSR (Next.js) helps first load and SEO but adds a server tier; a SPA is simpler to host. Python is quick to write; C# gives static typing and strong runtime performance. Choose for this team's context, not by preference alone.
Follow-up
- When would you split this monolith into services, and what would you split out first?
- How do you handle authentication between the SPA and the API?
- Your API's p99 latency doubles under load. Which layer do you look at first?
How would you approach designing a scalable system integration across multiple legacy platforms and microservi
How would you approach designing a scalable system integration across multiple legacy platforms and microservices?
Approach
- Start with an inventory: for each legacy system, list how it can be reached (REST, SOAP, a shared database, nightly batch files, a message queue), how much traffic it can take, and who owns its data. That decides the integration style for each one.
- Put an anti-corruption layer (an adapter service) in front of each legacy system. It translates the legacy model into a canonical model, so microservices never depend on legacy formats, and it lets you replace systems gradually with the strangler fig pattern.
- Prefer asynchronous events where the business allows eventual consistency. Use a broker (Kafka or RabbitMQ). Use the transactional outbox pattern so a database write and its event cannot diverge. Use change data capture (for example Debezium) when a legacy system has no API. Keep synchronous calls only where the caller needs an immediate answer.
- Design for failure: idempotent consumers keyed on a message or business id, retries with exponential backoff and jitter, a dead-letter queue with replay, timeouts and circuit breakers on synchronous calls, and a scheduled reconciliation job that compares totals between systems.
- Make it observable and safe to change: propagate a correlation id across every hop, trace with OpenTelemetry, version contracts (a schema registry for events), and add consumer-driven contract tests so one team cannot break another without the build failing.
Follow-up
- One legacy system accepts only a nightly batch file. How do you keep downstream services consistent during the day?
- Events for the same policy arrive out of order. How do you preserve ordering, or tolerate not having it?
- How would you migrate a single capability off the legacy platform with no downtime?
How do you manage data privacy, security standards, and compliance requirements within your system architectur
How do you manage data privacy, security standards, and compliance requirements within your system architecture?
Approach
- Classify the data first: which fields are personal, financial or health data. Collect only what each feature needs, and record the purpose and retention period for each category. Every later control depends on this map.
- Protect the data: TLS in transit, encryption at rest with keys managed in a KMS and rotated, and field-level encryption or tokenisation for the most sensitive fields so most services only ever see a token. Keep secrets in a vault, never in code or config files.
- Control and record access: least-privilege service identities, role-based access for people, separate production and non-production data (masked or synthetic in test), and append-only audit logs of who read or changed sensitive records. Keep personal data out of application logs.
- Build compliance into delivery: static analysis and dependency scanning in CI, threat modelling for new data flows, and retention jobs that delete or anonymise data on schedule. Erasure requests under regulations such as GDPR need an answer for backups and event logs; crypto-shredding (destroying a per-subject key) is one option.
- State the trade-offs: encryption and tokenisation make searching and analytics harder (deterministic encryption allows equality lookups but leaks which values are equal). Data-residency rules can restrict which regions or cloud services you can use.
Follow-up
- A customer asks to be deleted, but their data is in an immutable event log and in backups. What do you do?
- How do you let analysts query data that contains personal information without exposing it?
- How would you detect that personal data has leaked into logs?
How do you approach writing unit tests and integration tests for newly implemented features?
How do you approach writing unit tests and integration tests for newly implemented features?
Approach
- Start from behaviour: list the feature's rules and its edge cases (boundaries, empty and null input, error paths, permissions) and turn each one into a named test in arrange-act-assert form. Test what the code does, not how it is built, so refactoring does not break tests.
- Unit tests: fast and isolated, using pytest, xUnit/NUnit or Jest. Replace only the dependencies at the boundary (clock, network, random numbers) by injecting them, so the tests are deterministic. Too much mocking only tests the mocks.
- Integration tests: exercise the real boundaries. Use a real database through Testcontainers rather than an in-memory substitute that behaves differently. Call the HTTP layer in process (ASP.NET Core WebApplicationFactory, FastAPI TestClient). Use contract tests for APIs other teams consume.
- Keep the balance of the test pyramid: many unit tests, fewer integration tests, a handful of end-to-end tests on the critical journeys. Run all of them in CI on every pull request. Treat branch coverage on changed code as a signal, and write a failing test for every bug before fixing it.
Follow-up
- An integration test fails intermittently in CI. How do you track down the cause?
- Your code calls a third-party payment API. How do you test it without calling that API?
- When is a mock-heavy unit test worse than having no test?
Can you describe a home task or technical assessment you completed recently and walk through your architectura
Can you describe a home task or technical assessment you completed recently and walk through your architectural choices?
Approach
- Open with the brief and the constraints: what was asked, how much time you had, and what you deliberately left out of scope. Being explicit about what you skipped and why is stronger than presenting the task as complete.
- Walk through the structure layer by layer: API or controller, service or domain logic, persistence behind a repository interface. For each layer, give the reason it is separate (testability, the option to swap storage) and say whether it was worth it at this size.
- Name two or three real trade-offs with what you would choose at production scale: SQLite or in-memory storage versus PostgreSQL, synchronous processing versus a queue, a single module versus separate services, an off-the-shelf library versus your own code.
- Show how you checked it: which tests you wrote and what they cover, input validation and error handling, and a README with setup steps and assumptions. Then list what production would need: authentication, pagination, logging and metrics, configuration through the environment, a container and a CI pipeline.
- Prepare to change it live. Know the code well enough to add a field, an endpoint or a validation rule on the spot, and to say which tests would break.
Follow-up
- The data volume grows a hundredfold. What breaks first in your design?
- What would you refactor first if you had another day?
- Add a new requirement now. Where in the code does it go, and what tests do you add?
Explain how you would troubleshoot a performance bottleneck in a distributed enterprise environment.
Explain how you would troubleshoot a performance bottleneck in a distributed enterprise environment.
Approach
- Pin down the symptom with numbers: which endpoints, which percentile (p50 against p99), since when, and whether it is every user or one region, tenant or payload size. Check what changed in that window: deploys, config, traffic mix, data volume.
- Find where the time goes before forming theories. Follow a slow request through distributed traces to the span that accounts for the latency. Check each service's rate, errors and duration, and each resource's utilisation, saturation and errors (CPU, memory, connection pools, thread pools, disk, network).
- Work through the usual culprits in that span. In the database: slow query log, EXPLAIN ANALYZE, missing indexes, N+1 queries, lock waits. In the application: an exhausted connection pool, a saturated thread pool, garbage-collection pauses. Between services: timeouts set too high, retry storms, chatty synchronous calls.
- Use Little's law to check whether the numbers add up: requests in flight = throughput x latency. If the database pool has 20 connections and queries now take 100 ms, that pool tops out at about 200 queries per second. Anything above that queues.
- Change one thing, measure the same percentile under comparable load, then add protection so it cannot return quietly: an alert on that metric, a load test in CI, or a cap such as a timeout, bulkhead or rate limit.
Follow-up
- Latency is high but CPU and memory look normal on every host. Where do you look next?
- How would you tell a slow downstream service apart from your own service queuing requests?
- The slowness only happens during the nightly batch window. How do you investigate?
The plan starts with your own projects and the loop map, then covers SQL, live coding, frontend and full-stack topics, system design, delivery and testing, and finishes with behavioral rehearsal. Each day lists the reported questions it practises, plus PracHub practice items where they fit.
Prepare, practise & reflect
One practical outcome each day. Spend longer where you need it.
0 / 7 done01Map the loop and choose your projects
- Write the five reported rounds and, for each, what you still need to confirm with the recruiter (language, take-home, platform, panel members).
- Choose two projects from your CV for the project discussion and write an architecture summary for each: components, data flow, your role, the hardest decision, what you would change.
Deliverable: A one-page round map with open questions for the recruiter, plus two architecture summaries.
02SQL across relational tables
- Write an aggregation across three tables (for example accounts, transactions and categories) and check the cardinality of every join before trusting the sums.
- Rewrite it so the many-side is pre-aggregated, then compare results and explain the difference.
- Do the PracHub practice exercise on detecting a concurrent edit in an update path, then explain how it relates to concurrent writes on transaction data.
Deliverable: Two working queries with a short note explaining the grain and the join check, plus the practice solution.
Practice prompt ↗Practice prompt ↗03Live coding in C# or Python
- Solve two array, string, tree or graph problems in your chosen language from a blank file, saying the brute-force complexity before improving it.
- Do the PracHub practice problems on merging event streams and archiving a resource graph without recursion; state time and space complexity for each.
- Write unit tests for each solution, including empty input and duplicates.
Deliverable: Four tested solutions with complexity written next to each.
Practice prompt ↗Practice prompt ↗Practice prompt ↗04Frontend, state and full-stack choices
- Write a one-page explanation of how higher-order components work, with a small example, and how hooks or composition can replace them.
- Outline how you manage state in a large application: the kinds of state, the tool for each and a failure case such as out-of-order responses.
- Choose a framework and library stack for a scalable full-stack project and write the reasons and one rejected alternative for each layer.
Deliverable: A written explanation of higher-order components, a state strategy sheet and a justified stack choice.
Practice prompt ↗Practice prompt ↗Practice prompt ↗05Integration, cloud and troubleshooting
- Design an integration between a legacy core system and a cloud service: API layer, queue, data mapping, security pass and cutover with rollback.
- Design a resilient cloud service with failure modes, RTO and RPO, and write your own cloud experience as a short story.
- Write a troubleshooting sequence for a distributed performance bottleneck: confirm the symptom, check recent changes, trace requests, find the slow hop, fix and verify.
Deliverable: Two design diagrams with notes, and a numbered troubleshooting checklist.
Practice prompt ↗Practice prompt ↗Practice prompt ↗Practice prompt ↗06Testing, CI/CD and the take-home walkthrough
- Write how you decide between unit and integration tests for a new feature, with one example of each for the same feature.
- Describe a pipeline from your own work with stages, gates and rollback, and add how you would gate coverage on changed code.
- Prepare a walkthrough of a take-home or assessment you completed: requirements, architecture, trade-offs and what you would improve.
Deliverable: A testing strategy note, a pipeline description in your own words and a take-home walkthrough outline.
Practice prompt ↗Practice prompt ↗Practice prompt ↗07Behavioral rehearsal and full mock
- Write four STAR stories for the technical problem, competing deadlines, explaining to a non-technical partner and the disagreement, each with an outcome you can measure.
- Say each story aloud and trim until the situation takes two sentences and your actions take the most time.
- Run a full mock: one SQL query, one coding problem, one design and one story, then list the weakest answer and rework it.
Deliverable: Four rehearsed stories and a mock review listing the weakest answer and its fix.
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 Interview as a look at your problem-solving style and working values, and the reported prompts centre on a hard technical problem, deadlines in an agile team, communication with non-technical partners and technical disagreement. Prepare stories where your own decision and its result are visible, in STAR form.
What state management libraries do you prefer, and how do you handle complex state flows in large applications
What state management libraries do you prefer, and how do you handle complex state flows in large applications?
Approach
- Start by splitting state into kinds: local component state, shared client state, server data fetched over APIs, URL state and form state. Each kind gets a different tool, and naming them shows you do not put everything in one global store.
- Name tools you have used and why. For example, Redux Toolkit or NgRx when many components need predictable, traceable updates, Zustand or Context for small shared state, and TanStack Query for server data with caching and refetching. Say which one you would not use for a given case.
- For complex flows, describe the mechanics: normalised entities, selector functions, actions or events that describe what happened, and side effects such as API calls isolated from reducers. Mention optimistic updates and how you roll back on failure.
- Cover costs and edge cases: re-renders from broad subscriptions (fixed with selectors or memoisation), stale server data, race conditions between overlapping requests, and testing reducers and selectors as plain functions.
Follow-up
- How do you stop a state change from re-rendering components that do not use it?
- When would you refuse to put something in a global store?
- How do you handle two in-flight requests that return out of order?
What is your experience with CI/CD pipelines, and how do you ensure automated test coverage before deployment?
What is your experience with CI/CD pipelines, and how do you ensure automated test coverage before deployment?
Approach
- Treat this as a technical design answer: describe the pipeline stages in order. Lint and static analysis, unit tests, build an immutable artifact once, integration tests against real dependencies (Testcontainers or a test database), deploy the same artifact to staging, smoke tests, then production.
- Make tests block the merge: run them on every pull request and require the check to pass before merging. Use coverage as a signal, set as a floor on changed lines or branches, not as a target, because a high line coverage figure can still miss the error paths.
- Keep the pipeline fast and reliable: cache dependencies, run test suites in parallel, quarantine and fix flaky tests rather than retrying them silently, and fail on the first stage that breaks.
- Make releases low risk: blue-green or canary deployment, feature flags, database migrations that stay backward compatible with the previous release (expand, then contract), and an automated rollback triggered by health checks.
Follow-up
- A test fails one run in twenty. How do you find out why?
- How do you run a schema migration without breaking the version of the app still serving traffic?
Can you describe your experience with cloud infrastructure and how you would architect a resilient cloud-based
Can you describe your experience with cloud infrastructure and how you would architect a resilient cloud-based service?
Approach
- Open with your actual experience: what you ran on which cloud, who operated it, and the scale. Then walk through a design for a resilient service rather than listing product names.
- Describe the layers: stateless services behind a load balancer across several availability zones, autoscaling, a managed database with replicas and automatic failover, a queue to decouple slow or unreliable work, and health checks that remove bad instances.
- Include client-side resilience: timeouts on every call, retries with exponential backoff and jitter only for idempotent operations, circuit breakers, and idempotency keys so a retry does not double-apply. Add infrastructure as code, centralised logs, metrics and alerts.
- Set recovery targets. Define RTO and RPO, say how backups are tested by restoring them, and describe when multi-region failover is worth its cost and complexity versus multi-zone.
Follow-up
- What are your RTO and RPO for this service, and what drives them?
- How would you test that failover works before a real outage?
- What changes if a whole region becomes unavailable?
Tell me about a time you faced a difficult technological problem in your academic or professional career and h
Tell me about a time you faced a difficult technological problem in your academic or professional career and how you resolved it.
Approach
- Choose a problem with real technical content, such as a memory leak, a deadlock, a slow query, an integration failure or a hard algorithmic bug. An academic project is acceptable if the difficulty was real and you made the key decisions.
- Use STAR but spend most of the time on the diagnosis: the symptoms, the hypotheses you listed, how you eliminated them (logs, profiling, a minimal reproduction) and the root cause.
- State the fix, the alternative you rejected and why, and how you verified it, ideally with a before and after number or a regression test.
- Close with what you changed afterwards so it would not recur, such as a test, a monitor or a documented decision. Avoid saying 'we' for everything, because the story has to show your own contribution.
Follow-up
- What was the second most likely cause, and how did you rule it out?
- What would you do differently if you met the same problem again?
- How did you know the fix worked and did not just hide the symptom?
How do you prioritize tasks when managing multiple competing deadlines in an agile environment?
How do you prioritize tasks when managing multiple competing deadlines in an agile environment?
Approach
- Show a method, not a feeling. List every commitment, write down the real deadline and the consequence of missing it, note dependencies, and compare value against effort. Production incidents and blocked teammates come before planned work.
- Describe how you use the agile structure: ask the Product Owner to rank items, split large stories so something useful ships on time, and negotiate scope rather than silently absorbing it.
- Use one concrete example with numbers: two deadlines collided, you made the trade-off visible in the sprint, told stakeholders early, and the outcome was a specific date kept or a scope cut agreed.
- Avoid the story where you worked late to fit everything in. Say what you chose not to do and how you communicated it.
Follow-up
- The Product Owner says everything is top priority. What do you do?
- An urgent request arrives mid-sprint. How do you handle it?
- How do you tell stakeholders a deadline will slip?
Describe a situation where you had to explain complex technical information to a non-technical stakeholder or
Describe a situation where you had to explain complex technical information to a non-technical stakeholder or business partner.
Approach
- Choose a situation where the other person had to make a decision based on your explanation, such as a release freeze, a migration risk, a cost or a security finding. A story where nothing was at stake is weak.
- Describe how you prepared: you identified what they needed to decide, led with the conclusion and the impact on time, cost or risk, and replaced jargon with a concrete analogy or a diagram.
- Show you offered options with a recommendation and the trade-off of each, then checked understanding by asking them to restate the decision or the risk in their own words.
- Close with the result and any follow-up in writing. Avoid sounding condescending: the point is that the listener could act, not that you simplified.
Follow-up
- What did you do when the stakeholder pushed back on your recommendation?
- How did you confirm they had understood the risk?
- What would you cut from the explanation if you had half the time?
What steps do you take when you encounter a disagreement with a team member regarding a technical solution?
What steps do you take when you encounter a disagreement with a team member regarding a technical solution?
Approach
- Pick a real technical disagreement, such as a design choice, a library or a testing approach. Describe the other person's position fairly before yours, because the story needs to show you understood it.
- Explain how you moved from opinions to criteria: agree on requirements and constraints, then compare options with evidence such as a small prototype, a benchmark or a review of past incidents.
- Show how the decision was made and recorded (a short design note or architecture decision record), and what happened if you were overruled: you committed to the chosen approach and supported it.
- Include the relationship outcome. A story where you were simply right and the colleague was wrong sinks the answer; show a result that improved the solution or the working relationship.
Follow-up
- What if the evidence had been inconclusive?
- Tell me about a time you turned out to be the one who was wrong.
- When would you involve a manager or architect in the disagreement?
- 01
Tell me about a time you faced a difficult technological problem in your academic or professional career and how you resolved it.
- 02
How do you prioritize tasks when managing multiple competing deadlines in an agile environment?
- 03
Describe a situation where you had to explain complex technical information to a non-technical stakeholder or business partner.
- 04
What steps do you take when you encounter a disagreement with a team member regarding a technical solution?
- 05
What is your experience with CI/CD pipelines, and how do you ensure automated test coverage before deployment?
- 06
Can you describe your experience with cloud infrastructure and how you would architect a resilient cloud-based service?
How many rounds does the AXA Software Engineer loop have?
Candidates report five stages over roughly four to six weeks: Recruiter Screening, Technical Evaluation, Project Deep Dive, Behavioral Interview and Final Interview. Timing and format vary by region and seniority, so ask the recruiter for the exact sequence.
PracHub Software Engineer practice ↗How are the technical assessments run?
Candidates mention an online coding test on platforms such as Code In Game, take-home assignments, live coding and system design discussions with senior engineers. Which of these you get depends on the team. Ask the recruiter which applies and which language is allowed.
PracHub Software Engineer practice ↗Which programming language should I use?
The reports name Python, JavaScript and C#, and one reported question asks for a live-coding walkthrough in C# or Python. Use the language in which you can write correct code with tests and explain complexity. Confirm the options with the recruiter.
PracHub Software Engineer practice ↗How much SQL should I prepare?
Relational databases and SQL appear in the requirements candidates describe, and a reported question asks for an aggregation across multiple tables. Practise joins, grouping, the grain of a result and checking one-to-many joins before you sum. Expect to explain how you would make it fast.
PracHub Software Engineer practice ↗How should I prepare for the Project Deep Dive?
Pick two projects and write the architecture, your own role, the hardest decision and what you would change. Be ready to describe data flow, deployment, testing and security choices, and to name alternatives you rejected.
PracHub Software Engineer practice ↗What does behavioral preparation look like?
Candidates are advised to use the STAR format. Prepare stories for a hard technical problem, competing deadlines in an agile team, explaining technical information to a non-technical colleague and a technical disagreement. Each should show your decision and a measurable result.
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.
- 01AXA 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.
Veem Software Engineer Interview Guide
What Veem asks Software Engineer candidates, from reported rounds and questions.
Sorint.SEC Software Engineer Interview Guide
What Sorint.SEC asks Software Engineer candidates, from reported rounds and questions.
Raytheon Technologies Corporate Headquarters Software Engineer Interview Guide
What Raytheon Technologies Corporate Headquarters asks Software Engineer candidates, from reported rounds and questions.
NeuroFlow Software Engineer Interview Guide
What NeuroFlow asks Software Engineer candidates, from reported rounds and questions.