Plenty of the most useful Python in a company is written by people whose title isn't "software engineer" — operations analysts, mechanical and process engineers, finance and supply-chain folks who got tired of doing the same spreadsheet by hand. If that's you, the resume challenge is to present real, valuable automation work credibly without pretending to be a career software developer.
Frame the problem, then the tool
Operations Python is valued for what it eliminated, not for its elegance. Lead each bullet with the manual pain you removed, then name what you built:
- "Automated a weekly reconciliation that was done by hand in Excel, using a pandas script that pulls two exports and flags mismatches."
- "Built a small FastAPI service so the team could submit requests through a form instead of emailing a shared inbox."
- "Wrote a script to pull data from an internal API on a schedule and drop a cleaned CSV where the reporting tool expects it."
Each of these is honest, specific, and legible to a hiring manager who has that exact problem.
The operations Python vocabulary
You don't need to claim a full engineering stack. Name the tools you genuinely used and what you did with them:
- pandas / numpy — data cleanup, joining messy exports, deduplication, validation checks.
- FastAPI / Flask — small internal services and endpoints; say whether it was a personal tool or something a team relied on.
- requests / API integrations — pulling from or pushing to internal systems, webhooks, third-party APIs.
- Scheduling — cron, a scheduled task, or a job runner that makes the automation actually run without you.
- openpyxl / CSV work — because in operations the interface is very often a spreadsheet, and that's fine.
Skip the frameworks you only skimmed. A short list you can discuss beats a long list you can't.
Quantify from your own experience, honestly
Time saved and errors reduced are the right currency here, but only when the number is yours and defensible. If a report took a morning every week and now runs in minutes, say that — it's true and you lived it. If you don't have a clean measurement, describe the change qualitatively: "replaced a manual step that was a recurring source of copy-paste errors." Avoid inventing a percentage to sound impressive; in an interview, "how did you measure that?" ends the bluff quickly.
Positioning against the posting
Read the role first. If it's an analyst or ops job where Python is a force-multiplier, present your scripting as evidence of initiative and leverage — you don't need to compete with software engineers. If it's genuinely a developer role, be honest about where you are: comfortable with scripting and small services, still learning testing, packaging, or production deployment. Claiming senior-engineer depth you don't have gets exposed fast; owning a real, growing skill reads as credible.
A useful habit is to keep the actual artifacts as you build them — the repo or gist, a before/after description, the rough time it saved. Collecting that evidence somewhere durable (a Memory Board is one way) means when a posting values automation, you can align your resume to it with concrete work rather than a vague "proficient in Python."
Closing the gap without faking it
When a posting lists a tool you haven't used — say it wants Airflow and you've only used cron — you have two honest moves: point to the closest real thing you've done and describe how it maps, or leave it out and let your genuine strengths carry the application. Both beat padding the skills line with keywords you'd have to defend under questions you can't yet answer.