Source
Converted from your local HEIC files and stripped of image metadata before publishing.
About
Who I am, what kind of engineer I am, and how I like to work.
I am a backend, platform, and security engineer who likes difficult systems work. I care about reliability, clear architecture, real debugging, and building things that still make sense once they are running in the real world.
University of Maryland
Campus photos from your own files, not online sources.
These images come from the local HEIC files you provided. They connect the About page to your University of Maryland cybersecurity engineering background without using online images or AI-generated campus scenes.
Background
Cybersecurity engineering, grounded in a real UMD context.
My M.Eng. in Cybersecurity Engineering at the University of Maryland, College Park strengthened the secure systems, cloud security, offensive practice, and defensive engineering work behind this portfolio.
Style
Real campus context without synthetic backgrounds, stock imagery, or external photo credits.
Who I Am
I am not just trying to ship features. I like understanding how the system actually behaves.
My strongest work usually sits somewhere between backend engineering, platform reliability, and security. I like being close to the runtime, the telemetry, the packet flow, the release process, and the debugging trail when something goes wrong.
I enjoy building useful systems, but I also care a lot about whether the system is explainable. If a service is hard to observe, hard to reason about, or easy to break during rollout, I do not consider the job finished yet.
Why security stays close
A lot of my interest in security comes from the same mindset. I want systems to be safer in ways that are concrete, observable, and operational instead of cosmetic.
What I Want To Keep Doing
The environments where I do my best work.
Backend or platform teams where reliability, observability, and performance are treated as engineering work, not cleanup.
Security-minded environments where guardrails, automation, and debugging depth matter more than buzzwords.
Teams that value ownership, clear communication, and engineers who stay with the hard parts after launch.
Strengths
Where I add leverage.
I tend to be most useful when a project needs architecture, implementation, and post-launch follow-through from the same person.
Capability
Systems Engineering
I design concurrent services and data paths with explicit attention to latency, backpressure, rollout safety, and failure recovery.
Capability
Security Engineering
I translate security risk into maintainable controls: policy gates, CI checks, telemetry, detection content, and remediation workflows teams can keep running.
Capability
Low-Level Debugging
I trace crashes and unsafe states through binaries, memory layouts, allocators, syscalls, and operating-system behavior when the bug sits below the application layer.
Capability
Operational Rigor
I use OpenTelemetry, metrics, logs, and automation to reduce mean time to explanation, not just mean time to notice.
Working style
Build systems that stay clear, reliable, and useful once real traffic and failure modes show up.
Technical range matters, but I care just as much about whether the work is observable, supportable, and trustworthy after the first release.
Candor
I report risk, uncertainty, and tradeoffs directly. If the evidence is thin or the system is unsafe, I say so.
That matters in debugging, incident response, and security review, where false confidence is expensive.
Ownership
I stay with the hard parts of the work: incidents, cleanup, remediation, and operational follow-through after the visible milestone.
In practice, ownership looks like reliability under pressure and consistency with the team.
Disciplined Work
I am comfortable with repetitive, detail-heavy work when it improves the system: instrumentation, hardening, regression analysis, and documentation.
The result is usually better reliability, clearer handoffs, and fewer repeated failures.
Execution Depth
How I turn broad range into reliable delivery.
The goal is not to sound broad. The goal is to stay useful when the work crosses multiple layers and somebody needs to keep the whole thing understandable.
Operating layer
End-to-End Ownership
I stay involved from architecture through production reliability, including observability, rollout safety, and post-release hardening.
That keeps delivery grounded in runtime behavior, not just feature completeness.
Operating layer
Security Without Theater
I treat secure defaults, policy guardrails, and attack-surface reduction as part of engineering quality rather than optional add-ons.
That approach reduces rework and shortens the path from risk discovery to remediation.
Operating layer
Clear Communication Under Pressure
I write incident notes, project summaries, and technical handoff material that helps teams move quickly with shared context.
Good communication turns debugging depth into team-level velocity.
Interests
The technical areas I keep coming back to, even when they are not required by the current project.
Low-Level Systems
Operating system behavior, binary internals, allocators, and debugging beneath higher-level abstractions.
Security Research
Exploit techniques, real incident writeups, and defensive patterns that hold up outside lab conditions.
AI and Agentic Systems
How autonomous workflows fail, how they can be abused, and how to build safer tool-use patterns around them.
Distributed Architecture
Systems that remain observable, resilient, and performant as scale, concurrency, and failure modes increase.
Technical range
The tooling that keeps showing up across the work I do.
Engineering and Infrastructure
12 toolsGoPythonRustFastAPIBashSQLKubernetesDockerAWSAzureTerraformMicroservices
Debugging and Operations
9 toolsOpenTelemetryPrometheusGrafanaWiresharkGDBGitGitHub ActionsCI/CDLinux Internals
Security Tooling
8 toolsSemgrepCodeQLELKLLM SecurityTCP/IP Packet InspectionSocket ProgrammingLatency ReductionRoot Cause Analysis