Work on problems that don’t come with answers.

A short call with the recruiting team, then two to three technical rounds with the desk you would join, covering problem solving, code or market reasoning depending on the role. A final conversation with a partner closes the loop.

No. Many of our researchers and engineers joined from mathematics, physics and computer science backgrounds with no market exposure. What matters is depth in your own field and the appetite to learn how markets work.

There is no take-home assignment. Rounds are conversations and problems worked through live, so it helps to be ready to explain your own past work in detail and to think out loud.

Most roles sit on the trading floor in Mumbai, because the work depends on being close to the desk and to production systems. A small number of engineering positions are open to hybrid arrangements, which we state on the listing.

Yes. We run a structured internship each year and hire graduates directly onto research, engineering and trading teams. Interns work on live problems with a mentor on the desk.

You are paired with a mentor and given a real piece of the system to own, small at first and larger as you get your footing. Onboarding continues alongside the work rather than before it.

Write to careers@irage.in with a short note on what you work on. Roles are often shaped around a strong candidate, and we would rather see the profile early than not at all.

Every applicant who reaches an interview hears back with a decision. For applications that do not move forward at screening, we reply within two weeks.

Most production work is C++ on Linux, with Python for research tooling and analysis. Networking, kernel behaviour and hardware timing matter as much as the code itself.

Both exist. Teams cover the order gateway and latency-critical path, exchange connectivity, and the internal platforms that research and operations run on.

Not to join. You will pick up market structure quickly because the systems you own are described in those terms, and colleagues on the desk explain the trading context as you go.

Data structures and systems reasoning, one round on your own past projects in depth, and a discussion of how you would design or debug something close to what the team runs.

The team that built it. Engineers deploy their own changes and are on the roster for the systems they own, which keeps design decisions honest.

Yes. Performance, fill quality and latency numbers are visible to the team, and engineers sit with the traders whose results depend on that work.

Internal moves happen regularly, usually after a year in one area. Tell your lead what you want to work on and the conversation starts there.

Colocated servers at the exchanges, tuned network paths and FPGA work where it earns its place. You will have access to real hardware, not a simulated environment.

Teams are small, usually three to six people, and each owns a defined part of the stack end to end. You will not be one of fifty engineers on a single service.

Continuously, with review and staged rollout. Releases are small by design so a problem is easy to isolate and revert.

Yes. Certification, protocol changes and connectivity testing with the exchanges are handled by the team that owns the gateway.

Every change is read by someone else on the team before it ships. Reviews cover correctness and latency impact, not style preferences.

On-call rotates within the owning team and covers market hours plus deployment windows. It is rostered in advance and compensated.

Yes. Teams keep a share of each cycle for tooling, refactoring and experiments, agreed with the lead rather than squeezed into evenings.

Monitor live strategies through the session, judge when conditions change and work with research and engineering on what to adjust. Most of the day is analysis rather than manual order entry.

Traders shape strategy ideas with researchers and own the parameters and risk of what runs on their desk. Implementation is a joint effort with engineering.

Yes, enough to work with data and test an idea yourself. Python is the common starting point; you are not expected to write production systems.

Against agreed risk and the behaviour of the strategy over a period, not on single days. Reviews look at decisions and process alongside results.

Indian market hours, with pre-open preparation and a post-session review. Hours are fixed and the day ends when the session and review are done.

You start alongside an experienced trader on a live book with small limits, and take on more as your judgement is tested against the market.

Compensation has a fixed component and a performance component linked to the desk and the firm. The structure is explained in full at offer stage.

Strong quantitative reasoning and clear decision making under pressure. Candidates come from engineering, mathematics, economics and from other trading desks.

Set and monitor limits, watch exposure through the session in real time, and review breaches with the desks. The team also builds the tooling that makes exposure visible.

Risk reports independently of the desks, but sits on the same floor and works with traders continuously rather than at a distance.

A quantitative degree and comfort with data. Experience in derivatives, margining or exchange rules helps, and can be learned on the job.

Internal position and exposure systems built in house, exchange margin feeds, and Python tooling for scenario analysis and reporting.

Limits are proposed with the desk, approved by the risk committee and reviewed on a regular cycle, or immediately when market conditions change.

Live monitoring follows market hours, with pre-open checks and end-of-day reconciliation. Project work sits outside the session.

From monitoring and reporting into limit design, methodology and firm-level exposure work. Senior members sit in the risk committee.

Expect questions on probability, derivatives intuition and how you would react to a live exposure problem, plus a conversation about your past work.

Both. The session demands live monitoring, and the hours around it go into methodology, scenario work and improving the tooling.

The breach is flagged in real time and the position is brought back within limits first. The review with the desk happens afterwards and the reasoning is written down.

Yes. People move into risk from desks and from systems teams, and that experience is useful because the work depends on understanding both.

Everything the firm trades across cash equities, futures and options, including exchange margin treatment for each.

Limits, methodology and escalation paths are written down and version controlled, so any number on a dashboard can be traced to its definition.

Yes. Monitoring views, scenario runners and reports are built in the team, usually in Python against internal data services.

Market data quality, execution and latency analysis, and the measurement that tells the firm whether a change actually improved anything.

Python and SQL day to day, with internal time series stores and visualisation tooling. Large jobs run on the firm’s own compute.

Both sides exist. Some of the work is analysis that answers a question once; some is a pipeline or dashboard that has to run every day.

Enough curiosity to ask what the numbers mean. Analysts learn market structure through the questions the desks bring them.

Yes. Most projects begin as a question from a trader or researcher, and the answer is presented back to them directly.

A discussion of a past analysis you owned end to end, questions on statistics and data handling, and a practical problem using a small dataset.

Analysis is shared in regular internal sessions, and strong work reaches the whole floor rather than staying with one desk.

Tick-level market data across instruments and years, so efficiency and careful sampling are part of the job.

Apply through the role listing on this page, or write to careers@irage.in with your CV and a short note on what you work on.

Yes. Tell us which roles interest you and the recruiting team will route your profile to the right desks rather than duplicating the process.

Yes. Reapply whenever a role fits your experience, or after six months if your work has moved on. Previous applications stay on file.

Candidates moving to Mumbai receive a relocation allowance and help finding accommodation near the office, and the team keeps in touch through the move.

Identity and education proof, previous employment records and payslips. The recruiting team sends a checklist with the offer.