Harden a Python Automation Workflow - Paid Technical Test
Budget / Salary$100–200
TypeFreelance project
LocationRemote
Posted1 hour ago
This is a paid, fixed-price technical assessment using a small isolated Python repository and synthetic data. The budget cap is USD 200 and the expected timebox is 4 hours. Do not work beyond the timebox; document any unfinished work instead.
The repository simulates an automation that prepares and may create business records. It contains deliberate reliability and security defects. Your task is to make the workflow fail closed while keeping the implementation understandable.
### Required changes
1. Make dry-run the default and prove that no write client can be called without an explicit live mode.
2. Bind live execution to a single-use approval artifact containing the exact canonical payload hash.
3. Prevent duplicate creation across normal retries and concurrent attempts.
4. Add a durable, append-only audit trail without logging secrets or sensitive raw data.
5. Return clear machine-readable outcomes for dry-run success, blocked execution, duplicate detection, and successful write/readback.
6. Add or improve automated tests for the happy path and adversarial cases.
### Deliverables
- A Git patch or repository branch with the implementation.
- Automated tests and one command that runs them.
- A short `DECISIONS.md` explaining architecture, assumptions, tradeoffs, residual risks, and what you would do next in production.
- A short incident note describing how the original implementation could fail.
- Disclosure of AI tools used and how you verified their output.
### Constraints
- Use only the supplied synthetic data and fake API client.
- Do not request or use company credentials, production access, real records, or external services.
- Do not replace the project with a framework-heavy rewrite.
- Preserve a simple Python interface that another engineer can maintain.
- If a requirement is ambiguous, choose the safer behavior and state the assumption.
- You must personally perform the work; no agency, team, or subcontracting.
### Evaluation
We will assess system comprehension, Python design, tests, retry and concurrency safety, approval binding, auditability, secret handling, and written judgment. Completing this assessment does not guarantee a longer contract or production access.
### Proposal questions
1. Describe one Python automation you personally hardened. What could execute twice or write unexpectedly, and how did you prove your fix?
2. How would you bind a one-time human approval to one exact canonical payload without exposing secrets?
3. How would you test duplicate prevention across both retries and concurrent processes?
4. Confirm that you are an individual professional, will be the sole author, and will disclose any AI coding tools used.
5. Confirm that you can respect the 4-hour limit and document unfinished work instead of exceeding it.
The repository simulates an automation that prepares and may create business records. It contains deliberate reliability and security defects. Your task is to make the workflow fail closed while keeping the implementation understandable.
### Required changes
1. Make dry-run the default and prove that no write client can be called without an explicit live mode.
2. Bind live execution to a single-use approval artifact containing the exact canonical payload hash.
3. Prevent duplicate creation across normal retries and concurrent attempts.
4. Add a durable, append-only audit trail without logging secrets or sensitive raw data.
5. Return clear machine-readable outcomes for dry-run success, blocked execution, duplicate detection, and successful write/readback.
6. Add or improve automated tests for the happy path and adversarial cases.
### Deliverables
- A Git patch or repository branch with the implementation.
- Automated tests and one command that runs them.
- A short `DECISIONS.md` explaining architecture, assumptions, tradeoffs, residual risks, and what you would do next in production.
- A short incident note describing how the original implementation could fail.
- Disclosure of AI tools used and how you verified their output.
### Constraints
- Use only the supplied synthetic data and fake API client.
- Do not request or use company credentials, production access, real records, or external services.
- Do not replace the project with a framework-heavy rewrite.
- Preserve a simple Python interface that another engineer can maintain.
- If a requirement is ambiguous, choose the safer behavior and state the assumption.
- You must personally perform the work; no agency, team, or subcontracting.
### Evaluation
We will assess system comprehension, Python design, tests, retry and concurrency safety, approval binding, auditability, secret handling, and written judgment. Completing this assessment does not guarantee a longer contract or production access.
### Proposal questions
1. Describe one Python automation you personally hardened. What could execute twice or write unexpectedly, and how did you prove your fix?
2. How would you bind a one-time human approval to one exact canonical payload without exposing secrets?
3. How would you test duplicate prevention across both retries and concurrent processes?
4. Confirm that you are an individual professional, will be the sole author, and will disclose any AI coding tools used.
5. Confirm that you can respect the 4-hour limit and document unfinished work instead of exceeding it.
Apply on Freelancer →
Project sourced from Freelancer.com. Applications happen directly on the original platform — we never collect your data.