Position Overview

We are seeking a Senior Software Engineer who can work independently on key priority projects while contributing strategically to ministry-wide initiatives. This role requires someone who can balance immediate project delivery with building reusable capabilities that benefit the broader ministry family. The ideal candidate understands trade-offs, delivers outcomes on time, and leaves behind patterns and practices that enable other teams.

Primary Responsibilities

Strategic Technical Delivery

• Lead and deliver priority projects independently with minimal oversight, ensuring timely completion while maintaining quality standards
• Make pragmatic technical decisions that balance project timelines, scope, budget constraints, and long-term sustainability
• Navigate complex modernisation efforts involving legacy systems (Java, Appian, OutSystems, Pega Cloud, Microsoft Dynamics)
• Identify and manage critical technical dependencies early in project lifecycles, ensuring stakeholders understand constraints and impacts on delivery timelines

Ministry Family Contribution

• Build solutions with reusability in mind — create patterns, frameworks, and infrastructure that can be leveraged across multiple ministry systems
• Document architectural decisions, implementation patterns, and lessons learned to enable knowledge sharing across teams
• Contribute to shared technical goals and continuous improvement processes across the ministry family
• Mentor and enable other engineers through code reviews, technical guidance, and establishing best practices that others can adopt

Trade-off Management & Decision Making

• Evaluate when to build custom solutions versus adopting existing platforms, considering factors like data sovereignty, operational complexity, and organisational constraints
• Balance immediate delivery needs with establishing sustainable infrastructure for future initiatives
• Navigate competing priorities between perfect solutions and pragmatic approaches that meet current needs while allowing for future evolution
• Understand and communicate the implications of technical debt, making conscious decisions about when to incur it and how to manage it

 

Key Requirements

Technical Expertise

• 5+ years of software engineering experience with demonstrated progression in technical complexity and scope
• Strong foundation in software architecture, system design, and engineering best practices
• Experience with modern tech stacks relevant to government systems (e.g., Java, Salesforce, Kotlin, cloud platforms like GCC/AWS)
• Proven ability to work with both greenfield development and brownfield modernisation projects
• Understanding of DevOps practices, CI/CD pipelines, infrastructure as code, and observability

Strategic & Leadership Capabilities

• Demonstrated ability to work independently with minimal supervision while maintaining alignment with broader organisational goals
• Track record of making pragmatic technical decisions that consider business constraints, timelines, and long-term sustainability
• Experience contributing to technical strategy beyond immediate project boundaries — establishing standards, creating reusable components, or building shared infrastructure
• Ability to articulate trade-offs clearly to both technical and non-technical stakeholders
• Evidence of knowledge sharing through documentation, mentorship, or establishing practices that enable other teams

Problem-Solving & Execution

• Strong analytical skills with evidence-based problem-solving approach backed by testing and validation
• Ability to identify root causes beyond surface-level symptoms (e.g., database indexing issues masked as front-end performance problems)
• Proactive in identifying technical dependencies, risks, and constraints early in project lifecycles
• Comfortable working within government constraints (security requirements, compliance needs, data sovereignty) while finding pragmatic solutions

 

Desired Experience (Nice-to-Have)

• Government or highly regulated industry experience with understanding of compliance, security, and governance requirements
• Experience with platform migrations or modernisation initiatives (legacy system upgrades, cloud migrations, technology stack changes)
• Background in establishing technical standards or creating reusable frameworks used across multiple projects or teams
• Familiarity with grant management, social services systems, or ministry family domain knowledge

Work Environment

You will be working in a complex ministry environment characterised by:

• Multiple ongoing modernisation initiatives (ECDA systems, Baby Bonus, GPLS) alongside legacy system maintenance
• Diverse technology stack including Salesforce, OutSystems, Appian, Pega, Kotlin, Java, and cloud infrastructure (GCC/AWS)
• Government security and compliance requirements that shape technical decisions
• Resource constraints requiring pragmatic approaches that balance immediate needs with long-term sustainability

The Ideal Candidate

What Success Looks Like

In the first 6–12 months, a successful candidate will:

• Deliver at least one priority project on time while establishing reusable patterns or infrastructure that other teams can leverage
• Identify and document technical dependencies early, preventing last-minute surprises and ensuring stakeholder awareness
• Make clear technical recommendations backed by trade-off analysis that considers business constraints, not just technical ideals
• Contribute to ministry-wide technical goals through documentation, standardisation efforts, or enabling other engineers
• Demonstrate progression from delivery execution to strategic technical leadership within their project area

Red Flags — What We're NOT Looking For

We will screen out candidates who demonstrate:

• Execution-only focus without strategic thinking or awareness of how their work contributes to broader organisational goals
• Inability to articulate trade-offs in technical decisions or explain reasoning behind choices made under constraints
• Heavy on buzzwords but light on specifics when probed — vague answers about implementation details or challenges faced
• No evidence of knowledge sharing, documentation, or building reusable solutions that benefit other teams
• Narrow experience working only in ideal scenarios without handling constraints like legacy systems, budget limits, or compliance requirements

 

Software Engineering Assessment

Regulatory and Licensing Platform

Overview

This assessment simulates real work: you are given product requirements, a time constraint, and the freedom to make engineering decisions. There is no single correct answer — we are evaluating how you think, what you prioritise, and how you build software that is ready for production.

The platform you are building is a Regulatory and Licensing System used by government licensing officers and operators (businesses seeking licences) to manage the end-to-end application lifecycle.

At a Glance

Time Limit	3 days from receipt of this document
Scope	MVP — you decide what to build and what to defer
Stack	Your choice — justify your decisions in the README
AI Tools	Encouraged — document how you used them
Deliverable	GitHub repo (or zip) + README + SCOPE.md

What We Are Looking For

We are not looking for a complete system. We are looking for evidence that you can make good engineering decisions under constraints — and that you know how to work effectively with AI tools to ship quality software.

 

Think about what "production-ready" means to you and let that guide the choices you make. Not every feature needs to be built — but the things you do build should reflect how you would approach real work.

 

Where it makes sense, feel free to mock or stub. What matters is that the overall shape of the solution is coherent, and that your reasoning is clear.

 

Scoping Your MVP

Before writing any code, you are recommended to come up with a short scoping proposal. This file, SCOPE.md, should be part of your Git repository and is a key part of the eventual assessment.

 

Your proposal should cover:

• Which use case(s) or features you are choosing to build — it is not a must to do all three
• What you are explicitly deferring or mocking, and why
• Any assumptions you are making where requirements are ambiguous
• Your intended tech stack and architecture in 3–5 sentences

 

There are no wrong answers here — cutting scope deliberately is a senior engineering skill. We will assess the quality of your reasoning, not the quantity of features.

 

Using AI Tools

You are encouraged to use AI coding assistants (e.g. Claude, GitHub Copilot, Cursor, ChatGPT). This reflects how we work day-to-day. However, the value of this assessment lies in how you use them — not whether you use them.

 

What We Want to See

In your README, include a section called AI Usage that describes:

• Which tools you used and for what tasks
• Examples of prompts or instructions you gave the AI
• How you reviewed, validated, or corrected AI-generated output
• Any areas where the AI was unhelpful or produced code you discarded

 

Guiding AI Effectively

Experienced engineers don't just paste requirements into an AI chat. They give AI the context it needs to produce production-quality output. Consider providing your AI tool with:

 

Context Type	Example
Data model / schema	"Here is my Application entity and its status enum — generate a service method to transition status with validation"
Coding standards	"Use TypeScript strict mode. All async functions must handle errors explicitly. No any types."
System constraints	"Officers and Operators are different roles. Never expose the internal approval stage to Operators."
Acceptance criteria	"The operator must only see flagged checklist items, not the full checklist. Generate the API endpoint and response shape."
Output format	"Return the result as a class with dependency injection, following the repository pattern already in this codebase."

 

We will ask you about your AI usage during the debrief. Be honest — uncritical over-reliance on AI output is a red flag; thoughtful, verified use of AI is a strength.

 

Use Cases

The following three use cases define the full product scope. You do not need to implement all of them — refer to the Scoping Your MVP section above.

 

Use Case 1 — Operator Application Submission & Resubmission

Background

Applications are often submitted with incomplete or incorrect information, causing repeated back-and-forth cycles. This use case covers the guided submission and resubmission workflow from the operator's perspective.

 

User Story

As an Operator, I want to submit my application with clear guidance and receive specific feedback when information is incomplete, so that I can quickly address issues and resubmit without confusion or repeated rejections.

 

Acceptance Criteria

Initial Submission

• Complete form data entry
• Document uploads with drag-and-drop functionality
• Real-time AI verification status visible per uploaded document
• Progress indicator showing overall completion status

 

Resubmission Workflow

• Operator sees case status as "Pending Pre-Site Resubmission"
• Officer comments displayed prominently at top of application
• Feedback is linked to the specific form section or document it relates to
• Operator updates only the flagged sections — no need to re-enter entire application

 

Multi-Round Support

• Multiple rounds of feedback and resubmission are supported seamlessly
• Revision history and previous Officer comments are visible
• Application data is never lost between submission rounds

 

Use Case 2 — Officer Application Review & Feedback

Background

Officers need an efficient way to review applications and provide actionable feedback without getting caught in repeated revision cycles.

 

User Story

As a Licensing Officer, I want to efficiently review applications and provide clear, actionable feedback to operators, so that I can guide them toward complete submissions without repetitive review cycles.

 

Acceptance Criteria

Application Review

• Officer accesses full submission: all form data and documents in an organised structure
• AI verification results and flagged document issues are visible

 

Feedback Workflow

• Officer can request more information with specific, contextual comments
• Predefined comment templates available for common issues
• Setting application status triggers automatic operator notification

 

Resubmission Management

• Officer receives notification when case moves to "Pre-Site Resubmitted"
• Updated sections are highlighted; only changes are surfaced
• Officer can compare current submission against previous versions
• Resolution of previously flagged issues is tracked

 

Quality Assurance

• No applications are lost due to status transitions or filtering errors
• Complete audit trail of all feedback and resubmission rounds is maintained
• Workflow supports unlimited resubmission cycles

 

Status Mapping

All status transitions must follow the mapping below. Officer and Operator views show different labels for the same internal state.

 

Internal System Status	Officer View	Operator View
Application Received	Application Received	Submitted
Under Review	Under Review	Under Review
Pending Pre-Site Resubmission	Pending Pre-Site Resubmission	Pending Pre-Site Resubmission
Pre-Site Resubmitted	Pre-Site Resubmitted	Pre-Site Resubmitted
Site Visit Scheduled	Site Visit Scheduled	Pending Site Visit
Site Visit Done	Site Visit Done	Pending Post-Site Clarification
Awaiting Post-Site Clarification	Awaiting Post-Site Clarification	Pending Post-Site Clarification
Pending Post-Site Resubmission	Awaiting Post-Site Resubmission	Pending Post-Site Resubmission
Post-Site Clarification Resubmitted	Post-Site Clarification Resubmitted	Post-Site Resubmitted
Pending Approval	Route to Approval	Pending Approval
Approved	Approved	Approved
Rejected	Rejected	Rejected

 

Use Case 3 — On-Site Assessment & Post-Site Clarification

Background

Site inspections need structured documentation, but inconsistent capture leads to unclear follow-ups. This use case covers the structured inspection workflow and targeted post-site clarification.

 

User Story

As an Officer, I want to capture site visit findings and request clarification only on specific items, so that Operators can respond efficiently without being overwhelmed by the full inspection checklist.

 

Acceptance Criteria

Officer — On-Site Data Capture

• Officer accesses the full checklist after site visit is scheduled
• Officer inputs comments per checklist item
• Officer can save as draft (e.g. while working on an iPad on-site)
• Officer can mark individual items as "Need Further Clarification"

 

Status Transition

• On checklist submission, case automatically moves to "Pending Post-Site Clarification"

 

Operator — Targeted Response

• Operator does NOT see the full checklist
• Operator sees ONLY the items flagged for clarification
• Operator sees the Officer’s comment per flagged item
• Operator can respond to each item and upload supporting documents

 

Multi-Round Clarification

• Multiple clarification rounds are supported per checklist item
• Each item maintains a full audit trail: comments, responses, timestamps

 

Constraints

• Operators cannot see the internal approval stage at any point
• Operators see only the final outcome: Approved or Rejected

 

How You Will Be Evaluated

We will look at your submission as a whole — the code, your scoping decisions, how you used AI, and how you talk through it in the debrief. Areas we will consider include:

• Scope judgement — what you chose to build, defer, or mock, and why
• Production readiness — the quality and confidence of what you did ship
• AI tool usage — how effectively you guided and verified AI-generated output
• Code quality — structure, readability, and maintainability
• Documentation — clarity of your README and how well you communicate your decisions

 

Submission Checklist

Before you submit, confirm you have:

• A working codebase that runs with the steps in your README
• A md in your Git repository explaining what you built, what you deferred, and why
• An AI Usage section documenting how you used AI tools
• Error handling and input validation on all key paths
• No secrets or credentials committed to the repository
• A "What I would do next" section noting known gaps or next priorities

 

A note on honesty:

You will be asked about your choices in a debrief. We value candidates who clearly understand the trade-offs they made — including where they cut corners — over candidates who submit more code but cannot explain it. If something is mocked, say so. If AI wrote something you are not fully confident in, say so. Clarity and self-awareness are strengths.