GSA Capital Interview Guide: Official Process and Preparation

GSA Publishes the Process

In 2026, GSA Capital did something unusually helpful for candidates: it published a detailed interview process. For core research and technology roles, the firm says the standard path includes two first-round technical interviews of up to one hour each, a take-home exercise, a recruitment alignment call, up to roughly four hours of deeper interviews and final conversations with senior or technical leaders.

That is firmer evidence than anonymous interview recollections. It also shows how much third-party interview folklore has no official basis. GSA does not describe a 90-minute online assessment, a two-to-four-page signal report, interviews with two founding partners, a Belgrave Square "super day", a 15% pass rate or a fixed two-week offer timetable.

The company facts are more modest too. GSA says it was founded in 2005 and is a close-knit team of 150. It describes systematic trading across asset classes, geographies and time horizons, and says it manages its own capital alongside investor money. It does not publish an AUM figure or support claims about a particular stat-arb, options or macro allocation.

This guide uses the firm's published sequence as the spine, then prepares candidates for the work described in its current vacancies.

The Five Published Stages

First-round technical interviews

GSA says there are two remote interviews, delivered through HackerRank or Zoom, each lasting up to one hour. They assess foundations in computing, engineering, mathematics or statistics. The firm also warns that these rounds leave limited time for candidate questions.

This wording matters. HackerRank is named as an interview medium, not as proof of one standard timed coding test. The subject depends on the role.

Take-home exercise

The exercise is completed in the candidate's own time and is designed to show practical skill without live pressure. GSA's guidance is unusually direct: keep it simple, use time wisely and show sound design, tests, documentation and maintainability. It does not publish the task, page count or deadline.

For researchers, that suggests a clean analytical workflow. For developers, it suggests working software and engineering judgement. Neither inference should be confused with a disclosed question.

Recruitment alignment call

While the take-home is in progress, recruitment discusses motivation, goals and what the candidate needs to succeed. Use this call to resolve ambiguity in the brief and to ask about team fit, location and later stages. GSA presents it as mutual alignment, not another hidden technical test.

Deeper interviews

Round two can involve up to roughly four hours of onsite or remote interviews. Evaluation becomes more technical and team-specific. This is also the point at which GSA says candidates should understand what their role might look like.

Final conversations

Senior or technical leaders assess long-term potential and cross-functional fit. GSA notes that the route can flex when an alternative team fit emerges or further verification is needed. A strong performance therefore does not create a guaranteed outcome.

Role-Specific Preparation

Quantitative research

GSA's current quantitative-research vacancies describe creativity, rigour and attention to detail in the design of systematic strategies. Researchers use applied mathematics and statistics on large datasets, then contribute to research, implementation and development.

Prepare one project end to end: hypothesis, data availability, universe, validation, costs, portfolio construction and monitoring. Know exactly which choices were made after looking at results. If the take-home uses unfamiliar data, first build checks for timestamps, missingness, revisions and units. A sophisticated model on a contaminated dataset is not a sophisticated answer.

The firm's own interview page asks for honesty about strengths and weaknesses. Include a limitation that could genuinely reverse your conclusion, then propose the next test. Our quant research question guide and statistical arbitrage overview cover useful foundations without pretending to reproduce GSA's exercise.

Software development

GSA says software candidates do not need a finance background, but must care about using technology to solve relevant problems. Internship candidates need a strong computer-science foundation and evidence of high-quality code.

For the live interviews, practise writing a correct solution while explaining data structures, complexity and tests. For the take-home, optimise for a reviewer: a small interface, explicit assumptions, deterministic tests, sensible errors and a README that makes the project easy to run. Do not add distributed machinery to a task that works clearly in one process.

At the deeper stage, prepare one system you know well. Cover why it exists, the load and failure model, a trade-off you made and the evidence that the design worked.

Infrastructure and business operations

Current vacancies include IT and infrastructure alongside research, development and business operations. The role descriptions make the difference clear. Infrastructure work concerns high-performance global systems and practical operation; business operations spans areas including trading operations, risk, finance, compliance, recruitment and procurement.

Do not prepare these seats as diluted quant-research interviews. Use the vacancy's responsibilities. An infrastructure candidate should be ready to diagnose a system under failure. An operations candidate should show numeracy, prioritisation, control awareness and communication across stakeholders.

Use Each Stage to Add Evidence

The published sequence allows candidates to avoid repeating the same polished story five times. In the first technical rounds, make foundations visible: define terms, state assumptions, use a simple baseline and test the result. During the take-home, demonstrate practical judgement through structure, documentation and deliberate scope. The alignment call is the place to connect your preferred work with the actual team. Deeper interviews can then test whether the same reasoning survives challenge and whether you can work across research and engineering boundaries.

Build a small evidence inventory before applying. Researchers should record the data vintage, universe, validation split, costs and failed tests for one substantial project. Developers should identify code they owned, users, constraints, tests and measured operational outcomes. Infrastructure candidates should prepare an incident account with detection and recovery evidence. Business-operations candidates should show how a control or decision improved. Academic examples are valid, but label simulated or classroom results accurately.

Do not send confidential code, data or strategy details from an employer in an effort to appear relevant. GSA's take-home advice rewards maintainability and clear design, neither of which requires borrowed intellectual property. If a public repository is part of the application, make sure it runs from its instructions, contains no secrets and has a commit history you can explain.

Evaluation Criteria Inferred from GSA's Guidance

GSA tells candidates that it wants to understand reasoning, strengths and weaknesses, and it gives explicit advice about simple, maintainable practical work. It does not publish a numerical rubric. The following are therefore reasoned inferences from first-party material:

• technical foundations, shown by correct reasoning before specialised terminology;
• practical simplicity, choosing a design proportionate to the problem rather than maximising novelty;
• research integrity, including point-in-time data, honest limitations and resistance to data mining;
• maintainability, through interfaces, tests, documentation and reproducible execution;
• curiosity and ownership, asking useful questions and following a discrepancy through to evidence;
• generous collaboration, explaining work so another person can challenge or extend it.

An interview correction need not be fatal. If a test case disproves your first solution, isolate the failed assumption, revise the method and check the new boundary. That response gives more evidence about long-term potential than defending an answer you now know is wrong.

Practice for Each Stage

The following prompts are ours, based on the official process and role descriptions. They are not reported GSA questions.

Research foundations: A signal has a stable t-stat but loses money after costs. What evidence would tell you whether the problem is turnover, capacity, delayed execution or a false forecast?

Statistical judgement: You tried 200 related specifications. How would you estimate the true amount of data mining when the tests are correlated?

Live coding: Join market observations to the latest information actually available at each timestamp. Explain ordering, duplicate timestamps, late corrections and tests for look-ahead.

Research take-home: Present one primary result and one falsification test. Keep exploratory charts separate from confirmatory evidence and record every transformation.

Developer take-home: Implement the smallest maintainable service that meets the brief. Add tests around boundary conditions and one failure path; explain what you deliberately did not build.

Deeper interview: A backtest and live process disagree on the same date. Trace the investigation from source data through code version, parameters, environment and output comparison.

GSA explicitly says its questions are intended to reveal reasoning rather than trick candidates. Narrate assumptions and trade-offs, but do not fill silence with guesses. For probability practice where the role calls for it, use our quant probability questions.

Frequently Asked Questions

Is GSA's process the same for every role?

No. The published sequence is a roadmap for core research and technology positions. GSA says other teams and roles may differ, and even the standard path can flex.

Is there an online assessment before interviews?

GSA describes two remote first-round technical interviews through HackerRank or Zoom. It does not describe a separate standard 90-minute online assessment on its current process page.

What is the take-home?

The firm calls it a practical exercise that reflects work the team faces. It does not publish the task or deadline. Its advice is to keep the solution simple and focus on design, tests, documentation and maintainability.

Does GSA require a finance background?

Not for software development: the firm explicitly says it is unnecessary. Research vacancies ask for strong academic credentials and applied mathematical or statistical ability. Internship criteria are listed on each live vacancy.

How long does the process take?

GSA acknowledges that its process is not the shortest but publishes no fixed duration. Scheduling, take-home time and team matching can alter it. Ask recruitment about timing if another offer is active.

Is GSA the right fit for every quantitative candidate?

No. Its public material suggests close collaboration in a 150-person systematic firm and a process that values both research and implementation. That may suit candidates who want ideas challenged across functions and are comfortable with a substantial selection process. A pure researcher should ask how much production ownership the seat carries; a developer should ask how closely work connects to trading. At the time of review, research roles appeared in London and New York while many other openings were in London, but the live jobs page controls location. Compare the actual seat with the specialisation, pace and decision responsibility you want.

GSA has already told candidates what it values: foundations, practical judgement, curiosity, ownership and generous collaboration. Preparation should make those qualities visible at each stage.