Asvanth CSoftware Engineer
Resume

Software Engineer at Zeetaminds — since August 2024

I build the parts of software that people never see.

Backend services, the identity layer that guards them, and player software running on displays in places I will never visit. I care about what a system actually does in production — not what the spec says it should.

View experience Case studiesEngineering notes
GitHub LinkedIn Résumé asvanthc@gmail.com
  • Java
  • Play Framework
  • MyBatis
  • OAuth 2.0
  • OpenID Connect
  • JWT
  • Angular
  • TypeScript
  • Tizen
  • webOS
  • Android
  • SQL

Engineering identity

I build beyond the interface.

Most of what I work on has no screen. It is the layer that decides whether the thing with a screen can be simple — and it spans five areas that turn out to be the same problem seen from different heights.

01

Backend engineering

APIs, business logic and services in Java on the Play Framework, with Guice and MyBatis over a relational schema. The work that decides whether everything above it can be simple.

  • Java
  • Play
  • MyBatis
  • REST
  • SQL
02

Identity & security

OAuth 2.0 and OpenID Connect in practice: Authorization Code with PKCE, JWT validation against JWKS, refresh and session lifetime, SSO, and the difference between proving who someone is and deciding what they may do.

  • OAuth 2.0
  • OIDC
  • PKCE
  • JWT
  • SSO
03

Product engineering

Customer-facing software rather than exercises. Features that have to work for operators who did not read the release notes, on the day they need them.

  • Angular
  • TypeScript
  • CMS
  • Scheduling
04

Device & platform engineering

Signage players on Samsung Tizen, LG webOS and Android: media playback, remote control, snapshots and live view, on embedded runtimes with their own rules about what a browser is.

  • Tizen
  • webOS
  • Android
  • Media
05

AI engineering

Learning to build applications where a language model is one component in a system that still has to be correct: structured outputs, tool calling, retrieval, and evaluation that does not flatter itself. The newest of these five, and the one I am least expert in.

  • LLM APIs
  • Tool calling
  • RAG
  • Evaluation

Current work

Where I spend my days

Production software at a digital signage company: the backend that serves it, the identity layer that guards it, and the device code that has to behave the same on three vendors’ hardware.

Software Engineer at Zeetaminds

Chennai, India

Current

Zeetaminds builds a digital signage platform: a content management system that schedules and delivers media to displays running in shops, offices, campuses and public spaces. I work across the backend that serves those displays, the identity layer that guards it, and the device-side code that has to behave the same on hardware from three different vendors.

01Backend & APIs

  • Work on server-side features in Java on the Play Framework, with Guice for dependency injection and MyBatis for the SQL layer.
  • Build and extend REST endpoints consumed by both the web client and the device agents, which means two very different clients with different tolerance for change.
  • Write and review SQL against the relational schema behind content, scheduling and device state.
  • Investigate production issues from logs and reproduction rather than guesswork, and fix the cause instead of the symptom where the change is safe to make.

02Identity & access management

  • Worked on identity and access management, including OAuth 2.0 and OpenID Connect flows — Authorization Code with PKCE, token exchange, and single sign-on between applications.
  • Worked with JWT-based tokens: RS256 signatures, JWKS-based key distribution, claim and audience validation, and the practical differences between access tokens, ID tokens and refresh tokens.
  • Handled the parts of login that are easy to get wrong: state and nonce, login CSRF protection, redirect URI handling, session lifetime and token refresh.

03Device & platform engineering

  • Built and debugged the player-side web application that runs on Samsung Tizen (SSSP), LG webOS and Android signage devices.
  • Worked around the constraints of embedded browser engines: older runtimes, missing or partial web APIs, and vendor-specific device APIs that have no cross-platform equivalent.
  • Worked on media playback across these platforms — container and codec support, hardware decoder limits, and the failure modes where the same file plays on one device and silently does not on another.
  • Worked on device-management features including remote control, snapshots and live view, where the device, the network and the server all have to agree on state.

04Web client & integrations

  • Contributed features to the Angular + TypeScript management client used to operate displays, content and schedules.
  • Worked on integrations between the platform and external systems, including the compatibility work that legacy integrations demand.
  • Kept backward compatibility in mind as a hard constraint: devices in the field are not all on the latest build, and cannot be assumed to update on command.
Worked with
  • Java
  • Play Framework
  • Guice
  • MyBatis
  • SQL
  • REST APIs
  • OAuth 2.0
  • OpenID Connect
  • JWT / JWKS
  • Angular
  • TypeScript
  • JavaScript
  • Samsung Tizen
  • LG webOS
  • Android
  • Linux

Selected engineering work

Problems worth writing down

Two anonymised case studies from work, one personal project, and two slots I have deliberately left empty rather than fill with something invented.

Production engineering

Digital signage: one CMS, three device ecosystems

Getting the right media onto displays that run on hardware from three vendors, over networks nobody controls.

  • Java
  • Play Framework
  • MyBatis
  • SQL
  • Angular
  • +4
Production engineering

Identity as its own domain

OAuth 2.0 and OpenID Connect in production — Authorization Code with PKCE, JWT validation against JWKS, and SSO between applications.

  • OAuth 2.0
  • OpenID Connect
  • PKCE
  • JWT
  • RS256
  • +3
Systems engineering

Portfolio dashboard

A personal finance dashboard that replaced a spreadsheet — and turned into an exercise in how to fetch data from providers that do not want to be fetched from.

  • Node.js
  • Express
  • React
  • Vite
  • REST
AI engineeringTo be filled in

AI engineering project

Slot reserved for a real LLM application — not filled with an invented one.

  • LLM APIs
  • Tool calling
  • RAG
  • Evaluation
Developer toolsTo be filled in

Developer tooling

Slot reserved for a utility, automation or dashboard worth writing up.

Capability map

What I actually know, and how well

No percentages — a number like “Java 70%” means nothing to the person reading it. Three honest levels instead, and the difference between them matters.

ProductionUsed in software that shipped, and that I have had to debug when it broke.
Working knowledgeEnough to be productive and read other people’s code, short of deep expertise.
Currently learningActively building competence. Listed because it is honest, not because it is finished.

Languages

  • Java
  • JavaScript
  • TypeScript
  • SQL
  • Python
  • C / C++

Backend

Where most of my day goes.

  • Play Framework
  • REST API design
  • MyBatis
  • Guice / DI
  • Service architecture
  • Node.js / Express

Identity & security

The area I have gone deepest on, and the subject of most of my writing.

  • OAuth 2.0
  • OpenID Connect
  • Authorization Code + PKCE
  • JWT / RS256 / JWKS
  • Single sign-on
  • Session & token lifecycle
  • Threat modelling

Web

  • Angular
  • Browser APIs
  • HTML / CSS
  • Embedded web runtimes
  • React
  • Astro

Devices & platforms

Signage hardware: three vendors, three sets of rules.

  • Samsung Tizen (SSSP)
  • LG webOS
  • Android
  • Linux
  • Media containers & codecs
  • Device management / MDM

Data

  • MySQL
  • Schema & query design
  • MongoDB
  • Caching strategy
  • Vector databases

AI engineering

The newest area for me. Listed at the level I actually hold it, not the level it would be useful to claim.

  • LLM APIs
  • Prompt design
  • Structured outputs
  • Tool calling
  • RAG & embeddings
  • Agent orchestration
  • Evaluation

Tooling & infrastructure

  • Git
  • Gradle / Maven
  • Production debugging
  • Nginx
  • Docker
  • CI/CD pipelines
  • Cloud architecture

How I think

How I think about engineering

Ten things I actually believe about building software, most of them learned the expensive way.

  1. Understand the system before changing it.

    The fastest way to cause an outage is to fix a symptom in a part of the system you have not read yet. Before I change code I try to answer three questions: who calls this, what does it assume, and what breaks if it returns something different. If I cannot answer them, I am not ready to edit the file.

  2. Prefer simple architecture over clever architecture.

    Every layer of indirection is a thing the next person has to hold in their head at 2am. I would rather write a boring service with an obvious call path than an elegant one that needs a diagram to explain. Complexity should have to justify itself; simplicity gets the benefit of the doubt.

  3. Production behaviour beats theoretical correctness.

    A spec tells you what should happen. A device in a shop tells you what does. I have shipped code that was correct by the standard and still wrong in the field, because a runtime three years out of date disagreed. The real system is the source of truth, and the spec is a strong hypothesis about it.

  4. Debug from evidence, not from intuition.

    When something fails I want a log line, a network capture, a reproduction — something that constrains the search space. Intuition is useful for choosing which evidence to collect first, and dangerous as a substitute for collecting it. The question I keep asking is: what would I expect to see if I were right?

  5. Security is a property of architecture, not a feature you add.

    Working on IAM taught me that authentication decisions leak into everything: where state lives, how long a session survives, which service is allowed to trust which token. You cannot bolt that on at the end. Decide the trust boundaries first, and most of the individual security bugs stop being possible.

  6. An API is a contract, and someone already depends on it.

    Once a response shape is out there, a client is parsing it — possibly a device in the field that will not be updated this quarter. Adding a field is cheap, changing the meaning of one is expensive, and removing one is a decision, not a cleanup. I try to design endpoints as if I will never get to change them.

  7. Compatibility is an engineering constraint, not an annoyance.

    I write code that has to run on browser engines several years behind current, on hardware I cannot physically reach. That is not a bug in the plan; it is the plan. Treating old runtimes as a design input — rather than complaining about them — is most of what makes device work tractable.

  8. Observability beats guessing.

    The difference between a ten-minute fix and a two-day one is usually whether the system said anything useful before it fell over. Logging the input that caused the branch, not just the fact that the branch was taken, is the cheapest investment I know of.

  9. Build for failure, not just the happy path.

    Networks partition, devices reboot mid-download, tokens expire in the middle of a request, and a media file that worked yesterday hits a decoder that will not take it. The interesting part of the design is what happens then. Retries, timeouts and a safe fallback state are features, not defensive padding.

  10. AI should augment engineering, not replace the fundamentals.

    I use LLMs daily and they have genuinely changed how fast I work. They have not changed what it means for code to be correct. A model can produce a plausible integration in seconds; knowing whether it handles the expired-token case is still the job. I treat AI as a fast, confident junior collaborator whose work I am accountable for.

Direction

Currently learning

Stated as direction, not achievement. These are the areas I am deliberately spending time on — none of them are finished.

AI engineering

In progress

Treating an LLM as an unreliable component inside an otherwise ordinary system: where to put retries, how to validate structured output, when retrieval beats a bigger prompt, and how to evaluate any of it without fooling myself.

  • LLM application architecture
  • Tool calling
  • RAG
  • Vector databases
  • Evaluation
  • Agent workflows

Distributed systems

In progress

I already work on a system where thousands of clients hold their own state and the network is unreliable by default. I want the vocabulary and the theory behind the problems I keep meeting in practice.

  • Consistency models
  • Messaging & queues
  • Caching
  • Backpressure
  • Reliability
  • Observability

Cloud & infrastructure

In progress

Less clicking in consoles, more understanding of what the platform is actually doing. Containers, reproducible builds, and pipelines that make a deploy boring.

  • Containers
  • CI/CD
  • Infrastructure as code
  • Cloud architecture

Advanced backend engineering

In progress

The parts that only show up under load or under attack: concurrency, performance work backed by measurement, and API design that survives its second and third consumer.

  • System design
  • Concurrency
  • Performance profiling
  • API evolution
  • Security engineering

Engineering notes

Things I have had to understand properly

Mostly written after debugging something and realising my mental model was wrong. Identity, device platforms, media, and what actually changes when a language model joins the system.

All 10 notes

Path

How I got here

  1. 2020 — 2024

    B.Tech, Computer Science and Engineering

    Amrita Vishwa Vidyapeetham, Coimbatore

    Data structures and algorithms, operating systems, DBMS, computer networks, distributed computing, computer architecture, cryptography and network security.

  2. August 2024

    Joined Zeetaminds as a Software Engineer

    Zeetaminds

    Moved from coursework into production software: code that other people depend on, running on hardware I cannot reach.

  3. 2024 — now

    Production engineering across backend, identity and devices

    Zeetaminds

    Backend services in Java and Play, IAM with OAuth 2.0 and OpenID Connect, and device-side work across Samsung Tizen, LG webOS and Android.

  4. Now →

    Going deeper: AI engineering, distributed systems, system design

    Ongoing

    Building LLM-backed applications and studying the failure modes of distributed systems, with the same bias toward understanding the layer underneath.

Education

B.Tech, Computer Science and Engineering

Amrita Vishwa Vidyapeetham · Coimbatore, Tamil Nadu

2020 — 2024

  • Data Structures & Algorithms
  • Operating Systems
  • Database Management Systems
  • Computer Networks
  • Distributed Computing
  • Computer Architecture
  • Cryptography & Network Security
  • Object Oriented Programming

Certifications

21 edX course certificates

Coursework completed between 2019 — 2022, before I started engineering professionally. Listed for completeness rather than as evidence of current expertise — the work section is the better signal.

Amazon Web Services6
IBM6
The Linux Foundation4
University of Washington3
Columbia University1
University System of Maryland1

Have an interesting system to build?

I like talking about backend architecture, identity, the strange things devices do in production, and where language models genuinely help in a system that still has to be correct. If you are working on something in that space — or you think I have got something wrong in one of my notes — I would like to hear about it.

asvanthc@gmail.com +91 86104 97921 Download résumé