Before I wrote my first line of production code, I was an Army combat medic. After that I worked in court case management, construction, logistics, animal care, and facilities maintenance. None of those jobs had "software" in the title, but they all had the same shape: show up, diagnose the problem, fix it under pressure, and document what happened so the next person is not starting from zero.

That is the same shape as engineering work. The only question was whether I could prove it in a language that hiring managers actually trust.

This post is not a motivational story about following your dreams. It is a map. I want to show how a non-traditional background connects to real engineering behavior, as long as you can point to work that exists right now: repos, deployments, logs, and write-ups.

Career progression checkpoint illustration for this section.

What I actually did during my AWS internship

My first real bridge into engineering was an AWS Cloud Support Engineering internship. It was not theoretical. It was lab after lab inside training environments that broke on purpose.

During those months I:

  • Ran guided support rotations in simulated customer environments
  • Troubleshot Juniper and Junos networking labs through Jupyter notebooks
  • Built a serverless metadata extraction pipeline with Lambda, DynamoDB, and S3
  • Deployed an accessible frontend for that pipeline on AWS Amplify
  • Modeled the storage, transfer, and compute costs transparently

The capstone was a deployed workflow plus a documented cost breakdown. That is the moment cloud stopped being a buzzword for me. I had to read logs, understand failure modes, wire IAM permissions, validate data flow, and produce a working output someone else could inspect.

That operational rhythm felt familiar. In a medic role, you assess, stabilize, hand off, and chart. In cloud support, you assess, reproduce, mitigate, and document. The context is different; the behavior is not.

Open-source work in an existing codebase

While I was interning, I also contributed to CIRIS Ethical AI as a junior frontend developer. The work was small by design: onboarding docs, environment setup notes, JWT guidance, logging around token verification, lint fixes, and clearer error messages.

What mattered was the workflow. I had to clone a codebase I did not write, get it running locally, find friction points, improve them, submit pull requests, and track bigger changes as GitHub issues. That is the same rhythm as joining any existing engineering team. You are not inventing a product from scratch. You are making a system that already exists a little more understandable.

The personal projects that forced real problems

Alongside formal roles, I built and shipped my own projects. Static sites, full-stack apps, containerized services, AWS workflows. The tech stack changed every time, but the loop stayed the same:

  • Assemble a working stack
  • Deploy it somewhere real
  • Debug the runtime and configuration issues
  • Write down what broke and how I fixed it

Shipping forces you to touch DNS, build pipelines, environment variables, caching, IAM, and service configuration. Those are not tutorial problems. They are operational engineering tasks, and they do not care where you went to school.

My current role is not software, and that is fine

I currently work as a maintenance technician. It is not a coding job, but it is still operations: handle requests, diagnose issues, coordinate fixes, document what was done, and manage competing priorities. That mindset maps directly into support engineering, site reliability, and infrastructure roles where the job is keeping systems functional and responding when they are not.

What this adds up to

The outcome of this path is not a claim to be a senior engineer. It is a body of verifiable work:

  • Completed AWS labs and guided troubleshooting environments
  • A deployed serverless workflow with documented cost modeling
  • Open-source contributions merged into an existing codebase
  • Multiple self-hosted and cloud-hosted projects deployed and debugged
  • Write-ups tied to real issues and fixes

That is what interviewers can inspect. The transition is not an identity change. It is accumulated engineering activity.

Professional growth checkpoint illustration for this section.

Closing

Non-traditional backgrounds only matter if they produced real, inspectable work in the present. Labs completed, systems built, environments deployed, problems debugged, documentation written. That is what connects past experience to engineering roles.

If you are making a similar transition, do not try to sound impressive. Try to be traceable. Point to the repo, the deployment, the log, the fix. That is what gets you the conversation.