Candidates describe the role as designing, building and maintaining software for brokerage operations, with code reviews, testable code and security and compliance requirements as part of the day. Cloud-leaning variants add managing infrastructure, maintaining CI/CD pipelines and monitoring system health, and the role description also mentions documenting architectures, mentoring junior engineers and taking part in sprint ceremonies. For preparation, that translates into three layers: object-oriented design in C#/.NET or Java, relational databases and SQL, and enough AWS or Azure knowledge to talk about deployments, monitoring and failure.
The reported question set is split cleanly. Six questions are resume and motivation prompts (introduction, why Gallagher, the CV walk-through, fit for the role, salary expectations, your own questions). Five are fundamentals: the four pillars of OOP, tuning a slow SQL query, clustered versus non-clustered indexes, the lifecycle of a web request, and writing secure code. Four are project and architecture questions: the most complex system you have built, advocating for technical debt work, deployments and rollbacks, and a production outage. The fundamentals questions reward precise, checkable answers; the project questions reward a prepared story with real numbers and trade-offs.
The domain matters less than the engineering. Candidates are told they do not need to be insurance experts, but should show willingness to learn basic accounting, risk and insurance ideas, and reported example scenarios include designing a database schema for a policy management system and writing a SQL query for the top five highest-paying policies. Spend an hour on vocabulary (policy, premium, broker, carrier, claim, endorsement) so a schema or query question about policies does not slow you down.
How hard the loop leans on live coding depends on team and region. Many candidates describe the final technical and architecture conversations as resume-driven rather than whiteboard-heavy, while some regions use a structured aptitude test with quantitative and logical-reasoning sections. Prepare for both: a short coding and SQL warm-up routine, an aptitude pacing drill, and a resume where every listed technology is something you can explain two levels deep.
Recruiter Screen
reportedCandidates report an initial call with a recruiter about your background and fit for the role. The question types that belong to this stage are the resume and motivation prompts: introducing yourself, explaining your interest in the company, walking through your CV and connecting your experience to the role. The stage is also where candidates are advised to raise scheduling problems politely and to be ready to discuss pay expectations. Approach it as a prepared conversation: a short spoken summary, a specific reason for this company, and a clear map from your experience to the listed requirements.
What to demonstrate
- Background and fit for the role, as reported for this call
- Communication and career motivation
- Whether your experience maps to the listed requirements: C#/.NET or Java, SQL, and AWS or Azure
How to prepare
- Write and rehearse a spoken introduction that names your current stack (for example C#/.NET or Java, SQL, a cloud platform) and ends on why this role.
- Build a three-column table of role requirements, your evidence and your honest gaps, then practise the answer to the fit question from it.
- Research a market range for your level and location and choose the figure you will give if asked for salary expectations.
- Prepare questions for the team about stack, deployment process and legacy migration status.
Technical Assessment
reportedCandidates report a technical assessment that may be a coding challenge or an aptitude test, depending on team and region. Aptitude versions are described as covering quantitative aptitude (percentages, ratios, data interpretation), logical reasoning (patterns, deduction, sequencing) and a small domain section on accounting or insurance basics; a 40-question version with no negative marking is mentioned. Fundamentals questions on OOP, SQL and indexing are the reported technical topics. Approach it by splitting preparation: a speed-and-accuracy drill for any aptitude test, and a precise, example-backed review of OOP, joins, indexes and query tuning for the technical side.
What to demonstrate
- Working code and correct SQL, if the assessment is a coding challenge
- Speed and accuracy on quantitative and logical-reasoning items, if it is an aptitude test
- Command of OOP principles, relational database design and indexing
How to prepare
- Do timed sets of percentage, ratio and data-interpretation problems, and practise answering every item because no negative marking is reported.
- Write out the four OOP pillars with one C# or Java example each, plus the abstract class versus interface distinction.
- Write SQL from memory: top-N by amount, joins, GROUP BY with HAVING, and a read of an execution plan; add a clustered versus non-clustered index explanation.
- Sketch a schema for a policy management system with policies, customers, coverages and payments, and state the keys and indexes.
Final Round
reportedCandidates report a final interview with the hiring manager and the architecture team about technical decisions and project experiences, and describe it as conversational and resume-driven rather than high-pressure whiteboard coding. The project and architecture questions are reported as usually coming up in the final rounds: your most complex system and its trade-offs, advocating for technical debt work, deployments and rollbacks in the cloud, and troubleshooting a production outage. Candidate guidance also warns that skills listed on the resume can be explored in depth, so prepare each project with its architecture, your role, a decision you made and the business result.
What to demonstrate
- Ability to explain technical decisions and trade-offs on projects you built
- Depth of the technologies listed on your resume
- Cloud deployment, rollback and incident-handling experience
- Ability to describe business impact to non-technical stakeholders
How to prepare
- Prepare two projects with an architecture sketch, your specific contribution, one decision where you rejected an alternative, and a measured result.
- Write a deployment and rollback story for a cloud environment: pipeline stages, release strategy, health checks and how you reverted.
- Rehearse one production outage with a timeline: detection, first hypothesis, narrowing, fix, and the follow-up change.
- Review every technology on your resume and delete or mark anything you cannot discuss beyond surface level.
PracHub editorial advice for the preparation topics above.
Listing technologies on the resume that you can only discuss at surface level
Candidates report that the final conversation can go into depth on skills listed on the CV. Before the loop, go through each listed tool, remove or downplay any you cannot explain with a real example, and prepare one concrete story for each one you keep.
Answering the slow-SQL question with just "add an index"
Describe a sequence: read the execution plan, find scans and expensive joins, check that predicates can use an index, look at statistics, and rewrite the query before adding an index. Know how a clustered index (the table's physical order, one per table) differs from non-clustered indexes (separate structures with row pointers) and what each costs on writes.
Describing a complex system as a list of components with no trade-offs or business result
For each project, name the decision, the option you rejected and why, and one number (cost, latency, errors avoided or time saved). The reported question asks for trade-offs, and candidate guidance stresses tying work to business impact.
Treating a potential aptitude test as a relaxed formality, or leaving items blank
Where the process includes one, candidates report quantitative, logical-reasoning and domain sections, with no negative marking mentioned for the 40-question version. Practise timed sets, pace yourself so you reach the last item, and make an informed guess instead of skipping.
Giving generic answers to why this company and to the salary question
Prepare a reason that cites the role's reported work (legacy modernisation, cloud platforms, a client-facing portal) and one insurance idea you have learned. For pay, decide your range from market research before the call so you are not improvising.
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?
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?
Find overlapping job attempts and peak concurrency from lease records
A day of job_run history yields about 50,000,000 attempt records: (job_run_id, job_type, attempt, started_at, finished_at which is NULL when the worker died, lease_expires_at). Leases expire on a clock, so a job that outran its lease ran twice. Produce (a) every job_run_id whose attempts overlapped in wall-clock time and (b) the peak number of simultaneously running attempts per job_type with the minute it occurred. Target O(n log n). State how you treat a NULL finished_at and what clock skew does to your answer.
Approach
- Define the interval before sorting anything: an attempt occupies [started_at, COALESCE(finished_at, lease_expires_at)). finished_at is observed and lease_expires_at is only a promise, so every attempt without a finish contributes an estimate and the whole result is a lower bound on overlap rather than an exact count.
- For peak concurrency, sweep: emit 2n endpoints, sort by (timestamp, kind) with ends ordered before starts at equal timestamps, then walk the sequence maintaining a counter per job_type and record each type's maximum with its timestamp. O(n log n) dominated by the sort, O(n) space, or O(1) extra if the sort is external and the walk streams.
- For overlap detection, do not compare attempts pairwise. A single global sort by (job_run_id, started_at) gives both the grouping and the order; within a group, keep the maximum end seen so far and report an overlap exactly when the next start is less than that running maximum, which is one linear pass after the sort.
- Half-open intervals matter and are easy to get wrong: with closed intervals an attempt ending at the same millisecond another begins reads as concurrency two, and across 50,000,000 records that artefact swamps the real signal.
Follow-up
- A handler is not idempotent and you have found 400 overlapping jobs. Which of them actually caused damage, and what would you query to find out?
- Peak concurrency for one job_type is 4 against a configured cap of 4. Is the cap working, or is the data hiding attempts that never started?
How do you optimize a slow-running SQL query?
How do you optimize a slow-running SQL query?
Approach
- Measure before changing anything. Capture the actual execution plan: in SQL Server, the actual plan plus SET STATISTICS IO, TIME ON; in PostgreSQL, EXPLAIN (ANALYZE, BUFFERS). Record logical reads and elapsed time as the baseline. Note that EXPLAIN ANALYZE really executes the statement, so wrap any write in a transaction you roll back.
- Read the plan for the costly operator. Look for a table or index scan where you expected a seek, key lookups repeated thousands of times, hash spills, or a large gap between estimated and actual rows. A large gap usually means stale or missing statistics.
- Fix predicates that cannot use an index (non-sargable). WHERE YEAR(created_at) = 2024 becomes a half-open range (created_at >= '2024-01-01' AND created_at < '2025-01-01'). Watch for a leading-wildcard LIKE '%x', and for implicit conversions such as a varchar column compared with an nvarchar parameter, which can force a scan.
- Index for the query's shape. A composite index puts equality columns first and the range column last, and adds INCLUDE columns so the index covers the query and the lookups disappear. Then reduce the work itself: select only the columns needed, filter before joining or aggregating, and replace correlated subqueries and ORM N+1 loops with one set-based query.
- Prove the gain and name the cost. Compare reads and duration against the baseline. Every new index slows INSERT, UPDATE and DELETE and uses storage, so on write-heavy tables I check existing indexes for overlap before adding another.
Follow-up
- The query is fast in SSMS but slow when the application runs it. What could cause that? Cover parameter sniffing on a cached plan, different SET options such as ARITHABORT producing separate plans, and fixes like OPTION (RECOMPILE) or OPTIMIZE FOR.
- When would you not add an index, even though it makes this query faster?
- How would you find the slowest queries in production in the first place, for example with Query Store, sys.dm_exec_query_stats or pg_stat_statements?
Stop tag and share joins from fanning out a page
resource_tag is (resource_id, tag_id) with PK (resource_id, tag_id); resource_share is (resource_id, shared_with_user_id, permission). The tagged-and-shared listing inner-joins resource to both, filters tenant_id, tag_id = ANY($2) and shared_with_user_id = $3, orders by updated_at DESC and takes 50. Pages come back with fewer than 50 distinct resources and the total in the header is far too high. Explain the row multiplication, rewrite both the page query and the count query so each is correct, and name the index each one needs. PostgreSQL 16.
Approach
- Do the arithmetic against the predicates that are actually there. An inner join emits one row per matching child row, and both joins are filtered: tag_id = ANY($2) admits only the requested tags, shared_with_user_id = $3 admits one user's share rows. So a resource holding three of the requested tags and shared with $3 once yields three rows, not one — the multiplier is its count of matching tags times its share rows for that single user, and that second factor is 1 unless the table admits duplicate (resource_id, shared_with_user_id) pairs. LIMIT 50 then limits rows rather than resources, and COUNT(*) counts pairs — the header is the product, not the population.
- Reject DISTINCT as the fix. It deduplicates after the product has been built, so the planner must materialise and sort the fanned-out set before the LIMIT can apply, and it leaves any SUM or AVG in the same select list wrong.
- Rewrite both filters as semi-joins, keeping resource as the only row source: AND EXISTS (SELECT 1 FROM resource_tag rt WHERE rt.resource_id = r.resource_id AND rt.tag_id = ANY($2)) and the same shape against resource_share. A semi-join stops at the first match per resource and preserves the driving index order, so ORDER BY updated_at DESC, resource_id DESC LIMIT 50 still stops after 50 rows.
- Count with the same predicates and no join at all: SELECT count(*) FROM resource r WHERE r.tenant_id = $1 AND r.status = 'active' AND EXISTS (...) AND EXISTS (...). Nothing multiplies a resource, so the number is the population.
Follow-up
- The filter changes from 'any of these tags' to 'all of these tags'. Rewrite it and state what it costs relative to the ANY form.
- A resource can be shared with the same user twice under different permissions. Does your count change, and should it?
Explain the four pillars of Object-Oriented Programming and provide an example of how you have used them.
Explain the four pillars of Object-Oriented Programming and provide an example of how you have used them.
Approach
- Define each pillar in one line before any example. Encapsulation hides state behind methods that enforce invariants. Abstraction shows callers a contract and hides how it works. Inheritance reuses and specialises a base type. Polymorphism lets one call site run different implementations.
- Use one running example for all four rather than four unrelated ones. For instance, an IPremiumCalculator interface (abstraction), with each policy type supplying its own Calculate (polymorphism). A Policy class with a private status that changes only through Cancel() or Renew() (encapsulation). A shared base class for common policy fields (inheritance).
- Separate the two kinds of polymorphism. Overloading is resolved at compile time. Overriding is resolved at runtime through virtual dispatch. In C# a method must be marked virtual and the subclass must use override (new only hides the base method), while Java methods are virtual by default.
- Give the trade-off. Deep inheritance chains are fragile because a change to the base class ripples into every subclass. I default to composition plus interfaces and keep inheritance for true is-a relationships that honour Liskov substitution.
- Tie it to real code you wrote: the class names, what each pillar bought you (a new policy type added without editing the caller, an invariant that could no longer be broken), and how you tested it.
Follow-up
- What is the difference between an abstract class and an interface, and when would you pick each? Cover single class inheritance versus multiple interfaces, and default interface methods in C# 8+ and Java 8+.
- Describe a time inheritance caused you problems. How would composition have changed the design?
- How does dependency injection relate to abstraction, and how does it make your classes easier to unit test?
Describe the difference between a clustered and a non-clustered index.
Describe the difference between a clustered and a non-clustered index.
Approach
- Clustered index: its leaf level is the table's data rows, stored in order of the clustered key, so a table can have only one. In SQL Server, a PRIMARY KEY becomes the clustered index by default, unless one already exists or NONCLUSTERED is specified.
- Non-clustered index: a separate B-tree whose leaf rows hold the index key and a row locator. The locator is the clustered key if the table has a clustered index, or a RID if the table is a heap. SQL Server allows up to 999 non-clustered indexes per table.
- Explain the lookup cost. If a non-clustered index lacks columns the query needs, every matching row pays a key lookup into the clustered index. INCLUDE columns make the index covering and remove that cost. For low-selectivity predicates, the optimizer may decide a full scan is cheaper than many lookups.
- Say what makes a good clustered key: narrow, unique, static and ever-increasing, such as an IDENTITY or bigint. Every non-clustered index stores the clustered key, so a wide key bloats them all. A random GUID key causes page splits and fragmentation; NEWSEQUENTIALID or a separate surrogate key avoids that.
- Note how other engines differ. InnoDB in MySQL always clusters on the primary key. PostgreSQL tables are heaps: its CLUSTER command reorders a table once and does not maintain that order afterwards.
Follow-up
- Which column would you choose as the clustered key for a policy table that is mostly read by policy number but inserted in date order, and why?
- What is a covering index, and how do INCLUDE columns differ from adding the same columns to the index key?
- Why might the optimizer ignore a non-clustered index you created on a column used in the WHERE clause?
Walk me through the lifecycle of a web request from the browser to the database and back.
Walk me through the lifecycle of a web request from the browser to the database and back.
Approach
- Browser side: parse the URL and check the browser's HTTP cache. Resolve DNS through the browser cache, then the OS cache, then a recursive resolver. Open TCP (three-way handshake) and then TLS; TLS 1.3 needs one round trip for a full handshake, TLS 1.2 needs two. Then send the HTTP request with headers and cookies.
- Edge and routing: a CDN or reverse proxy may answer from cache. Otherwise a load balancer terminates TLS (or passes it through), applies routing and health checks, and forwards the request to a healthy app instance.
- Application: in ASP.NET Core, the request passes through the middleware pipeline (exception handling, authentication, authorization, routing) to a controller or endpoint. Model binding and validation run there, then the business logic.
- Database: the data layer (for example Entity Framework) takes a connection from the pool and sends a parameterized query. The database parses it, reuses or builds a plan, reads pages from the buffer cache or disk, and takes locks according to the isolation level. Rows go back to the app, which maps them to objects and serializes the result to JSON.
- Return path: the response carries a status code and headers such as Cache-Control and Set-Cookie. The browser parses HTML into the DOM and CSS into the CSSOM, fetches subresources and runs JavaScript, then lays out and paints. At each hop, say where latency and failures usually come from.
Follow-up
- Where would you add caching along this path, and how would you keep it from serving stale policy data?
- What happens when the application's database connection pool is exhausted, and how would you detect it?
- How would you trace a single slow request across these layers? Cover correlation IDs, distributed tracing and per-hop timings.
How do you ensure your code is secure and resilient against common vulnerabilities?
How do you ensure your code is secure and resilient against common vulnerabilities?
Approach
- Anchor the answer on the OWASP Top 10, then give one concrete control per threat. Prevent SQL injection with parameterized queries everywhere. An ORM does not make you safe automatically: EF Core's FromSqlRaw with a concatenated string can be injected, while FromSqlInterpolated turns values into parameters.
- Enforce access control on the server for every request. Check that the authenticated user is allowed to see the specific record (for example, that a policy id belongs to that client) to block insecure direct object references. Apply least privilege to service accounts and database logins too.
- Handle the browser threats. For XSS, use context-aware output encoding plus a Content-Security-Policy. For CSRF, use anti-forgery tokens and SameSite cookies. Validate input on the server against allow-lists. Store passwords with a slow salted hash (PBKDF2, bcrypt or Argon2id), never a fast hash like SHA-256.
- Keep secrets out of code and config files. Use Azure Key Vault or AWS Secrets Manager with managed identities. Run dependency scanning and static analysis in CI so a vulnerable package fails the build. Keep PII and tokens out of logs.
- Resilience: set timeouts on every outbound call. Retry with exponential backoff and jitter, and only for idempotent operations. Add circuit breakers (for example Polly in .NET) and idempotency keys on writes, so a dependency failure degrades the service instead of cascading.
Follow-up
- A scanner flags a critical vulnerability in a package already running in production. What do you do, in what order?
- How do you make a payment or policy update endpoint safe to retry without creating duplicates?
- How would you keep personal data out of logs and error messages while still being able to debug?
Walk me through the architecture of the most complex system you have built. What were the trade-offs?
Walk me through the architecture of the most complex system you have built. What were the trade-offs?
Approach
- Open with the business problem and scale in two sentences: who used the system, request or data volumes, and what failure would cost. Then sketch the components: clients, API layer, services, data stores, queues and external integrations. Walk one real request through them end to end.
- Pick two or three decisions and treat each the same way: the options you considered, the one you chose, and what it cost. Examples are monolith versus services, relational versus document store, synchronous calls versus a queue, or VMs versus containers on AWS or Azure.
- State your own part precisely: what you designed, built or decided versus what the team or an architect did. Use "I" for your work. Only name technologies you can explain to the level of configuration and failure modes.
- Cover the hard non-functional parts: how data stays consistent across components (transactions, outbox, idempotent consumers), how the system scales and where it bottlenecked, how it is monitored, and how deployments and rollbacks work.
- End with the measured outcome (latency, cost, incident count, delivery time) and what you would change if you rebuilt it today, with the reason. A design with no regrets reads as shallow.
Follow-up
- What breaks first if traffic grows ten times, and what would you change to handle it?
- How does the system behave when its most important downstream dependency is unavailable for an hour?
- If you rebuilt it on a cloud platform today, which component would you change first, and why?
Describe a situation where you had to troubleshoot a critical production outage. What was your process?
Describe a situation where you had to troubleshoot a critical production outage. What was your process?
Approach
- Choose a real incident where you were hands-on. Open with the impact in numbers: what users could not do, for how long, and how it was detected (an alert, or a customer report, which is itself a gap worth naming).
- Mitigate before you diagnose, and say so. Roll back the last deploy, turn off a feature flag, fail over, or scale out to stop the bleeding. Explain how you chose between rolling back and fixing forward.
- Show a structured diagnosis. Ask what changed (deploys, config, certificates, traffic, upstream dependencies). Read error rate, latency and saturation dashboards. Follow logs by correlation ID. Bisect the scope: one region, one endpoint, one tenant, or one instance.
- Separate trigger from root cause. For example, the deploy only triggered the outage; the real cause was a missing index, connection-pool exhaustion or a retry storm. Explain how you confirmed it, for example by reproducing it or seeing the metric recover after the fix.
- Close with the blameless postmortem: concrete follow-ups (a new alert, a test, a runbook, a safer deploy step), who owned them, and what changed afterwards. Mention how you kept stakeholders updated during the incident.
Follow-up
- How did you decide between rolling back and fixing forward, and what would have changed that decision?
- What monitoring or alerting did you add so this failure is caught sooner next time?
- How did you tell the cause apart from a coincidence that happened at the same time?
The plan follows the three reported rounds: resume and motivation answers first, then the OOP, SQL and aptitude fundamentals, then cloud deployments and incidents, then the project deep dive, finishing with a full mock loop.
Prepare, practise & reflect
One practical outcome each day. Spend longer where you need it.
0 / 7 done01Map the loop and audit your resume
- List the three reported rounds (Recruiter Screen, Technical Assessment, Final Round) and write which of your skills each one touches.
- Go through your resume line by line and mark every technology as deep, working or surface; remove or prepare each surface item.
- Write the requirement-evidence-gap table for C#/.NET or Java, SQL, AWS or Azure, and communication.
Deliverable: A one-page loop map plus a resume audit with each technology marked deep, working or surface, and the requirement-evidence-gap table.
Practice prompt ↗02Introduction, motivation and CV answers
- Write and rehearse out loud your answers to the introduction, why Gallagher, and the CV walk-through; record them and cut anything vague.
- Research the company's public pages and write three facts you can tie to your experience, plus a short glossary of policy, premium, broker, carrier, claim and endorsement.
- Choose your salary range from public data and write the sentence you will use when asked.
Deliverable: Three recorded spoken answers (introduction, why Gallagher, CV walk-through), a one-page fact and glossary sheet, and a written salary sentence.
Practice prompt ↗Practice prompt ↗Practice prompt ↗Practice prompt ↗03OOP and database fundamentals
- Write the four OOP pillars with a short C# or Java example for each and one real use from your own code; add the abstract class versus interface comparison.
- Write a SQL query for the five highest-paying policies with ties handled, then rewrite it two ways (ORDER BY with LIMIT or TOP, and a window function).
- Explain clustered versus non-clustered indexes and write the sequence you follow to tune a slow query, using an execution plan from a query you have run.
- Do PracHub's own practice question on stopping tag and share joins from fanning out a page, to check you can reason about one-to-many joins.
Deliverable: A one-page OOP sheet with examples, two working top-N queries, a written query-tuning checklist and one completed join-fan-out exercise.
Practice prompt ↗Practice prompt ↗Practice prompt ↗Practice prompt ↗04Web request lifecycle, security and aptitude drills
- Draw a request from browser to database and back: DNS, TLS, load balancer, web server, application code, data access, response, caching; label where each failure could occur.
- List common vulnerabilities (injection, XSS, broken authentication, insecure secrets) and the matching defence in your stack, such as parameterized queries and output encoding.
- Do a timed set of percentage, ratio, data-interpretation and sequence problems, answering every item, and review the errors.
Deliverable: An annotated request-lifecycle diagram, a vulnerability-to-defence table, and a scored timed aptitude set with an error log.
Practice prompt ↗Practice prompt ↗05Cloud deployments, rollbacks and outages
- Write your deployment answer: pipeline stages, infrastructure as code, release strategy, health checks, rollback trigger and database migration handling.
- Compare rolling, blue-green and canary releases for a web application on AWS or Azure, with the cost and risk of each.
- Write a production-outage timeline from your own experience: detection, first hypothesis, narrowing, fix and the permanent follow-up, with the monitoring you would add.
Deliverable: A written deployment-and-rollback answer, a three-way release strategy comparison, and one outage timeline ready to tell.
Practice prompt ↗Practice prompt ↗06Project architecture and technical debt stories
- Draw the architecture of your most complex project, list two trade-offs with the rejected alternatives, and attach a measured result to each.
- Write the technical-debt story with evidence, the scoped fix, what you deferred and the measured result.
- Rehearse explaining the architecture to a non-technical stakeholder in three sentences about business impact.
Deliverable: An architecture diagram with a trade-off table, a written debt-advocacy story, and a three-sentence stakeholder summary.
Practice prompt ↗Practice prompt ↗07Full mock loop and your questions
- Run a spoken mock of all three stages in order: the recruiter conversation, a technical set of OOP, SQL and index questions, then the project and outage conversation.
- Write your questions for the team and for the hiring manager and architecture team.
- Do a short coding warm-up with PracHub's practice problems on a rolling failure rate and on overlapping job attempts, to keep coding fluent in case the assessment includes a coding challenge.
Deliverable: A recorded mock with a list of weak answers to fix, a final list of questions for the team, and two completed coding warm-ups.
Practice prompt ↗Practice prompt ↗Practice prompt ↗Expand any day for tasks and deliverables. Your progress is saved on this device.
For this loop, the behavioral material is mostly resume, motivation and project storytelling. Candidates report resume and motivation prompts early and project questions about trade-offs, technical debt and incidents in the final rounds, so prepare a few strong stories with concrete decisions and measured results.
Tell me about yourself.
Tell me about yourself.
Approach
- Use a present, past, future structure: your current role and stack in a sentence, two earlier experiences that explain how you got here, then why this Software Engineer role is the next step.
- Pick two highlights that match the requirements the role lists (an object-oriented language such as C# or Java, SQL, cloud work) and give each a result, such as a migration finished or an incident rate reduced.
- Keep it to a few sentences per section and stop on the role, so the conversation moves forward instead of repeating the CV walk-through.
- The mistake that sinks it is a chronological list of employers with no point of view; if every sentence could come from anyone's resume, rewrite it around one theme.
Follow-up
- Which of those experiences would you like to go deeper on?
- What do you want from your next role that your current one does not give you?
What do you know about Gallagher, and why are you interested in joining the company?
What do you know about Gallagher, and why are you interested in joining the company?
Approach
- Use only facts you can verify from the company's public pages and the job posting: it is an insurance brokerage and risk management business, and the role mentions cloud transformation, legacy modernisation and client-facing platforms.
- Tie one of those facts to your own experience, for example a legacy-to-cloud migration you worked on or a transaction-heavy system you kept reliable, so the answer is about fit instead of flattery.
- Show willingness to learn the domain: name two insurance or accounting ideas you have already looked up (policy, premium, broker, claim) and what you noticed about them as a software problem.
- The mistake is a generic answer about size, brand or culture that would fit any employer; avoid repeating slogans and avoid claims about the company's values that you cannot source.
Follow-up
- Which part of the business would your software work touch first?
- What would you want to learn about insurance in your first month?
Walk me through your CV/resume.
Walk me through your CV/resume.
Approach
- Choose one thread, such as backend systems on C#/.NET and SQL growing into cloud ownership, and tell each job as a problem, your contribution, the stack and a result in about three sentences.
- Spend most of the time on the last two roles and the one most relevant to the target role; compress early roles to a line each.
- Every technology you name can be followed up, so say which ones you used daily and which only briefly, and cut anything you cannot explain with an example.
- Explain job changes and gaps briefly and positively, with what you moved toward rather than what you left.
Follow-up
- Which technology on your resume are you least confident in?
- Why did you move on from that role, and what would you do differently?
How does your experience relate to our company and this specific role?
How does your experience relate to our company and this specific role?
Approach
- Build the answer from the requirements candidates describe: an object-oriented language such as C# or Java, SQL and relational design, AWS or Azure concepts, written and verbal communication, and working with product and architecture people.
- For each requirement give one concrete piece of evidence with a result, such as a query you tuned, a service you deployed or a requirement you translated for a business stakeholder.
- If you lack the nice-to-have areas (insurance, infrastructure as code, React or Angular), say so and name the adjacent experience and what you are doing to close the gap; do not stretch your resume.
- Close by connecting one of your projects to the kind of work the role involves, such as modernising an older system or building a customer-facing portal.
Follow-up
- Where is the largest gap between your experience and this role?
- Tell me about a time you picked up a new technology to deliver something quickly.
What are your current salary expectations?
What are your current salary expectations?
Approach
- Research the typical range for your level and location from several public sources, treating small self-reported samples with caution, and decide your target and your floor before the call.
- If asked early, you can ask what range is budgeted for the role first; if you do give a number, give a range whose lower end you would accept, anchored to scope and experience.
- Keep the answer factual and calm, linking it to the 3+ years or lead-level scope you are applying at, and state that you are open to discussing total compensation.
- Pay-history questions have different legal limits depending on location, so check yours and decide in advance how you will answer; the mistake is naming a figure with no research or reacting to a counter-offer on the spot.
Follow-up
- Is that figure flexible if the rest of the package is strong?
- What matters to you besides base pay when choosing between offers?
Do you have any questions for us about the team or the company?
Do you have any questions for us about the team or the company?
Approach
- Prepare five or six questions that show engineering curiosity: which stack the team runs (.NET, Java, a frontend framework), how much of the system is legacy versus cloud-native, and how deployments are done.
- Ask how the engineers, CloudOps people and architecture team divide responsibility, and how product requirements reach the developers.
- Ask what a good first project looks like and how onboarding to the insurance domain works, since domain knowledge is something candidates are told they will learn.
- Skip questions answered on the careers page, and avoid opening with pay, remote policy or leave; the mistake is saying you have no questions.
Follow-up
- Why did you ask that, and what would a good answer change for you?
- What would make you decline an offer from this team?
Tell me about a time you had to advocate for paying down technical debt rather than building new features.
Tell me about a time you had to advocate for paying down technical debt rather than building new features.
Approach
- Use a situation, task, action, result structure with one real example: a component, library or pipeline whose upkeep was slowing releases or causing incidents, and where you argued for fixing it before adding more features.
- Make the case with evidence a product manager can use: incident counts, hours lost to workarounds, release cycle time, or the risk to a compliance or security obligation.
- Describe the scoping decision: a bounded, incremental refactor or migration step with an agreed outcome instead of a rewrite, and what feature work you deferred in exchange.
- State the result with a measurement and what you learned; the mistake that sinks the story is framing it as engineers wanting to tidy code without a cost to the business.
Follow-up
- What feature work did you give up, and who agreed to that?
- What would you have done if the product manager had refused?
- How did you show the debt work paid off afterwards?
How do you handle deployments and rollback strategies in a cloud environment?
How do you handle deployments and rollback strategies in a cloud environment?
Approach
- Describe a pipeline that builds an artifact once and promotes the same artifact through test and staging to production, with infrastructure defined as code (Terraform or ARM templates, for example) so environments are reproducible.
- Name the release strategies and when each fits: rolling updates, blue-green with a traffic switch, canary releases with a small percentage first, and feature flags to decouple deploy from release.
- Define rollback precisely: redeploy the previous artifact or switch traffic back, with health checks and alert thresholds (error rate, latency) that trigger it; in Kubernetes that is a rollout undo.
- Cover the hard part, the database: use expand-and-contract migrations so the old and new application versions both work against the schema, because a destructive migration cannot be rolled back by redeploying code.
- Ground it in one release you ran, including what the monitoring showed and what you changed in the process afterwards.
Follow-up
- How do you roll back a release that included a column drop?
- Which metrics decide between rolling back and rolling forward?
- When would you pick blue-green over a canary release?
- 01
Tell me about yourself.
- 02
What do you know about Gallagher, and why are you interested in joining the company?
- 03
Walk me through your CV/resume.
- 04
Tell me about a time you had to advocate for paying down technical debt rather than building new features.
- 05
Tell me about a time you had to pivot your technical approach midway through a project.
- 06
Walk me through your resume and highlight a project where you had to learn a new technology on the fly.
How long does the interview process typically take?
Candidates report three rounds over about 3-5 weeks. Other guidance for the role puts it at two to four weeks and says region, team availability and internal approvals can stretch it, so stay in touch with the recruiter and keep your preparation moving.
Arthur J. Gallagher & Software Engineer candidate reports ↗Are the technical interviews live-coding or conversational?
It depends on the team and region. Many candidates describe the final technical and architecture rounds as conversational and focused on resume and projects, but you should still be ready to discuss code design and SQL in detail. Keep a short routine of SQL and OOP practice.
Arthur J. Gallagher & Software Engineer candidate reports ↗Is there an aptitude test for all Software Engineering roles?
Not always. Reports say aptitude tests with math, logical reasoning and domain basics are common in some regions, such as India, and for early-to-mid-level roles, while senior loops in the US or UK lean toward architecture and behavioral interviews. If yours includes one, practise timed sets and answer every item.
Arthur J. Gallagher & Software Engineer candidate reports ↗Will there be a background check?
Candidate guidance says a background check is a mandatory part of the offer process, tied to the financial and insurance data involved. Make sure your resume dates and employment details are accurate and easy to verify.
Arthur J. Gallagher & Software Engineer candidate reports ↗Which technologies should I prepare?
Prepare an object-oriented language (C#/.NET or Java), SQL with relational design and indexing, and either AWS or Azure at the level of deployments, monitoring and networking basics. For cloud-focused tracks, add CI/CD, infrastructure as code (Terraform, ARM templates), Docker and Kubernetes, and monolith versus microservices trade-offs. React or Angular and insurance experience are listed as nice-to-haves.
PracHub Software Engineer practice ↗How should I prepare for the final round with the hiring manager and architecture team?
Prepare two projects in depth: architecture diagram, your contribution, two trade-offs, a business result, and an outage or deployment story. Review every technology on your resume, and prepare questions about the team's stack and legacy migration so the conversation goes both ways.
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.
- 01Arthur J. Gallagher & 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.
Together Ai Software Engineer Interview Guide
Failure-handling practice for Together Ai software engineer candidates: requests whose outcome a timeout leaves unknown, where a retry is safe, and deduplicating at the receiver instead of assuming exactly-once delivery.
Lambda Software Engineer Interview Guide
Failure-handling practice for Lambda software engineer candidates: requests whose outcome a timeout leaves unknown, where a retry is safe, and deduplicating at the receiver instead of assuming exactly-once delivery.
CoreWeave Software Engineer Interview Guide
Failure-handling practice for CoreWeave software engineer candidates: requests whose outcome a timeout leaves unknown, where a retry is safe, and deduplicating at the receiver instead of assuming exactly-once delivery.