Interview guides · Crc Group

Crc Group Software Engineer Interview Guide

Crc Group Software Engineer interview guide: reported rounds, questions and how candidates describe the process.

The 60-second brief

As a Software Engineer at Crc Group, you are tasked with building robust, scalable solutions that underpin our complex insurance distribution services. This role is critical to our mission; you are not merely writing code, but architecting the digital infrastructure that enables our teams to provide seamless service to our clients. You will work within a collaborative environment where engineering excellence meets practical, client-focused problem solving. The work is intellectually demanding and highly influential. You will contribute to projects that require a deep understanding of both technical implementation and business logic. Whether you are working within the.NET ecosystem or tackling broader architectural challenges, you will have the opportunity to influence the direction of our platforms.

This guide is scoped to a Software Engineer candidate at Crc Group.

Focus areas

Problem Solving
.NET
Algorithmic Thinking

The Crc Group interview process

Crc Group candidates report 3 rounds over 3-5 weeks. The stages below are what candidates describe, not a published process.

Application Review

Initial assessment of your application to determine fit for the Software Engineer role.

What to demonstrate

Initial assessment of your application to determine fit for the Software Engineer role
Depth in Problem Solving

How to prepare

Be able to walk your CV end to end in two minutes, and say why this company specifically.
Have your salary expectations, notice period and location constraints ready, and ask for the rest of the loop in writing.

Recruiter Screen

A conversation with a recruiter to discuss your experience and expectations.

What to demonstrate

A conversation with a recruiter to discuss your experience and expectations
Depth in Problem Solving

How to prepare

Be able to walk your CV end to end in two minutes, and say why this company specifically.
Have your salary expectations, notice period and location constraints ready, and ask for the rest of the loop in writing.

Technical Deep Dives

In-depth technical discussions with engineers and architects about your skills and experience.

What to demonstrate

In-depth technical discussions with engineers and architects about your skills and experience
Depth in Problem Solving

How to prepare

Answer aloud and timed: Write a function to solve [a standard algorithmic challenge] on the whiteboard.
Answer aloud and timed: Tell me about a time you had to learn a new technology quickly to complete a project.

Where candidates lose points

Think out loud

This is the most crucial piece of advice for our technical interviews. Your thought process is as important as the code you write.

Own your weaknesses

If you are unsure about a specific technology or concept, be honest. We value the ability to identify knowledge gaps and the willingness to learn.

Prepare your stories

Use the STAR method (Situation, Task, Action, Result) to structure your behavioral answers.

Be ready for whiteboarding

Practice explaining your logic on a whiteboard or virtual equivalent, as this is a core component of our technical assessment.

Questions & practice

How would you approach designing a solution for [a specific technical problem]?

Medium · Technical Problem Solving & Coding

Approach

Restate the input: its shape, its size, and what is guaranteed about it.
Name the brute-force solution and its complexity before improving on it.
Choose the data structure from the access pattern, not from familiarity.
State the target complexity and say which constraint rules the naive version out.

Follow-up

How does this change if the input no longer fits in memory?
What is the worst case, and how likely is it on real data?

Explain your approach to writing unit tests for your code.

Medium · Technical Problem Solving & Coding

Approach

Restate the input: its shape, its size, and what is guaranteed about it.
Name the brute-force solution and its complexity before improving on it.
Choose the data structure from the access pattern, not from familiarity.
State the target complexity and say which constraint rules the naive version out.

Follow-up

How does this change if the input no longer fits in memory?
What is the worst case, and how likely is it on real data?

Write a function to solve [a standard algorithmic challenge] on the whiteboard.

Medium · Technical Problem Solving & Coding

Approach

Restate the input: its shape, its size, and what is guaranteed about it.
Name the brute-force solution and its complexity before improving on it.
Choose the data structure from the access pattern, not from familiarity.
State the target complexity and say which constraint rules the naive version out.

Follow-up

How does this change if the input no longer fits in memory?
What is the worst case, and how likely is it on real data?

Keep soft-deleted accounts from blocking re-registration

Easy · soft delete · unique constraints · engine differences

app_user holds user_id, tenant_id, email CITEXT, password_hash (NULL for SSO principals), email_verified_at, auth_version, status ('invited','active','suspended','deactivated'), created_at, updated_at, deleted_at. Two live accounts for one address inside a tenant must be impossible, but an address freed by a soft delete must be reusable, and the same tenant may delete and re-register it repeatedly. Write the uniqueness DDL for PostgreSQL 16, then the equivalent for MySQL 8 where partial indexes do not exist, and say what each permits once three deleted rows already hold that address.

Approach

Start from what is actually unique: not (tenant_id, email), but (tenant_id, email) among live rows. PostgreSQL says that directly — CREATE UNIQUE INDEX app_user_live_email ON app_user (tenant_id, email) WHERE deleted_at IS NULL. A full constraint over the same two columns burns the address permanently the first time someone deletes an account.
Keep case-insensitivity in the type or the index, never in the application: CITEXT as given, or UNIQUE (tenant_id, lower(email)) as an expression index where the extension is unavailable. A case-sensitive unique column is exactly how two accounts for one human appear.
For MySQL 8 the predicate has to move inside the key: add a discriminator column that is a constant 0 while the row is live and is set to user_id on delete, with UNIQUE (tenant_id, email, deleted_marker). Live rows share the constant and still collide; deleted rows differ from each other and stop colliding.
State the NULL variant and its dependency: leaving the marker NULL for deleted rows also works, because a unique index treats NULLs as distinct — true in MySQL, and true in PostgreSQL only under the default NULLS DISTINCT, which PostgreSQL 15 lets you reverse. Check the polarity against the three existing deleted rows: constant-on-live is what preserves the collision you want, and reversing it silently admits duplicate live accounts.

Follow-up

A deleted account re-registers with the same address the next day. Do the old resource rows follow the new user_id, and how does the API keep the two principals apart?
How do you honour an erasure request while resource_revision.actor_user_id still references this table?

Find version gaps and relay lag with window functions

Medium · window functions · event tables · frame semantics

outbox_event holds event_id, aggregate_type, aggregate_id, aggregate_version, event_type, payload, status ('pending','published','dead'), attempts, created_at, published_at. A projection is missing rows and you must decide whether the relay skipped events or the consumer dropped them. Write three queries over the last seven days: one listing every aggregate_id whose published aggregate_version sequence has a hole, one giving per-day counts with a running total, and one returning the newest published event per aggregate. For each, say where the window function is evaluated relative to WHERE and LIMIT. PostgreSQL 16.

Approach

Gaps: compute lead(aggregate_version) OVER (PARTITION BY aggregate_id ORDER BY aggregate_version) in a subquery, then filter next_version <> aggregate_version + 1 in the outer query. Window functions are evaluated after WHERE, GROUP BY and HAVING and before the outer ORDER BY and LIMIT, so the predicate cannot sit in the same WHERE clause and PostgreSQL 16 has no QUALIFY.
Say what the seven-day filter does to the answer: it truncates every partition, so the first row per aggregate has no predecessor inside the window and a hole spanning the boundary is invisible. Widen the window, or join to resource.version as the authority for the true maximum.
Running total: SELECT date_trunc('day', created_at) AS d, count() AS n, sum(count()) OVER (ORDER BY date_trunc('day', created_at) ROWS UNBOUNDED PRECEDING). An aggregate inside a window call is legal because grouping runs before windowing. The grouping key is unique per row here so ROWS and RANGE agree, but write the frame anyway — over ungrouped rows with tied timestamps the default RANGE frame pulls in every peer row and the total jumps.
Newest per aggregate: DISTINCT ON (aggregate_id) ... ORDER BY aggregate_id, aggregate_version DESC is the cheap PostgreSQL-only form when an index matches that order; row_number() OVER (PARTITION BY aggregate_id ORDER BY aggregate_version DESC) = 1 is the portable form and needs a subquery for the same evaluation-order reason as the gap query.

Follow-up

Relay failover redelivers events. Does a duplicate break the gap query, and how would you detect one from this table alone?
Turn the gap check into a continuous monitor rather than a query someone runs after an incident. What does it watch?

How do you ensure your code is scalable and maintainable?

Medium · Technical Problem Solving & Coding

Approach

Fix the scope first: who calls this, how often, and what they do when it fails.
Name the read and write paths separately; they rarely have the same bottleneck.
Choose a partition key and say what query it makes expensive.
State the consistency you need, and where you are willing to be stale.

Follow-up

What breaks first when traffic grows ten times?
How does this behave when that dependency is down for an hour?

Evolve the resource contract without breaking integrations you cannot upgrade

Hard · versioning · backward compatibility · deprecation

GET /v1/resources/{id} returns status from a four-value enum ('draft','active','archived','deleted'), a numeric version, and the body inline. Consumers are a browser app you deploy and roughly 300 server-side integrations, some untouched for two years, that switch exhaustively on status and parse ids as JSON numbers. You must add a 'pending_review' status, move bodies over 256 KB to a body_ref pointer, and expose per-field change history from resource_revision. Specify the compatibility policy, the wire changes, how both generations are served, and the evidence that lets you remove the old shape.

Approach

Write the policy first and date it: fields are added, never retyped or repurposed; consumers ignore unknown fields; an unknown enum value maps to a documented fallback; nothing is removed until telemetry shows no caller reads it. Then say the uncomfortable part out loud - v1 shipped without the unknown-value rule, so 300 running integrations have no fallback, and no server change can install one into code that is already deployed.
That single fact forces per-request negotiation rather than a server-side default. Keep one internal model and select a serialiser from an explicit version in the request, and default a caller that sends nothing to the oldest supported version. Defaulting to the newest is the change that breaks every integration that never asked for anything, on the day you ship.
Downgrade 'pending_review' for old callers to the nearest state they already handle, 'draft', and state the loss explicitly: those integrations cannot see review state and will treat the resource as editable. If that is unacceptable for one integration, the remedy is moving it to the new version, not a cleverer projection - there is no mapping that invents a state the client has no code for.
Make the body change additive. Old callers keep body inline; the new shape adds body_ref and a size field, and resources over the limit are served to old callers by resolving the pointer server-side or by refusing with a documented code, chosen once and published. Never repurpose body to carry the pointer: a client that renders it shows a storage key to a user, and that failure is silent, where a missing field would have been loud. While you are here, serialise BIGINT ids as strings in the new shape - a browser parsing JSON numbers gets IEEE-754 doubles, exact only to 2^53 - and treat that as its own breaking change requiring the same negotiation, not a quiet fix.

Follow-up

An old integration submits a status transition while the resource is really in 'pending_review'. What does the write path accept, and what does it reject?
Two years on you want to delete the v1 serialiser. What evidence makes that safe, and who must be contacted before it happens?

Walk me through your process for debugging a complex production issue.

Medium · Technical Problem Solving & Coding

Approach

Establish what changed and when, before forming any theory.
Pick a bisection that eliminates candidates whichever way it turns out.
Check the instrumentation before believing the symptom.
Separate the trigger from the cause; the deploy is rarely the bug.

Follow-up

What would you look at first, and what would it rule out?
How would you tell a cause from a coincidence here?

Suggested practice checklist

Built from the rounds and topics Crc Group candidates report.

Day 1 — Map the Crc Group loop

Write out the reported sequence: Application Review, Recruiter Screen, Technical Deep Dives.
For each round, write one sentence on what it is judging, from the description above, and mark the one you are least ready for.

Deliverable: A one-page map of the 3 reported rounds, with the weakest marked.

Day 2 — Work Problem Solving

Spend the session on Problem Solving, which Crc Group candidates report being tested on.
Write one worked example in Problem Solving and time yourself on it.

Deliverable: One timed worked example in Problem Solving.

Day 3 — Work .NET

Spend the session on .NET, which Crc Group candidates report being tested on.
Write one worked example in .NET and time yourself on it.

Deliverable: One timed worked example in .NET.

Day 4 — Work Algorithmic Thinking

Spend the session on Algorithmic Thinking, which Crc Group candidates report being tested on.
Write one worked example in Algorithmic Thinking and time yourself on it.

Deliverable: One timed worked example in Algorithmic Thinking.

Day 5 — Answer out loud: Technical Problem Solving & Coding

Answer aloud, timed: How would you approach designing a solution for [a specific technical problem]?
Answer aloud, timed: Walk me through your process for debugging a complex production issue.

Deliverable: Spoken answers to 2 reported Technical Problem Solving & Coding question(s), under time.

Day 6 — Answer out loud: Behavioral & Professional Background

Answer aloud, timed: Tell me about a time you had to learn a new technology quickly to complete a project.
Answer aloud, timed: How do you handle disagreements regarding technical architecture with your peers?

Deliverable: Spoken answers to 2 reported Behavioral & Professional Background question(s), under time.

Day 7 — Dry run for Crc Group

Run one full mock under time, then write down the two questions you most want to ask your interviewers.

Deliverable: A completed timed mock and two questions to ask.