>mithil_batra.log
Available — SWE / New Grad 2027

Mithil
Batra.

// Software Engineer · AI / ML · Backend & Systems · Full-Stack

I build systems — then I figure out why they break, and make them better.

CSE undergrad at NIT Delhi; software engineering intern at HSBC in summer 2026. I like the unglamorous parts of engineering: making services talk to each other, keeping ML honest, and turning a broken thing into a reliable one.

explore projectsdownload resume
★ start here Pit Wall →Walk-forward backtests: 75.0% top-3 hit-rate in 2025 — level with the pick-the-top-3-qualifiers baseline, not above it

severity core · scroll, it docks and keeps watch

at a glance
99.467%ile
JEE Main
Top 0.5% nationwide
AIR 5376
JEE Advanced
Qualified
800+
Problems Solved
Across coding platforms
section 01
$grep -r 'what broke' ./incidents

The Engineering Log

I don't just collect projects — I collect problems. Each case study opens up one project: the symptom, the root cause and the fix, with results, a demo and the source. Click one to open it.

> the problem
From the outside a Formula 1 race looks like chaos. Can live timing and telemetry actually predict who finishes on the podium — without quietly fooling yourself with data leakage?
> my role
Solo — designed the feature pipeline, trained and evaluated the models, built the dashboard and deployed it with Docker on a cloud VM.
> the approach
Pull live timing and telemetry through FastF1, engineer features from it, then train and compare tree-based models — judged by an honest top-3 hit-rate rather than a flattering accuracy score.
> architecture
  1. 1FastF1 ingestion pulls live timing + telemetry per session
  2. 2Leakage-safe feature pipeline: strictly time-ordered splits + walk-forward season backtesting
  3. 3Random Forest vs. gradient-boosting models, compared on top-3 hit-rate
  4. 4Flask REST API + dashboard, containerized with Docker on a public cloud VM
  5. 5Automated race-data fetching and model retraining
key challenge

Data leakage. Naive random splits let information from the future bleed into training and inflate the score. The fix was strict time-ordering and walk-forward backtesting across seasons — so every prediction is made only from the past.

resolution

An honest metric beats an impressive one. Top-3 hit-rate under walk-forward validation tells the truth; a shuffled split just tells you what you want to hear.

> results · model vs baseline

Top-3 hit-rate — the average share of each race's real podium that appears in the model's three picks. Walk-forward: before every race the model is retrained on earlier races only, then scored on that race. Baseline: pick the three fastest qualifiers.

seasonmodelbaselineΔ
202420 races61.7%63.3%−1.6
202524 races75.0%75.0%±0.0
2026 (to R17)17 races56.9%60.8%−3.9

It matches the baseline in 2025 and trails it by 1.6–3.9 points in 2024 and 2026 — it doesn't beat the qualifying grid yet.

Random-forest model · walk-forward run of 22 Oct 2026 on the deployed app (/api/backtest). The repo README's ~74% (2025) and ~63% (2024) come from an earlier run on 8 Aug 2026 (73.6% and 61.7%). A 6-race holdout isn't reported: the training script picks its 'best model' on those same races.

> demo
screenshot/pit-wall.jpg
Pit Wall — live dashboard · now tracking the 2026 season
> live from pit-wall · /api/weekend

loading the next race weekend…

demo access · The live app is served over plain HTTP from a small VM, so browsers that enforce HTTPS-only may block it. The screenshot and race data above are relayed over HTTPS.

Try the demo View source# permalink
⚑ The console you're reading is styled like an incident dashboard. Resolvr is the real one.
> the problem
When a service breaks, teams bleed time to scattered signals — no single place to track the issue, page the right person, and actually drive it to resolution.
> the approach
A React Native (Expo) mobile app on an Express + MongoDB API, modelled around how incidents actually move: active → escalated → acknowledged → resolved.
> architecture
  1. 1Expo (React Native) client — issues, incidents, projects and notifications
  2. 2Express REST API, with Socket.IO pushing live incident updates to every client
  3. 3MongoDB (Mongoose) stores each incident's escalation chain, current level and next-escalation time
  4. 4Raising an incident starts an escalation timer; unacknowledged incidents climb the chain
  5. 5Firebase Cloud Messaging push notifications reach the on-call engineer's phone
key challenge

Escalation logic — deciding who gets paged, when, and how it climbs if no one acknowledges, all without spamming the whole team on every alert.

resolution

Incident response is a state machine. Model the states explicitly and the UI, the alerts, and the escalation rules all fall out of it cleanly.

> demo
on-call: you0 open
Incidents
IncidentsIssuesProjects
✓
All quiet
No open incidents.
INC-0041 · db pool exhaustedRESOLVED
INC-0039 · webhook 5xx spikeRESOLVED
> try it · no expo go needed

Trigger an alert, then acknowledge it before it escalates.

the mobile app
React Native (Expo) client on a Node.js + Express API with MongoDB, Socket.IO and Firebase Cloud Messaging. Runs in Expo Go against its own backend.
this browser demo
A separate React re-implementation inside this portfolio. It reproduces the mobile workflow — the backend's status names, push-style alerts and escalation — with a client-side state machine, and does not connect to Resolvr's backend. Escalation is compressed from 5 minutes (up to 3 attempts in the real API) to one escalation after 6 seconds.
  1. active
  2. —6s, no ack→escalated
  3. →acknowledged
  4. →resolved

acknowledging while active skips escalation · transitions unit-tested (lib/incident.test.mjs)

server log — waiting for an alert…
↑ Try the demo View source# permalink
> the problem
Interview prep is mostly static question banks — no questions tailored to your role, and no feedback until a mentor has time for you.
> the approach
Simulate a real interview: generate role-based questions with an LLM, evaluate the answers, and hand back specific, instant feedback — no mentor required.
> architecture
  1. 1Clerk sign-in → pick a role, tech stack and experience level
  2. 2Gemini generates role-specific interview questions as JSON
  3. 3Answers are spoken — captured with speech-to-text while the webcam runs
  4. 4Gemini rates each answer and returns 3–5 lines of feedback as JSON
  5. 5PostgreSQL (Drizzle ORM) stores interviews, answers and feedback history
key challenge

Getting the model to produce consistent, useful evaluation instead of vague praise — structuring prompts and schemas so feedback is specific and actionable.

resolution

A model is only as good as the structure around it. Constrain generation and grading with clear schemas and role context and the quality jumps.

> known limitations
Ratings come from a single Gemini call without a fixed rubric, so the same answer can score differently between runs. Next step: a rubric in the prompt and averaging across several calls.
> demo
screenshot/ai-mock-interview.jpg
AI Mock Interviewer — live app · role-based interviews with instant feedback

demo access · The landing page is public; starting an interview needs a free sign-in (Google or email, via Clerk). There's no guest mode yet — the architecture steps above walk through the full flow.

Try the demo View source# permalink
section 02
$cat RUNBOOK.md

My Runbook

Four rules I engineer by — each one learned the hard way on a project above.

  1. rule 01· learned inpit-wall

    Honest metrics beat impressive ones

    Measure what you'd bet on in production. A walk-forward top-3 hit-rate told the truth where a shuffled split flattered.

  2. rule 02· learned inresolvr

    Model the states explicitly

    Most systems are state machines in disguise. Name the states and the UI, alerts and edge cases fall out of them.

  3. rule 03· learned inai-mock-interview

    Constrain the model, not the user

    An LLM is only as good as the structure around it. Schemas and context beat clever prompts.

  4. rule 04· learned inhsbc

    Leave it more reliable than you found it

    Bug fixes and code-quality work aren't glamorous; they're what lets a service ship to production.

section 03
$git log --deployments

Deployment History

Where the code met production and other people's expectations.

HSBC

deployed

Software Engineering Intern

Jun 2026 – Jul 2026

Worked across internal enterprise services — an AI chatbot, a microservice integration, and a production Spring Boot app.

  1. tds-chatbot
  2. vidura-integration
  3. panorama-fixes
  4. deploy-workflows
  5. production
  • Improved an internal TDS chatbot with better intent recognition, response generation, and workflow automation to handle employee tax queries.
  • Integrated the Vidura microservice into the GPS portal via service integration, API integration, and environment configuration.
  • Supported the Panorama application (Spring Boot + GCP) with production bug fixes and code-quality improvements.
  • Worked on application debugging, service integration, environment configuration, and production deployment workflows.
Spring BootGCPMicroservicesNLPAPIs
section 04
$curl -s /api/status | jq

System Status

Real health checks, not decoration — this page pings my production apps every 30 seconds while you're here.

Running checks…checks every 30s while you're here
  • pit-wallchecking
    mithil-f1-pitwall.duckdns.org
    —
  • ai-mock-interviewchecking
    automated-ai-interviewer-nbog.vercel.app
    —
  • portfoliochecking
    this site · vercel · approx. round trip
    —
  • resolvrmobile app · runs in Expo Go — try the in-browser replica in its case file ·source ↗
section 05
$systemctl status --capabilities

Systems & Runtime

The stack I reach for — and a few certifications that back it up.

lang/Languages
JavaPythonCC++JavaScriptTypeScript
fw/Frameworks & Libraries
Spring BootSpringNext.jsReactFlaskOpenCVTailwind CSS
api/Backend & APIs
REST APIsMicroservicesAPI IntegrationWebhooksNode.js
db/Databases
PostgreSQLMySQLMongoDB
cloud/Cloud & DevOps
GCPAWSAzureDockerGitGitHub
ml/AI / ML
Machine LearningDeep Learningscikit-learnPandasArtificial Intelligence
core/Core
Data Structures & AlgorithmsOOPDesign PatternsSoftware Engineering
tools/Tools
PostmanArduinoFigma
installed certifications

Apache Cassandra

Udemy

Distributed database management, fault tolerance, and horizontal scalability.

Azure Services

Microsoft

Designing and deploying scalable cloud solutions — Functions, Storage, DevOps pipelines.

C++ Proficient Practitioner

Edchart

Advanced C++: STL, memory management, and performance optimization.

section 06
$tail -f telemetry.log

Telemetry & Signals

Awards, leadership, and the academic track record behind the profile.

> awards & leadership
  • Gold — MST Tournament 2025Held at NIT Jaipuraward
  • Quarter-Finalist — Flipkart GRiDNational engineering challengecompetition
  • L'Oréal Sustainability ChallengeQuarter-Finalistcompetition
  • Deputy General Secretary — GDSCGoogle Developer Student Clubs, NIT Delhileadership
  • Executive — Training & Placement CellNIT Delhi · calling and social media teamleadership
> education

  1. National Institute of Technology, Delhi

    2023 – Present
    B.Tech, Computer Science & Engineering
    CGPA 8.93

  2. Stepping Stones Sr. Sec. School, Chandigarh

    2022 – 2023
    CBSE (Class XII)
    91.8%

  3. Seth Anandram Jaipuria School, Vasundhara

    2020 – 2021
    CBSE (Class X)
    94.6%
> loaded coursework
Software EngineeringData MiningDatabase Management SystemsQuantum ComputingMachine LearningArtificial IntelligenceNatural Language ProcessingComputer VisionPattern RecognitionProbability & StatisticsOptimization Techniques
section 07
$./contact --open-channel

Open a Channel

Hiring, collaborating, or just want to talk shop about systems and F1? Reach out.

channels.sh
hiring-signal.logrec
INFOauditstrong fundamentals ✓
INFOauditships real systems ✓
INFOauditthinks about failure ✓
CRIThiringrecommend=PROCEED → schedule technical interview
$ resolvr incident create
priority