QA Engineer — CTRM Platform

About the role

A hands-on QA engineer owning the quality of our CTRM platform end to end: deciding what has to be tested, building the automation, finding the defects that matter and making sure they stay fixed. You work directly with backend engineers, the product manager, the data team, and the traders and finance users who will run their business on the system — no account manager in between.

Agents write most of the code here. That makes testing more important, not less: the team ships quickly, and a large part of quality now depends on independent verification that the system does what the business needs, not what the code happens to do.

What the work looks like

The system we are building exists so that anyone involved in a deal can reconstruct the P&L between any two points of the chain, at any moment, on an agreed and versioned allocation basis. A defect here is rarely a broken button. It is a pricing formula averaged over the wrong period, a provisional cost that is never replaced by the actual, a figure that changes when someone reruns last month, or an FX rate applied on the wrong date. Numbers from this system feed invoices, hedges and shareholder reporting.

Scope

• Test strategy and test plans for the platform: deal capture, pricing and pricing periods, provisional and final invoicing, costs, demurrage and claims, P&L and margin, reporting
• Automated tests at API, data and UI level, integrated into CI so every change runs against them
• Realistic test data and scenarios — term contracts, multi-lot cargoes, price-formula deals, FX, late invoices, cost reallocation — and expected results someone in the business has signed off
• Regression testing of calculations: the same deal must produce the same P&L, and a past date must reproduce the P&L as it stood then
• Data and integration testing — market data feeds, imports from accounting and operations systems, reconciliation between the platform and the source it came from
• Reviewing agent-written code and agent-written tests critically: a test that always passes is worse than no test
• Working with users on acceptance testing and turning their “this number looks wrong” into a reproducible defect
• Release quality: what is safe to ship, what is not, and why

Requirements

• 4+ years in QA or software testing, with ownership of test strategy and automation on a business-critical product
• Strong test automation in Python (pytest or similar) or another mainstream language; API testing; UI automation with Playwright, Cypress or similar
• Good SQL and the ability to test data directly: write queries to check a calculation, find a population mismatch, prove a number wrong
• Experience testing calculation-heavy or financial systems — trading, banking, payments, billing, ERP or accounting. You think in edge cases: rounding, dates and time zones, currencies, partial quantities, reversals and corrections
• Understanding of CI/CD and of where tests belong in it
• Working with coding agents, seriously. You use agents to write tests and tooling, and you know how they fail: tests that assert what the code does rather than what it should do, mocks that hide the real behaviour, coverage that looks high and checks nothing. We hire for verification habits, not speed
• Precise written communication: defect reports a developer can reproduce on the first attempt, and test results a manager can act on
• English sufficient to present findings and defend a release decision
• Professional proficiency in Russian

Nice to have

• Experience with CTRM/ETRM systems or energy or commodity trading — deal lifecycle, pricing formulas, invoicing, P&L
• Performance and load testing
• Property-based or data-driven testing for financial calculations
• Experience setting up a QA function or test framework from scratch in a growing team

What we offer

• Ownership of quality on the platform, and room to shape how testing is done
• Direct access to founders, engineers and business users; short feedback loops
• Generous AI tooling budget — frontier models are a working expense, not a perk
• Competitive compensation, discussed individually

How to apply

Share your CV and an answer to any of the questions below, at your choice. Applications without answers are not reviewed.

1. A cargo is priced on an average of five quotation days after the bill of lading, in USD, with costs invoiced in EUR. The P&L for this deal shown last month differs from what the system shows today for the same date, and nobody changed the deal. How would you test for this, what would you look at first, and what tests would you add so it cannot happen silently again?
2. Give a real case where a defect reached production in a system where numbers mattered — money, quantities, prices. What was wrong, why did the tests miss it, how was it found, and what did you change?
3. Show a real prompt or task brief you gave an agent to write tests, and what it produced. Then one case where agent-written tests looked good and did not actually protect anything: what was wrong, how you noticed, what you did instead.
4. Which systems have you personally tested — trading, banking, payments, billing, ERP or accounting? Pick one and tell us about a defect class specific to that kind of system that someone without that experience would miss.

Originally posted on Himalayas