Senior Software Engineer - Polyglot

The posting

OVERVIEW OF 73 STRINGS:

73 Strings is an innovative platform providing comprehensive data extraction, monitoring, and valuation solutions for the private capital industry. The company's AI-powered platform streamlines middle-office processes for alternative investments, enabling seamless data structuring and standardization, monitoring, and fair value estimation at the click of a button. 73 Strings serves clients globally across various strategies, including Private Equity, Growth Equity, Venture Capital, Infrastructure and Private Credit.

Our 2025 $55M Series B, the largest in the industry, was led by Goldman Sachs, with participation from Golub Capital and Hamilton Lane, with continued support from Blackstone, Fidelity International Strategic Ventures and Broadhaven Ventures.

Role Summary

We’re looking for a Senior Software Engineer to own the integration layer of our platform: the services that pull market data, FX rates, and client data into 73 Strings, and the APIs that expose our data back out to clients and their systems.

This is the surface where our platform meets everyone else’s. Third-party feeds change format without warning, client APIs behave differently from their documentation, and a valuation that arrives late or with a stale FX rate is a real problem for a real investment committee. You’ll build services that hold up under that, and you’ll own them from the first commit through to running them on Kubernetes.

It’s a hands-on senior role for someone who moves without being pushed. You’ll work closely with Data Engineering, Product Management, and the product verticals, and you’ll be expected to challenge an integration design or an API contract that won’t survive contact with production.

What You’ll Own

Third-Party and Market Data Integrations

• Own our integrations with market data and reference data providers, FX and currency sources, and the financial data vendors our valuation and monitoring products depend on.

• Design ingestion services that treat vendor unreliability as normal: rate limits, partial responses, schema changes, retries, idempotency, and sensible degradation when a feed goes down.

• Own correctness at the boundary. Validate what arrives, reconcile against expectations, and make sure a bad upstream payload fails loudly instead of quietly polluting downstream data.

• Build the integrations as reusable patterns rather than one-off adapters, so the fifth provider takes days rather than the same weeks as the first.

Client API Integrations and Data-Out APIs

• Build and own the integrations that connect 73 Strings to client systems, including their internal APIs, file-based exchanges, and third-party platforms in their stack.

• Design and deliver the APIs through which we expose our data to clients: clear contracts, versioning, pagination, authentication, and authorization that stands up to enterprise security review.

• Make those APIs genuinely performant. Understand the query patterns behind each endpoint, and design for the payload sizes our largest clients actually request.

• Own the interface contract over time: deprecation as a planned event, backwards compatibility as a default, and breaking changes as a deliberate, communicated decision.

Service Ownership, End to End

• Own your services from code to production: design, implementation, tests, CI/CD, deployment on Kubernetes, configuration, and rollback.

• Instrument what you build. Metrics, structured logs, traces, dashboards, and alerts that let you or an on-call engineer diagnose an issue without reading the source.

• Define and meet SLOs for the services you own, and be honest about where the current design is a risk.

• Take part in on-call for your services, and close incidents with a fix that prevents the next one rather than a note in a document.

• Manage the cost and resource footprint of your services alongside their performance.

Performance and Reliability

• Treat performance and reliability as requirements, not as a later optimization pass. Know the latency and throughput profile of your services and where they break.

• Profile before optimizing. Find the actual bottleneck, whether it’s a query plan, a serialization cost, a chatty call pattern, or a thread pool.

• Design for failure modes you can name: timeouts, backpressure, circuit breaking, bulkheads, and graceful degradation under load.

• Reduce complexity and technical debt where it threatens reliability, and make the case for that work with data.

Collaboration and Craft

• Write production-grade Java and Python that other engineers can read, test, and change safely.

• Partner with Data Engineering on the contracts between services and the data platform, so ingestion, modelling, and exposure line up rather than each solving the same problem twice.

• Work with Product Management to shape requirements, question assumptions, and push toward simpler solutions that ship.

• Contribute to architecture and design reviews across the wider engineering group, and raise the bar around you through review and mentorship.

• Interact with clients occasionally, mainly on integration design and technical troubleshooting. This is not a client-facing role, but you should be comfortable in the room when it helps.

What You Bring

• Strong hands-on backend engineering experience, with production ownership of services that other teams and external systems depend on.

• Proficiency in both Java and Python. Not one plus a reading knowledge of the other — you should be able to build and debug production code in either.

• A real track record with complex integrations: third-party APIs, market or reference data feeds, financial data exchanges, or enterprise client systems.

• Experience with financial data and the care it demands: as-of semantics, corrections and restatements, currency conversion, precision, and audit trails.

• Demonstrated depth in API design: REST or gRPC, contracts and versioning, authentication and authorization, and the trade-offs behind each choice.

• Solid understanding of distributed systems, microservices, event-driven architecture, and the operational realities of running them.

• Hands-on experience deploying and operating services on Kubernetes, with working knowledge of CI/CD and infrastructure-as-code.

• Practical experience with observability tooling, and the instinct to instrument a service before it becomes an incident.

• Comfort with relational databases and query performance, plus enough familiarity with data platforms (Snowflake, Databricks, or similar) to work well with Data Engineering.

• A self-starter track record: you find the important work, scope it, and drive it without needing a ticket written for you.

• Experience in a scaleup where the roadmap, the team, and the requirements all change at once, and where you were expected to build things that outlive the quarter.

• Exposure to SaaS and multi-tenant architecture: tenant isolation, per-client configuration, and the operational cost of both.

• FinTech, financial services, or another regulated industry is a strong plus. Tool-agnostic is an advantage: we’d rather hire someone who picks the right tool than someone who defends a favourite.

• Clear written communication. You can write a design doc that survives review and explain an incident to a non-engineer without hiding behind jargon.

How You Work With AI

We’re an AI-first company, and that has to mean something more than having a coding assistant installed. We expect senior engineers here to have genuinely changed how they work.

• You use AI as a working tool across the job, not just in the editor: reverse-engineering an undocumented vendor API, generating integration test cases and edge-case payloads, drafting and reviewing migration plans, triaging production logs, and writing the documentation nobody else wants to write.

• You go beyond prompt-and-paste. You’ve built or configured something (agentic workflows, evaluation harnesses, custom tooling, MCP integrations, automated review or triage) that made a repeatable part of engineering measurably faster or more reliable.

• You know where AI output cannot be trusted. Generated integration code that handles the happy path and silently drops errors is worse than no code at all. You verify, you test, and you can explain how you verified.

• You apply the same judgement to AI-generated code that you’d apply to a junior engineer’s pull request: read it, challenge it, own it once you ship it.

• You share what works. A technique you discovered that stays on your machine is worth a fraction of one the whole team adopts.

If your answer to “how do you use AI” is autocomplete and the occasional chat window, this role will feel like a stretch — and we’d rather tell you that now.

You Will Excel If You…

• Question everything. A vendor contract that can’t be honoured, an API shape that leaks our internal model, a requirement that would produce a wrong number: you raise it rather than build it.

• Believe a service isn’t done until it’s deployed, instrumented, and someone other than you can operate it.

• Are drawn to messy integration problems and enjoy turning them into something repeatable.

• Are comfortable owning something end to end, including the pager.

• Care that the numbers are right, because in our business a wrong number reaches an investment committee.

• Move without waiting to be told, and know when to bring others in rather than build alone.

• Know the difference between pragmatic and sloppy, and won’t compromise on the former to avoid the latter.