Senior Software Engineer (Remote)

Global Finance Teams; Metro Manila; On-site; PHP 1,500,000 - 2,400,000; Full time

Job summary

Global Finance Teams is seeking a senior engineer to own and deliver complex technology projects with a strong emphasis on precise specifications, guardrails, and acceptance criteria. You will guide the work with both LLM agents and human review to ensure the business needs are met while maintaining scalable, reliable systems.

You will define non-functional requirements, performance targets, and telemetry, then drive implementation and verification, shipping improvements and guarding against

Qualifications

• Ability to write precise requirements including non-functional aspects.
• Judgment on scale, cost, and failure modes.
• Ability to prioritize ruthlessly to avoid bloat.
• Ability to sense what is right for the customer.

Responsibilities

• Think through options, trade-offs, risks, and how it links to upcoming work.
• Write the specification with acceptance criteria, out-of-scope items, telemetry, and non-functional requirements.
• Implement with an acceptance script that checks criteria and telemetry.
• Ship, observe, fix defects, and monitor production for issues.
• Learn from guardrails and costs, and queue improvements as permanent checks.
• Start with small improvements, growing into feature-level work.
• Mastery means owning larger features and improving tooling.
• No daily standups.

Skills

Specification design

Systems judgment

Prioritization

Product sense

Job description

How We WorkWe're looking for a senior engineer to take on a growing share of technical delivery.Most implementation here is performed by AI coding agents. We don't care much about what the source code looks like as long as it meets requirements. We don't often read it line by line. We instead focus on increasing our software delivery rate and decreasing our shipped defect rate through better specification, better tools, and compounding improvements.There are a handful of us, so you will decide on your feet and work directly with every employee and with customers. We don't have time to wait for multiple PR cycles.We are not hiring for any particular AI tool or harness. Whatever we use today will be replaced soon. We instead hire for key concepts that outlive any individual tool:

• Reliability comes from the system around the model, not the model. We assume it will do the wrong thing. Specifications, guardrails, and acceptance criteria exist so the implementer can be as unintelligent and untrusted as possible. If correctness depends on the model being clever, the process is wrong.
• Specifications have to be pedantic, because nobody catches it in review. If the code must be fast, "fast" appears in the requirements as a number and a test. The judgment that used to surface in code review moves forward into the spec, where it can be stated and checked.
• You are a supervisor. Your intuition is honed on years of experience, and it scales by being encoded into our systems. You need to know that a sequential scan is fine at ten thousand rows and fatal at ten million, that a retry without an idempotency key charges someone twice, and that a migration takes a lock and stalls the write path. Nobody will read the code and notice.
• Correctness is defined against the business, not the ticket. What the customer needs and pays for is the standard.

About the Role

Your job is to know the business and the systems well enough to spot when an agent has produced the wrong thing, to keep its work inside the given scope, and to improve the process so that class of error can't recur. That takes more design judgment, review discipline, and product knowledge than a conventional senior role, not less. It's the wrong job if you want to spend your days writing code by hand.

Responsibilities

• The LoopFor any piece of work, with LLM and human review as appropriate at each step:
• Think it through interactively: options, trade-offs, what could go wrong, and how it links to what's coming.
• Write the specification: acceptance criteria, an explicit out-of-scope list, telemetry, and the non-functional requirements: latency, query behaviour, memory, and cost.
• Implement: including an acceptance script that checks the criteria are met, inclusive of emitting telemetry and omitting out-of-scope work.
• Ship and observe: run the acceptance script, fix what's needed, and watch production for defects.
• Learn: what guardrails were hit, what cost time, and queue the work that turns the lesson into a permanent check.
• Ramp and What Success Looks LikeYou'll start on small improvements and bug fixes to build familiarity with the business, the technology, and the process, growing into feature-level work.
• Mastery shows up as owning larger features, authoring specifications rather than receiving them, and improving the tooling and harness.
• Signs of success after three months:
• You write specifications that get built without multiple rounds of review and without serious technical or product design flaws.
• You can review what a coding agent has produced, find problems, and suggest fixes without asking other team members.
• You are constantly improving our development tools as a byproduct of your work.
• We don't feel like we need a daily standup.

Qualifications

• Eight or more years building and operating web services, or fewer with clear evidence of senior-level ownership.
• Depth in at least one dynamic language. Python preferred but definitely not required.
• Experience in relational database schema design, query performance, migration, and troubleshooting. Postgres preferred but other relational databases (MySQL,

Required Skills

• Specification and verification design. Can you state a requirement precisely enough that it can't be misread, including the non-functional parts, and then design how to prove that it works?
• Systems judgment. You know what breaks at scale, what it costs, and what fails; you assume every network call will fail and every model will misbehave.
• Ruthless prioritization. What's in, what's out, and what isn't worth doing at all, which it usually isn't. Going along with whatever the LLM suggests leads to bloated projects we can't afford. It also means recognizing when the lesson from a piece of work is worth more as a permanent check than the next three tickets.
• Product sense. You can tell whether something is right for a customer without being told.