00 YOUR NAME software engineer / research builder
FILE / ENGINEER-01 STATUS / OPEN TO WORK LOCATION / INDIA

00 / IDENTITY

I build software where application logic meets operating reality.

MSR Computer Science student working across backend engineering, distributed systems, computer networks, and full-stack development. My current work involves building infrastructure to exercise, observe, and debug clustered Software-Defined Networking systems.

inspect current work open resume
primary build language Python
algorithmic language C++
systems environment Linux / Docker
network stack ONOS / Atomix / Mininet
application stack MERN
problem-solving signal LeetCode 2000+
role target

Backend, systems, distributed systems, networking, platform engineering, and technically substantive full-stack roles.

01 / CASE FILE

Research engineering · active

Failure-oriented testing for a distributed SDN controller.

The central engineering problem is not simply generating operations. It is determining whether a sequence caused a meaningful distributed failure, correlating delayed evidence to the correct operation, and separating product faults from harness faults.

PLATE A — EXECUTION PATH not to scale

BUILT

Infrastructure that can change a live experimental system.

  • 01

    Three-node ONOS cluster with external Atomix nodes in Docker.

  • 02

    Mininet and Open vSwitch topology controlled through OpenFlow.

  • 03

    Python APIs and CLI entry points for cluster and topology operations.

  • 04

    Installable test-harness package rather than a one-off experiment script.

  • 05

    Custom ONOS event logger for node-local observations.

CURRENT ENGINEERING QUESTIONS

The hard part begins after an operation returns successfully.

  • A

    How long should each event family be observed before declaring absence?

  • B

    How should delayed events be attributed when later operations overlap?

  • C

    Which signals distinguish ONOS, Atomix, Mininet, and harness failures?

  • D

    Which feedback signals can guide exploration without invasive instrumentation?

TRACE / REPRESENTATIVE observation pending 
[4180] remove_link(s1, s2)           accepted
[4181] remove_onos_node(onos2)       effect delayed
[4181+] cluster event stream          cross-node divergence
[oracle] correlate(operation, events)  under construction

Research source code is not currently public. Architecture, implementation trade-offs, debugging evidence, and publish-safe support tooling can be discussed.

02 / WORK LOG

Selected technical artifacts
02.1

Developer tooling

Cluster test harness package

Reusable Python interfaces around ONOS, Mininet, cluster lifecycle, REST calls, and process control. Packaged as a wheel with configuration-driven behavior and command-line entry points.

PythonuvRESTLinux
built
02.2

Observability

ONOS event observation layer

Custom ONOS application and parser architecture for collecting device, link, host, cluster, and leadership events from individual controller nodes, preserving enough context for later correlation.

JavaOSGiKarafONOS API
active
02.3

Protocol analysis

Atomix traffic analysis experiments

Packet-capture experiments using a Wireshark Lua dissector, Java stream processing, and protobuf/Kryo investigation. The failed decoding paths were useful: they established the practical limits of passive observation for this target.

WiresharkLuapcap4jKryo
prototype
02.4

Distributed programming

Multi-instance socket system

Python peer system with explicit handshakes, length-prefixed messages, dispatching, reconnection, peer management, and per-instance logs. Built to understand connection lifecycle and failure recovery rather than to imitate a framework.

PythonTCPConcurrencyFraming
built
02.5

Full-stack engineering

Browser-based Windows interface

MERN project recreating selected Windows 10 interaction patterns in the browser. It demonstrates application construction and UI state management, but is presented honestly as an interface project rather than an operating-system simulation.

ReactNode.jsExpressMongoDB
built

03 / CAPABILITY INDEX

Conservative self-assessment

Depth is uneven by design.

I do not claim equal expertise across every technology listed here. The useful combination is strong programming, practical systems debugging, and the ability to acquire enough domain knowledge to build reliable tooling around unfamiliar infrastructure.

area working evidence assessment
Python engineering Test harness, fuzzer, packaging, REST clients, process control, parsers, socket systems strong
Algorithms / C++ Sustained competitive programming; LeetCode rating above 2000 strong
Backend / MERN Full-stack applications, REST APIs, React state, Node services, MongoDB working proficiency
Linux / infrastructure Dockerized clusters, SSH systems, networking, packaging, logs, process and environment debugging working proficiency
Networks / distributed systems ONOS, Atomix, Mininet, OVS, OpenFlow, events, delayed convergence, cluster faults research depth
Java ecosystem ONOS application work, OSGi components, Maven/Bazel reading, Karaf deployment functional
PYTHON C++ JAVASCRIPT JAVA LINUX DOCKER GIT UV MININET OVS ONOS ATOMIX WIRESHARK REACT NODE MONGODB

04 / ROLE FIT

Where this profile is useful

Useful when the work requires more than implementing a ticket from a settled specification.

01

Backend engineering

APIs, application logic, debugging, data flow, and building maintainable services rather than only user interfaces.

02

Systems and platform tooling

Automation around processes, containers, networks, observability, reproducible environments, and failure investigation.

03

Distributed systems and networking

Roles where delayed effects, partial failure, state replication, protocols, and cross-component debugging are normal.

04

Technically demanding full-stack work

Product teams that need a developer comfortable moving from the browser to APIs, deployment, Linux, and system behavior.

05 / CONTACT

Discuss the engineering, not just the keywords.

I am seeking internships and entry-level roles where debugging, systems understanding, and independent technical learning are treated as useful engineering skills.

your.email@example.com
LinkedIn GitHub LeetCode Other Resume PDF
Email copied.