Amazon SDE I · AUTA APJ · Job 10454435 · Round 4 only

Prev: 2. Hour · Next: 4. Questions

3. Stories you speak — sixteen Leadership Principles

This is a rehearsal notebook for Adarsh Vishwakarma. Read it as yourself. R1 was 13 Aug 2026. R2 was 18 Aug 2026. R3 is done. This folder is Round 4 only. Live Code is Java. Job 10454435 still has no public write-up that names a live-round question. Other people’s prompts show what a leftover hour can look like. They are not a list for this Job ID. Unnamed stays unnamed.

How to STAR in this hour

Fifteen seconds of Situation: product, who hurt, the constraint that made the obvious path fail. Ten of Task: what you owned, intern title honest. Forty of Action: three mechanisms you implemented, in order, plus the option you discarded. Fifteen of Result: one resume metric family, then stop. They will ask why. Answer on the same path. Do not restart the STAR. Do not change project unless they change the principle.

What they might ask

Named leftover stems are IE-asked in other loops (GFG 2025 leftover hour; LC 6806195, 8362604, 8430457, and similar). They are shape evidence, not a forecast for Job 10454435. Spoken facts are Resume-derived.

What you say

If they do not name a principle: Dive Deep first — Ylogx Redis and RLS together, bot database latency down 35 percent, three-tier isolation in Postgres. Then Deliver Results — Horizon 17th of more than eighty at ERC 2024. If the intro already used the rover, Deliver switches to Ylogx 40 percent faster reports at 99.9 percent uptime. Third if they want another: GiftedBooks, student doubts from hours to three to ten minutes.

Failure and feedback: Argus 73 percent mAP was not shippable for floor alerts. Deadline: Horizon sequencing to the ERC date; the resume has no missed ERC and no missed 99.9 percent. Conflict: IQVIA hybrid versus vector-only, then commit on evals.

They might ask next

If they askYou answer
Why that approach?Name the discarded option and the failure mode on this story. Stay on the same product.
How do you know it worked?The resume number that belongs on this product. No extra percent, p95, TTL, or sample size the PDF does not state.
What would you do differently?A real missing test or a sequencing miss on this path. Argus 73 percent is the honest “I was wrong about a ship bar.” Horizon has no invented miss.
I versus we?I for modules you shipped. We for Horizon 17th / 80+, Argus site −50% / 2× after alerts existed, and named team hackathon prizes.

Keep straight

Tighten

Stop after the metric. If they already heard that project this hour, speak the locked backup named on the card — a full second story. If they ask several prompts, do not spend a fourth primary on the same org. Name the backup. Dates answer “which intern ran longest”: Ylogx, November 2024 to October 2025. Two extra genuine stories from your notes (not sixteen extra trophies): IQVIA DOM truncation demo (q-dd-dom) and Ylogx client-side aggregation crash (q-hs-crash). Click every leftover wording from 9. LP list.

Customer Obsession — GiftedBooks

On this resume the customer is a student with their own PDF who still lost hours on doubts. Work backwards from that file, not from a generic tutor voice or a pretty VR lab that cannot answer.

What they might ask

IE-asked as theme (GFG sde-1-17 extra for customers; Ruchi “proud of” family). Resume-derived GiftedBooks: RAG PDF Q&A, sub-300 ms, 99.5% uptime, PYQ topics, +35% reading, +50% engagement, 2.5× comprehension, hours → 3–10 min. Other loop, not a forecast for Job 10454435.

What you say

Situation. GiftedBooks is a VR learning suite with 3D labs and avatars. The customer is a student who already has PDFs and still loses hours on doubts from that material. A lab that cannot answer from the upload is decoration. A generic tutor that sounds like a textbook is the wrong customer, because the student is studying from their notes, not from a model’s prior.

Task. I needed to cut time-to-answer without inventing syllabus, keep the assistant usable during study, and make the study path reflect what exams actually asked. I owned the RAG and PYQ path, not every 3D lab or avatar asset.

Action. Three mechanisms, then the option I discarded.

  1. I shipped retrieve-then-generate over that student’s PDF: chunk with enough context for a table or derivation, embed once at ingest, store vectors with user and document metadata, and retrieve a small user-scoped top-k at question time.
  2. I kept generation small so the API could stay under 300 milliseconds, and I abstained when no supporting span existed. Another student’s notes never retrieve.
  3. I added previous-year question topic ranking as a separate deterministic pass over past papers, not as the generator guessing the exam.

I discarded stuffing the whole textbook into every prompt, and I discarded a generic chatbot disconnected from the upload.

Result. Average doubt time moved from hours to three to ten minutes. Reading efficiency improved 35 percent, engagement 50 percent, comprehension 2.5 times. The API stayed sub-300 milliseconds with 99.5 percent uptime.

They might ask next

If they askYou answer
What did you implement?Ingest, chunk, embed-once, user-scoped retrieve, generate-or-abstain, and PYQ ranking as a separate pass. Not every avatar asset.
Why RAG, not stuffing the PDF?Dumping the textbook blows tokens and latency and cites the wrong annex. Retrieval keeps a small evidence set from their file.
Why not a generic tutor?Fluent textbook voice can ignore the student’s upload. The customer’s artifact is the source of truth.
Why is PYQ not the LLM?Exam-topic ranking is frequency over past papers. Letting the model “predict” the exam presents speculation as analysis.
How do you know the numbers?Hours to 3–10 minutes, +35%, +50%, 2.5×, sub-300 ms, and 99.5% are the GiftedBooks resume family. The PDF has no student headcount and no study-protocol n. Mechanism plus those numbers.
What did you not own?Every 3D lab mesh and avatar. LangSmith, Azure AI Search, and GraphDB are IQVIA tools, not this product.
What would you add next?A small grounded-versus-wrong-citation check. That eval is not already on the resume.

Keep straight

Tighten

Stop after 3–10 minutes (and the listed GiftedBooks family if they are still with you). If they already heard GiftedBooks this hour, speak the locked backup: Ylogx SQL RAG +65% analysis productivity, still behind three-tier RLS — a full second story, not a fourth Ylogx primary.

If they already heard GiftedBooks

Situation. At Ylogx I was a software developer intern, November 2024 to October 2025. Operators who were not SQL users still needed warehouse facts. Pasting rows into a prompt truncated data and invented totals. A chatbot that returned numbers without isolation would have served the wrong customer: another organization’s rows.

Task. I needed non-technical people to ask in English and get inspectable SQL and results, without one organizational tier reading another.

Action. Natural-language questions hit FastAPI LangChain SQL RAG with the caller’s identity and organizational tier, constrained to SQL only over allow-listed schema. The query executed read-only as the caller’s database role so row-level security still filtered a JOIN that was too broad, and I returned the SQL with the result so a human could see grain. Repeat schema and hot answers used Redis only with tier and role in the key, so a cache hit was still that customer’s answer. I discarded dumping ninety days of rows into the model, and I discarded generated SQL on a table-owner connection.

Result. SQL RAG improved analysis productivity 65 percent. Isolation stayed three-tier RLS in Postgres. That 65 percent is analysis productivity for those users, not model accuracy.

Ownership — Ylogx RLS

On this resume ownership is isolation on the path the bot and reports already shared. The intern ticket was a chatbot and a report builder. App-only filters were still not done.

What they might ask

IE-asked leftover hours (LC 6806195 beyond task; LC 8362604 identified myself; IE.in 2024-grad). Resume-derived Ylogx three-tier RLS + RBAC, 99.9% uptime, 40% faster reports. Other loop, not a forecast for Job 10454435.

What you say

Situation. At Ylogx I interned on a full-stack AI BI product: FastAPI and NestJS over Postgres, React dashboards, and a LangChain SQL RAG chatbot. The bot returned rows in a demo. Application-only organization checks would still have allowed a generated JOIN to cross a tier. A green demo was incomplete and unsafe.

Task. I was not a named security team. I still owned correctness for three organizational tiers on the shared bot and reporting path. Done was not “SQL appears.” Done was rows that belong to the caller, on a path operators would keep using.

Action. Three mechanisms, then the option I discarded.

  1. I put row-level security and RBAC into Postgres so generated SQL ran as the caller’s non-owner database role. A legal JOIN still lost the other organization’s rows at the database.
  2. I mapped identity to three organizational tiers — org, team, and user-shaped levels — on both the chatbot path and the report builder, so isolation was not a React hide.
  3. I kept that same role mapping in the CloudFront, ALB, ECS, Docker serving path rather than protecting only a local demo, and I held the product at 99.9 percent uptime on that path.

I discarded app-only WHERE org_id = ?, NestJS middleware alone, and trusting the model to remember the tenant predicate.

Result. Three-tier isolation sat in the database. The product held 99.9 percent uptime. Report generation was 40 percent faster on the same identity-to-role path.

They might ask next

If they askYou answer
What did you implement?Postgres RLS policies, RBAC, identity-to-role mapping on bot and reports, generated SQL as the caller’s database role.
Why the database, not the UI?Every generated query reaches Postgres. The UI never sees some JOINs. HTTP 200 with a legal JOIN is still a leak.
Why three tiers, not one admin boolean?Row filters and route-level RBAC answer different questions: which rows, versus whether the caller may hit an admin export. Literal tier names are not on the resume — org / team / user-shaped levels.
How do you know 99.9%?Resume serving number on ECS, ALB, CloudFront, CI/CD. No missed month, ticket ID, or monitoring-board name on the PDF.
What about 40% reports?Custom report builder on the same Postgres identity path. Mechanism plus the resume number. No sample size on the PDF.
What did you not own?AWS account owner, Kafka, EKS. Kubernetes is on the skills line; this intern product is ECS + Docker.
What would you add next?Denied cross-tier fixtures from day one, including a JOIN through a mapping table.

Keep straight

Tighten

Stop after isolation and 99.9% (40% reports if they are still on the same path). If they already heard Ylogx this hour, speak the locked backup: Horizon GStreamer 60 FPS + costmap as ship-blockers beyond a camera demo.

If they already heard Ylogx

Situation. On Horizon I was core software, February to June 2024, not a narrowly titled webcam owner. A lab stream could satisfy a camera demo. ERC required an operator feed and occupancy the planner could trust. A healthy video with a stale costmap is two systems, one of them failing.

Task. I needed to own the software ship-blockers even when they crossed a camera ticket: live video, dense mapping, and a costmap in front of the actuators.

Action. I shipped a GStreamer camera pipeline at 60 FPS so the operator saw the newest frame instead of a stalled historical stream. I moved ZED 2 mapping at more than two million points per second into the local costmap, and I downsampled a separate branch for RViz so visualization did not starve planning. I put fusion and predictive planning on that costmap, and I treated stale occupancy while the feed looked live as the blocker I had to close. I discarded stopping at a camera demo, and I discarded buying another sensor as the first fix near a date that did not move.

Result. We placed 17th of more than eighty teams. Obstacle detection improved 40 percent and collision risk fell 55 percent. I owned the software path, not mechanical or electrical work.

Invent and Simplify — IQVIA Hybrid RAG

On this resume invention is hybrid plus graph plus a citation gate on 200+ page BRDs. Simplification is fewer untraceable steps: cite or abstain, traced tests — not a thinner demo.

What they might ask

IE-asked leftover hours (LC 8362604 challenge / simplifying; LC 7563011 POCs; GFG April 2026 HM significant technical challenge — page heading “Common Questions”). Resume-derived IQVIA Hybrid RAG: Azure AI Search Hybrid + Semantic, GraphDB, LangGraph adaptive retrieval, LangSmith tests, 200+ page BRDs. Other loop, not a forecast for Job 10454435.

What you say

Situation. I am a software developer intern at IQVIA in Kochi, April 2026 to present. Analysts had to live inside more-than-two-hundred-page BRDs. Stuffing a PDF into a context window spends tokens and cites the wrong annex with a straight face. A vector-only demo is fast and still misses exact clause IDs. “What breaks if this requirement changes” is a dependency edge, not a cosine neighbor.

Task. I needed retrieval a human could audit: recover the exact requirement, hop dependents, generate test cases that fail when the span is missing. Simplification meant less untraceable work.

Action. Three mechanisms, then the option I discarded.

  1. I ingested each BRD once, chunked by headings, requirement IDs, and table boundaries, and I indexed lexical fields and vectors in Azure AI Search. One hybrid query ran keyword alongside vector; Azure’s semantic ranker reordered for meaning.
  2. When the question was identifier, impact, or depends-on, I took a bounded GraphDB hop — one or two hops with a visited set — then fetched neighbor text from the search index. GraphDB answered structure. Azure answered citeable prose. That hop is not LangGraph.
  3. LangGraph adaptive retrieval chose lexical versus semantic versus hop so the writer saw a small evidence set. Cite-or-abstain: no supporting span, no sentence. LangSmith gold items carried expected citation IDs; test-case generation was itself a traced job.

I discarded vector-only, keyword-only, stuffing the 200+ pages, and raising vector top-k instead of a graph hop.

Result. The path processed more-than-two-hundred-page BRDs with traces, evals, and generated tests. No extra IQVIA percentage.

They might ask next

If they askYou answer
What did you implement?Structure-aware chunking, Azure hybrid query plus semantic ranker, bounded GraphDB hop, LangGraph mode choice, cite-or-abstain, traced test-case generation.
Why hybrid, not vector-only?Clause IDs are lexical. Paraphrased policy is semantic. Either alone is a hole. Similar embeddings are not requirement coverage.
Why GraphDB, not more chunks?Dependency is an edge. Neighbors of a cosine hit are not dependents. Bound the hop. Do not load an entire connected component into the prompt.
GraphDB versus LangGraph?GraphDB stores requirement dependency. LangGraph is workflow state for the agent.
How do you know it works?200+ page BRDs, traces, test-case generation. No nDCG, gold-set size, or IQVIA latency SLA on the resume.
What did you not own?Building Azure AI Search itself. No named Neo4j cluster on the intern bullet — speak GraphDB.
What would you add next?Freeze gold questions with expected citation IDs before adding another retrieval mode.

Keep straight

Tighten

Stop after 200+ page BRDs with traces and tests. If they already heard IQVIA Hybrid RAG, speak the locked backup: StratifyLabs −30% ML iteration + marketplace 50+. Deep Research is Learn, not a second Invent trophy.

If they already heard IQVIA Hybrid RAG

Situation. Computer-vision prototyping was trapped in one notebook, one GPU queue, and one person. Every small experiment became environment setup. A one-model demo disappeared with its author. StratifyLabs needed to be a reusable lab, not a Colab.

Task. I wanted edit, infer, and inspect to happen in the browser, and I wanted pretrained starting points to be catalog items other people could reuse.

Action. I built a shared 3D simulation lab with a URDF editor and WebGL so scene structure was visible in the tab. I ran suitable small models as browser inference on that interactive path, and I kept large training off the click. I shipped a marketplace of more than fifty pretrained models and datasets with community profiles, and I gave Gemini RAG voice characters the current scene and URDF context rather than last week’s chat. I discarded a full training box per user, and I discarded treating a field ROS2/Gazebo stack as this browser product.

Result. ML iteration time fell 30 percent. The marketplace held more than fifty models and datasets. That 30 percent is iteration time, not frame rate.

Are Right, A Lot — Argus 73→89

On this resume “right” is a held-out mAP you would alert a human on. Seventy-three percent missed helmets and also fired junk boxes. That number is the feedback. There is no manager quote on the resume.

What they might ask

IE-asked leftover hours (GFG 2025 last negative feedback; LC 6806195 got feedback; Rudraksh mistake). Resume-derived Argus YOLOv9 73% → 89% mAP on 15,000+ images, 24 FPS. Other loop, not a forecast for Job 10454435.

What you say

Situation. Argus is industrial computer vision for PPE and attendance. A detector can look promising in a notebook and be wrong on a floor. At 73 percent mAP the model missed helmets and also proposed junk boxes. Either one trains people to ignore the alert. That number is not a page-the-floor number.

Task. I had to drop the comfortable belief that a rising training curve was enough. Right meant a held-out mAP I could alert a human on, at a frame rate the live stream could support, with events that could be audited.

Action. Three mechanisms, then the option I discarded.

  1. I treated 73 percent mAP as unshippable for alerts. I inspected error classes — lighting, PPE variation, rare no-helmet — on more than 15,000 images, and I iterated YOLOv9 until held-out mAP reached 89 percent.
  2. I kept non-maximum suppression on the boxes and measured end-to-end 24 FPS: decode, infer, NMS, I/O, not notebook forward-milliseconds only.
  3. I wrote structured events — camera, class, confidence, time, box — to Postgres, not video blobs, and I scaled to more than twenty containerized feeds only after both bars held.

I discarded shipping the 73 percent demo, hiding behind a confidence tweak, and putting a heavier backbone on the stream that would miss 24 FPS. An LLM caption is not an IoU-gated box.

Result. The detector moved from 73 to 89 percent mAP at 24 FPS on more than 15,000 images, then supported more than twenty cameras. After alerts existed, site violations were down 50 percent and compliance doubled. Those last two are operational outcomes after the gate, not another name for mAP.

They might ask next

If they askYou answer
What did you implement?Train/eval loop on 15k+ images, mAP gate, NMS, end-to-end 24 FPS, Postgres event schema. Scale after the gate.
Why was 73% wrong?Missed helmets are silent. Junk boxes are loud. Both produce alarm fatigue. I treated a rising notebook score as launch-ready. That was the judgment failure, past tense.
Why YOLOv9, not a two-stage detector?Live industrial budget. A heavier two-stage path risked 24 FPS on many streams. OpenCV decoded and resized — preprocessing, not the detector.
How do you know the numbers?Resume: 73→89, 15k+, 24 FPS, 20+, −50%, 2×. No precision-recall table, split ratio, 95% mAP, or higher-up quote on the PDF.
mAP versus −50%?mAP is held-out box quality. −50% violations and 2× compliance are what happened on site after humans acted on alerts. We for those site outcomes. I for the detector and gate.
What did you not own?Plant headcount, a named GPU, ByteTrack, YOLOv8-as-Argus. Public API README is unavailable — no invented routes.
What would you add next?Hold out a camera or site earlier, labeled as future work. Per-camera error budget is also future work.

Keep straight

Tighten

Stop after 89% mAP at 24 FPS (site −50% / 2× only if they ask what happened after alerts). If they already heard Argus 73% this hour, speak the locked backup: Ylogx measured bot-DB −35% versus “the model is slow.”

If they already heard Argus

Situation. At Ylogx the SQL RAG chatbot paused, so instinct said the generator was slow. The demo still returned rows. Every natural-language turn was reaching Postgres. Blaming the model was the anecdote. The database path was the measurement.

Task. I needed to disconfirm “the model is thinking” and find which layer owned latency.

Action. I measured bot database latency around the query path instead of rewriting the prompt first. I put Redis cache-aside on repeat questions and schema metadata, with organizational tier in the key, and I kept RLS on every miss. I returned inspectable SQL so wrong grain was visible even when tenant isolation was correct. I discarded prompt-tuning as the first fix, and I discarded a larger RDS as the first fix.

Result. Bot database latency fell 35 percent. The belief that changed was “the model is slow” versus a measured database path.

Learn and Be Curious — IQVIA LangGraph

On this resume curiosity is Deep Research with a stop condition. Tutorial-complete is not architecture. Traces show whether the ranker, an empty scrape, or the writer failed.

What they might ask

IE-asked leftover hours (GFG 2025 learnt something that wasn’t required; LC 7850431 didn’t know what to do next; LC 7623949 Learn by name). Resume-derived IQVIA LangGraph Deep Research across 200+ websites, LangSmith. Other loop, not a forecast for Job 10454435.

What you say

Situation. I am a software developer intern at IQVIA in Kochi, April 2026 to present. Analysts needed research across the open web, not a single scraper and a fluent paragraph. Calling an LLM from FastAPI was already a skill. Stateful multi-agent research, ranking across more than two hundred sites, and a writer who must not treat an empty scrape as a fact were not.

Task. I needed to rank research across more than two hundred websites without inventing page contents. Curiosity needed a stop: traces that showed whether the ranker, an empty scrape, or the writer failed.

Action. Three mechanisms, then the option I discarded.

  1. I learned LangGraph typed state, reducers that append surviving documents, and checkpoints so a dead Playwright branch did not erase Bing and so one failed domain could resume.
  2. I learned a planner plus parallel tools — Firecrawl, Bing, DuckDuckGo, Google Playwright — then a ranker on quality, recency, and agreement, including rejecting empty or boilerplate pages and not counting syndicated mirrors as extra votes.
  3. I learned LangSmith traces as the stop: node order visible, empty scrape reaching the writer visible, writer synthesizing only from ranked retained evidence, iteration cap on citation hops.

I discarded a linear plan-scrape-write chain, a homegrown loop with one mutable dictionary, and one scraper or one search API as “research.”

Result. Research ranked across more than two hundred websites, with traces. No extra IQVIA percentage. No hour count on the resume.

They might ask next

If they askYou answer
What did you implement?Planner node, parallel tool fan-out, append reducers, checkpoints, agreement ranker, citation-gated writer, LangSmith traces.
Why LangGraph, not a linear chain?Parallel tools fail independently. A linear chain loses Bing when Playwright times out. Checkpointed state is the learning that mattered.
Didn’t know what to do next?Options I considered: one scraper versus parallel tools; linear chain versus graph; stuffing versus retrieve-and-cite. Traces picked the stop.
How much time?No hour count on the resume. Speak the mechanism.
How do you know ranking worked?Coverage across 200+ sites and a ranker that uses agreement, not first-hit confidence. Two high-ranked pages can contradict. No nDCG on the PDF.
What did you not own?I did not invent LangGraph. I did not shard a research index.
What would you add next?Freeze gold questions with expected citations before adding a fifth tool. Cache completed scrapes sooner.

Keep straight

Tighten

Stop after 200+ sites with traces. If they already heard IQVIA Deep Research — or Invent+Learn+Backbone already used IQVIA this hour — speak the locked backup: Horizon ROS2 + GStreamer + ZED 2.

If they already heard IQVIA Deep Research

Situation. From February to June 2024 I was core software on Team Horizon. ERC required ROS2, GStreamer timing, ZED 2 point clouds, RViz, Gazebo, and costmap planning. Gazebo lighting was not dirt.

Task. I needed to learn enough, before an immovable ERC date, for the operator to see 60 FPS and for the planner to trust current occupancy.

Action. I learned GStreamer source, convert, encode, and UDP-family send so live video preferred the current frame over perfect historical delivery. I learned ZED 2 mapping at more than two million points per second into the rover frame with timestamps, keeping density for the local costmap and downsampling visualization. I learned to compare pipeline, callback, and sensor clocks in the field, because a visually live feed can mask stale occupancy. I discarded MJPEG over TCP as the live operator path, and I discarded simulation-only sign-off.

Result. We placed 17th of more than eighty. The resume reports 60 FPS, 2M+ points per second, 40 percent better obstacle detection, and 55 percent lower collision risk. Learning stopped when the planner saw a live grid, not when Gazebo looked pretty.

Hire and Develop the Best — IEDC member

On this resume you were a Tech Team member, not a hiring manager. The bar is that another laptop can run the build. There is no mentee count on the PDF.

What they might ask

IE-asked as helping-juniors / teammates elsewhere (Bhavya R2 teammates). Resume-derived IEDC CUSAT Tech Team; eight hackathons (CodeRecet 1st, MLH Best Project, Magnathon 2.0 runner-up). Other loop, not a forecast for Job 10454435.

What you say

Situation. I was on the Tech Team at IEDC CUSAT while studying CSE, CGPA 8.42. Club and hackathon stacks were not shared. If only one laptop could run the build, the next event stopped when that person moved. I did not hire anyone. I was a member.

Task. I wanted the next person to run the build and own the risky module rather than depend on my machine. The bar was independent ability.

Action. Three mechanisms, then the option I discarded.

  1. I shared environment setup, the failures we had already hit, and review on the module that actually broke, not a generic onboarding slide.
  2. I paired on the risky path until another laptop could reproduce the build, then I stepped back.
  3. Across eight national and regional hackathons I used the same habit: rapid software and a deploy someone else could repeat, rather than a hero demo on my machine.

I discarded hoarding a working setup on one laptop.

Result. Tech Team membership, eight hackathons, first at CodeRecet, MLH Best Project, Magnathon 2.0 runner-up. CGPA 8.42 is education, not a coaching metric. I have no mentee count.

They might ask next

If they askYou answer
What did you implement?Shared setup, review on the module that broke, pairing until another laptop reproduced the build.
Why pairing, not tickets?I was not a manager. Pairing until launch works is observable. Invented tickets would misstate the role.
How do you measure this at intern scope?Named event outcomes and “someone else can run it.” Not a retention percent.
What did you not own?Hire, fire, ratings, a recruiting loop, a mentee headcount. Team prizes are we when they were team events.
What would you add next?A short runbook earlier. The resume does not claim a wiki already existed.

Keep straight

Tighten

Stop after “someone else can run it” and the named events. If they already heard IEDC, speak the locked backup: Horizon pairing until someone else can launch GStreamer / costmap.

If they already heard IEDC

Situation. On Horizon, camera, mapping, and launch knowledge could live in one head. ERC placement was a team score. If only I knew GStreamer topic names and launch order, integration stopped when I moved to mapping.

Task. Perception and planning had to be launchable by someone else before the event, not trapped in my shell history.

Action. I paired on launch files until another person could start the camera node and confirm the expected topics. I shared ZED rate versus visualization constraints so a pretty cloud did not get mistaken for planner input. I stayed on the costmap integration until a teammate could connect occupancy to planning without copying a hidden environment from my laptop. I discarded hero ownership of the working rover bring-up.

Result. We placed 17th of more than eighty. The useful Hire-shaped result is that launch order left one head. Placement remains we.

Insist on the Highest Standards — Argus 89% + 24 FPS

On this resume the standard is a gate that stayed fixed: held-out mAP, live FPS, and an auditable event. Cameras after the gate, not instead of it. Are Right was the changed belief. This card is the refused defect.

What they might ask

Resume-derived Argus 15k+ images, 73→89% mAP, 24 FPS, then 20+ cameras, Postgres events. Same intern as Are Right, different beat. Other loop, not a forecast for Job 10454435.

What you say

Situation. Argus sits on an industrial safety path. Seventy-three percent mAP is not a standard I would use to notify a floor. Alarm fatigue is the cost of a low bar. A model that is accurate in a notebook and too slow on live video is also below the bar.

Task. I needed a gate that stayed fixed: held-out quality, live throughput, and an auditable event. Cameras after the gate, not instead of it.

Action. Three mechanisms, then the option I discarded.

  1. I required both 89 percent mAP and 24 FPS. Either miss blocked scale.
  2. I kept NMS on detections and wrote accepted events to Postgres so “camera 7, Tuesday 18:04, no-helmet” was queryable. Bulk video stayed out of the table.
  3. I refused to attach more than twenty feeds to the 73 percent model to look like progress.

I discarded shipping at 73 percent, and I discarded treating notebook mAP as the production standard.

Result. After the gate, the path supported more than twenty cameras. Site violations were down 50 percent and compliance doubled after alerts existed. The standard was mAP plus FPS plus logs.

They might ask next

If they askYou answer
What did you implement?Dual gate (89% mAP and 24 FPS), NMS, Postgres events not video blobs, scale only after both bars held.
Why both mAP and FPS?A late correct box is still a missed intervention. A fast junk box is still alarm fatigue.
Why events, not MP4 in Postgres?Backups should not carry media. Operators query metadata. Video blobs are load without the same audit shape.
Is this the same as Are Right?Same intern, different question. Belief change versus refused defect. If they already heard 73%, stay on follow-ups or use the Ylogx dashboard backup — do not restart the paragraph.
How do you know?Same Argus resume family. No second eval set and no missed SLA on the PDF.
What would you add next?Publish concrete fail cases and hold out a camera earlier, labeled would-add.

Keep straight

Tighten

Stop after the gate (mAP + FPS + logs), then cameras. If they already heard Argus this hour, speak the locked backup: Ylogx 99.9% / sub-210 ms dashboards, no LLM on that GET.

If they already heard Argus

Situation. Ylogx had thirty KPI dashboards operators used during the day. Putting a generator on those GETs would have made every tile wait on a model, invent KPIs, and couple availability to a vendor. Sub-210 milliseconds would have died.

Task. I needed a serving standard: deterministic numbers, held uptime, no fluent lie on the hot path.

Action. Dashboard GETs went NestJS identity and RBAC, then pooled Postgres with RLS, returning numbers and labels — not generated prose. The browser loaded JS from CloudFront; private tenant JSON was not an edge-cache object. Ad-hoc English stayed on the separate SQL RAG path. The thirty tiles never called the model. I discarded one model call per KPI tile.

Result. Dashboards stayed sub-210 milliseconds. Uptime held at 99.9 percent. Thirty tiles improved operations 60 percent.

Think Big — StratifyLabs

On this resume thinking big is a reusable CV lab and a catalog, not one impressive notebook. −30% is ML iteration time. 50+ is marketplace items, not GPUs.

What they might ask

IE-asked as theme (Sarvesh idea for major project). Resume-derived StratifyLabs: 3D lab, browser inference −30%, marketplace 50+, URDF/WebGL, Gemini scene bots. Other loop, not a forecast for Job 10454435.

What you say

Situation. Computer-vision work often dies in one GPU, one notebook, one model, and one person. Every experiment becomes machine setup. StratifyLabs needed to be a CV SaaS and a 3D lab, not a one-off demo that vanished with its author.

Task. Experiment, share, and reuse had to become the default. Someone who was not a ROS expert should still load a URDF and try a model in a browser.

Action. Three mechanisms, then the option I discarded.

  1. I built a shared 3D lab: URDF edits change the scene, WebGL renders the current structure in the tab.
  2. I put suitable small-model inference in the browser so the edit-infer-inspect loop did not wait on a lab machine, and I kept large training off that interactive request.
  3. I shipped a marketplace of more than fifty pretrained models and datasets with community profiles, and I grounded Gemini voice characters in the current scene and URDF rather than a disconnected chat panel.

I discarded a Colab-per-person default, and I discarded treating 50+ catalog items as 50 GPUs.

Result. ML iteration time fell 30 percent. The marketplace contained more than fifty models and datasets.

They might ask next

If they askYou answer
What did you implement?3D sim lab, URDF editor, WebGL render, browser inference for small models, marketplace catalog, scene-conditioned Gemini bots.
Why browser inference?The bottleneck was environment setup, not another native simulator. Field ROS2/Gazebo is a different product and a different entry cost.
Is −30% a frame rate?No. Iteration time. Argus 24 FPS and Horizon 60 FPS are other products.
What did Gemini do?Explain current scene context after deterministic scene state is fixed. It must not mutate the URDF or hallucinate objects that are not there.
How do you know?Resume −30% and 50+. Mechanism; no user n on the PDF. The GitHub README is default Next.js — resume features win.
What did you not own?A GPU farm, LangSmith on this bullet, Ylogx-style three-tier RLS as this product’s evidence.
What would you add next?Clearer catalog-versus-fine-tune boundary. A current-scene eval for the bots as future work.

Keep straight

Tighten

Stop after −30% and 50+. If they already heard StratifyLabs (including as Invent backup), speak the locked backup: IQVIA 200+ sites, framed as coverage scale, not as a second Invent card.

If they already heard StratifyLabs

Situation. Analysts could not treat the first web result as truth. One scraper missed families of pages. First-hit ranking looked confident when two credible pages contradicted. Research needed coverage across a large web, not a single gold URL.

Task. I needed a research path that ranked more than two hundred websites with agreement, not a bigger prompt.

Action. A planner wrote a search plan into LangGraph state, then tools fanned out in parallel across independent indexes and a browser path. Reducers appended surviving documents so one dead branch did not wipe the run; a ranker scored quality, recency, and agreement and rejected boilerplate and mirrors. The writer synthesized only from ranked retained evidence, or abstained, with an iteration cap on citation hops. I discarded one Google path as research, and I discarded treating a fluent paragraph as confirmation.

Result. Research ranked across more than two hundred websites.

Bias for Action — Horizon ERC date

On this resume speed is fusion on the sensors we had before an immovable ERC date. Collision is not a reversible decision, so skipping the costmap is not action. The resume has no missed ERC.

What they might ask

IE-asked leftover hours (LC 7724048 strict deadline; LC 8362604 missing a deadline; IE.in 2024-grad urgent/trade-off). Resume-derived Horizon Feb–Jun 2024, ERC 2024, 17th / 80+, 60 FPS, +40% obstacle, −55% collision. Other loop, not a forecast for Job 10454435.

What you say

Situation. From February to June 2024 I worked core software for Team Horizon’s semi-autonomous Mars rover for ERC 2024. More than eighty teams. The event date did not move. Waiting for a perfect lab or another sensor as the first response would have put the useful software after the event. A live video feed is not a costmap.

Task. Perception, mapping, and planning had to run on the hardware we had. Speed without a live occupancy grid would have been reckless, because collision is not a reversible decision.

Action. Three mechanisms, then the option I discarded.

  1. I shipped a GStreamer camera pipeline at 60 FPS — newest frame, UDP-family drop-over-stall — instead of a naive MJPEG stream that stalls later bytes.
  2. I moved ZED 2 mapping at more than two million points per second into the local costmap, downsampled visualization, and kept density for planning.
  3. I put fusion and predictive planning in front of the actuators, and I used field time because Gazebo lighting is not dirt. When occupancy lagged a healthy feed, that was the ship-blocker I named.

I discarded waiting for extra rover hardware as the first fix, and I discarded polishing simulation until the date passed.

Result. We placed 17th globally of more than eighty teams. Obstacle detection improved 40 percent. Collision risk fell 55 percent. The date was met.

They might ask next

If they askYou answer
What did you implement?GStreamer 60 FPS pipeline, ZED 2 mapping into the local costmap, fusion and predictive planning, field time-sync between feed and occupancy.
Why fusion, not another sensor first?Near a fixed date, extra hardware adds drivers, calibration, and integration delay while time alignment and planning stay unsolved. Fusion uses sensors we had.
Did you miss the deadline?I do not have a missed ERC. Communication if a ship-blocker is late is early and specific: the feed is late, or the costmap is stale. Then extra hardware is the cut. The run still happened.
60 FPS versus planning?The operator can see 60 FPS while the planner reads old rocks. Action meant closing both clocks.
How do you know?17th/80+, 60 FPS, 2M+ pts/s, +40%, −55%. Mechanism plus resume numbers. No sample size on the percentages. Placement is we.
What did you not own?Chassis, mechanical, electrical. Team-lead title. 17th as a solo result.
What would you add next?Name the ship-blocker in week one. Time-box sensor versus fusion against collision risk.

Keep straight

Tighten

Stop after 17th / 80+ and the date was met. If they already heard Horizon this hour, speak the locked backup: eight named hackathons (CodeRecet 1st, MLH Best Project, Magnathon 2.0 runner-up).

If they already heard Horizon

Situation. Across eight national and regional hackathons the clock was the weekend, not a semester. Stacks were unfamiliar. Waiting for a perfect architecture would have meant no demo and no deploy.

Task. I needed working software on the event clock, and a deploy someone else could run, not a slide.

Action. I picked the smallest path that produced a real artifact — running software, not a deck — in the first hours. I paired on the risky module so the deploy was not trapped on one laptop. I shipped production-shaped deployment for the demo path we had, rather than rewriting the stack mid-event. I discarded over-planning the architecture until the submission window closed.

Result. First at CodeRecet, MLH Best Project, Magnathon 2.0 runner-up, across eight events. Those are event outcomes, not Argus mAP and not ERC 17th.

Frugality — Ylogx Redis −35%

On this resume frugality is Redis on repeat NL and schema lookups instead of a larger RDS first. Isolation still has to hold. There is no AWS bill on the resume.

What they might ask

IE-asked as theme (LC 7981646 Innovate/Frugality architecture). Resume-derived Ylogx Redis −35% bot database latency; CloudFront / ECS / Docker / ALB / Route 53. Other loop, not a forecast for Job 10454435.

What you say

Situation. At Ylogx I interned on BI and SQL RAG over Postgres. Every natural-language turn that hit the database was latency and load. Repeat questions and schema lookups are not proof the instance is undersized. The obvious spend was a larger RDS.

Task. I needed to cut hot-path database work without weakening three-tier isolation, and without moving dashboard tiles onto a model.

Action. Three mechanisms, then the option I discarded.

  1. I measured bot database latency instead of buying headroom first.
  2. I put Redis cache-aside on repeat answers and schema metadata, with organizational tier and role in the key, so a cross-tier hit could not be celebrated as a latency win.
  3. On a miss, SQL still ran as the caller role with RLS. If Redis was down, Postgres as that role, never table-owner, never fail-open isolation. CloudFront served static assets only — private tenant JSON was not an edge object.

I discarded a larger RDS as the first move, Redis keys from raw English only, and Redis as source of record.

Result. Bot database latency fell 35 percent. Isolation stayed in Postgres. Uptime held at 99.9 percent on the existing ECS path rather than an oversized snowflake host.

They might ask next

If they askYou answer
What did you implement?Measure bot-DB latency, Redis cache-aside, tier and role in the key, RLS on miss, Redis-down fallback as caller role.
Why Redis, not a bigger RDS?Repeats and schema lookups are cache-shaped. Instance size does not fix the same English asked twice.
Why still RLS after cache?A cached answer for the wrong organization is still a leak. Key = tier, role, query fingerprint, schema version.
Why not CloudFront for answers?Private tenant JSON is not a public asset. CloudFront is static JS.
How do you know −35%?Resume bot-DB family. Not dashboard sub-210 ms. No p95, TTL, instance class, or bill on the PDF.
What did you not own?Corporate cloud finance. Kubernetes as this intern’s production path — Ylogx is ECS + Docker.
What would you add next?Write invalidation rules next to RLS from day one. Test cross-tier cache denial as a fixture.

Keep straight

Tighten

Stop after −35% with isolation still on. If they already heard Ylogx Redis this hour, speak the locked backup: Horizon fusion versus extra hardware.

If they already heard Ylogx

Situation. On Horizon, the expensive-looking answer near ERC was another sensor. Extra hardware meant drivers, calibration, and integration delay. Time alignment and planning would still have been unsolved. We already had cameras and a ZED 2.

Task. I needed occupancy the planner could trust without waiting on a purchase that would not land in time.

Action. I fused onboard sensing we already had into occupied, free, and uncertain costmap cells with timestamps in a shared frame. I kept dense points for local planning and downsampled visualization so we did not spend link and compute on a pretty cloud the planner did not use. I put predictive planning on that fused grid rather than on raw pixels or a hoped-for extra device. I discarded extra rover hardware as the first fix, and I discarded a giant vision model as a substitute for fusion.

Result. Collision risk fell 55 percent. Obstacle detection improved 40 percent. We placed 17th of more than eighty. The scarce resource was the calendar, not another device on order.

Earn Trust — GiftedBooks + 99.5%

On this resume Earn Trust is saying the VR lab was not enough, shipping grounded isolated Q&A, and disclosing the GitHub README mismatch if they open the repo. Customer Obsession already used the 3–10 minute outcome. Here the beat is honesty.

What they might ask

IE-asked as an LP name (LC 7623949 Earn Trust; LC 7035289 not good at). Resume-derived GiftedBooks grounded PDF Q&A, sub-300 ms, 99.5% uptime, hours → 3–10 min. Other loop, not a forecast for Job 10454435.

What you say

Situation. GiftedBooks had VR labs, avatars, and PDFs. A polished lab that could not answer from the student’s own material was decoration. A generic chatbot with a confident textbook voice was not a teaching assistant. That was awkward to say because the visible surface looked impressive. The current GitHub README describes AegisAI. That is not the resume product.

Task. I needed to name those trust failures before dressing them up, then ship grounded, isolated, available help, and be honest if someone opened the repo.

Action. Three mechanisms, then the option I discarded.

  1. I said the VR surface was not enough. I shipped contextual Q&A over that user’s PDF, with per-user document metadata so another student’s notes never retrieve.
  2. I abstained when no source span existed, kept generation bounded for sub-300 milliseconds, and held 99.5 percent uptime as hosting, not as model intelligence.
  3. I disclose that the current GitHub README describes AegisAI, and that GiftedBooks on the Aug 2026 resume is the product I speak. I would fix the README.

I discarded treating the VR surface or a generic model as sufficient, and I discarded answering off-PDF to satisfy the request.

Result. Doubt time moved from hours to three to ten minutes, with +35% reading, +50% engagement, 2.5× comprehension, and 99.5% uptime.

They might ask next

If they askYou answer
What did you implement?User-scoped RAG, generate-or-abstain, bounded generate for sub-300 ms, hosting path that held 99.5%.
Why abstain?A fluent off-PDF answer becomes a false fact the student memorizes. Trust is span or silence.
Why disclose AegisAI here?Customer is the user outcome. Earn Trust is vocal self-criticism. One sentence, no AegisAI features. If they did not open GitHub and this is Customer, leave the README off the spoken STAR.
Something you are not good at?I have fewer production Java hours than intern Python, TypeScript, and ROS2 hours. Live Code is Java. Internships were not JVM. I close the gap in this loop’s editor. That is not a project primary.
How do you know 99.5%?GiftedBooks hosting number. Distinct from Ylogx 99.9%.
What did you not own?LangSmith on this bullet. Every avatar asset.
What would you add next?Citation-grounding eval, labeled future work, not a shipped LangSmith claim.

Keep straight

Tighten

Stop after honesty plus 99.5% / 3–10 min. If they already heard GiftedBooks (including as Customer), speak the locked backup: Ylogx 3-tier RLS, JOIN-leak class named out loud.

If they already heard GiftedBooks

Situation. At Ylogx the chatbot returned SQL and rows. Saying “it works” would have hidden a class of failure: a JOIN can be legal SQL and still return another organization’s rows if isolation lives only in the application.

Task. I needed to name that leak class out loud, including when the demo account looked clean, and put the control where every query actually ran.

Action. I stated the failure mode in the working path: generated JOIN, mapping table, HTTP 200, wrong tenant. I put RLS and RBAC for three tiers in Postgres and ran generated SQL as the caller’s database role so the denied row is a fixture, not a speech. I kept cache keys tier-scoped so a later Redis hit could not launder a wrong-org answer into a latency win. I discarded app-only filters and “the UI hides that org” as the control.

Result. Isolation sat in the database. Uptime held at 99.9 percent. The trust mechanism is the named JOIN-leak class plus RLS, not a dramatic conversation.

Dive Deep — Ylogx Redis and RLS

On this resume Dive Deep is anecdote versus metric on the same path: the demo returned rows; every NL turn still hit Postgres; app-only isolation is a JOIN leak. Lead is Redis and RLS together, not a search-console ticket.

What they might ask

IE-asked leftover hours (GFG 2025 deep dive a bug; LC 6806195 critical issues; LC 7850431 deep dive). Resume-derived Ylogx Redis −35% bot DB + three-tier RLS + 99.9%. Other loop, not a forecast for Job 10454435.

What you say

Situation. At Ylogx I was a software intern from November 2024 to October 2025. The SQL RAG chatbot returned SQL and rows, so a happy-path demo said the product worked. Two facts disagreed with that anecdote. Every natural-language turn still hit Postgres, so latency felt like the model thinking. And if isolation lived only in the application, a generated JOIN could return another organization’s rows. The same confident response could be slow, wrong-grained, or leaked.

Task. I had to separate query shape, missing cache, and security in the wrong layer, and make three organizational tiers real where SQL actually ran. Measuring the database path was not beneath the intern ticket.

Action. Three mechanisms, then the option I discarded.

  1. I measured bot database latency around the query, rather than rewriting the prompt first.
  2. I put RLS and RBAC into Postgres so generated SQL ran as the caller’s database role. A syntactically valid JOIN still lost unauthorized rows.
  3. I added Redis cache-aside for repeat questions and schema lookups with tier and role in the key, and I cached only the allowed payload. Redis down meant Postgres as that role, never fail-open RLS. Showing the generated SQL made wrong grain visible even when the tenant was correct.

I discarded prompt rewriting as the first fix, a larger database as the first fix, and app-only organization checks as the isolation story.

Result. Bot database latency fell 35 percent. Three-tier isolation sat in Postgres. Uptime held at 99.9 percent. The deep dive was latency plus isolation on the same path.

They might ask next

If they askYou answer
What did you implement?Bot-DB latency measurement, Postgres RLS + RBAC, generated SQL as caller role, Redis cache-aside with tier in the key, inspectable SQL.
Why measure the database, not the generator?The pause was a round trip. A timer on the query path changed the diagnosis.
Why Redis and RLS together?Cache without tier shares “top SKU” across organizations. RLS without cache leaves every turn on Postgres. Either alone is an incomplete dive.
What was the bug class?Wrong-org JOIN through a mapping table; every NL turn hitting Postgres; cache key missing tier. No ticket ID on the resume.
How do you know −35%?Resume bot-DB family. Not dashboard sub-210 ms. No p95. No TTL.
What did you not own?DBA-manager title. A named production incident. Search-console work is not this story.
What would you add next?Denied-tier tests and cache-isolation fixtures from day one. Invalidation rules beside RLS.

Keep straight

Tighten

Stop after −35% plus three tiers. If they already heard Ylogx Redis and RLS this hour, speak the locked backup: IQVIA ranking contradiction / exact-span retrieval. Stay on that path for “what would you do differently” — do not mint a new intern to fill the probe.

If they already heard Ylogx Redis and RLS

Situation. On two-hundred-page BRDs, a vector demo returned a similar paragraph and looked successful. At the detail level, clause IDs were missed. Two high-ranked sources could disagree. An empty scrape could still reach a fluent writer. First-hit retrieval is false certainty.

Task. I needed to inspect chunks, traces, and agreement instead of trusting the sentence. The answer had to be supported by an exact span, or it had to stop.

Action. I used Azure hybrid and semantic retrieval so an identifier and a paraphrase could both be found, then a bounded GraphDB hop when the question was depends-on. I ranked on quality, recency, and agreement, including not counting mirrored copies as independent confirmation, and I refused to average two contradictory requirements into vague prose. LangSmith made empty-tool results visible. A generated sentence or test case failed when no source span overlapped. Cite-or-abstain was the stop. I discarded first-hit writing, vector-only coverage, and treating a professional paragraph as evidence.

Result. More-than-two-hundred-page BRDs processed with traces and generated tests. More than two hundred sites ranked on the research side. No extra IQVIA percentage.

Have Backbone; Disagree and Commit — IQVIA hybrid vs vector

On this resume conflict is technical: hybrid plus graph versus a vector-only demo date. Then commit on evals. There is no named fight and no manager quote on the resume.

What they might ask

IE-asked leftover hours (GFG 2025 conflict coworker/manager; LC 8430457 disagreement with manager; LC 7724048 convince someone). Resume-derived IQVIA Hybrid RAG versus vector-only, LangSmith span gate, 200+ page BRDs. Other loop, not a forecast for Job 10454435.

What you say

Situation. The fastest demo for RAG on PDFs is a vector index. At IQVIA, BRDs were more than two hundred pages, with clause IDs, tables, and requirement dependencies. A vector-only path optimizes for ship date. Similar embeddings are not requirement coverage. A clause identifier can cosine-miss while a fluent retention paragraph comes back looking right.

Task. I needed to challenge the retrieval choice through its failure mode, propose a testable alternative, and then stop reopening the tool debate once the path was chosen. I am a software developer intern, not a skip-level.

Action. Three mechanisms, then the option I discarded.

  1. I contrasted three failure modes: lexical retrieval for an exact ID, semantic retrieval for policy language, graph hops for dependents. I stated that a nearest neighbor can miss the identifier entirely.
  2. I proposed Azure AI Search hybrid plus semantic ranker, plus a bounded GraphDB hop, plus LangGraph adaptive routing so the writer saw a small evidence set.
  3. Once that path was selected, I committed by instrumenting LangSmith evals and test-case generation: no overlapping source span, the case fails. I did not keep a quiet vector-only side project. I did not reopen the library every week.

I discarded vector-only as done, and I discarded repeating the tool argument after commit.

Result. Hybrid RAG processed more-than-two-hundred-page BRDs with traces and generated tests. Disagree on retrieval. Commit on evals. No extra percentage.

They might ask next

If they askYou answer
What did you implement?Failure-mode argument, hybrid + semantic + bounded GraphDB hop + adaptive routing, LangSmith evals and traced tests as the commit.
What did the other person say?I do not have their words on the resume. The other side wanted a date. That is rational. Coverage versus speed is the conflict.
How did you convince?A question that needs an exact clause fails on vector-only. An eval requiring span overlap turns opinion into a red trace.
What if they say manager?Same technical story. Intern, not a skip-level win. No fight scene.
How do you know you were right?200+ page BRDs, traces, tests that fail without spans. No fabricated win rate.
What did you not own?Overruling a named manager. Building Azure AI Search.
What would you add next?Put the eval table in the room before the disagreement. Freeze the gold slice earlier.

Keep straight

Tighten

Stop after disagree on retrieval, commit on evals, 200+ page BRDs. If they already heard IQVIA Backbone, speak the locked backup: Ylogx RLS-in-DB versus app-only WHERE.

If they already heard IQVIA hybrid vs vector

Situation. The Ylogx chatbot returned rows. An app-level organization filter looked enough for a quick release. Generated SQL or a JOIN can take a path the UI never represented. “The UI hides that org” is not a control.

Task. I needed to challenge app-only isolation on the failure mode, then commit to database policy as a platform rule.

Action. I stated that syntactically legal SQL can be unauthorized: JOIN through a mapping table, HTTP 200, wrong tenant. I put RLS and RBAC for three tiers into Postgres and ran generated SQL as the caller’s non-owner role so the deny is observable in a fixture. I added Redis only after keys carried tier, so speed could not become a side door. After that decision I did not leave an app-only exception path “just for the bot.” I discarded NestJS middleware alone, views without row policy, and trusting the model to add the tenant predicate.

Result. Isolation sat in the database. Uptime held at 99.9 percent. Bot database latency later fell 35 percent with tier-safe cache. The commit was policy in Postgres, not a stand-up argument.

Deliver Results — Horizon 17th / 80+

On this resume delivery is a rover that ran on challenge day. Judges scored the run, not bag files. The setback is stale occupancy and field versus simulation. Default second unnamed LP after Dive Deep.

What they might ask

IE-asked as family (unnamed leftover blocks; LC 8362604 / 7724048 deadline-shaped). Resume-derived Horizon ERC 2024: 17th / 80+, 60 FPS, +40% obstacle, 2M+ pts/s, −55% collision. Other loop, not a forecast for Job 10454435.

What you say

Situation. ERC 2024 had more than eighty international teams and a fixed date. I was on Horizon software from February to June 2024. More bag files and Gazebo screenshots would have looked active. Judges scored a rover that ran on the day. Dirt and lighting did not match simulation.

Task. I needed a live operator feed and a costmap the planner could trust. A lab video was not a result. A rover that mapped while planning on stale occupancy was not a result either.

Action. Three mechanisms, then the option I discarded.

  1. I shipped GStreamer at 60 FPS so operators saw current video, not a stalled history.
  2. I moved ZED 2 mapping at more than two million points per second into RViz and Gazebo for the node graph, and into the local costmap for planning, with visualization downsampled so the pretty cloud did not starve occupancy.
  3. I put fusion and predictive planning on latest occupancy. When the costmap lagged a healthy feed, I treated stale occupancy as the ship-blocker and closed that split in the field, not only in sim.

I discarded more simulation polish, a late architecture rewrite, and extra hardware first.

Result. We placed 17th globally of more than eighty teams. Obstacle detection improved 40 percent. Collision risk fell 55 percent after fusion. The date was met.

They might ask next

If they askYou answer
What did you implement?GStreamer 60 FPS, ZED mapping into the local costmap, fusion and predictive planning, field close on stale occupancy.
Why feed and costmap as key inputs?Perception without planning does not complete the challenge. Activity in Gazebo is not the score.
Missed a commitment?Sequence plus early specific risk. Costmap stale, or feed late. Extra hardware is the cut. The resume states 17th, not a miss.
What failed first inside a success?Stale occupancy behind a live-looking camera. Sim lighting unlike dirt.
How do you know?17th/80+, 60 FPS, 2M+ pts/s, +40%, −55%. Percentages: mechanism, no invented n. Placement is we.
What did you not own?Mechanical and electrical. Team-lead title. 17th as a personal trophy.
What would you add next?Calendar the ship-blocker in week one. Time-box fusion versus hardware against collision risk.

Keep straight

Tighten

Stop after 17th / 80+. If the intro or Bias already used the rover, speak the locked backup: Ylogx 40% faster reports + 99.9%.

If they already heard Horizon

Situation. At Ylogx, a chatbot that merely produced SQL was not the business result. Operators needed custom reports, non-technical users needed warehouse facts, and no organization could read another tier’s rows. A fast leak is not delivered.

Task. I needed faster reporting at held availability, useful natural-language analysis, and database-enforced isolation on the path those features already shared.

Action. I kept FastAPI and NestJS on a shared Postgres path and enforced three-tier RLS so reports and the bot inherited the same role mapping. I added Redis for repeat bot work with tier in the key, so latency work did not skip isolation. I kept the thirty dashboard KPIs off the model, and I served through CloudFront, ALB, ECS, and Docker so availability was a rolling image, not a patched box. If isolation is still only in the application, that is the blocker I name before calling the product done. I discarded app-only filtering as done, and I discarded calling a SQL demo the product outcome.

Result. Reports became 40 percent faster at 99.9 percent uptime. Analysis productivity rose 65 percent. Bot database latency fell 35 percent. Thirty KPI dashboards improved operations 60 percent at sub-210 milliseconds. Done includes isolation. Still no SLA miss on the resume.

Strive to be Earth’s Best Employer — Horizon sharing

On this resume Earth’s Best is a student rover team, not Amazon HR. Empowerment means another person can launch the node. Hire and Develop already used IEDC as primary. This primary is Horizon sharing.

What they might ask

Resume-derived Horizon core software; ERC 17th / 80+ as we. Other loop, not a forecast for Job 10454435.

What you say

Situation. Horizon rover software was fragile if camera, mapping, and launch knowledge lived in one head. ERC placement was a team score. I was a software team member, not a people manager and not a hiring loop.

Task. Teammates needed to launch perception without my laptop, integrate the costmap, and carry that into the next subsystem. Empowerment meant executable knowledge, not a slide deck.

Action. Three mechanisms, then the option I discarded.

  1. I paired on launch files until someone else could start the GStreamer camera node and confirm topics.
  2. I shared ZED rate versus visualization so a dense cloud for RViz was not mistaken for planner input, and I shared costmap expectations and node order.
  3. I stayed until the other person could run the path, including the failure we had already hit in the field, then I moved to the next module.

I discarded hero ownership of the working environment.

Result. We placed 17th of more than eighty as a team. The Earth’s Best result I can defend is that launch order was not trapped in one head. I claim no happiness score or mentee count.

They might ask next

If they askYou answer
What did you implement?Pairing on launch files, shared ZED-versus-viz constraints, costmap node order until someone else could run it.
Why pairing, not a presentation?Ready means they can launch. A deck does not start ROS2 nodes.
Is this the same as Hire?Hire primary is IEDC club scope. This primary is Horizon on a date that scored a team. If Horizon already appeared, use IEDC below.
How do you measure?Someone else launches. Team placement. Not an HR metric. +40% / −55% are Deliver product numbers, not coaching scores.
What did you not own?People-manager title, ratings, a mentoring program with a name. 17th as a personal employer trophy.
What would you add next?Pair and write a short runbook earlier. Resume does not claim that wiki.

Keep straight

Tighten

Stop after launch order left one head. If they already heard Horizon this hour, speak the locked backup: IEDC pairing.

If they already heard Horizon

Situation. At IEDC CUSAT, people joining club and hackathon projects did not share one stack. If only one laptop ran the build, the next event failed when that person worked elsewhere. I was a Tech Team member, not a manager.

Task. The next person needed to run the build and own the risky module.

Action. I shared environment setup and the failures already hit, in review, not as a slogan. I paired on the risky module until another laptop reproduced it. Across eight hackathons I treated a deploy someone else could repeat as the bar, not a hero demo. I discarded hoarding the working setup.

Result. Tech Team membership, eight events, CodeRecet first, MLH Best Project, Magnathon 2.0 runner-up. No mentee count. CGPA 8.42 is not this metric.

Success and Scale Bring Broad Responsibility — Argus 20+ cameras

On this resume scale is more than twenty cameras after 89% mAP and 24 FPS. Twenty copies of a 73% detector multiply ignored alarms. Order: quality, then width.

What they might ask

Resume-derived Argus 20+ containerized cameras after 89% mAP and 24 FPS; Postgres event logs; −50% violations and 2× compliance after alerts. Other loop, not a forecast for Job 10454435.

What you say

Situation. One-camera detection is not industrial safety. At more than twenty cameras, wrong alerts scale harm as well as benefit. A detector at 73 percent mAP would multiply misses and false alarms until people learned to ignore PPE warnings.

Task. I needed the detector ready before multiplying it, real-time throughput held, and an audit trail for the people operating the system. Secondary effect was alarm fatigue, not a planet metric.

Action. Three mechanisms, then the option I discarded.

  1. I did not scale at 73 percent. I moved YOLOv9 to 89 percent mAP at 24 FPS on more than 15,000 images, with NMS on the boxes.
  2. Only then I containerized ingest workers for more than twenty feeds, dropping stale frames rather than queuing delayed alerts.
  3. I stored structured events in Postgres — camera, class, confidence, time, box — not JPEG blobs. Humans acted on alerts. Operational −50% violations and 2× compliance came after that loop existed.

I discarded attaching twenty cameras first and fine-tuning later, and I discarded putting video files in the relational table.

Result. More than twenty cameras after the gate. Violations down 50 percent and compliance doubled after alerts. Order matters: quality, then scale. mAP is not those operational numbers.

They might ask next

If they askYou answer
What did you implement?mAP + FPS gate, then containerized ingest workers, stale-frame drop, Postgres events not JPEG blobs.
Why is scaling 73% irresponsible?Twenty streams of missed helmets and junk boxes train the floor to ignore the system. Harm multiplies faster than benefit.
Events versus video?Operators query “camera 7, Tuesday 18:04.” Video in Postgres makes every backup carry media. Events are the scale-friendly record.
How do you know?Resume 20+, 89%, 24 FPS, −50%, 2×. No site count, EKS-as-Argus, Kafka-as-Argus, or GPU SKU on the PDF.
What did you not own?A twenty-site rollout, plant headcount, sharding Postgres.
What would you add next?Per-camera error budget, labeled future work. Held-out camera as a strengthening step, not a shipped claim.
10× cameras?Keep 89% mAP and 24 FPS. Workers or batching if latency holds. Drop stale frames. Store events. Refuse 73% at any width. I will not claim 10× FPS.

Keep straight

Tighten

Stop after 20+ cameras after the gate. If they already heard Argus this hour, speak the locked backup: Ylogx ALB/ECS with RLS already on.

If they already heard Argus

Situation. Ylogx traffic sat on CloudFront, Route 53, ALB, ECS, and Docker. Adding desired count without isolation would have multiplied a leak. Adding cache without tier would have multiplied a wrong-org answer. Scale without the wall is broad irresponsibility.

Task. Serving had to grow on a path that already knew the caller’s database role.

Action. RLS and RBAC for three tiers were in Postgres before I treated ECS desired count as a scaling lever. ALB health checks and rolling image replacement bounded blast radius; one mutable VM was not deploy, health, and routing in one domain. Redis keys already carried tier, and dashboard GETs still had no LLM, so extra load did not invent KPIs or skip isolation. I discarded scaling a table-owner connection, and I discarded Compose-on-one-box as production scale.

Result. 99.9 percent uptime held on that path. Bot database latency was 35 percent lower with a safe cache. I did not shard. Honest next step is pool, fixtures, then more tasks — not Kafka, not a multi-region claim.

If they ask several prompts

Other leftover hours stacked several named stems in one sitting. That is shape evidence, not a forecast for Job 10454435. Keep the spread. A backup is a second story. Do not spend a fourth primary on the same org. Name the backup. Internships stay a timeline, not a contest.

What they might ask

IE-asked clusters (LC 6806195, 8362604, 8430457, 7850431, 7724048, 7623949; GFG 2025 leftover hour). Other loops, not this Job ID.

What you say

I pick the locked primary for the stem they just asked. If that project already appeared, I name the backup on that card and tell it as a full second story. Failure and feedback stay Argus 73 percent. Deadline stays Horizon sequencing, with no invented miss. Conflict stays IQVIA hybrid versus vector-only. Current role is IQVIA intern, two systems, then stop — not an LP dump.

They might ask next

If they askYou answer
Feedback; critical issues; beyond taskArgus 73% (Are Right). Ylogx Redis+RLS (Dive Deep). Horizon ship-blockers (Ownership backup) so Ylogx is not used twice if Dive Deep already spoke. If they only ask beyond-task: Ylogx Ownership primary.
Challenge; missing deadline; identified myself; simplifyingIQVIA Hybrid RAG (Invent). Horizon sequencing (Deliver, no miss). Ylogx JOIN-leak (Ownership). Stratify browser inference (Invent backup) so IQVIA is not Invent twice.
Disagreement; critical feedback; exceeded expectationsIQVIA hybrid versus vector (Backbone). Argus 73% (Are Right). Ylogx RLS beyond the chatbot ticket (Ownership).
Failed; missed deadline; current architectureArgus 73%. Horizon sequencing, no miss. Architecture is IQVIA two systems, not a new LP.
Deep dive; didn’t know; feedbackYlogx Redis+RLS. IQVIA LangGraph options (Learn). Argus 73%. Three orgs.
Deep dive; missed commitment; convinceYlogx Redis+RLS. Horizon sequencing, no miss. IQVIA hybrid versus vector.
Deep Dive; Learn; Earn Trust (names)Ylogx Redis+RLS. IQVIA LangGraph. GiftedBooks RAG + 99.5% + README disclosed.
Which intern ran longest in production?Ylogx, November 2024 to October 2025. That is a date.

Keep straight

Tighten

Default unnamed pair: Dive Deep, then Deliver. Third: GiftedBooks 3–10 min. Do not recite sixteen LP names. After the metric, stop. Full project mechanics live in chapter 5. Named leftover prompts live in chapter 4.

Companion: older 25-chapter notebook · research bible · study book.