Here is a small puzzle. A lender has a fixed pot of money for the week and a queue of loan applications, each with an amount, an estimated chance of default and an expected margin. Which ones do you approve? Would you trust a gut feeling, or a model that can prove its answer is the best one the rules allow? If the second option sounds like more fun, remote decision engineer jobs are probably worth your time. This is a full-time, remote position open to candidates anywhere in the world, paying USD 125,000 a year, and the daily work is turning messy business choices into rules and optimisation models written in Python, SQL and Gurobi.
A decision engineer sits between the people who set policy and the systems that carry it out. Credit and pricing teams write policies in slide decks and email threads; you make them precise enough for a machine to run thousands of times a day.
In plain terms, the decision engineer job description for this role covers four things: building decisioning rules and optimisation models, translating business policies such as credit or pricing rules into code, running simulations and A/B tests on decision strategies, and watching how those strategies behave once they are live. The next few sections walk through one problem from start to finish.
Go back to the loan queue. Before you touch a solver, you need three answers written down. What exactly is being decided? Here it is a yes or no for each application, maybe with a credit limit attached. What are you trying to make as large or as small as possible? Perhaps expected profit after losses. And what must never happen? A total lending budget, a cap on exposure to any one segment, a regulatory rule that certain applicants must be declined.
A credit manager might say "we want growth, but carefully". Your job is to ask questions until that becomes something like "maximise expected margin, subject to the expected loss rate of approved loans staying under a stated threshold". Skip this and you get a well-tuned model of the wrong problem. Good framing also tells you what data to pull with SQL.
"Decline if the applicant is under 18" is a rule. "Refer to manual review if stated income is missing" is a rule. These belong in a versioned rule layer, often plain Python, that a reviewer can read line by line.
Rules start to break down when choices compete for the same scarce resource. If approving one large loan means you cannot fund three smaller ones, a simple score cut-off will not find the best mix. That is where optimisation earns its place. A sensible design layers the two: hard rules filter, then the optimiser picks the best mix of what is left. Knowing which tool fits which part of the problem is one of the most useful decision engineer skills you can bring.
Here is the loan problem stated the way you might sketch it on a whiteboard before opening an editor:
In Gurobi's Python interface you would add the binaries with something like m.addVars(apps, vtype=GRB.BINARY), set the objective, add each constraint, and call optimize. The interesting part comes afterwards: checking the answer makes sense, reading shadow prices on a relaxed version to see what one extra dollar of budget is worth, and spotting when the risk limit is so tight the model approves almost nothing. Building the same model in a comparable solver counts as relevant experience.
You test it against the past. Run the new strategy over a few months of historical applications and compare with what actually happened. The trap: you only know repayment outcomes for loans the old policy approved, so a naive simulation flatters any strategy that approves people the old one declined. Correcting for that gap, or at least stating it plainly in the results, is part of the work.
Simulation tells you what might happen. A/B testing tells you what does happen. Sending a small, random share of live traffic through the new strategy while the rest stays on the current one gives you a clean comparison. You will design these tests and explain the results to people who care more about profit than p-values.
A model that worked in March can quietly misbehave by July. Applicant mix shifts, or an upstream data field changes format. Monitoring outcomes in production is a named part of this role. That means alerts on approval rates, average risk of approved loans, solver run times and how often fallback rules fire. When something moves, you find out why.
A degree in operations research, applied mathematics, computer science or economics is common among people in this role. For decision engineer jobs, an operations research degree is the most direct route, since it covers linear and integer programming, though many strong candidates learned optimisation on the job.
The firmer requirement is experience: four or more years building decision or optimisation systems, with strong Python and SQL and hands-on use of Gurobi or a similar solver. Lending or fintech experience is a plus. To be straightforward, this is not one of the entry level remote decision engineer jobs. If you are early in your career, the path is to build that experience first, often from an analytics or data role.
The listed pay is USD 125,000 per year for a full-time position. That figure is the one stated for this role, so treat it as the decision engineer salary per year here rather than a promise about the wider market. The job is fully remote and open worldwide, so anyone searching for decision engineer jobs remote worldwide can apply without relocating.
Remote work here still means regular contact: written updates, design notes on modelling choices, and probably some calls across time zones. People who do well in decision engineer work from home jobs write clearly and flag problems early.
Start by solving a few real problems end to end. Pick a public dataset, frame a decision, write the model in Python with Gurobi's free academic or trial licence or an open-source solver, and back-test it. For structured study, a university optimisation class or the solver vendor's documentation beats hunting for a decision engineer course or decision engineer certification; no credential is required here.
Expect decision engineer interview questions to test formulation more than recall. You may be asked to formulate a small problem aloud, write a SQL query that builds a feature from transaction tables, explain why a back-test can mislead, or describe how you would roll out a new credit policy safely. Practise reasoning out loud.
Treat your decision engineer resume as a list of solved problems. For each role, name the decision, the method and the outcome you can honestly describe: "built an integer programme in Gurobi to allocate weekly credit limits; replaced a manual spreadsheet process" says far more than a list of libraries. Mention Python and SQL in context and call out any lending or pricing work.
To apply, upload your CV through the application form on this page. Nothing is charged for that, and a fee request from anyone would be a reason to walk away. This is one of the remote decision engineer jobs hiring now, so if the loan puzzle at the top made you want to start sketching variables, send your CV in.