Robotic process automation sounds futuristic until you actually watch a Blue Prism bot quietly clear out an afternoon of manual data entry, and then it just looks like relief. That is what this developer role is really about: building and maintaining the automations that take repetitive, rules-based work off a team's plate, then keeping those automations healthy once they are live.
The company behind this listing runs a mix of finance and operations processes through Blue Prism already, and this hire is meant to grow that footprint rather than start it from scratch. That distinction matters for how the role feels day to day, since there is existing code to learn and existing conventions to follow, not a blank canvas.
Learning an existing codebase of automations is its own skill, separate from being able to build one from a blank project. Reading someone else's process logic, understanding why a particular exception handler was written the way it was, and only then proposing a change is generally how the first few weeks go. Rewriting something before understanding why it was built that way is a common early mistake, and one that experienced developers on this team try to catch before it causes a real problem.
A background in another RPA tool, like UiPath or Automation Anywhere, is not required but is genuinely useful, since a lot of the underlying logic transfers. Exposure to a scripting language such as Python or VBScript for edge cases Blue Prism cannot handle natively is a plus too, as is prior experience automating anything finance- or operations-heavy, where a single wrong output actually matters. Someone who has debugged a production automation at two in the morning once already tends to approach error handling differently than someone who has only built demos.
Some weeks lean heavily into building something new from a fresh set of requirements, working alongside a cross-functional team that includes business analysts and the people whose workflows are actually getting automated. Other weeks are mostly maintenance: chasing down why a bot failed against a website that changed its layout overnight, or adjusting a workflow because the underlying business process shifted. Both kinds of weeks matter equally here, and senior on the title means owning those decisions rather than waiting to be told which one today is.
Take a claims-processing bot that has run cleanly for months and suddenly starts failing on one specific document type. Figuring out whether that is a formatting change upstream, a timeout on a slow server, or an edge case nobody accounted for at build time is a normal Tuesday, and it usually involves reading logs closely before touching any code at all.
A bachelor's degree in computer science, software engineering, or a closely related field is the baseline here, alongside 24 months of hands-on Blue Prism experience. A strong portfolio matters as much as the resume itself, so having a couple of processes you can walk through, even from a previous job or a personal project, puts an application ahead of one without that. Being able to explain why a process was built a certain way, not just that it works, is what interviewers usually probe for.
Two years might sound like a short bar for a senior-adjacent development role, and in a sense it is. What tends to close the gap is depth: someone who spent that time owning a handful of complex processes end to end usually interviews better than someone who touched twice as many but never past the initial build.
The stipend is meant for exactly what it sounds like: a decent monitor and a chair that does not wreck your back by month three, since a developer working from home still needs real equipment to do the job well.
Everything about this role is remote, with no office and no location requirement anywhere in the world. That said, the team still meets, mostly through video calls for planning and code review, so being reachable during a reasonable overlap window matters more than logging a fixed nine-to-five. Git handles the code side of collaboration, and most day-to-day coordination happens over chat rather than long meetings, a setup a lot of developers on this kind of Remoteroles listing say they actually prefer once they get used to it. A typical week might involve two scheduled calls and the rest asynchronous, unless something breaks in production and a faster huddle is needed.
Production incidents do not wait for business hours in every time zone, so an on-call rotation covers off-hours issues rather than putting that entirely on one person. Outside of that rotation, the schedule is largely up to the developer, as long as code review turnaround stays reasonable for the rest of the team.
If this sounds like your kind of work, apply with your resume and, if you have one, a short writeup or portfolio link covering a Blue Prism process you built. Interviews typically involve a technical conversation about a real automation challenge rather than an abstract coding test, since that tends to surface how someone actually thinks through a broken process under time pressure. A second, shorter conversation with the wider team usually follows before an offer goes out.