What drives me
Build systems that stay clear, reliable, and useful once real traffic and failure modes show up.
I care about work that is technically honest, operationally grounded, and still understandable when things start going wrong.
Atharva Gham · Backend · Platform · Security
Open to backend, platform, software, and security rolesI am a backend, platform, and security engineer who likes hard systems problems.
I work on APIs, distributed services, observability, production debugging, and security automation. The kind of work I enjoy most is the work that has to hold up after launch, not just look good in a demo.
Current focus
- Backend services, APIs, and event-driven systems in Go, Python, and Rust
- Observability and debugging workflows that shorten time from symptom to root cause
- Security tooling that fits into real engineering workflows instead of becoming process theater
- Documentation, rollout safety, and operational habits that make systems easier to trust
How I work
CandorThat matters in debugging, incident response, and security review, where false confidence is expensive.
OwnershipIn practice, ownership looks like reliability under pressure and consistency with the team.
Disciplined WorkThe result is usually better reliability, clearer handoffs, and fewer repeated failures.
Who I Am
A systems-minded engineer who likes being close to the real behavior of software.
I am most comfortable in backend and platform work where the real details matter: service behavior, instrumentation, packet flow, debugging, release safety, and the security controls around all of that.
I like understanding why systems behave the way they do, especially when the answer sits below the surface symptom. That is why a lot of my work naturally pulls me toward observability, runtime evidence, security tooling, and low-level debugging.
What matters to me
Clean architecture matters, but I care just as much about whether the system is legible, debuggable, and trustworthy when it is under real load.
What I Am Focused On
What is shaping the work I want to do next.
Building public security and systems projects that are technically honest and easy to explain.
Looking for backend, platform, and security roles where reliability and debugging depth actually matter.
Studying low-level systems and threat-modeling patterns that feed back into real product work.
OTel-first
Tracing, metrics, and logs designed into service workflows
1,000+
Security alerts enriched and triaged through automation
13+
Services and infrastructure components monitored in production
20%
Reduction in manual security and operations toil
Hiring Snapshot
Where I am most relevant for modern engineering teams.
The through-line is practical systems ownership: services that run reliably, security controls that fit delivery, and debugging habits grounded in evidence.
Role fit
Backend and Platform Engineering
Services, APIs, event-driven workflows, deployment safety, and production debugging across Go, Python, Linux, and cloud infrastructure.
Best fit: backend, platform, infrastructure, and reliability-focused software roles.
Role fit
Security Engineering
Security automation, detection logic, application-security guardrails, IAM workflows, and secure CI/CD controls that engineering teams can maintain.
Best fit: product security, AppSec, detection engineering, and security tooling roles.
Role fit
AI and Agentic Security
Threat modeling for LLM-enabled tools, prompt-injection risk, tool-use boundaries, policy gateways, and auditable automation flows.
Best fit: AI security, agent platform safety, and automation governance work.
Role fit
Systems Debugging and Low-Level Analysis
Runtime evidence, packet captures, Linux behavior, GDB, memory analysis, and root-cause work when the useful answer sits below the surface symptom.
Best fit: teams that need debugging depth, incident learning, and strong technical writing.
What I Build
The kind of work I want to keep doing.
I am at my best when the work spans implementation, runtime behavior, operations, and security instead of ending at the first shipped version.
Scope
Backend Services and Data Systems
Concurrent services, APIs, ingestion paths, and the operational details that keep core systems predictable under load.
Scope
Observability and Incident Tooling
Tracing, metrics, dashboards, and debugging workflows that shorten the distance from symptom to explanation.
Scope
Security Automation and Guardrails
CI checks, policy gates, detection logic, IAM workflows, and security automation teams can keep running without constant babysitting.
Scope
Low-Level Research That Improves Delivery
Low-level debugging, exploit analysis, and architecture writeups that sharpen engineering judgment and defensive design.
How I Work
How I usually add value.
I tend to help most when a team needs someone who can design carefully, debug from evidence, and stay with the operational details after launch.
Strength
End-to-end backend ownership
I stay with services beyond implementation: rollout safety, observability coverage, failure analysis, and the cleanup work that makes them dependable.
Strength
Security that ships with the product
I turn security into running engineering controls like CI checks, policy gates, detection logic, IAM automation, and safer AI-tool boundaries.
Strength
Debugging from evidence
When behavior gets strange, I work from traces, packets, logs, binaries, and runtime evidence instead of guessing from surface symptoms.
Why Teams Pull Me In
The situations where I usually become most useful.
This is the kind of work I want more of: systems that need real reasoning, clear communication, and someone willing to stay with the problem until it makes sense.
Signal
I stay close to runtime behavior
I like working where telemetry, packet flow, release safety, and production debugging are part of the day-to-day job instead of cleanup after the fact.
Signal
I care about systems that are explainable
A backend service or security workflow is only half-finished if nobody can reason about it once it is running under pressure.
Signal
I am comfortable with technical depth
When the fast answer is wrong, I am happy to go lower: traces, logs, packet captures, binaries, kernel behavior, and the actual mechanism behind the problem.
Selected Outcomes
A few concrete results.
These numbers are the shorthand version of how I usually contribute: less guesswork, less toil, and fewer fragile releases.
40%
Faster identification of production bottlenecks after trace rollout
1,000+ / week
Alerts enriched automatically so analysts could focus on real incidents
30%
Faster rollouts after automating server configuration and validation
Explore
The rest of the site.
The About page explains who I am, Projects shows the strongest work, Workbench covers how I study systems and security, and the resume is the quick summary.
Profile
About
Who I am, how I work, and the kind of engineering problems I want to keep solving.
Profile, values, and focus areas
Open aboutCareer
Experience
Roles, measurable outcomes, and the supporting credentials behind the engineering work.
Work history and credentials
Open experienceCase studies
Projects
Case studies across backend systems, security tooling, low-level research, and applied product work.
Project gallery and deep dives
Open projectsResearch and practice
Workbench
Hands-on systems and security study distilled into patterns, workflows, and practical takeaways.
Research, workflows, and technical depth
Open workbenchField notes
Writing
Technical notes on observability, AI security, low-level debugging, and the engineering decisions behind shipped work.
Systems and security writing
Open writingReach out
Contact
Private contact request flow for role discussions, collaborations, and technical conversations.
Private outreach and next steps
Open contactFeatured project
Newest projectEnterprise NIDS: Network Detection and Analysis Platform
Built a Python-based network detection platform that supports offline PCAP investigation, live traffic capture, explainable incident reporting, and a FastAPI dashboard with operational telemetry.
Enterprise NIDSSecurity Product
2026The hard part was making low-level network analysis readable and operationally…
Built dual execution paths for offline PCAP analysis and continuous live capture…
Enterprise NIDS now works as an end-to-end detection and analysis…
2 analysis modesOffline PCAP and live…
FastAPI + UIDashboard, APIs, and report…
GitHub-readyCI, docs, and rendered…
The hard part was making low-level network analysis readable and operationally useful at the same time. Raw packets and flows are not enough on their own, so the platform had to connect capture, detection, diagrams, reports, and runtime visibility without becoming a pile of disconnected scripts.
PythonFastAPISQLiteScapyDPKTMermaidGitHub Actions
Latest writing
Observability as a Root-Cause Discipline
Tracing is not just dashboards. It is the shortest path from symptom to mechanism when latency or correctness starts drifting in distributed systems.
Systems
5 min readThe value of observability is not the graph. It is the speed at which a team can move from a vague production symptom to a defensible explanation of what actually changed.
Contact
Good outreach is specific.
I do not publish a direct phone number on the open web. If you are reaching out about a role, project, or collaboration, send the context here and I will follow up directly. The most useful messages include team context, role scope, timeline, and why the conversation makes sense now.
Process
Share the context
Tell me about the role, team, project, or collaboration so I can respond with the right level of detail.
Process
I review it directly
I use the request form to keep outreach focused and direct contact details off the public site.
Process
Next step stays direct
If the conversation makes sense, I follow up directly with the best next step, including phone details when useful.
Include the team, role, timeline, or project scope. That keeps outreach focused and lets me respond with the right context while keeping direct contact details private.
Private Contact
Request a conversation.
Share the role, team, or collaboration context. I review requests myself and keep direct phone details private until there is enough context for a useful conversation.