Career transitions into tech are often written as stories about potential. That approach usually falls apart in interviews, because potential is hard to verify. What hiring managers actually respond to is concrete work: labs completed, systems built, documentation written, problems debugged, environments deployed. This post is not a motivational transition story. It is a grounded explanation of how a non‑traditional background can connect to real engineering behaviors that are already visible in projects and work history.

Nothing in this post is hypothetical. Every example maps to something that exists: a lab, a deployment, a repository, or a documented process. The goal is not to convince anyone with adjectives. The goal is to make the path traceable.

Starting point

Before tech, my work was operational and field‑based. Army healthcare, case management in court systems, construction, logistics, animal care, and facility maintenance. Those roles were not software jobs. They did, however, involve repeatable processes, documentation, coordination, troubleshooting under pressure, and responsibility for outcomes. That matters only if it shows up later in observable engineering behavior, so the focus here is on where that actually happened.

AWS support internship: applied cloud work

The first direct bridge into engineering work came through an AWS Cloud Support Engineering internship. This was not a research or theory role. It was guided, lab‑driven work inside AWS environments.

Concrete activities during that internship included:

• Guided support rotations in training environments • Juniper/Junos troubleshooting labs delivered through Jupyter notebooks • Building a serverless metadata extraction workflow using Lambda, DynamoDB, and S3 • Deploying an accessible frontend for that workflow on AWS Amplify • Implementing a transparent cost model to estimate storage, transfer, and compute usage

These were not abstract exercises. They required reading logs, interpreting failure modes, configuring IAM, wiring services together, validating data flow, and producing working outputs. The capstone project produced a deployed workflow and a documented cost breakdown. That is the point where cloud services stopped being conceptual and became operational.

Open‑source frontend work: operating inside existing codebases

Alongside formal internship work, I contributed to CIRIS Ethical AI as a junior frontend developer. The scope was intentionally small: onboarding documentation, environment setup notes, JWT guidance, logging around token verification, lint fixes, and clearer error messages.

The engineering behavior here was not inventing new systems. It was reading an existing codebase, running it locally, identifying friction points, improving documentation, submitting pull requests, and tracking larger changes as GitHub issues. That is the same behavior expected in real teams: understand the current system first, improve it incrementally, leave a transparent record of changes.

Building and deploying personal projects

Parallel to work roles, I built and deployed web projects, demos, and infrastructure experiments. These include full‑stack applications, static sites, containerized services, and AWS‑hosted workflows. The consistent pattern has been:

• Assemble a working stack • Deploy it to a real environment • Debug real runtime and configuration issues • Document what broke and how it was fixed

This matters more than the specific tech choices. Shipping a deployed system forces interaction with DNS, build pipelines, environment variables, caching, IAM, and service configuration. Those are operational engineering tasks, not tutorial exercises.

Current work: facilities and operations

My current role is a maintenance technician. It is not a software role, but it is still operations work: handling requests, diagnosing issues, coordinating fixes, documenting work completed, and managing competing priorities. That operational mindset carries directly into support engineering, site reliability, and infrastructure roles where the core task is keeping systems functional and responding to incidents.

What this adds up to

The outcome of this path is not a claim to be a senior engineer. The outcome 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 • Documented fixes and write‑ups tied to real issues

That is what interviewers and hiring managers can inspect. The transition is not described as identity change. It is described as accumulated engineering activity.

Closing

Non‑traditional backgrounds only matter to the extent they produce 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.

This is not a story about potential. It is a record of work already done.