A reflective collection of artifacts from my work as an engineer and communicator
View My ArtifactsMy name is Abdelruhman Shaat, and I'm a Computer Engineering student at the University of Maryland. This portfolio was built to satisfy my English course's requirement to select and reflect on artifacts that represent my growth as a communicator, problem-solver, and engineer. While my day-to-day work is technical, each project I build is also an act of communication: to teammates who inherit my code, to users who depend on my tools, and to reviewers who evaluate my decisions.
The three artifacts collected here span a personal project, an academic systems project, and a professional deliverable from my internship at Freddie Mac. Each is paired with a contextual statement that describes the artifact's purpose and audience, the process and challenges behind it, and what it reveals about how I've grown. Together, they trace a progression from independent tinkering to low-level systems fluency to quantifiable impact on a real engineering team.
Purpose & Audience. I built this trading bot on my own initiative to automate an options-trading strategy I had been running manually. The primary audience was myself — a tool to reduce the manual overhead and emotional decision-making involved in trading — but it doubled as a portfolio piece demonstrating that I could take a domain problem outside of computer science (options trading) and translate it into working software.
Process & Challenges. The hardest part wasn't the trading logic; it was reliability. I integrated the Alpaca API for live quote retrieval and order execution, then built contract-filtering logic to select option contracts within a defined strike-price range, and order-polling logic to confirm fills without blocking the rest of the program. I also wrote a weekly automation routine that dynamically allocates capital, which forced me to think carefully about failure modes: what happens if a quote request times out, or an order partially fills, or the market is closed when the routine runs.
Reflection. This project taught me that automating a real-world process is as much about constraint-writing (capital limits, strike-price ranges, error handling) as it is about the happy path. It was my first time shipping something with real financial consequences if the logic was wrong, which pushed me to write more defensive, well-tested code than I had in coursework.
Purpose & Audience. This artifact is an interactive shell written in C that communicates directly with the kernel. Its audience was academic in origin — demonstrating mastery of process management and system-call-level programming — but it now serves a second audience: employers evaluating whether I understand what happens beneath the frameworks I use every day.
Process & Challenges. Building the shell meant implementing command parsing, process creation, and execution entirely through system calls, with no higher-level libraries to fall back on. The difficulty wasn't any single feature; it was the edge cases: malformed input, orphaned child processes, and commands that behaved differently depending on how the shell forked and waited on them. I spent as much time debugging process lifecycles as I did writing new functionality.
Reflection. Working close to the kernel changed how I read error messages and reason about failure in every other language I use. It also reinforced a habit I try to carry into all of my writing and code: being explicit about assumptions, because in C nothing is handled for you unless you handle it yourself.
Purpose & Audience. As a Software Engineer Intern at Freddie Mac, I modernized the logging system across 14+ microservices and built a log analyzer that aggregates and parses logs to surface errors and performance bottlenecks. The audience here wasn't just my own team; it was every engineer who gets paged during an incident and needs to understand, quickly, what went wrong and where.
Process & Challenges. The challenge was less technical than organizational: logging conventions had drifted across 14+ services, so before I could build tooling, I had to understand and reconcile how different teams logged errors. I designed and tested the API endpoints in Postman, maintained the surrounding CI/CD pipeline in Jenkins, and tracked the work through Jira as part of an Agile/Scrum team, which meant regularly explaining the problem and the fix to people with different levels of context.
Reflection. This is the artifact I'm proudest of, because its value is measurable: it saves roughly 30 minutes per incident by giving engineers faster, clearer insight into what broke. It taught me that the most valuable engineering work is often invisible infrastructure, and that explaining the "why" behind that work — in code reviews, standups, and documentation — is what makes it actually get adopted.
Below is the draft of a presentation I delivered internally at Freddie Mac on the risks of AI adoption in enterprise software engineering — covering where AI tooling introduces error, bias, and oversight gaps in a regulated environment, and how engineering teams can mitigate them. The final recording is still being processed; an embedded player will replace this placeholder once it's ready.
Video coming soon