cswork / libraryOpen practice workspace

Interview guides · Gravitas Recruitment Group (Global)

Gravitas Recruitment Group (Global) Software Engineer Interview Guide

Gravitas Recruitment Group (Global) Software Engineer interview guide: reported rounds, questions and how candidates describe the process.

The 60-second brief

As a Software Engineer at Gravitas Recruitment Group (Global), you are at the intersection of high-frequency finance and cutting-edge technology. This role is not merely about writing code; it is about building the infrastructure that powers critical market connectivity, trading platforms, and cloud-based telephony solutions. You will be expected to solve complex, low-latency problems that directly impact the firm’s ability to remain competitive in global markets. Your work will involve collaborating with cross-functional teams, including traders, quantitative analysts, and infrastructure engineers. The environment is fast-paced, requiring you to balance the need for rapid application development with the rigorous stability standards required for high-stakes financial operations.

This guide is scoped to a Software Engineer candidate at Gravitas Recruitment Group (Global).

Focus areas

  • Software Engineering (general)
  • Cloud Engineering
  • Coding Assignments

The Gravitas Recruitment Group (Global) interview process

Gravitas Recruitment Group (Global) candidates report 3 rounds over 3-5 weeks. The stages below are what candidates describe, not a published process.

Initial Screening

The process begins with an initial screening to assess basic qualifications.

What to demonstrate

  • The process begins with an initial screening to assess basic qualifications
  • Depth in Software Engineering (general)

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

A series of technical assessments that include on-the-spot coding assignments.

What to demonstrate

  • A series of technical assessments that include on-the-spot coding assignments
  • Depth in Software Engineering (general)

How to prepare

  • Answer aloud and timed: Describe a situation where you had to debug a complex system issue under tight time constraints.
  • Answer aloud and timed: How do you ensure the robustness of your code when integrating with legacy trading systems?

Behavioral Discussions

Discussions designed to evaluate your behavioral fit and responses under pressure.

What to demonstrate

  • Discussions designed to evaluate your behavioral fit and responses under pressure
  • Depth in Software Engineering (general)

How to prepare

  • Prepare three examples from your own work, each with a decision you made and an outcome you can quantify.
  • Re-read the description of the behavioral discussions above and write down what you would ask to confirm before it.

Where candidates lose points

Think Aloud

During coding rounds, explain your thought process clearly. We are interested in how you approach ambiguity and complexity.

Understand the Context

Research the specific challenges related to the job title—such as latency for Market Connectivity or scalability for Cloud Engineering.

Ask Questions

Use the time at the end of your interviews to ask insightful questions about the team's current technical challenges and the company's long-term goals.

Your interviewers are looking for a partner in problem-solving

Treat the interview as a collaborative session rather than a test.

Questions & practice

Can you walk me through your approach to optimizing a piece of code for low-latency performance?

Medium · Technical and Coding Proficiency

Approach

  1. Restate the input: its shape, its size, and what is guaranteed about it.
  2. Name the brute-force solution and its complexity before improving on it.
  3. Choose the data structure from the access pattern, not from familiarity.
  4. 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?

How do you handle memory management in high-concurrency environments?

Medium · Technical and Coding Proficiency

Approach

  1. Say what the runtime actually does before reasoning about the code.
  2. Name what is shared across threads and what owns each piece of state.
  3. Identify the window where an invariant is briefly untrue.
  4. Distinguish a value from a reference to it, and say which one you handed out.

Follow-up

  • What happens if two callers reach this at the same time?
  • Where could this allocate more than you expect?

Can you explain the trade-offs between different data structures for a real-time data feed?

Medium · Technical and Coding Proficiency

Approach

  1. Restate the input: its shape, its size, and what is guaranteed about it.
  2. Name the brute-force solution and its complexity before improving on it.
  3. Choose the data structure from the access pattern, not from familiarity.
  4. 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 why the owner filter ignores the listing index

Medium · composite index · query plans · sort elimination

The only index on resource is (tenant_id, status, updated_at DESC, resource_id DESC). A new endpoint returns one user's resources across all statuses, newest created first: WHERE tenant_id = $1 AND owner_user_id = $2 ORDER BY created_at DESC LIMIT 20. On a tenant with 2M rows it takes 900 ms and EXPLAIN shows a sort above a large scan. Explain precisely why the existing index cannot serve it, give the index that can, and state which of these the new index still will not help: owner_user_id alone across tenants; the same query ordered by updated_at. PostgreSQL 16.

Approach

  1. Separate the two jobs an index does. For filtering, a composite btree is seekable only on a left prefix, so with no predicate on status the scan can at best range over tenant_id and test owner_user_id per row; PostgreSQL 16 has no btree skip scan to jump the unconstrained column.
  2. For ordering, the index is sorted by (status, updated_at) within a tenant and not by created_at, so the LIMIT cannot stop early: every matching row is read and then sorted. That is the 'Sort Method: top-N heapsort' line, and it is why the plan reads 2M rows to answer with 20.
  3. Derive the replacement from the access path — equality, equality, then the ordering column: CREATE INDEX CONCURRENTLY ON resource (tenant_id, owner_user_id, created_at DESC). The scan seeks to the (tenant, owner) range and walks 20 entries in order, so the Sort node disappears along with the row-read.
  4. Treat INCLUDE (title, status) as conditional, not free. An index-only scan still visits the heap for any row whose page is not marked all-visible, so on a table taking 1.2k writes/second the win depends on autovacuum keeping the visibility map current, and the wider index costs more on every insert.

Follow-up

  • 90% of rows are status='active'. Would a partial index WHERE status = 'active' change your answer, and for which of the three queries?
  • A dashboard runs this for 40 owners in one page load. What changes about the design?

Denormalise tenant onto revisions and backfill it live

Hard · denormalisation · online migration · backfill

resource_revision (revision_id, resource_id, version, actor_user_id, change_kind, patch, request_id, created_at) has 400M rows and no tenant column; tenant_id lives only on resource. Two reads need it: a tenant-scoped audit feed ordered by created_at DESC, and an offboarding purge. Both join back to resource today. Justify adding tenant_id to resource_revision against those two reads, name the anomaly the copy introduces and the constraint that prevents it, then give the ordered migration for a live table taking 1.2k writes/second — the lock each step takes, how the backfill is batched, and where each step stops being reversible. PostgreSQL 16.

Approach

  1. Justify from the access path rather than from taste. Without the column, the audit feed either scans resource_revision by created_at and discards other tenants' rows, or resolves the tenant's resource_ids first and probes with them — both proportional to the tenant's whole history rather than to one page. With (tenant_id, created_at DESC, revision_id DESC) it is a seek that stops at 50 rows, and the purge becomes a ranged delete instead of a join.
  2. Name the cost exactly: a second copy of a fact can disagree with the first. Make the disagreement unwritable rather than documented — add UNIQUE (resource_id, tenant_id) on resource so it can serve as a foreign-key target, then FOREIGN KEY (resource_id, tenant_id) REFERENCES resource (resource_id, tenant_id) on the revision table. A revision can then only ever carry its parent's tenant.
  3. Step one, expand: ALTER TABLE resource_revision ADD COLUMN tenant_id BIGINT NULL, with no default, so it is a catalogue change and no rewrite. It still needs ACCESS EXCLUSIVE for an instant, and that instant queues behind the longest open transaction on the table while every later query queues behind it — set lock_timeout to 2s and retry rather than wait.
  4. Step two, dual-write: deploy the writer that populates tenant_id on every new revision while reads still use the join. Reversible by redeploying the previous build, because nothing reads the column yet.

Follow-up

  • The backfill is half finished and a rollback is required. What state is the table in, and what does the previous build do with a half-populated column?
  • How do you verify the backfill actually finished, given rows are still being inserted while it runs?

How do you ensure the robustness of your code when integrating with legacy trading systems?

Medium · Technical and Coding Proficiency

Approach

  1. Say who the caller is and what they do when the call fails halfway.
  2. Define the identity of a request so a retry cannot double-apply it.
  3. Separate accepted, pending, failed and confirmed; they are different facts.
  4. Design the error taxonomy before the success shape; callers branch on it.

Follow-up

  • What happens if the caller retries after a timeout?
  • How does a client discover it is on an old version of this contract?

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

  1. 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.
  2. 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.
  3. 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.
  4. 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?

Describe a situation where you had to debug a complex system issue under tight time constraints.

Medium · Technical and Coding Proficiency

Approach

  1. Establish what changed and when, before forming any theory.
  2. Pick a bisection that eliminates candidates whichever way it turns out.
  3. Check the instrumentation before believing the symptom.
  4. 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 Gravitas Recruitment Group (Global) candidates report.

Day 1 — Map the Gravitas Recruitment Group (Global) loop

  • Write out the reported sequence: Initial Screening, Technical Deep Dives, Behavioral Discussions.
  • 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 Software Engineering (general)

  • Spend the session on Software Engineering (general), which Gravitas Recruitment Group (Global) candidates report being tested on.
  • Write one worked example in Software Engineering (general) and time yourself on it.

Deliverable: One timed worked example in Software Engineering (general).

Day 3 — Work Cloud Engineering

  • Spend the session on Cloud Engineering, which Gravitas Recruitment Group (Global) candidates report being tested on.
  • Write one worked example in Cloud Engineering and time yourself on it.

Deliverable: One timed worked example in Cloud Engineering.

Day 4 — Work Coding Assignments

  • Spend the session on Coding Assignments, which Gravitas Recruitment Group (Global) candidates report being tested on.
  • Write one worked example in Coding Assignments and time yourself on it.

Deliverable: One timed worked example in Coding Assignments.

Day 5 — Answer out loud: Technical and Coding Proficiency

  • Answer aloud, timed: Can you walk me through your approach to optimizing a piece of code for low-latency performance?
  • Answer aloud, timed: How do you handle memory management in high-concurrency environments?

Deliverable: Spoken answers to 2 reported Technical and Coding Proficiency question(s), under time.

Day 6 — Rehearse your own examples

  • Prepare three examples from your own work where you made the decision, each with the outcome you can quantify.

Deliverable: Three examples written out, each with a number attached.

Day 7 — Dry run for Gravitas Recruitment Group (Global)

  • 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.

Behavioural preparation

Behavioural rounds judge the decision you made and what it cost.

Tell callers you do not own that their integration breaks

Medium · deprecation · compatibility · stakeholders

A field in a write endpoint's response must change shape. You own the endpoint; you do not own the four internal callers or the outbound webhook consumers who read it. Describe a deprecation you were responsible for: what you shipped first, how you established who was actually reading the field, the window you gave and what set its length, what you did about the consumer who never moved, and how you decided removal was safe. Name the signal you used, not the announcement you sent.

Approach

  1. Establish the reader set empirically rather than from a wiki of owners: per-field usage counters keyed by principal, or access logs attributed to a consumer. State the blind spot of whichever you pick, since a consumer that reads the field only on a monthly job will not appear in a week of logs.
  2. Ship additive first. Populate the new field alongside the old one so no reader is forced to move, which is also what keeps a rolling deploy safe, because old and new instances answer the same requests at the same time and a rollback must still find the old shape present.
  3. Set the window from the slowest legitimate consumer's release cadence, not from your calendar, and decide separately what to do for a consumer with no release process at all, such as an external webhook endpoint you can only email.
  4. Convert silence into evidence before you rely on it: a short, low-traffic removal window that makes a still-dependent consumer fail visibly and loudly while you are watching, rather than at three in the morning after you have moved on.

Follow-up

  • How would you detect a consumer that reads the field only during a monthly export?
  • One caller refuses to move and has a commercial relationship behind it. What changes in your plan and what does not?

Reverse your own decision and price the reversal

Medium · reversibility · measurement · migrations

Describe a technical decision you made and later reversed. Pick one that cost something: a service you split and merged back, a cache you added and removed, an index you created that pushed the planner onto a worse plan, a projection you rebuilt from scratch. State what you believed when you decided, the measurement that changed your mind, how long the wrong version ran in production, and what the reversal cost in migrations, dual writes, and a deprecation window for callers you did not own.

Approach

  1. State the original rationale without irony, in the version you would still defend given what was known then. If it is not defensible, the story is about carelessness rather than judgement, and a different example serves you better.
  2. Give the measurement that moved with a before and after: the p99 that did not improve, the cache hit rate that sat at 40%, the plan that flipped to a sequential scan once the table passed a size you can name.
  3. Cost the reversal in steps, not adjectives: expand-and-contract deploys, the dual-write window, the callers who had to be notified, the rows already written in the wrong shape that had to be backfilled or abandoned.
  4. Distinguish reversal from rewrite by naming what you kept. Most good reversals preserve the schema or the interface and undo one decision inside it, which is also why they were affordable.

Follow-up

  • What in that decision was irreversible, and did you know it was irreversible when you made it?
  • How did you tell the people who had already built on top of the original decision?

Turn a code review disagreement into a decision

Easy · code review · optimistic concurrency · communication

A colleague's change updates a row with UPDATE resource SET version = version + 1 WHERE resource_id = $1 AND version = $2 and treats an affected-row count of zero as a successful no-op. You read that as a silently lost update; they think returning 200 is friendlier to clients than returning a conflict. Describe how you have handled a review disagreement of this shape: what goes in the comment, when you leave the thread, and who decides. Then write the comment you would leave here, in under 80 words.

Approach

  1. Sort the disagreement before writing anything. A silently discarded write is a correctness claim about data; the choice between 409 and 412 is taste. Only the first justifies blocking a merge, and saying which one you are doing is most of the value of the comment.
  2. Make the claim reproducible in the comment itself with an interleaving rather than a principle: A reads version 7, B reads version 7, B commits version 8, A's predicate matches zero rows, A is told it succeeded and A's edit is gone.
  3. Offer the alternative with its cost attached: return 409 carrying the current version and the revision that won, so the client can re-read and re-apply. Note that automatic retry is not the fix, because a retry re-reads the winner's state and reapplies an intent formed against data that no longer exists.
  4. Apply an escalation rule you can state: two round trips on the thread, then a call, and the service's owner decides rather than the reviewer. A reviewer who cannot be overruled is a bottleneck with extra steps.

Follow-up

  • Where would you put the test that fails if someone reintroduces the swallowed zero rowcount?
  • The author says clients cannot handle a 409. How do you check whether that is true?