Ansatz Capital Careers: Roles, Salaries & How to Apply

Ansatz Capital’s official website identifies it as a quantitative trading firm based in New York, with a small team of scientists and engineers. For someone researching careers, the most useful next step is its official Lever careers board, reached through the website’s Careers link.

Start with the employer’s own descriptions. They let you distinguish a company’s broad identity from the work a particular team is hiring someone to do. Here, the advertised titles are Research Engineer and Software Engineer. A directory’s generic “quantitative researcher” label should not replace those job descriptions.

The website is brief. It does not provide enough detail to independently establish every traded asset class, strategy horizon, team size or performance claim found in third-party profiles. This guide therefore focuses on the public evidence useful for choosing and preparing for a role. It does not infer a strategy from the fact that the engineering team works on latency.

Last checked: 3 October 2026. The table below is a snapshot of postings visible on that date. Return to the official board to check whether each role remains listed before preparing an application.

Each row links to the employer’s complete description. Figures are the advertised base compensation in that posting’s local currency, not a salary survey or a guaranteed offer.

All four descriptions also mention possible longer-term incentives. They do not specify a bonus amount, payout formula, deferral schedule or value for those incentives. Consequently, the table cannot establish total compensation or compare the expected value of two offers.

The ranges are attached to these jobs rather than a published graduate, mid-level and senior salary ladder. The London research posting does not show the full-time field visible on the other three descriptions; confirm the employment arrangement directly rather than filling that gap by analogy.

If you receive an offer, ask for the base currency, bonus terms, payment dates, any guarantee and conditions on one-time payments in writing. A discretionary award should remain a separate unknown in your budget. Comparing London and New York also requires taxes, living costs and immigration circumstances; converting the headline range alone will not answer the personal decision.

The New York Research Engineer description covers investigating trading ideas, testing and deploying strategies, and extending research infrastructure. It welcomes both people focused on statistical patterns and people focused on building useful research software. Python implementation is central to the research duties.

The London research qualifications specify a bachelor’s degree in a relevant technical field, statistics and quantitative problem-solving, and independent implementation ability. Python and C++ or an equivalent are preferred; prior quantitative finance or trading experience is a plus rather than a requirement. That is useful evidence for applicants coming from scientific research or engineering. It does not mean every candidate with a technical degree meets the role’s expectations.

The New York Software Engineer description instead emphasizes scalable trading applications and production infrastructure. It specifies C++11 or later experience, describes a C++20 codebase with Python above it, and names Linux, networking, CPU cache behavior and performance trade-offs. The London software role describes the same broad engineering emphasis.

Use the following distinction to choose evidence for your application. The deliverables are our interpretation of the advertised responsibilities, not the employer’s assessment rubric.

Systems engineering is a specialization to discuss within the software description here. A separate Systems Engineer vacancy was not on the checked board. Do not treat every desirable systems skill as a mandatory qualification, or assume that the research role is a pure mathematics job with someone else responsible for implementation.

The employer’s internship notice explicitly states that Ansatz Capital does not have an internship program at this time. It permits a resume to be kept on file and says applicants should not expect a response. Although the board displays this entry alongside jobs, it is not evidence of an active summer internship, a 2027 intake or an application deadline.

For a student, separate two decisions: whether the firm has a program that fits your enrollment stage, and whether your current evidence fits a full-time role. A resume collection page resolves neither eligibility for a future program nor the timing of an offer.

For a graduate or career changer, the research qualification that prior trading experience is optional is more relevant than assuming an annual campus intake. Build your case around the actual responsibilities, then confirm experience expectations, work authorization and start-date flexibility with the hiring team if your application progresses. The checked sources do not publish a dedicated graduate program, visa policy or university-specific hiring schedule.

This is an independent practice exercise, not an Ansatz take-home assignment. Its purpose is to show how you connect statistical reasoning with code and an honest conclusion.

Suppose your hypothesis is that a large return is followed by a reversal. Use a public dataset you are permitted to use, or clearly labeled synthetic data while learning. Before running a model, write down the sampling frequency, the observation available at decision time and when the hypothetical trade can begin. If the signal uses today’s closing price, assuming a fill at that same close needs an explicit justification.

1. Define the rule before inspecting the test period. For example, compare next-period returns after unusually large positive and negative observations with an unconditional baseline. Choose the threshold using the training period only.
2. Audit the observations. Record missing timestamps, duplicate rows, price adjustments and the treatment of gaps. Show one example of a rejected row and why rejecting it changes the calculation.
3. Keep evaluation chronological. Freeze the rule before examining a later period. Document overlapping return windows and why your uncertainty estimate accounts for dependence, or explain that your initial estimate is incomplete.
4. Add a cost scenario. Report gross results and a transparent hypothetical cost deduction. Identify the turnover calculation. A cost assumption is a sensitivity test, not evidence of attainable execution.
5. Try to invalidate the idea. Compare a simpler rule, inspect another period and explain whether the result depends on a few observations. Count the variants you tried so that the final result is not presented as a single untouched experiment.

Illustrative arithmetic, with invented numbers: if the gross average per completed trade is 2 basis points and the assumed round-trip cost is 3 basis points, the modeled net result is −1 basis point per trade. That exercise has rejected the tested implementation under those assumptions. A strong report explains the failure without quietly removing the cost or retuning on the held-out period.

Deliver a short README, one runnable script or notebook, tests for your calculations, a results table and a one-page brief. State what you learned, what you could not establish and what observation would justify another experiment. A clean negative result can make your judgment more visible than a chart with unexplained positive returns.

For the engineering direction, try this independent practice project: replay timestamped synthetic messages through a small application, update a state object and export a deterministic checksum. You can begin with a single-threaded implementation. Label the messages synthetic and describe their schema.

Write tests for an empty input, a duplicate, a missing sequence number, a malformed message and a burst. Decide what happens when a consumer cannot keep up. Silently dropping data is not an acceptable unexplained behavior; define whether the application blocks, rejects work, records loss or stops.

Once correctness is explicit, benchmark throughput and latency under a documented workload. Report both a central measure and a tail measure, alongside the machine, compiler options, input size and measurement method. Repeat the run and preserve the baseline. Explain what your numbers measure and what they exclude.

Change one thing, such as allocation behavior or memory layout, and rerun the same tests and workload. If you add concurrency, explain ownership, ordering and how you checked for races. A fast run that produces a different checksum has not improved the same program.

Prepare to discuss the evidence in plain language: where the bottleneck appeared, what profiler information supported your choice, what trade-off you made and how you would revert the change. Avoid introducing lock-free structures merely because the job description mentions them. An understandable, measured design is a better learning artifact than a complicated implementation you cannot reason about.

This exercise does not reproduce an exchange, validate production readiness or certify expertise in low-latency trading. It gives you a concrete artifact for discussing engineering judgment and a clear list of what you still need to learn.

Begin with one role and office. Make a two-column note: an advertised responsibility on the left, your evidence on the right. “Implemented a statistical idea independently” needs a specific example of your work, not only a list of Python libraries.

For each example, be ready to explain the problem, your contribution, the result and the limitation. A collaborative project should make your contribution explicit. A confidential project can be described at a level your employer permits; do not publish proprietary data or code to make a portfolio more impressive.

Use the vacancy to prioritize practice. A research discussion can be rehearsed around assumptions, statistical uncertainty, data timing and implementation. An engineering discussion can be rehearsed around debugging, resource usage, correctness and measured performance. These are suggested topics derived from the work; the checked employer sources do not describe a fixed interview sequence or a verified question bank.

Before accepting an interview, clarify the expected format and permitted tools. During the process, ask how research and engineering responsibilities are divided, who reviews changes, how work is prioritized and what success looks like during the first months. Those answers are more useful for evaluating the actual job than guessing the culture from a directory profile.

Adapt the pace to your starting point. Two weeks is an organization tool, not a promise of interview readiness.

At the end, ask another person to run the artifact using only the README. Missing instructions, hidden manual edits and an unrecorded dependency are useful findings. Fix them before linking the project in an application.

The checked public sources do not establish current headcount, complete strategy coverage, typical realized bonuses, visa sponsorship, required office attendance or a standardized interview process. Third-party profiles also differ on founding details. We do not turn those gaps into company facts or use a UK entity’s incorporation date as the founding date of the entire firm.

For the research direction, take the QuantSteps assessment to identify gaps in statistical and Python foundations, then inspect the quantitative research path.

For engineering, the quantitative developer blueprint explains the direction and shared foundations; the specialist route is planned. QuantSteps’ current deeper teaching focuses on research. Evaluate a systems learning plan against the advertised C++ and production requirements rather than assuming a research course covers them.

Use these learning resources to build understanding and evidence. They are independent of Ansatz Capital and do not imply employer endorsement, a guaranteed interview or a job offer.