Amazon LP Story Bank + Metrics Defense

Adarsh Vishwakarma · SDE I AUTA APJ Job 10454435 still none · R4 / Bar Raiser rehearsal

Official LPs: aboutamazon.com/leadership-principles · ConvBI-only page: ConvBI-LP-Interview.html · RLS: ConvBI-RLS-RBAC.html · Codebook: ConvBI-Bar-Raiser-Interview.html · Claude follow-up drill (same page): Claude LP interrogation

strongest backup notes STAR makeup — do not present as fact shipped understand would-do Claude — not locked bank

How a Bar Raiser wants a story

This is rehearsal, not a scoring sheet. Speak as Adarsh. Coaching notes can sit in third person. Do not name the poster Leadership Principle out loud. Do not invent metrics, mentee names, manager fights, missed deadlines, Qdrant, Haar, p95, TTL, or bills.

A Bar Raiser is listening for a real event with a cost, a decision you owned, a mechanism you can defend, and a result you can keep honest. They are not listening for the name of the poster on the wall. If they ask “tell me about a time…”, answer the question. Do not pause to label the principle. Do not recycle the same spoken project for every prompt in the same hour.

Must remember — spoken form
  • 90–120 seconds for the first STAR. Situation and Task are short. Action is the meat. Result is one or two sentences, then stop.
  • I vs we. Team Horizon and ConvBI were teams. Say “we” for the rover and the product. Say “I” for video+ZED, for Nest RLS middleware, for the inherited chatbot path, for the renderer prototype. If you cannot draw the line, you do not own that sentence.
  • Mechanism, not slogan. “I cared about the customer” is empty. “Doubt resolution went from hours to a 3–10 minute grounded RAG + PYQ loop because the student’s own PDF was the source of truth” is a mechanism.
  • One project per spoken answer. Do not stack IQVIA + Ylogx + Horizon in one breath. Timeline is chronology, not a ranking. Never say an internship was “the deepest.”
  • Do not name the poster LP. They already know which card they asked. Naming it sounds like a script.
  • Pick a failure that had a cost. Argus at 73% mAP was not shippable for floor safety. Client-side aggregation crashed the browser. DeepQuery 0% confidence was a synthesis JSON parse, not empty retrieval. IQVIA DOM truncation made the agent click the wrong zoom. Those are speakable. Do not invent a missed deadline or a manager fight.
  • Do not reuse the same spoken story for every prompt in the same hour. If GiftedBooks already filled Customer, do not also use it for Think Big in that loop unless they pull you there.

Recommended same-hour spread (speak first, then leave the project alone):

  • Customer Obsession → GiftedBooks (3–10 min doubt collapse + PYQ)
  • Ownership → Ylogx inherited chatbot (Y1) or RLS (Y5) — pick one, not both as the first sentence
  • Invent and Simplify → Y4 ElementRenderer reuse, or IQVIA Hybrid RAG if they are already on IQVIA
  • Are Right, A Lot → Argus 73→89 refuse-to-ship
  • Learn and Be Curious → IQVIA DeepQuery LangGraph
  • Hire and Develop the Best → IEDC Tech Team member pairing (no mentee count)
  • Insist on the Highest Standards → Argus 89% + 24 FPS before 20+ cameras
  • Think Big → StratifyLabs platform (3D lab + marketplace + browser inference)

If the hour stays on ConvBI / Projas, Ylogx primaries in the broader loop are Ownership, Frugality, Dive Deep — not six ConvBI trophies. Do not dump 40%, 99.9%, +65%, −35%, +60%, and sub-210ms in one paragraph. Pick the metric that belongs to the question.

Education flag if they open the PDF: resume.md CGPA is 8.42; ResumeWithSummarySep2026.pdf says 8.12. Resolve before you speak a number. GiftedBooks GitHub README currently describes AegisAI — resume wins; say that if they ask. StratifyLabs GitHub README is a Next.js scaffold — resume wins. Horizon resume says 17th/80+; public Horizon materials sometimes say ~18th and #1 India — flag the discrepancy, do not pick a fight.

Master story inventory

These are real events. Leadership Principles are angles on the same events — not 64 unrelated lives. Memorize the 12 core stories. Use the other cards as backups when the hour already spent the primary project.

CodeReal experienceBest LPs
Y1Inherited SQL-RAG chatbot after teammate leftOwnership, Dive Deep, Bias for Action
Y2data:null / state-format failureDive Deep, Learn, Are Right
Y3MySQL-oriented SQL against PostgreSQL + validationAre Right, Highest Standards, Dive Deep
Y4Structured JSON + ElementRenderer reuseInvent, Backbone, Earn Trust, Frugality
Y5RLS + RBAC + SET ROLE + fail-closedOwnership, Highest Standards, Earn Trust, Scale
Y6Cache-aside / resume Redis −35% vs this Nest MapFrugality, Dive Deep, Are Right
Y7Client review cycles / Tally → RDSCustomer Obsession, Earn Trust, Deliver
Y8Deterministic dashboards + report builder + ECSDeliver, Ownership, Frugality
Y9Git conflicts → branch separationEarn Trust, Hire, Earth
Y-crashClient-side aggregation crashed the tab (notes)Highest Standards, Dive Deep
I1DeepQuery LangGraph multi-stage researchLearn, Think Big, Invent, Scale
I2BRD Hybrid RAG + Neo4j + Azure SearchInvent, Learn, Backbone, Dive Deep
I3LangSmith / evals / not demo-onlyHighest Standards, Dive Deep
I-DOMStakeholder demo DOM truncation (notes)Dive Deep, Bias for Action
H1GStreamer 60 FPS operator videoBias, Invent, Deliver, Earth
H2ZED 2 perception into costmap — not the plannerOwnership, Learn, Dive Deep
S1StratifyLabs platform + marketplaceThink Big, Invent, Frugality
S2GiftedBooks grounded RAG + PYQCustomer, Earn Trust, Think Big
S3Argus 73→89 mAP then 20+ camerasAre Right, Highest Standards, Scale, Deliver
HACK8 hackathons; 1st / Best Project / runner-upBias, Deliver — need one concrete build
M1IEDC Tech Team member pairingHire, Earth — no mentee count
12 stories to speak fluently first
  1. Y1 inherited chatbot — Ownership
  2. Y2 data:null — Dive Deep
  3. Y3 dialect / validator — Are Right
  4. Y4 renderer prototype — Invent / Backbone / Trust
  5. Y5 RLS — Ownership / Standards / Scale
  6. Y6 cache vs bigger RDS — Frugality
  7. GiftedBooks 3–10 min + README honesty — Customer / Earn Trust
  8. Argus refuse 73%, gate 89%/24 FPS, then cameras — Are Right / Standards / Scale
  9. IQVIA Hybrid RAG vs vector-only — Invent / Backbone
  10. IQVIA DeepQuery LangGraph — Learn / Think Big backup
  11. Horizon video+ZED on the ERC date — Bias / Deliver / Earth — flag 17 vs ~18
  12. StratifyLabs platform — Think Big
Flags before you open any PDF
  • CGPA: resume.md 8.42 vs ResumeWithSummarySep2026.pdf 8.12. Align. Do not guess in the room.
  • Horizon placement: resume 17th / 80+ vs public Horizon materials ~18th and #1 India. Volunteer the discrepancy.
  • GiftedBooks GitHub README currently describes AegisAI. Resume wins. Say so.
  • StratifyLabs GitHub README is a Next.js scaffold. Resume and stratifylabs.design win.
  • Redis −35% is the resume bot-DB hop. This Nest checkout has an in-process fieldsCache Map, 5 minutes.
  • IQVIA has no percent and no latency on the resume.
  • You do not have a locked named mentee, manager fight, or missed-deadline story. Do not manufacture them.

1. Customer Obsession

Claude Customer Obsession follow-up drill — Claude’s wording, not the locked bank

Leaders start with the customer and work backwards. They work vigorously to earn and keep customer trust.

Coaching: the customer is the student on GiftedBooks, the Ylogx operator who cannot write SQL, and the client who keeps changing the Tally-to-report workflow. Do not turn this into “I used RAG.” Work backwards from the workflow that was broken.

GiftedBooks — doubt collapse + PYQ workflow strongest

Speak-first for Customer. Angle is the student’s study loop, not VR as a demo. Think Big later can reuse GiftedBooks only if this hour did not already spend it — and even then the emphasis must be “learning system,” not this 3–10 minute collapse.

Situation

I built GiftedBooks as a VR learning suite at giftedbooks.study. The students I was designing for were not stuck on “I wish I had a chatbot.” They were stuck on a study loop: find what actually matters for the exam, read it, get stuck, and then wait hours for a human to unstick them. A generic tutor that invents a syllabus is worse than no tutor, because it spends the student’s trust. The GitHub README on that repo currently describes AegisAI. If they ask, I say the resume is the product I shipped and I would fix the README. I do not import AegisAI features into this story.

Task

I needed a product that started from that loop and worked backwards. Done did not mean “an avatar that talks.” Done meant a student could upload their own material, ask a doubt against that material, get an answer fast enough to stay in flow, and see which topics past papers actually rewarded — without me claiming I could predict the next exam.

Action

I split two jobs that people keep gluing together. First, a PDF-upload RAG path: authenticate the student, accept their file, chunk and embed it once, store vectors with user and document metadata, and at question time retrieve a small user-scoped set and generate from those chunks. The API path on the resume is sub-300ms; I treat that as the retrieve-and-answer path, not as proof the model is faithful. Second, a PYQ-analysis topic prioritization engine that ranked observed past-paper topics as deterministic analytics, not as an LLM guessing the paper. Those two sat inside 3D labs and AI avatars so the student stayed in one environment. I rejected a generic chatbot, stuffing the whole textbook into every prompt, and mixing users’ PDFs. Cross-user retrieval would have been a trust bug, not a feature.

Result

In the user testing we reported for the project, average doubt resolution moved from several hours to the 3–10 minute range, reading efficiency +35%, session engagement +50%, and 2.5× faster content comprehension versus traditional study methods in that testing. Uptime on the resume is 99.5%. I do not claim a randomized controlled trial, a student headcount, or LangSmith on this project. Those numbers are project-reported user-testing results. If they ask for sample size or the exact protocol, I say I need to pull that — I do not invent it.

Spoken 90–120s. “The customer was a student whose study loop was broken. They could find a chapter, get stuck on a derivation, and lose hours waiting for a person. I did not start from ‘let’s put an LLM in VR.’ I started from that wait. I made their uploaded PDF the source of truth: ingest once, retrieve a small scoped set, answer from those chunks on a sub-300ms API path. I kept previous-year-question ranking as a separate analytics path so the model would not invent the syllabus. In our user testing, doubts that used to take hours landed in a 3–10 minute window, and we reported +35% reading efficiency and +50% engagement. The trust move was grounding plus isolation, not a smarter generic tutor.”

Likely interviewer questions
Who was the customer, and what did they actually need?

The customer was the student in the study loop, not “education” as a market. They needed three things in one sitting: know which topics past papers actually used, read those topics, and get a stuck question unstuck without waiting until evening. A chat box next to a PDF does the third badly if it is not grounded in their file, and it does the first dishonestly if the model invents a syllabus. I designed backwards from that loop.

How did you know students needed this? Did you talk to them?

The product was designed around a workflow I could watch: find material, understand it, resolve a doubt. PYQ ranking came from the observation that students treat every chapter as equal until an exam punishes them. I do not invent a named student or a survey N. The resume’s +35% / +50% / 2.5× / 3–10 min are user-testing results we reported for the project. If they want the protocol, I say I will get the sample and the instrument — I do not make them up in the room.

Why not a generic ChatGPT wrapper?

A generic model does not know which PDF the student is holding. It can quote a formula from a different edition or a different board. That is a trust failure. Whole-book prompting also blows the latency I was targeting and still is not isolation. I wanted their file as the evidence set, and I wanted PYQ as analytics over papers, not as the model predicting the exam.

What did you refuse to ship because it would have broken trust?

Cross-user retrieval. Mixing embeddings without user and document metadata would have answered one student’s doubt from another student’s notes. That can look “smarter” in a demo and still be the wrong product. I also refused to let the LLM own PYQ “predictions.” Ranking observed topics is a different job from inventing the paper.

Walk me through what happens when a student asks a question.

Student is authenticated. The question hits the RAG path against that student’s ingested chunks — not a global soup. We retrieve a small top-k, generate a short answer from those chunks, and return on the sub-300ms API path. PYQ topic ranking is a separate deterministic path over past papers. The VR labs and avatars are the shell. I do not claim Azure AI Search or Neo4j here; those are IQVIA. I do not invent FAISS cluster topology just because FAISS is on the skills line.

Your GitHub README says AegisAI. Which product is this?

That is a README mismatch on the current GitHub copy. The resume and giftedbooks.study are GiftedBooks — VR labs, PDF RAG, PYQ. AegisAI is a different personal-safety project on my resume. I would fix the README. I do not blend features to make one story sound larger. If they press Earn Trust, I say the mismatch out loud rather than hoping they do not open the repo.

Deeper probes
Sub-300ms — what did you actually measure?

The resume says contextual Q&A at sub-300ms. I speak that as the API retrieve-and-answer path, not as model-faithfulness and not as a p95 I invented. I do not have a labeled citation eval on the resume. Latency is not proof the chunk was the right derivation. If they want the probe host, the percentile, and the payload, I say that is missing from what I can defend today.

What would you change if you rebuilt the customer loop?

I would add a citation-facing eval so “grounded” is measurable, not hoped. I would fix the README on day one. I would write down the user-testing protocol so +35% and 3–10 min have a denominator I can defend. I do not invent that I already did those.

How is this different from GiftedBooks as Think Big?

This answer is the student’s wait time and trust. Think Big is “this is a learning system — VR lab plus grounded RAG plus PYQ — not a chat widget.” Same product, different sentence. I do not give both as the first story in the same hour.

Must remember
  • Customer = student study loop. Mechanism = scoped PDF RAG + separate PYQ analytics.
  • 3–10 min, +35%, +50%, 2.5×, sub-300ms, 99.5% — user-testing / resume family. Not an RCT unless I can prove one.
  • README says AegisAI. Resume wins. Say it if asked.
  • No student headcount. No LangSmith on this project. No Azure Search here.
Missing — do not invent
  • User-testing N, instrument, and whether 3–10 min is mean, median, or a band.
  • Exact chunker, embedding model, and vector store operations topology.
  • Whether 99.5% was measured window or a target.
Ylogx — client review cycles and evolving requirements (Y7) backup

Coaching: different angle from GiftedBooks. Here the customer is the client operator / reviewer on ConvBI, not a student. Do not replay the 3–10 min numbers. Do not invent a named client quote.

Situation

At Ylogx, November 2024 to October 2025, I interned on ConvBI / Projas — conversational BI over accounting-shaped data. The product was not specified once and frozen. We had recurring client review and demo cycles. Client-side people were in the Tally ERP to RDS path and in downstream notifications. Requirements moved after they saw a report, a bot answer, or a dashboard tile that did not match how they actually closed a month.

Task

My job was to turn that friction into an engineering change that still fit the existing Nest + FastAPI + Postgres system. A UI request that ignored RLS, or a one-off patch that ignored the report builder, would have looked responsive and still been wrong.

Action

I treated the review as a workflow signal, not as a ticket to copy. I asked what they were trying to finish — a custom report, an AI analysis, a KPI, a Tally ingest — and I translated that into a change that lived on the existing path: deterministic report SQL, chatbot structured output, dashboards, identity. I used demos to check direction before I piled on more surface area. I do not invent a manager argument. I also do not invent a specific sentence a client said if I cannot hear it in my head; I speak the class: analysis and reporting were hard for people who did not live in SQL, and the product had to absorb that without becoming a pile of special cases.

Result

The product went through development, QA, client review, and handoff as iterations, not a one-shot release. What shipped was custom reports, SQL-RAG analysis, KPI dashboards, and the surrounding ingest path. I do not hang 40% or 99.9% on “because I listened in a meeting.” Those are product-family numbers with their own measurement questions.

Follow-ups
Give a specific example of feedback that changed the design.

I stay with the workflow class rather than inventing a quote. Recurring reviews showed people struggling to go from a question to a chart they could defend. That pushed us toward a structured chatbot response — chart type, data, dimensions, metrics — that could reuse the report builder’s ElementRenderer, instead of treating the bot as a blob of text. If they want the exact meeting and the exact UI complaint, that exact sentence is something I still need to lock. I will not mint one.

How did you avoid becoming an order-taker?

I mapped the request onto the existing architecture. If they asked for “just show all the rows,” that is not a design if it crosses a tenant. If they asked for a new chart island, I asked whether ElementRenderer already knew that contract. Customer obsession here was protecting the customer from a patch that would fail the next review.

What did the customer care about that you initially underweighted?

They cared whether the month-close workflow completed — ingest, report, number they could show — not whether I had used LangChain. I had to keep translating “make the bot smarter” into “make the answer render in the same language as the report they already trust.”

Tally ERP to RDS — what was your part?

That path was part of the evolving product: client-side people were involved in Tally to RDS and notifications. I do not claim I owned their entire ERP. I owned turning the friction we saw in reviews into BI-side changes that still sat on Nest, FastAPI, and Postgres. If they want the exact ingest job I wrote, I need to pin the file and the handler — I do not invent a pipeline diagram.

Deeper probes
Did you ever say no to a customer request?

Yes in the security sense: generated SQL does not get to become the access policy, even if a reviewer wants “just this join.” That is Highest Standards / Ownership if they follow it. For this LP I keep it as: the customer’s long-term trust is isolation plus a number they can replay, not a leaky demo.

How is this different from SQL-RAG +65%?

Y7 is the review loop and changing requirements. +65% is the analyst who could not write SQL. Same internship, different customer sentence. I do not give both as the opening story in one hour.

Must remember
  • Customer = client reviewer / operator. Mechanism = friction → architecture-fit change → demo → iterate.
  • No invented client name or quote. No manager fight.
  • Do not pin 40% / 99.9% on a single review.
Missing — do not invent
  • One concrete client request, date, and the exact UI or SQL change I personally merged.
  • Which Tally-ingest pieces I wrote versus integrated against.
Ylogx SQL-RAG — analysts who could not write SQL (+65%) backup

Coaching: customer is the non-SQL analyst. Emphasis is access to their own numbers, not “I built LangChain.” FastAPI proposes SQL; Nest executes under RLS. LangChain, not LangGraph.

Situation

On ConvBI, a lot of the people who needed a number were not the people who could write a join. They still had to answer “what happened to this account this month” without opening a SQL client and without seeing another organization’s rows. A report builder helped when they already knew the shape. It did not help when the question showed up in language.

Task

I needed a path from a natural-language question to a result they could look at — chart or table — without making the model the database user and without teaching every analyst SQL.

Action

I worked on a LangChain SQL-RAG chatbot. The split I still defend: FastAPI generated candidate SQL from schema context and prompts; NestJS executed that SQL on a per-request transaction as the caller’s non-owner role, with RBAC on feature and table and RLS on rows. The response was structured — chart type, data, dimensions, metrics — so the same ElementRenderer the report builder used could draw it. I am not claiming LangGraph on Ylogx. I am not claiming the model was allowed to SET ROLE.

Result

The resume says that chatbot improved analyst data-retrieval productivity by 65%. I treat that as a project-level observed or estimated productivity outcome, not as a controlled experiment unless I can show the baseline, the population, and the instrument. I do not stack Redis −35% into this Customer answer unless they ask what happened on repeat questions.

Follow-ups
Who could not write SQL, and what were they trying to do?

Operators and analysts who lived in the business question, not in Postgres. They needed retrieval and a visual they could put next to a deterministic KPI, not a raw result set in a terminal. The customer was that person. The risk was giving them a fluent wrong number from another org or from MySQL-shaped SQL on Postgres.

Why not just train them on the report builder?

The report builder is the right tool when the question is already a report. A lot of questions arrive as language first. Forcing SQL or a 12-step builder is asking the customer to become us. The bot is the on-ramp. The builder stays the place you go when you need a saved, deterministic artifact.

How do you keep customer trust if the model writes SQL?

Trust is not “the English sounded right.” Nest executes as the caller. RLS filters rows — it does not “reject” a legal SELECT. Missing GRANT is a permission error. App hasTableAccess is HTTP 403. Chat metadata CRUD can use executeWithoutRLS after RESET ROLE — I do not claim every table is under RLS. If they want the leak story, that is Ownership / Standards, not this customer sentence.

What does +65% actually mean?

Analyst data-retrieval productivity on the resume. I will not dress it up as a scientific A/B. If they ask baseline hours, I say that methodology is something I need to lock. I will not invent a time-and-motion study.

Deeper probes
Did the customer ever get a wrong chart?

Yes as a class: data:null when rows existed, because a state-format mismatch broke the downstream parser; and MySQL-oriented SQL against PostgreSQL. Those are Dive Deep / Are Right stories. For Customer I say: a wrong empty state is a customer failure even when the warehouse is full. I fixed the format path and the prompts plus validation. Validation does not guarantee semantic correctness.

LangChain or LangGraph?

Ylogx SQL-RAG is LangChain. LangGraph is IQVIA DeepQuery and the BRD processor graphs. I keep those internships separate.

Must remember
  • Customer = non-SQL analyst. Mechanism = NL → FastAPI SQL propose → Nest execute under RLS → structured render.
  • +65% is resume productivity, methodology weak until locked.
  • Not LangGraph. Not “Postgres rejected the query.”
Missing — do not invent
  • Baseline, N, and instrument for +65%.
  • Which exact analyst role titles the client used.
Freelance Discord subscriptions — correctness is customer experience (C1) backup

Coaching: genuine fourth from cover-letter / notes, not a makeup. Keep it high-level. There is no concrete client name in the lock. Do not invent one, a revenue number, or a subscriber count.

Situation

Outside the internships I did freelance work that included apps, CMS, CRM, and subscription-driven Discord automation. The failure class I still use is simple: a bot that grants a role when payment starts and never revokes it when payment ends is “working” in the happy path and wrong as a customer experience. The paying customer thinks they bought a gated community. The community owner thinks churn is enforced. Neither is true if the off-path is missing.

Task

Make the subscription lifecycle match the access lifecycle — not just the join path.

Action

I treated correctness as the product. Grant on start is only half the workflow. The customer-facing outcome is: when entitlement ends, access ends. I do not name a client I cannot defend. I do not invent Stripe event names or a Discord API version if I cannot see the code in front of me. I speak the principle I actually used: the workflow outcome is the experience, not the fact that a webhook returned 200 once.

Result

I learned to test the cancel and expire paths as hard as the welcome path. I do not attach a resume percent to this work. If they want the business name, contract, or before/after ticket volume, I say that is not on the resume and I will not invent it.

Follow-ups
What did the customer actually care about?

Whether the right people could enter after they paid, and whether access stopped when they should not be there. They did not care which Discord library I used. Correctness was the experience.

Who was the client?

I do not have a locked client name in my interview notes. I will not mint one. I can speak the subscription-access failure class. If they need a named logo, I say that detail is not something I am putting on the table today.

How is this Customer and not just a bugfix?

The happy-path feature was already “done” in a demo sense. The customer still gets a bad product if the off-path leaks access. Working backwards from the owner’s promise — paid members only — is the LP, not the webhook.

Deeper probes
What did you measure?

Nothing I will quote as a percent. I will not invent churn or ticket counts. The test is: grant and revoke both happen.

Why is this weaker than GiftedBooks?

Because I cannot name the client, the stack pin, or a resume metric. It is a real angle from my notes. It is not the speak-first story.

Must remember
  • High-level only. No invented client name, stack pin, or %.
  • Line to keep: correctness is customer experience.
Missing — do not invent
  • Client name, dates, payment provider, Discord guild size, before/after metrics.

2. Ownership

Claude Ownership follow-up drill — Claude’s wording, not the locked bank

Leaders are owners. They think long term and don't sacrifice long-term value for short-term results. They act on behalf of the entire company. They never say "that's not my job."

Coaching: speak-first is Y1 — inherited chatbot after a teammate left. Y5 is security ownership with an honest I/we line. Horizon is a boundary story (video+ZED, not planner). Y8 is the intern who did not stop at “I don’t own AWS.” Do not rank internships. Dates: Horizon Feb–Jun 2024, Ylogx Nov 2024–Oct 2025, IQVIA Apr 2026–present.

Y1 — inherited SQL-RAG chatbot after a teammate left strongest

Speak-first Ownership. Learn and Be Curious can reuse Y1 later only with the how I learned angle (request map, not library-first). Do not give both openings in the same hour.

Situation

At Ylogx I was already on ConvBI when responsibility for the SQL-RAG chatbot became a gap after another team member left. The bot was not a side script. It was the path from a business question to generated SQL to a structured answer operators used next to reports. I did not own that service on day one. Waiting for a reassignment would have left the product with a hole.

Task

Make the service mine in the only way that counts: reproduce it, understand every hop, and keep it moving. I was an intern, not the engineering manager. “Not my job” would have been accurate as a ticket label and wrong as an owner.

Action

I reproduced the stack locally and walked the request with a map, not with a tutorial binge. LangChain state went into dynamic prompts, then schema lookup, then SQL generation on FastAPI, then Nest execution, then the response the UI parsed. I added logging at service boundaries so the next failure was a hop I could name, not a vibe. That map is what let me hit the real failure classes: data:null when the warehouse still had rows, because a state-format mismatch broke the downstream parser; MySQL-oriented SQL against PostgreSQL; and validation that still does not pretend to be semantic truth. I fixed the format path, the prompt examples, and deterministic checks. I did not “rewrite LangChain.” I learned the path I had inherited.

Result

I could operate the chatbot, explain it, and change it. The product kept the NL path instead of parking it. I do not invent the calendar day the teammate left or how many days until I was productive. If they ask, I say those dates are not locked. I do not hang +65% on “because I inherited it.” +65% is the resume productivity family for the chatbot as a product.

Spoken 90–120s. “A teammate left and the SQL-RAG chatbot — the path from a question to SQL to a structured chart — became a gap. I did not wait for someone to assign it. I stood it up locally and traced LangChain state, dynamic prompts, schema lookup, FastAPI SQL generation, Nest execution, and the response parser. I put logs on those boundaries. That is how I found data:null was a format mismatch, not an empty database, and how I found MySQL-shaped SQL hitting Postgres. I fixed the format path, the prompts, and validation. Validation still does not guarantee the SQL means what the user meant. The ownership was the whole hop list, not a single function.”

Likely interviewer questions
Why take responsibility for somebody else’s service?

Because the product still depended on it. Reassignment time is customer-visible downtime in a small intern team. The shortest path to reducing that dependency was me understanding it. I did not need a new title. I needed a local repro and a map.

What did you actually not know on day one?

I did not have the LangChain state shape, the prompt assembly, or which stage dropped the field the parser expected. I also did not assume I knew why a chart came back empty. Library docs do not tell you our stage contract. The request map did.

What is data:null, in your words?

The UI got a structured payload whose data field was null. The database still had the rows. The failure was between stages: state format did not match what the next hop parsed, so the renderer had nothing. I fixed the format path and reran the cases. I do not invent a Jira key.

Did you become the tech lead?

No. I became the person who could run, debug, and change that path. Intern title stayed intern. I vs we: the product is we; the map, the boundary logs, and those two failure classes are I.

What would you do differently?

I would have written the hop diagram and the state contract on the first day, before the first fix, so the next person does not inherit a ghost. I would have added a fixture that asserts “rows exist, payload must not be data:null” so that class cannot return quietly.

Was this also Learn and Be Curious?

It can be, if they ask how I learned. The Ownership sentence is “the gap was mine.” The Learn sentence is “I learned by request-map, not by reading LangChain cover to cover.” I pick one opening per hour.

Deeper probes
Where did you add logging, exactly?

At service boundaries: after generation, after Nest execution, before the UI consumed the structured object. I wanted to see which hop last held a good payload. I do not invent a Datadog dashboard or a log-volume percent.

Did validation make the bot correct?

No. It catches invalid or dialect-unsafe classes. Semantic correctness still needs schema context, prompts, tests, and a human looking at a weird total. I say that out loud. Highest Standards will reuse this honesty.

LangChain versus LangGraph — did you migrate it?

No. Ylogx stayed LangChain SQL-RAG. LangGraph is IQVIA. I did not “upgrade” the inherited bot into a graph to sound current.

Must remember
  • Teammate left → gap → I reproduced → hop map → boundary logs → data:null format + MySQL/Postgres prompts.
  • I for the map and those fixes. We for ConvBI.
  • No invented leave date, no mentee, no manager fight.
Missing — do not invent
  • Date the teammate left; time-to-productive.
  • Exact log line format and which file names in this checkout match production Ylogx.
Y5 — RLS + RBAC security ownership (I vs we) backup

Coaching: Ownership angle is “I treated isolation as my job.” Highest Standards later is “I refused LLM-as-security.” Do not copy this STAR. I vs we: Nest middleware + policy generator are the pieces to claim carefully; not a hand-written DBA migration of record; intern, not named security team.

Situation

ConvBI put multiple organizational tiers on one PostgreSQL instance. A green chatbot demo that returns rows is not done if a generated JOIN can still read another org. App-only WHERE and “the model will add organizationId” fail the first time a handler is missed.

Task

Own the isolation class on the bot and reporting path. I was not a DBA of record and not AWS account owner. I still could not say security was someone else’s epic.

Action

I worked the Nest side: JWT carries identity; RBAC decides feature and table; each fact request opens a Sequelize transaction; SET ROLE to that user’s non-owner database role; set_config for app.organizationId from the verified JWT, not from SQL text the model wrote. If there is no db role, fail closed to rls_no_access. A CREATE POLICY generator emits policies — I do not claim I hand-wrote every production migration as the DBA. Postgres FILTERS rows. A legal SELECT that asks for ORG_B while the GUC is ORG_A returns zero rows. It does not “reject” the statement. Missing GRANT is a permission error. Application hasTableAccess is HTTP 403. Chat CRUD can use executeWithoutRLS after RESET ROLE — I do not say every table is under RLS.

Result

Three-tier row isolation on the shared warehouse path the resume claims. 99.9% is serving uptime, not a leak-ticket SLA. I do not invent a penetration-test count.

Follow-ups
Why is this Ownership and not just a security ticket?

Because a demo that leaks is a product I would have shipped if I had stopped at “the SQL ran.” I treated the boundary as part of delivering BI, not as a future team’s job.

What did you write versus what did the team own?

I can defend Nest middleware, per-request transaction, SET ROLE, GUC from JWT, fail-closed role, and a policy generator. I do not claim I was the DBA who applied every GRANT in production by hand. We for the warehouse and the three tiers. I for the request path I implemented in this Nest tree.

What happens if the model writes WHERE organizationId = ORG_B?

If the session GUC is ORG_A and the policy USING requires that GUC, ORG_B rows stay invisible. HTTP can still be 200 with zero rows. I do not say Postgres rejected the query. If hasTableAccess fails, that is 403 in the app.

Is every table under RLS?

No. Chat metadata CRUD uses executeWithoutRLS — RESET ROLE — on purpose. Warehouse facts should not ride that path. If they catch me saying “everything is RLS,” I correct myself in the room.

Deeper probes
Did anyone push back?

I do not invent a manager fight. The discarded options were app-only WHERE, middleware-only checks, and trusting the model to add the predicate. I argued those fail on the first missed handler. That is a design disagreement, not a performance-review story.

This checkout versus resume Redis — does that change ownership?

No. Cache is a different hop. Resume cache-aside is Redis −35% bot DB. This Nest snapshot has an in-process Map with 5-minute fieldsCache. I say “resume Redis hop versus this snapshot Map” if they open the repo. Ownership of isolation does not become a cache story.

Must remember
  • I: Nest path, generator, fail-closed. Not: “I am the DBA.” Not: every table RLS.
  • Postgres filters rows. Missing GRANT ≠ RLS hide. 403 is app.
  • No FORCE RLS claim unless I can show it in the live tree.
Missing — do not invent
  • Whether production applied FORCE ROW LEVEL SECURITY.
  • Exact three role names the client used in their org chart.
Horizon — video + ZED ownership boundary (not the planner) backup

Coaching: this story exists to draw a line. Core software member, not team lead. Do not absorb predictive planner, full costmap, or custom sensor-fusion. Resume 17th/80+; public Horizon materials sometimes ~18th and #1 India — flag, do not fight. +40% obstacle definition is weak — do not lean on it.

Situation

February to June 2024 I was core software on Team Horizon’s ROS2 Mars rover for the European Rover Challenge 2024. The rover needed an operator point of view and a spatial sense of the terrain. The whole vehicle was a team system: cameras, compute, navigation, control. I did not own the rover.

Task

Own the video path and the ZED 2 perception integration so the operator could see, and so depth and spatial data could enter the navigation conversation. Done was not “I also wrote the planner.”

Action

I engineered a GStreamer pipeline on ROS2 for real-time operator video — resume 60 FPS — including the multi-feed POV problem, rather than shoving raw frames through the application layer. I integrated the ZED 2 stereo camera for environmental scanning — resume 2M+ point-cloud samples per second — and visualization in RViz and Gazebo. I integrated that perception into the navigation / costmap flow. I did not own the predictive planner implementation, the full costmap implementation, or a custom sensor-fusion stack. If they ask who wrote the trajectory chooser, I say that was not me.

Result

We took the rover to ERC 2024. Resume: 17th of 80+ as a core software member. Public Horizon materials sometimes say about 18th globally and #1 in India. I flag that discrepancy; I do not argue with the interviewer about a place. Resume also has +40% obstacle-detection accuracy and −55% simulated collision events on test tracks. I treat +40% as a weak definition — compared to other video-feed tools in our notes, not a labeled detection benchmark I can defend like Argus mAP. I do not move those percents onto Ylogx or IQVIA.

Follow-ups
Did you build the planner?

No. I understand how a planner consumes pose, kinematics, and a costmap, and I integrated perception into that pipeline. I did not own the predictive planner.

What does ownership mean on a competition rover?

It means I can be the person who is awake for the video pipe and the ZED integration when it breaks on the field. It does not mean I speak for navigation, mechanical, or the team as lead. I was a core software member.

17th or 18th?

Resume says 17th/80+. Team-facing public materials have said ~18th and #1 India. I will not pick a fight in the room. I will say both exist and I will align the resume with the source of record. The ownership story does not depend on the place.

Why GStreamer instead of rolling your own frames?

The operator needed a media pipeline — capture, encode, transmit — not an application thread copying pixels. That is also the Invent backup. Here I say: I owned that pipe because the rover was unusable as a remote vehicle without it.

Deeper probes
What is a costmap, then, if you did not own it?

A grid of traversal cost: lethal near obstacles, cheaper in free space. I fed perception into that world. I do not claim a specific scoring function or that I wrote the plugin. −55% is resume simulated collisions on test tracks — I need the track definition if they press the number.

Were you the software lead?

No. Core software member. IEDC later is also member, not lead. I keep those titles honest.

Must remember
  • Own: GStreamer video, ZED integration, perception into nav flow. Not: planner, full costmap, fusion, team lead.
  • 17th vs ~18th: flag. +40% obstacle: weak definition — do not boast.
Missing — do not invent
  • Codec, bitrate, resolution, measured glass-to-glass latency.
  • Official ERC source of record for 17 vs 18.
Y8 — dashboards + AWS delivery; intern who did not say “not my job” backup

Coaching: Ownership of the path to users, not “I am the AWS account owner.” Do not dump six metrics. Think Big later can use ConvBI as a product vision — different sentence.

Situation

ConvBI needed operators to see KPIs without waiting on an LLM, and the intern work did not stop at localhost. Reports, dashboards, and the chatbot only matter if they are reachable. I was not the company’s AWS account owner and I did not control billing.

Task

Help ship a serving path and deterministic tiles, not park deploy as “DevOps will do it.”

Action

I engineered 30 KPI dashboards on React and Recharts whose GET path is deterministic SQL — no LLM on the tile fetch — so a known metric does not wait on generation. I worked the report builder as the place you design a saved artifact. On the resume I led AWS deployment using ECS, CloudFront, Docker, and ALB, plus Route 53, and GitHub Actions CI/CD that cut release time by 2× versus manual steps. I say “led” as intern initiative on that path, not as account root. I do not quote an AWS bill.

Result

Resume family: 30 dashboards, +60% reduction in manual reporting overhead, sub-210ms response times, 99.9% uptime, 40% faster report generation, 2× release. I pick one or two if they ask Ownership — usually “tiles are deterministic and the intern path included deploy.” I do not recite the whole list. Methodology for each percent is a Dive Deep question, not this STAR’s payload.

Follow-ups
You were an intern. How was deploy your job?

Because a feature on my laptop is not a product. I did not need the root account to write Docker, a GitHub Actions workflow, and an ECS/ALB/CloudFront path the team could run. I needed to refuse “that’s infra.”

Why no LLM on dashboard GET?

A KPI the business already defined should not change because a prompt drifted. Generation belongs on the exploratory bot path. That is long-term value over a flashy tile.

Did you own Route 53 and the AWS org?

No. I worked those pieces as an intern on the deploy path. I do not claim account ownership, IAM architecture for the company, or a bill I saved.

What does 2× release mean?

Resume: CI/CD eliminated manual deployment steps and reduced release time by 2×. I need the before/after procedure if they press. I will not invent minutes.

Deeper probes
Sub-210ms — p95?

The resume says sub-210ms. I do not upgrade that to p95 or invent a TTL. If they want percentile and probe host, that is missing.

How is this different from Think Big ConvBI?

This is “I did not stop at application code.” Think Big is “conversational BI plus reports plus KPIs plus tenant security is one product.” Same internship, different question.

Must remember
  • Intern, not AWS account owner. No bills.
  • Deterministic dashboards. LLM stays off GET.
  • Do not dump six metrics.
Missing — do not invent
  • Before/after release minutes; who clicked AWS consoles in production.
  • Percentile definition for sub-210ms; uptime observation window.

3. Invent and Simplify

Claude Invent and Simplify follow-up drill — Claude’s wording, not the locked bank

Leaders expect innovation and always find ways to simplify. They look for new ideas from everywhere. They accept they may be misunderstood.

Coaching: speak-first is Y4 renderer reuse — original Ylogx-heavy simplify. Story 2 is IQVIA Hybrid RAG (Invent primary in the spread lock). Story 3 is GStreamer as a pipeline. Story 4 is StratifyLabs browser inference. Do not copy Hybrid RAG’s Learn angle (hybrid vs vector-only + 2-hop). Do not copy StratifyLabs Think Big (platform vision).

Y4 — structured chatbot JSON reused ElementRenderer strongest

Speak-first Invent. The invention is the contract. The simplify is not building a second chart island. Have Backbone energy if they ask about disagreement — prototype instead of argument — but do not invent a manager fight.

Situation

The ConvBI chatbot was starting to return useful rows, and the report builder already knew how to draw elements. The easy wrong move was a second visualization stack “for AI.” That would have doubled testing and guaranteed the bot’s chart and the report’s chart would drift.

Task

Give the bot a way to show charts and tables without inventing a parallel renderer. I needed something I could show, not a slide.

Action

I proposed a structured JSON contract: chart type, data, dimensions or labels, metrics, and enough context to render. Then I pointed that object at the existing ElementRenderer from the report builder. I built a prototype instead of arguing that reuse was cleaner. The team and manager could click it. FastAPI still only proposed SQL and metadata; Nest still executed. The renderer stayed deterministic once the payload was valid.

Result

One visualization mechanism for bot and builder. I do not invent which exact chart types the prototype covered. I do not invent that someone shouted. Acceptance was “they could see it.” This is also the simplify people want when they ask “tell me about a time you made something simpler.”

Spoken 90–120s. “The chatbot needed charts, and we already had a report builder with an ElementRenderer. The inventive move was not a new library. It was a structured response — type, data, dimensions, metrics — that the old renderer could consume. I prototyped it so the discussion was a screen, not an opinion. We kept one place that knows how to draw. I may have been misunderstood as ‘blocking a dedicated AI chart module.’ I accepted that. Two renderers would have been the complicated thing.”

Likely interviewer questions
Why not a new chart library for the bot?

Because the abstraction already solved drawing. A second library is more code, more visual drift, more bugs when a client asks for the same KPI in two places. Reuse was available because the contracts could be made compatible.

What was the invention if the renderer already existed?

The contract and the decision to make the bot speak the builder’s language. Invention here is the interface, not a new npm package. Simplify is deleting a future island.

Were you misunderstood?

I can be read as slowing a flashy AI UI. I accepted that and showed a prototype. I do not invent a fight with a named manager.

Where did the idea come from?

From the report builder sitting in the same product. Official LP text says leaders look for ideas from everywhere. Mine came from the code we already shipped, not from a paper.

What did the JSON look like?

Chart type, data, dimensions, metrics, context. I do not recite a schema I cannot open. If they want field names, I say I will walk the renderer props from the repo rather than guess.

Did this fix the client-side aggregation crash?

No. That crash was aggregating large slices in the browser — a Highest Standards story. Renderer reuse is about one drawing path. I keep them separate.

Deeper probes
What if the model emitted a type the renderer did not know?

Then the contract failed closed to a safe fallback — table or error — rather than a half-drawn island. I do not invent a specific enum list if I cannot see it.

Frugality overlap?

Yes in spirit: we did not buy a second chart world. If the hour already used Y4 for Invent, I do not also open Frugality with the same prototype. Frugality on Ylogx can be cache-aside versus scaling the DB for repeat bot questions.

I vs we?

I proposed the contract and built the prototype. We accepted it into the product. The renderer already existed as team code.

Must remember
  • Invention = structured contract. Simplify = one renderer. Proof = prototype, not argument.
  • No manager fight. No invented chart-type list.
Missing — do not invent
  • Exact chart types in the prototype; exact TypeScript interface names unless opened.
IQVIA Hybrid RAG — do not make one model do discovery + graph + tests backup

Coaching: Invent angle is separation of jobs so retrieval, relationships, and test generation are not one blob. Learn’s Hybrid story is “why hybrid vs vector-only + 2-hop.” Do not paste the same Action paragraph.

Situation

At IQVIA, April 2026 to present, I work on FastAPI systems. One of them is a Hybrid RAG processor over large BRDs and PDFs — resume 200+ page class. If I had pointed one chat model at a 200-page BRD and asked it to “find requirements, know dependencies, and write tests,” I would have invented a demo and simplified nothing.

Task

Make the jobs separable: ingest and index, retrieve, walk relationships, generate test cases. Each stage should be observable.

Action

I used an 8-node ingestion graph: extract text, chunk at 1500 tokens with 200 overlap on cl100k_base tiktoken, embed at 3072 dimensions, write Azure AI Search index brd-documents, extract requirements per chunk, analyze relationships, persist Neo4j Document / Requirement / Entity with DEPENDS_ON. Retrieval is hybrid: BM25 plus vector kNN plus semantic reranker plus a 2-hop Neo4j walk — not “the model remembers the PDF.” Test-case generation is a separate 5-node graph with asyncio.gather, not the ingest graph wearing a hat. Redis and Celery appear in requirements and are not wired; jobs are in-memory maps. I say that. LangSmith is how we inspect, not a recall number I do not have. There is no labeled precision/recall set on this project.

Result

A pipeline that can take a large BRD and produce indexed chunks, a requirement graph, and test cases without one undifferentiated agent. I do not quote an IQVIA percent or latency. Local/ intern system — I do not claim a hosted multi-region service.

Follow-ups
Why not one agent on the whole PDF?

Because discovery, graph structure, and test generation fail in different ways. One blob hides which stage lied. Separate nodes can be retried, logged, and disagreed with.

What did you invent versus stitch?

The invention is the composition: hybrid index plus graph plus a second graph for tests. Azure AI Search, Neo4j, and LangGraph are pieces. The simplify is not making gpt-4o be the database.

Redis and Celery are in requirements.txt — did you use them?

Not wired. In-memory job maps. I will not claim a queue I did not connect.

Is this LangGraph the same as DeepQuery?

Same internship, different system. DeepQuery is web research. This is BRD ingest. I do not merge them into “my IQVIA agent.”

Deeper probes
Chunk 1500 / overlap 200 — why those numbers?

They are the configured token budget on cl100k_base. I can defend that they exist in code. I do not invent an ablation that picked 1500 as optimal unless I ran one.

Did you evaluate retrieval quality?

No labeled recall/precision set. I will not mint nDCG. LangSmith is traces. Honesty is the Invent-adjacent standard: do not ship a fake eval.

Must remember
  • Invent = split jobs. 8-node ingest, 5-node tests, hybrid + 2-hop.
  • No IQVIA %. Redis/Celery not wired. No labeled IR set.
Missing — do not invent
  • Production hosting topology; human eval rubric scores.
Horizon — GStreamer pipeline versus raw frames backup

Coaching: Invent/Simplify only. Not ownership of the rover. Not Learn’s “layers must agree.”

Situation

The rover needed a live operator POV. The naive build is “subscribe to camera frames in the application and forward them.” That dumps media problems — encode, clock, multi-feed — into ROS nodes that should not be a video stack.

Task

Treat video as a pipeline so the rest of the software could stay software.

Action

I put GStreamer in front of that problem: a dedicated media pipeline for capture and transmission, including multi-video POV, instead of raw frame forwarding. Resume 60 FPS. I do not invent codec, bitrate, or glass-to-glass milliseconds.

Result

Operators had a real-time feed the stack could live with. +40% obstacle is not this story’s metric and its definition is weak — do not drag it in. ERC place is not the simplify result.

Follow-ups
Why GStreamer?

Because we needed a media pipeline, not an application loop copying pixels. Encode, pacing, and multi-feed are solved problems in that toolkit.

What did you simplify?

The application layer. Navigation and perception integration did not also have to be a streaming server.

Could you have used WebRTC or raw UDP?

Those are different designs. I did not run a bake-off I can quote. I chose a pipeline that the ROS2 rover software could integrate. I do not invent latency tables.

Deeper probes
60 FPS measured where?

Resume claim for the pipeline. Probe host, resolution, and whether that is camera, encode, or display are not locked. I will not upgrade it to a p95.

Is this the same as ZED ownership?

No. GStreamer is the color/POV pipe. ZED is stereo depth and scanning. I can mention both in Ownership. Here I stay on the media pipeline.

Must remember
  • Simplify = pipeline vs raw frames. No +40%, no planner, no 17th as the punchline.
Missing — do not invent
  • Codec, transport, bitrate, latency measurement method.
StratifyLabs — browser inference + marketplace backup

Coaching: Invent/Simplify = remove local GPU setup and reuse models. Think Big = “this is a platform.” GitHub README is a Next.js scaffold — resume wins.

Situation

Computer-vision experimentation usually means a local GPU, a notebook, and a model you cannot share without a zip file. That loop is slow and antisocial.

Task

Make iteration simpler: run inference in the browser, reuse other people’s models, stop rebuilding the same demo.

Action

I shipped browser-based WebGL inference so you could try a model without a local GPU setup, and a marketplace with 50+ pre-trained models plus dataset hosting. URDF editing and a 3D lab sit next to that, but this answer is the friction cut: inference where the student already is, reuse instead of retrain. Resume −30% ML iteration cycles. Gemini-powered RAG voice agents with 3D characters exist on the resume; I do not make them the Invent sentence unless asked. If they open GitHub and see a Next.js scaffold README, I say the resume and stratifylabs.design are the product story and I would fix the README.

Result

−30% iteration time as reported for the project; marketplace 50+. I do not invent MAU or a GPU-hours bill. I do not claim this is Think Big unless they ask why it is a platform.

Follow-ups
What did you simplify?

The setup tax. Browser inference plus a marketplace means fewer “install CUDA, miss a driver, lose an afternoon” loops and fewer from-scratch retrainings for a known model.

Why WebGL inference rather than a hosted GPU API?

Hosted GPU is another account, another queue, another bill I will not quote. In-browser was the simple path for experimentation. I do not invent that it matches A100 throughput.

Is the GitHub repo the product?

The current README looks like a Next.js scaffold. Resume and stratifylabs.design win. I would align the repo. Same Earn Trust pattern as GiftedBooks / AegisAI.

Deeper probes
How was −30% measured?

Resume: reduced ML iteration cycles by 30% via browser-based WebGL inference. Baseline and diary method are not locked. I will not invent a study N.

50+ models — who trained them?

Marketplace of pre-trained models and datasets. I do not claim I trained all 50. I do not invent names.

Must remember
  • Simplify = browser inference + reuse. README scaffold ≠ product.
  • −30% and 50+ are resume; methodology weak. No bills.
Missing — do not invent
  • Baseline for −30%; which models I trained versus listed.

4. Are Right, A Lot

Claude Are Right, A Lot follow-up drill — Claude’s wording, not the locked bank

Leaders have strong judgment and good instincts. They seek diverse perspectives and work to disconfirm their beliefs.

Coaching: speak-first is Argus — refuse to ship 73% mAP for floor safety. That is judgment plus a number you were willing to kill. Y3 is data disconfirming “the model hallucinated / empty DB.” Y6 is measuring cache versus guessing “DB is slow.” DeepQuery 0% confidence is “do not blame retrieval.” Highest Standards also uses Argus — different sentence: 89% and 24 FPS before 20+ cameras.

Argus — 73% mAP was not shippable for floor safety strongest

Speak-first Are Right. You were willing to be wrong about “the detector works.” 73% was a working demo and a bad safety product. Do not invent class-wise AP, train/val split, or a site name.

Situation

Argus is an industrial safety system: YOLOv9 PPE-compliance detection. The first model I could run was not a toy — it produced boxes — and the reported mAP sat at 73%. For a slideshow that is a result. For a floor where a missed helmet is a person, 73% is a belief I had to disconfirm: “it works, ship the cameras.”

Task

Decide whether 73% was a product. My judgment was no. Then I had to earn a better number rather than argue taste.

Action

I treated error mode as the question, not “add cameras.” More streams at 73% just multiplies misses. I worked a 15,000+ image training set and iterated YOLOv9 until reported mAP moved 73% to 89% at 24 FPS real-time inference. I do not invent the split, the augmentations, the GPU, or per-class AP. I do not invent a safety officer I argued with. The disconfirming evidence was the metric and the use case together: a detector that technically runs can still be the wrong thing to hang a compliance workflow on.

Result

89% mAP at 24 FPS. After that gate, a Dockerized multi-feed pipeline processed 20+ camera streams with PostgreSQL audit logging. Automated alerts reduced recorded safety incidents by 50% in the pilot the resume reports. I keep the order honest: quality and real-time first, then width. If they want the pilot site, duration, or how “incident” was coded, that is not locked — I will not mint it.

Spoken 90–120s. “I had a YOLOv9 PPE model at 73% mAP that drew boxes and looked like progress. I did not ship it. Floor safety is not a hackathon demo. I assumed my first ‘it works’ was wrong and I went back to data and training — 15,000+ images — until I had 89% mAP at 24 FPS. Only after that did we go to 20+ cameras and audit logging. The resume’s pilot says recorded violations dropped 50% after alerts. The judgment call was refusing to confuse a running model with a safe one.”

Likely interviewer questions
Why was 73% not enough?

Because the miss is a person without PPE. A demo mAP is an average; the operational cost is the miss on the floor. I treated 73% as evidence against shipping, not as a milestone to celebrate.

Why not just add more cameras at 73%?

That scales the error. Twenty feeds of a weak detector is a wider false sense of safety. Width came after 89% and 24 FPS.

Why not just collect more images?

More data can help. So can labels, class balance, and what you are actually failing on. I would look at the dominant error class rather than assume volume is the only lever. I did use 15k+ images. I do not claim that size alone was the magic.

What belief did you disconfirm?

That “the model runs in real time enough to show” meant we were ready. Running is not ready.

Did anyone want to ship the 73% model?

I do not invent a named stakeholder fight. I can say the temptation exists on every CV demo. I used the metric and the safety bar as the argument, not a personality story.

What does 50% / 2× after alerts mean?

Resume: automated PPE violation alerts reduced recorded safety incidents by 50% in pilot deployment. I have also seen “2×” language in notes as the flip of that family. I will not invent a second study. I speak the resume sentence and I admit I need the coding guide for “incident” if they press.

Deeper probes
mAP of what classes, what IoU?

Not locked. I will not invent 0.5:0.95 versus 0.5 or a class list. If they go there, I say I need the eval notebook.

24 FPS on which hardware?

Not locked. I will not invent a GPU SKU. The resume pairs 89% with 24 FPS as the real-time gate.

How is this different from Highest Standards?

Are Right is “I changed my mind about 73% being done.” Highest Standards is “I would not widen to 20+ cameras until 89% and 24 FPS stayed fixed.” Same project, different question. One opening per hour.

Must remember
  • Refuse 73%. 15k+ images. 89% @ 24 FPS, then 20+ cameras. Pilot −50% recorded incidents.
  • No invented split, GPU, site, or manager fight.
Missing — do not invent
  • Train/val split, class AP, IoU, hardware, pilot definition of incident, duration.
Y3 — MySQL-shaped SQL on Postgres; data disconfirmed “hallucination / empty DB” backup

Coaching: Are Right = you were willing to drop the first story you told yourself. Dive Deep can use the same incident; this answer stresses disconfirming the belief.

Situation

ConvBI’s warehouse is PostgreSQL. The chatbot sometimes returned failures or empty-looking results. The cheap beliefs are “the model hallucinated” or “the database is empty.” Both are tidy. Both were wrong as the first full story.

Task

Disconfirm those beliefs with the actual SQL and the actual rows.

Action

I extracted the generated SQL and ran it. I looked at whether rows existed. They did. I looked at the SQL dialect — MySQL-oriented patterns against PostgreSQL. I inspected the prompt examples that were teaching that dialect. I fixed prompts and added deterministic validation. I still say the validator does not guarantee semantic correctness. I also had the data:null class on a different hop — format mismatch — which is the cousin lesson: do not stop at the slogan.

Result

The NL path stopped dying on dialect mistakes we had accidentally taught. I do not invent a count of tickets. +65% stays a product-level number, not this bug’s A/B.

Follow-ups
What evidence changed your mind?

Rows in the database plus SQL I could read. The query itself showed the dialect mismatch. That beats “the LLM is dumb” as a root cause.

Did you seek another perspective?

I used the database and the prompt file as the other perspectives — not a committee. Official text says seek diverse perspectives and disconfirm. Mine were artifacts, not extra opinions I will invent.

Could it still have been an empty schema cache?

Yes, and I would have checked schema lookup as a hop. In the case I tell, the SQL existed and the dialect was wrong. I do not merge every failure into one myth.

Does validation mean you are now always right?

No. It removes a class of invalid SQL. A legally valid Postgres SELECT can still answer the wrong business question.

Deeper probes
Show me a MySQL-ism you saw.

I speak the class: MySQL-oriented patterns in generated SQL on Postgres. I do not invent a specific backtick or LIMIT/OFFSET dialect example if I cannot see the log. If they want one token, I say I will open the prompt examples rather than guess.

How is this different from Y1 Ownership?

Y1 is “I took the orphaned service.” Y3 is “my first explanation was wrong and I let the SQL talk.” Same chatbot, different LP sentence.

Must remember
  • Beliefs killed: empty DB, “just hallucination.” Evidence: rows + extracted SQL + prompts.
  • Validator ≠ semantic truth.
Missing — do not invent
  • Exact SQL string, date, and which prompt example taught MySQL.
Y6 — measured cache versus guessing “the DB is slow” backup

Coaching: Are Right = mechanism over vibe. −35% methodology is weak — say so. Resume Redis vs this snapshot’s 5-minute in-process Map — say so. Key by role+org, not query text alone.

Situation

Repeat chatbot questions felt slow. The room’s first story is always “GPT is thinking” or “Postgres is slow.” Either can be true. Neither is a design.

Task

Find whether we were repeating database work we had already paid for, without turning cache into a cross-tenant leak.

Action

I treated it as a measurement problem. Repeat suitable bot queries could hit a cache-aside path instead of the warehouse again. The key includes role and org, not query text alone, so a cached payload cannot become another tier’s answer. On a miss, execution still runs as the caller with RLS. Resume: Redis reduced query latency by 35% on that bot-DB story. This Nest checkout has an in-process Map and 5-minute fieldsCache. I say “resume Redis hop versus this snapshot Map.” I do not invent a hit-ratio dashboard or a TTL as a resume number beyond that 5-minute field cache in this tree.

Result

Resume −35% bot-database latency for that family. I will not pretend the methodology is a formal capacity test. I will not say I put Redis in this exact snapshot if they are reading the Map.

Follow-ups
What belief did you drop?

That latency was only the model, or only “the DB is slow” as a personality. Repeat work is a mechanism. Measure the hop.

Why key by role and org?

Because a cache keyed only on the English question would be a leak machine. Two users can ask the same sentence.

Is −35% solid?

It is a resume number whose methodology I treat as weak until I can show baseline, population, and window. I still use it as the order of the story, not as a scientific paper.

Redis or Map?

Resume Redis cache-aside. This checkout: in-process Map, 5-minute fieldsCache. I keep both sentences ready.

Deeper probes
Does cache skip RLS?

It must not. Miss path executes as caller. Hit path must already be keyed by identity. I would rather miss than serve ORG_B’s chart to ORG_A.

Did you scale RDS instead?

That would have been the expensive guess. I do not quote a bill I avoided. Frugality can use this if Invent/Are Right did not already spend it this hour.

Must remember
  • Measure the hop. Key role+org. Resume Redis −35% vs snapshot Map.
  • No invented p95, hit ratio, or bill.
Missing — do not invent
  • Baseline method for −35%; production Redis topology.
DeepQuery — 0% confidence runs were synthesis parse, not retrieval backup

Coaching: Are Right = you would have been wrong to blame the scrape. Learn uses DeepQuery as orchestration curiosity. Think Big uses 200+ sites as breadth. Keep this on the mis-attribution.

Situation

IQVIA DeepQuery is a LangGraph state machine, not a chatty agent: planner, light_search, clarifier, context_builder, query_generator, search_fanout, aggregator, url_intelligence, scrape_controller, cross_page_reasoning, decision_engine, synthesizer. I had saved runs to look at. Some runs looked like failures: metadata confidence 0%, short answers, grade D. The tidy belief is “retrieval died; we did not scrape enough.”

Task

Disconfirm that belief before I “fixed search.”

Action

I looked at the artifacts, not the slogan. A strong run in the same family: 857 URL pool → 120 filtered → about 137 pages, 99% confidence, long report. Weak runs: on the order of 236–256 words, 0% confidence, but facts and pages were still collected. That pattern matches synthesis JSON parse failure or a truncated save after scrape and reasoning already succeeded — not an empty web. Blaming url_intelligence or Firecrawl would have been the wrong fix. Azure OpenAI, local CLI, not a hosted product.

Result

I treat 0% confidence as a synthesizer contract problem until the artifacts say otherwise. I do not quote an IQVIA product percent. I do not claim I already shipped a perfect repair metric.

Follow-ups
Why not blame retrieval?

Because pages and facts were there. The report was short and confidence was zero. That is downstream of scrape.

What would the wrong fix have been?

Raising scrape caps, adding another search engine, or loosening URL filters — spending money and time on a hop that had already worked.

Is 0% a model that is unsure?

In these artifacts it is consistent with parse failure defaulting confidence, not a calibrated epistemic “I don’t know.” I do not oversell it as a philosophical uncertainty story.

Deeper probes
How many such runs?

In the benchmark write-up I use: 12 runs, 10 graded A, 2 graded D with 0% confidence. I do not invent more.

Did you change the synthesizer?

I can speak the diagnosis. I will not invent a production patch percent or a date I “fixed confidence forever.”

Must remember
  • 0% + short text + pages present ⇒ synthesis/parse, not empty retrieval.
  • 857→120→~137 is the strong-run example. No IQVIA % on resume.
Missing — do not invent
  • The exact exception string on those two D runs; whether a fix is merged.

5. Learn and Be Curious

Claude Learn and Be Curious follow-up drill — Claude’s wording, not the locked bank

Leaders are never done learning. They are curious about new possibilities and act to explore them.

Coaching: speak-first is DeepQuery — you learned orchestration, URL intelligence, HITL by building it. Y1 backup is request-map learning. Horizon is the conceptual jump that layers must agree. Hybrid RAG backup is hybrid vs vector-only + 2-hop — not the Invent “split the jobs” paragraph.

IQVIA DeepQuery — learning LangGraph orchestration, URL intel, HITL strongest

Speak-first Learn. You were curious enough to explore a research workflow that is not “chat with tools.” Acted: you built the graph. Not a book report.

Situation

At IQVIA I needed to learn how to run deep research as a system, not as a longer prompt. A single chatty agent that searches and writes is easy to demo and hard to control. I had not shipped this graph before. The resume target is research across 200+ websites with source-aware synthesis. The runtime is a local CLI, Azure OpenAI, not a hosted chat product.

Task

Learn the pieces by implementing them: planning, cheap grounding, clarification, bounded query generation, multi-engine fan-out, URL intelligence before scrape, waved scrape, cross-page reasoning, a decision loop, synthesis, and human-in-the-loop where a human should still speak.

Action

I learned LangGraph as a state machine. Nodes I can walk: planner → light_search → clarifier → context_builder → query_generator (on the order of 12–15 queries) → search_fanout (DDGS, Bing scrape, Firecrawl concurrent per query) → aggregator with URL dedup → url_intelligence (filter before scrape; target often 120–180) → scrape_controller in waves → cross_page_reasoning → decision_engine loop → synthesizer. I learned why URL intelligence sits before Firecrawl: thinking is cheaper than scrape. I learned HITL as pre-clarify modes and post-run refinement that re-enters at url_intelligence — not a human typing every query. I learned to read artifacts when confidence said 0%. Curiosity that does not open the folder is tourism.

Result

I can operate and explain a deep-research graph that fans out and then bounds cost with a filter. Example strong run: 857 URLs → 120 filtered → ~137 pages. I do not quote an IQVIA latency or success percent. I am still learning the failure class on synthesis parse. That is the point of the LP — never done.

Spoken 90–120s. “I had to learn deep research as a state machine, not as a chatty agent. I built DeepQuery on LangGraph: plan, a light search so clarification is grounded, a bounded 12–15 query generation, fan-out across DDGS, Bing, and Firecrawl, then URL intelligence before I pay for scrape — we often aim to keep the scrape set in a 120–180 band — then waved scrape, cross-page reasoning, a decision loop, and synthesis. HITL is clarify and refine, not a human inside every node. I learned the hard way that a 0% confidence file can still have pages; the lesson was in the synthesizer. A strong run in my notes went 857 URLs to 120 filtered to about 137 pages. I do not have an IQVIA percent to quote.”

Likely interviewer questions
What did you have to learn that you did not know?

How to keep research state explicit; how to put a think hop before scrape; how fan-out without a filter becomes a cost bomb; how HITL should re-enter a graph. I did not learn that from a course title. I learned it by wiring nodes and reading failed saves.

Why multiple search sources?

One engine is one blind spot. DDGS, Bing HTML, and Firecrawl search fail differently. Diversity is a research need, not a logo collection.

What is URL intelligence?

A filter-and-score hop on the candidate pool so we scrape fewer useless routes. Target scrape set often 120–180 from a much larger pool. I do not invent a feature-weight formula I cannot open in code.

Where is the human?

Pre-clarify: auto / hybrid / manual. Post-run refinement re-enters at url_intelligence. Not a human approving every URL in the 857.

Is this hosted?

Local CLI plus artifact folders. I do not claim a multi-tenant IQVIA SaaS for DeepQuery.

How is this different from Hybrid RAG?

DeepQuery browses the web. Hybrid RAG indexes a BRD you already have. Same intern, two systems. I never say “my IQVIA agent” as if they were one.

Deeper probes
Playwright?

Notes mention Playwright-class work when useful content is browser-rendered. I will not claim a Playwright node if the walk I am doing is DDGS / Bing / Firecrawl. If they ask why a browser scraper exists in the ecosystem, I say JS-rendered sources. I do not invent that every run uses it.

What will you learn next on this graph?

Make synthesis parse failures visible as a first-class status, not a 0% that looks like “the web was empty.” I do not invent that I already did.

Did you only read LangGraph docs?

Docs do not teach our URL cap or our 0% saves. I learned by running and opening folders. Same habit as Y1’s request map, different internship.

Must remember
  • State machine, not chatty agents. Filter before scrape. HITL at clarify/refine.
  • 857→120→~137 speakable. No IQVIA %. Local CLI.
Missing — do not invent
  • Exact URL-intel weights; Playwright-in-path claim without opening the node list.
Y1 — learned the inherited LangChain path by request-map backup

Coaching: Learn angle only. Ownership already used “I took the gap.” Here the sentence is how you learn unfamiliar code.

Situation

When the chatbot became mine, I did not understand LangChain state, dynamic prompts, schema lookup, SQL generation, Nest execution, and the UI parser as one machine. I could have learned “LangChain” as a library.

Task

Become productive on this path, not on a generic tutorial.

Action

I built a system map from the request, hop by hop, and I only opened a library when a hop forced me. I added boundary logs so the next unknown was smaller. Curiosity was directed: what does this stage emit, and who consumes it?

Result

I could find format mismatches and dialect bugs because I knew the seams. I do not invent a course certificate or a time-to-green metric.

Follow-ups
How did you learn it quickly?

Request path first, libraries second. I reproduced locally and wrote the hop list. Speed came from not boiling the ocean.

What did you stay curious about after it worked?

Whether validation was lying about semantics, and whether MySQL examples were still in the prompts. Working is not understood.

Would you still take a course?

Yes, after I have a map. A course without our state object is trivia.

Deeper probes
What was the hardest hop to learn?

The state-format contract between generation and the parser — the data:null class. The library docs do not mention our field names.

LangGraph envy?

I learned LangGraph at IQVIA later. I did not rewrite Ylogx to look modern. Chronology, not ranking.

Must remember
  • Learn by request-map. Not “I read LangChain.”
Missing — do not invent
  • Calendar time to first independent fix.
Horizon — ROS2 + GStreamer + ZED; layers must agree backup

Coaching: Learn = conceptual jump. Not Ownership’s “I owned video.” Not Invent’s “pipeline vs frames.”

Situation

I came into Horizon as software, not as someone who already thought in ROS2 frames, media pipelines, and stereo depth at once. Those look like three tools. They are three languages that only work when they agree.

Task

Learn enough of each layer to integrate video and ZED perception without pretending I had learned planning.

Action

I learned ROS2 as a graph of nodes and frames, GStreamer as a media pipeline, ZED as a depth and point-cloud source at 2M+ samples/sec on the resume, and RViz/Gazebo as the place you see whether those frames actually line up. The jump was: camera image, depth, coordinate frames, map, visualization, and navigation are separate. If the frame IDs or the time stamps disagree, you have a confident lie. I acted by integrating perception into the nav conversation, not by reading a robotics textbook to the end.

Result

I could contribute to a competition rover as core software. I still cannot honestly teach the predictive planner. That remaining ignorance is part of the LP — I know where my learning stopped.

Follow-ups
What was the hardest conceptual jump?

That a pretty camera feed and a point cloud can still be useless to navigation if frames and interfaces do not agree. Tools are not a stack until the contracts match.

How did you explore it?

Visualization first — RViz and Gazebo — then the pipe, then the integration point. I did not start at the planner I did not own.

+40% — did you learn that number was weak?

Yes. Notes compare GStreamer to other video-feed tools. That is not Argus-style mAP. I learned to be suspicious of my own resume line.

Deeper probes
TF trees — did you own them?

I needed them to be right for ZED and video to be useful. I do not claim I designed the full robot TF. If I cannot show the URDF I wrote, I do not say I did.

What are you still curious about?

How the planner I did not write consumes the costmap my perception fed. I can study that without stealing credit.

Must remember
  • Jump = layers must agree. Stop at planner honesty.
  • +40% definition weak — say so if the number comes up.
Missing — do not invent
  • Which frames I authored; classroom courses I “used.”
IQVIA Hybrid RAG — hybrid vs vector-only + Neo4j 2-hop backup

Coaching: Learn angle. Invent already used “do not make one model do everything.” Here you learned why BM25 + kNN + semantic rerank + 2-hop is a different question than “embed the PDF.”

Situation

I already knew a vector store can retrieve “similar” chunks. A 200+ page BRD is full of requirements that depend on each other. Similarity is not dependency. I was curious whether hybrid search plus a graph would teach me something vector-only would hide.

Task

Learn the retrieval modes by wiring them, not by watching a keynote.

Action

I learned Azure AI Search hybrid as BM25 plus vector kNN plus a semantic reranker on index brd-documents, and I learned Neo4j as Document / Requirement / Entity with DEPENDS_ON that I can walk two hops. Chunking math I can recite: 1500 tokens, 200 overlap, cl100k_base, 3072-dim embeddings. I learned the two graphs must not be confused: LangGraph is the workflow; Neo4j is the knowledge graph. I learned Redis/Celery are in the file and not in the runtime. I learned I do not have a labeled IR set — so I have not “learned” recall.

Result

I can explain when I want lexical match, when I want neighbors in embedding space, when I want a reranker, and when I want “this requirement depends on that one.” I do not quote a quality percent.

Follow-ups
Why not vector-only?

Because identifiers, section numbers, and exact phrases in a BRD often lose to cosine. BM25 still matters. And “depends on” is a walk, not a nearest neighbor.

What is a 2-hop?

From a retrieved requirement, step to neighbors over DEPENDS_ON so a test case sees the prerequisite, not just the similar paragraph.

What did you learn you still do not know?

Whether hybrid+graph beats vector-only on a labeled set. I have not built that set. Curiosity includes stopping at the evidence I have.

Deeper probes
Chunk tokenizer versus embedding tokenizer?

Chunk boundaries use cl100k_base. Embeddings are the Azure deployment’s tokenizer. They are a common approximation, not proof they are identical. I learned that distinction from the code, not from marketing.

Same story as Invent?

No. Invent is job-splitting. This is retrieval-mode curiosity. I change the first sentence.

Must remember
  • Hybrid = BM25 + kNN + semantic rerank + 2-hop. Two meanings of graph.
  • No recall/precision. Redis not wired.
Missing — do not invent
  • Reranker configuration name; hop Cypher I cannot quote from memory without opening the service.

6. Hire and Develop the Best

Claude Hire and Develop follow-up drill — Claude’s wording, not the locked bank

Leaders raise the bar with every hire and promotion. They develop leaders and take coaching seriously.

Coaching: this is the thin LP. Adarsh is IEDC Tech Team member, not lead. Resume has no mentee count. Do not invent a named mentee or a fake outcome. Stories 1–3 stay inside documented pairing and process. Story 4 is a labeled hypothetical — never present as fact. Do not rank internships.

IEDC Tech Team member — pairing, not a lead narrative strongest

Speak-first because it is the honest campus leadership line. Strength is humility plus a real mechanism: pairing on tech-team work. Weakness is no named mentee and no count. If they ask for “one person you developed,” do not mint a name.

Situation

At CUSAT I sat on the IEDC Tech Team as a member — the resume says Tech Team, IEDC CUSAT, not president, not hiring manager, not a mentee program with a headcount. IEDC is a campus innovation cell. People show up with half-built hackathon ideas, half-broken Git, and a lot of confidence. If I tell this as “I raised the bar with every hire,” I am lying. We were not hiring.

Task

Help other students become able to ship their own piece — not collect a mentee statistic, not take their repo.

Action

I paired. The pattern I can defend without a name: sit on the same laptop or the same call, make them drive, and force the same habits I use on intern work — reproduce locally, name the hop that failed, do not paste a stack overflow answer you cannot explain. I reviewed ideas the way I want a reviewer to review me: what is the customer loop, what is the failure if the demo Wi-Fi dies, what will you delete. I did not run a promotion committee. I did not assign performance ratings. When someone wanted me to “just finish their module,” I treated that as the opposite of develop — I would do the hard part with them once, then make them do the next one.

Result

I can say I took coaching and pairing seriously as a member. I cannot say “N mentees reached production.” I will not invent a student whose app got users because of me. Across campus I also have eight hackathons with CodeRecet 1st, MLH Best Project, Magnathon 2.0 runner-up — those are my results, not a coaching scoreboard I will hang on someone else.

Spoken 90–120s. “I am an IEDC Tech Team member, not the lead and not a hiring manager. The resume has no mentee count and I will not invent one. What I actually did was pair: they drive, we reproduce the break, we name the hop, they take the next change. If they wanted me to finish the module so they could present, that is not developing them. I do not have a named person and a before/after I can defend in this room. If that is the bar for the question, I would rather say the gap than mint a story.”

Likely interviewer questions
Tell me about someone you developed.

I do not have a locked name and outcome on paper. I will describe the pairing pattern. I will not invent a mentee. If they need a named person, I say that is missing and I will not fill it live.

Were you the IEDC lead?

No. Tech Team member. Same honesty as Horizon core software member, not team lead.

How do you raise the bar if you cannot hire?

On a campus team the bar is what you accept in a PR or a demo. I refused to accept “it works on my machine” as a story, and I refused to accept me shipping their feature as mentorship.

How do you take coaching?

The internships are where I was coached: inherited chatbot, RLS review, ERC integration. I ask for the hop I got wrong, not for comfort. I do not invent a manager’s speech.

Eight hackathons — did you coach those teams?

Those are my placements. I will not convert them into a coaching program. If I paired at a hackathon, I still do not have a named mentee outcome in the lock.

CGPA 8.42 or 8.12?

resume.md is 8.42. A September 2026 summary PDF says 8.12. I flag it. I do not pick a fight. I align documents before I speak a number. That is not Hire — but if they opened education, I do not bluff.

Deeper probes
This sounds thin. What else have you got?

Horizon launch pairing and Ylogx branch discipline. I still will not invent a junior I onboarded onto RLS. That card is labeled makeup.

Would you hire yourself?

I would hire the person who draws I vs we and kills 73% mAP. I would not hire the person who invents mentees. That is the bar I apply to my own answers.

Did you interview anyone?

No campus hiring loop I will claim. I do not invent an interview rubric.

Must remember
  • Member, not lead. No mentee count. No named mentee.
  • Mechanism = pairing, they drive, hop names, refuse to finish their module.
Missing — do not invent
  • A real name, a skill they lacked, a measurable improvement, a duration of pairing.
Horizon — launch pairing / knowledge sharing on the video pipeline backup

Coaching: develop = making the next person able to run GStreamer/ZED when you are not on the headset. Still no named mentee. Still not team lead.

Situation

On Horizon the video and ZED path was easy to make a single-person mystery. ERC does not care that I understood GStreamer if the next software member cannot bring the POV up.

Task

Share the pipeline so it was a team asset: how to start it, where it breaks, what I did not own.

Action

I paired on launch: bring the GStreamer path up, show the multi-feed POV, show where ZED data entered visualization, and say out loud that the planner was not mine so nobody inherited a lie. Knowledge sharing was “here is the interface,” not “watch me be a hero on launch day.”

Result

The rover’s software story was not trapped in one head as badly as it could have been. I do not invent that a named junior became perception lead. ERC 17th/80+ (flag ~18th) is a team result, not a coaching KPI.

Follow-ups
Who did you train?

Other software members on the launch path. I do not have a locked name. I will not mint one.

What did you teach besides commands?

The ownership boundary. Teaching someone the planner I did not write would have been theater. Teaching them the pipe and the lie to avoid is develop.

Were you their manager?

No. Peer on a student team.

Deeper probes
Any written runbook?

I will not invent a wiki URL. Pairing on launch is what I can defend. If a doc exists I will point to it when I have it; I will not describe pages I cannot see.

How is this different from Ownership Horizon?

Ownership is “I owned video+ZED.” This is “I made that knowledge transferable.” Same rover, different sentence.

Must remember
  • Pair on launch. Teach the boundary. No named mentee. Not lead.
Missing — do not invent
  • Names, runbook location, hours taught.
Y9 — Git branch discipline so teammates stop colliding backup

Coaching: develop-the-team via process, not a mentee fable. Earn Trust adjacent. Keep it small and true.

Situation

On ConvBI we had Git collisions — two people in the same files, merge pain, lost time. That is how a small intern team accidentally trains everyone to fear touching the chatbot or the report builder.

Task

Make branch separation clear enough that the next change did not require a hero merge.

Action

I pushed for clearer branch separation so workstreams — bot, reports, dashboards, RLS — did not sit on one sticky branch. The coaching move was not a lecture on Git theory. It was “this is why your Friday night conflict happened” and a simpler lane so people could develop features without stepping on each other.

Result

Fewer collide-and-blame cycles as a class. I do not invent a conflict count or that I became GitHub org owner.

Follow-ups
How is this Hire and Develop?

Because the team gets faster when the next intern can own a lane. Process is how you develop people when you cannot hire.

Did you enforce rebase law?

I do not invent a rebase religion. I speak clearer branch separation. If they want the exact branching model, I say I need to lock it.

Was this after a blow-up?

It was after collisions. I do not invent a fight or a missed deadline.

Deeper probes
What lanes?

Bot versus builder versus dashboards versus the RLS middleware — the seams we already had. I do not invent GitFlow ceremony.

I vs we?

I argued for separation and kept my work on a lane. We still merged as a team.

Must remember
  • Collisions → clearer branches. No conflict %, no manager fight, no missed deadline.
Missing — do not invent
  • Exact branch names, protected-branch settings, number of incidents.
MAKE-UP — hypothetical junior onboarding onto ConvBI RLS makeup
MAKE-UP / HYPOTHETICAL — DO NOT PRESENT AS FACT. There is no documented junior, no onboarding week, and no mentee outcome. If they ask for a coaching anecdote you do not have, you may think aloud with this as a would-do design. You may not slip into past tense. You may not give this person a name.

Situation

Hypothetical. A new intern joins ConvBI and is about to touch a handler that talks to Postgres.

Task

Hypothetical. Get them safe on RLS before they ship a JOIN.

Action

I would sit them on one request: JWT → transaction → SET ROLE → GUC from JWT → a SELECT that asks for the other org and comes back with zero rows. I would make them draw executeWithoutRLS and say out loud which tables must never use it. I would not let them “add organizationId in the prompt” as their first PR. I would not invent that I already ran this program.

Result

None in reality. The hoped-for result would be a person who can fail closed without me in the room. I do not have that story.

Follow-ups (still hypothetical)
Can I tell this as “I onboarded a junior”?

No. That would be a fact you do not have. If you hear yourself use past tense, stop.

Why have this card at all?

So you can answer “how would you develop someone on your last team?” as a design, and so you do not panic-invent a mentee.

What if they insist on a real coaching story?

Return to IEDC pairing or Horizon launch pairing. Repeat that names and counts are not on the resume.

Deeper probes
Give the junior a name to make it vivid?

No. A name is how a makeup becomes a lie.

Could Y1 teammate-left be coaching?

No. That person left. You inherited code, not a mentee.

Must remember
  • Badge makeup. Red box. Future tense. No name. Do not present as fact.

7. Insist on the Highest Standards

Claude Highest Standards follow-up drill — Claude’s wording, not the locked bank

Leaders have relentlessly high standards. Defects do not get sent down the line. Problems are fixed so they stay fixed.

Coaching: speak-first is Argus as a gate — 89% and 24 FPS before width. Are Right already used “I refused 73%.” Do not open both with the same first sentence in one hour. Y5 here is “LLM is not a security control.” Notes crash is “fix so it stays fixed.” IQVIA is LangSmith plus validator honesty — no demo-only RAG.

Argus — 89% mAP and 24 FPS before 20+ cameras strongest

Speak-first Standards. Defects do not go down the line: a weak detector does not get multiplied across a floor. Problems stay fixed: the quality gate is in front of scale, not a hope after alerts.

Situation

After I had a detector that ran, the next tempting defect was architectural: wire 20+ cameras and “improve the model later.” That sends a known quality defect down the line into every feed and every audit row.

Task

Hold a gate: real-time and quality first, width second. 89% mAP and 24 FPS were the resume bars I used as “this may proceed.”

Action

I kept training and evaluation on the 15k+ set until 73% was not the number we were about to multiply. I required 24 FPS so a “high quality” model that cannot keep up is also a defect — a late box is a miss in motion. Only then did I deploy a Dockerized multi-feed pipeline with PostgreSQL audit logging and automated violation alerts. I did not treat alerts as a substitute for detection quality. Alerts on garbage detections are a defect amplifier.

Result

20+ streams sat behind a model I was willing to stand in front of. Pilot: recorded safety incidents −50% after alerts. I still do not invent the coding guide. I do not say 73% shipped “for a while” unless I can prove a staged rollout — the story I tell is refuse, then gate, then widen.

Spoken 90–120s. “Highest standard on Argus was not a slogan about safety. It was a sequence. I would not send a 73% model down the line into 20 cameras. I held 89% mAP and 24 FPS as the gate — quality and real-time — and only then did we Dockerize multi-feed, log to Postgres, and alert. If I reverse that order I multiply misses. The pilot’s recorded incidents dropped 50% after alerts. I need the incident definition if you press the number. The standard I will repeat is: defects do not get a wider pipe.”

Likely interviewer questions
What defect were you refusing to pass down the line?

A detector that was not good enough for PPE compliance, and a detector that was not real-time. Either one becomes twenty defects if I widen first.

Is 89% high enough?

It was the bar I used to allow width. I do not claim it is human-level or that class-wise performance is even. I would keep raising it if the miss class was still operationally bad. I do not invent that class list.

Why 24 FPS as a standard, not just mAP?

A correct box that arrives after the person left the frame is a miss. Standards here are quality and timeliness together.

Did the pilot fix stay fixed?

Audit logging plus alerts are how a detection becomes an operational loop. I do not invent a six-month regression test. Dockerizing the multi-feed path is how I kept the runtime repeatable.

How is this different from Are Right?

Are Right is changing my mind about 73%. Standards is the gate in front of 20+ cameras. If I already told Argus this hour, I should use Y5 or the Ylogx crash for Standards.

Would you ship 89% in a warehouse Amazon runs?

I would ask what miss is acceptable and measure class-wise. I would not import Argus’s number as a universal safety SLA. I do not invent Amazon’s PPE policy.

Deeper probes
What would have been “demo quality”?

73% on one webcam, no audit trail, no FPS gate. That is the defect I refused to send down the line.

Any label-quality standard?

I know labels matter. I do not have a locked inter-annotator number. I will not invent one.

2× after alerts?

Stay with resume −50% recorded incidents in pilot. Do not add a second invented multiplier.

Must remember
  • Gate: 89% + 24 FPS then 20+ cameras. Defect = weak model × width.
  • If Argus already used this hour, switch LP story.
Missing — do not invent
  • Class-wise AP, hardware, label protocol, incident coding, how long 73% existed internally.
Y5 — refuse LLM-as-security backup

Coaching: Standards angle. Ownership Y5 was “I took the boundary.” Here the sentence is “a fluent SQL is not a control.”

Situation

The chatbot could generate a JOIN that looked professional and still returned another organization’s facts. If I had accepted “the model usually adds the filter,” I would have sent a defect to every customer.

Task

Make authorization deterministic. The model does not get a vote.

Action

Authentication, then RBAC on feature and table, then a non-owner DB role on a per-request transaction, then RLS USING the org GUC copied from JWT. Fail closed to rls_no_access. I did not accept prompt-level security as a standard. I keep executeWithoutRLS off warehouse facts. I say Postgres filters rows; it does not reject a legal SELECT. I say the SQL validator does not make the number true.

Result

Three-tier isolation as a product standard, not a hope. 99.9% is not this standard. I do not invent a red-team report.

Follow-ups
Why wasn’t an application WHERE enough?

The first handler you forget is the defect you shipped. The database has to remain the last filter.

Is the validator a high standard?

It is a standard against invalid SQL. It is not a standard against a wrong total. I will not sell it as semantic safety.

Did you send a defect down the line once?

The RESET ROLE leak class is why fail-closed exists in the story. I do not invent a customer-visible breach. I say an earlier RESET path was not acceptable and we closed it.

Deeper probes
FORCE RLS?

I do not claim FORCE ROW LEVEL SECURITY unless I can show it in the live tree. Highest Standards includes not over-claiming the control.

Same as Ownership Y5?

Same mechanism, different first sentence. One per hour.

Must remember
  • LLM is not a control. Filter ≠ reject. Validator ≠ truth. executeWithoutRLS is scoped.
Missing — do not invent
  • A named production incident. FORCE RLS in prod.
Ylogx notes — client-side aggregation crash; fix so it stays fixed notes

Coaching: handwritten, speakable, no new percents. 40% faster reports and 99.9% are not measured solely from this crash.

Situation

Dynamic reports could aggregate and filter across chart types. I put that aggregation on the client. When a user asked for a large slice, the browser crashed. The agent path on that UI became unstable. That is a defect I sent to the operator’s tab.

Task

Keep heavy aggregation off the client when the slice is large, and make the fix structural so the next large slice does not revive the crash.

Action

I moved heavy aggregation to a server / preload path for the AI-requested report. I required an explicit click to load full data instead of stuffing the tab. I cleaned up so the agent and the UI stayed stable. Multi-chart generation stayed on the LLM path as data, not as screenshots of reports. I did not weaken RLS to “make the chart easier.”

Result

The UI rendered. The agent stayed stable. I do not claim this crash study produced the resume’s 40% or 99.9%. Those are product-family numbers. This story is the defect class and the stay-fixed shape: server path plus explicit load.

Follow-ups
What was the cost?

A crashed tab and an unstable agent in a review or a real session. I do not invent a client name or a lost deal.

Why did it stay fixed?

Because the default is no longer “dump the large slice into the browser.” The server path and the click-to-load are the new line. A hotfix that left aggregation on the client would have come back.

Is this your 40%?

No. I will not pin 40% faster reports on this crash.

Deeper probes
How large was the slice?

Not locked. I say “large enough to crash the tab.” I do not invent row counts.

Failure they can use if they ask for a mistake?

Yes. I sent aggregation to the client. That was my defect. Cost was a crashed UI. Fix was structural.

Must remember
  • Client agg crashed. Server path + click to load. Not the 40% / 99.9% study.
  • Do not weaken RLS to fix a UI crash.
Missing — do not invent
  • Row count, browser, date, whether a client saw it live.
IQVIA — LangSmith, not demo-only RAG; validator honesty backup

Coaching: Standards = observability and not pretending evals you do not have. Cross-wire validator honesty from Ylogx if they stay on “does your check make GenAI safe?”

Situation

Hybrid RAG and DeepQuery can look brilliant in a stakeholder window and still be uninspected. A demo-only RAG is a defect you send to the next team.

Task

Make the system traceable, and refuse to claim quality numbers I did not measure.

Action

I used LangSmith so a run is a trace, not a vibe. I kept ingestion, retrieval, graph, and test generation as separate inspectable stages. I say out loud: no labeled precision/recall set; Redis/Celery not wired; DeepQuery 0% confidence can be parse failure. On Ylogx I say the SQL validator does not guarantee semantic correctness — I bring that honesty here so I do not grow a second personality. Stakeholder demo notes: DOM was truncated, the agent clicked the last chart’s zoom, I raised DOM max chars and max DOM elements 50→80, reasoning med because low failed; the path then demoed. I do not hang an IQVIA percent on that demo.

Result

I can inspect what happened. I can demo after the DOM fix. I still do not have a published IR quality bar. The standard includes saying that.

Follow-ups
What did you refuse to claim?

Recall, precision, a hosted SLA, Redis-backed jobs, and any IQVIA latency percent.

Is LangSmith an eval harness?

It is tracing / observability in the story I can defend. I do not invent a golden set size or a scorecard I cannot open.

DOM truncation — is that Highest Standards?

It is a defect that made the agent wrong in a stakeholder test. I fixed config so the agent could see the control. I do not turn it into a resume metric. Dive Deep can use the same notes if this hour already spent Standards on Argus.

Deeper probes
Did low reasoning fail?

Yes — notes say reasoning med; low did not work. I do not invent token counts.

Validator honesty in one line?

A check can remove a bad class and still leave a wrong business answer. I will not advertise a validator as “the model is safe.”

Must remember
  • LangSmith = inspect. No IR labels. No IQVIA %. DOM 50→80, reasoning med, then demoed.
  • Validator ≠ semantic correctness (Ylogx honesty travels).
Missing — do not invent
  • LangSmith project name, eval suite size, stakeholder titles.

8. Think Big

Claude Think Big follow-up drill — Claude’s wording, not the locked bank

Leaders create and communicate a bold direction. They think differently and look around corners for ways to serve customers.

Coaching: speak-first is StratifyLabs as a platform, not a model demo. IQVIA Deep Research is backup only for Think Big (Learn already owns it as primary). GiftedBooks here is “learning system, not chat box.” ConvBI is one product vision — do not dump six metrics. Do not rank internships.

StratifyLabs — platform, not one demo (3D lab + marketplace + browser inference) strongest

Speak-first Think Big. Invent already used “browser inference simplifies setup.” Here the sentence is the direction: CV experimentation as a place, not a notebook.

Situation

Most student and indie CV work I watched was a one-off: one dataset, one model, one local GPU, then the repo rots. The corner I did not want to miss was that the next experiment would repeat the same scaffolding — environment, inference, sharing — every time.

Task

Communicate and build a broader direction: a computer-vision SaaS where simulation, inference, reuse, and conversation sit in one browser. Not “I trained a model.”

Action

I built StratifyLabs at stratifylabs.design as a platform: an integrated 3D simulation lab, browser-based WebGL inference so you do not start with a local GPU, a marketplace with 50+ pre-trained models and dataset hosting, a URDF robot code editor for 3D prototyping, community profiles, and Gemini-powered RAG voice agents with animated 3D characters so you can talk inside the simulated environment. The bold part is the combination. Each piece exists elsewhere. The direction is “the iteration loop lives here.” If they open GitHub and see a Next.js scaffold README, I say resume and the live site win, and I would fix the README — I do not shrink the vision to match a stub README, and I do not invent users I cannot defend.

Result

Resume: −30% ML iteration time; marketplace 50+. I do not invent MAU, revenue, or a GPU bill. I do not claim this replaced Amazon SageMaker. I claim I pointed at a bigger loop than a demo notebook.

Spoken 90–120s. “I did not want another one-model demo. StratifyLabs was a direction: do computer-vision iteration in the browser — 3D lab, WebGL inference without a local GPU, a marketplace of 50+ models and datasets, URDF prototyping, and voice RAG characters in the scene. The corner I was looking around was the next student’s wasted week on environment setup and the next team retraining a model that already existed. We reported a 30% cut in iteration time. The GitHub README currently looks like a Next.js scaffold; the resume and stratifylabs.design are the product I will talk about, and I would align the repo.”

Likely interviewer questions
Why a platform instead of a simple ML demo?

Because the wasted time was the loop, not the forward pass. Demo notebooks do not reuse, do not simulate, and do not share. I wanted those corners in one product.

What was the bold direction in one sentence?

Make CV experimentation a shared place in the browser, not a private GPU ritual.

Isn’t this just Three.js plus an API?

The pieces are ordinary. The direction is the loop: simulate, infer, reuse, talk. I will not inflate it into a foundation-model company.

Who is the customer at scale?

Students and builders who iterate on perception without a lab. I do not invent a headcount. I do not invent an enterprise contract.

GitHub looks empty. Did you think big or think slide-deck?

The README is wrong-shaped today. That is an Earn Trust fix. The live product and the resume are the direction I shipped. I do not hide the mismatch.

How is this different from Invent StratifyLabs?

Invent is “browser inference and a marketplace simplify setup.” Think Big is “I was building a platform on purpose.” One opening per hour.

Deeper probes
−30% baseline?

Not locked. I will not invent a diary study. The number is resume-reported iteration-cycle reduction via WebGL inference.

What did you look around the corner and miss?

Repo hygiene — a scaffold README — is a corner I underweighted. The product vision is not an excuse for a misleading front door.

Would you do this at Amazon?

I would still ask what loop we are in and whether we are building a demo or a place. I do not pretend StratifyLabs is an Amazon internal platform.

Must remember
  • Platform = lab + marketplace + browser inference + URDF + voice RAG. Not one notebook.
  • README scaffold: say it. −30% / 50+ resume. No MAU, no bills.
Missing — do not invent
  • User count, baseline method, which of the 50+ I trained.
IQVIA Deep Research — 200+ sites, breadth with a bound (backup) backup

Coaching: Think Big backup only. Learn is the primary DeepQuery card. Here the sentence is breadth plus filter so cost stays bounded — looking around the corner of “one search box.”

Situation

A single search engine is a narrow room. The research questions IQVIA pointed at needed a wide evidence set — resume 200+ websites — without turning the run into an unbounded crawl that nobody can defend.

Task

Set a direction: orchestrated multi-source research that stays wide and then chooses.

Action

I designed for fan-out first — many queries, several engines — then URL intelligence so the scrape set is chosen, often in a 120–180 band from a pool that can be hundreds (example 857 → 120 → ~137 pages). The bold idea is not “scrape the internet.” It is “breadth with a think hop.” Local CLI, Azure OpenAI. I do not claim a hosted IQVIA research product for the world.

Result

A system that can leave a 200+ site class evidence trail and still stop. I do not quote an IQVIA percent. If Learn already used DeepQuery this hour, I should not also open Think Big here unless they pull me.

Follow-ups
Why 200+ websites?

Breadth and source diversity. One index is one bias. The resume number is the research class, not a promise that every run hits the same count.

Isn’t more URLs just more cost?

That is the corner. Filter before scrape. The pool can be 857; the scrape is the chosen set. Thinking big without a bound is just a bill I will not invent.

What is the direction you communicated?

Research as a graph with a decision loop, not as a longer chat.

Deeper probes
Is this bigger than Hybrid RAG?

Different direction: web versus your BRD. I do not rank them. Chronology: both IQVIA, April 2026–present.

Did 0% confidence shrink the vision?

It shrank my trust in confidence as a banner. It did not mean the architecture should become a single search box again.

Must remember
  • Backup only. Breadth + filter. 200+ is resume class. Example 857→120→~137.
  • No IQVIA %. Not hosted.
Missing — do not invent
  • A product launch plan or customer count inside IQVIA.
GiftedBooks — VR + RAG + PYQ as a learning system, not a chat box backup

Coaching: Think Big only if Customer did not already spend GiftedBooks this hour. Emphasis is the system, not the 3–10 minute wait — you may mention the wait as a result, not as the whole LP.

Situation

The default “edtech AI” is a chat widget glued to a PDF. That is a small idea. Students already have chat widgets. They do not have a place where the lab, the grounded tutor, and the exam map are one environment.

Task

Build a learning suite, not a wrapper.

Action

I put three directions in one product at giftedbooks.study: VR 3D labs and avatars as the place you stay, PDF RAG as the grounded doubt path, and PYQ analytics as the map of what past papers actually used. The corner is dropping any one of those and getting a gadget. README currently says AegisAI — I flag it; resume wins.

Result

A suite with resume user-testing: sub-300ms Q&A, 99.5% uptime, +35% reading, +50% engagement, 2.5× comprehension, doubts hours → 3–10 min. I do not dump all of those unless asked. For Think Big I pick the system shape first, then one outcome if they want proof anyone used it.

Follow-ups
What was the bold idea?

A study environment where presence, grounded answers, and exam-map analytics are one loop — not a chatbot sticker.

Is VR the big idea?

VR is the shell. The direction is the loop. VR without grounding is a headset. RAG without PYQ is a tutor with no map. PYQ without the lab is a spreadsheet.

Did you already tell GiftedBooks?

If I used 3–10 min for Customer this hour, I pick StratifyLabs or ConvBI here. I do not replay the same spoken story.

Deeper probes
Student headcount?

Not on the resume. I will not invent it.

AegisAI overlap?

Different project. Safety app versus learning suite. README mismatch is not a product merge.

Must remember
  • System = VR + grounded RAG + PYQ. Not a widget. README flag.
  • Do not reuse as Customer in the same hour.
Missing — do not invent
  • User-testing N; student headcount.
ConvBI — conversational BI + reports + KPIs + tenant security as one product backup

Coaching: Think Big for Ylogx is the product shape. Do not dump 40%, 99.9%, +65%, −35%, +60%, sub-210ms. Ownership Y8 was deploy-path. This is the direction you were building toward.

Situation

Operators were stuck between a SQL client, a static dashboard, and a chat toy that could not be trusted on a shared warehouse. Each of those is a small product. The corner is an org that needs all four jobs in one place: ask in language, save a report, watch KPIs, and not see each other’s rows.

Task

Treat ConvBI / Projas as that product, not as “we added a bot to Power BI.”

Action

I worked the pieces as one direction: LangChain SQL-RAG for questions, a custom report builder with a shared renderer, thirty deterministic KPI dashboards, and RLS+RBAC so the exploratory path cannot become a leak. FastAPI proposes; Nest executes as the caller. Tiles do not wait on an LLM. The bold communication was: conversational and deterministic can live together if security is in Postgres. I was an intern, not the founder of record and not the AWS account owner.

Result

A BI product that went through client review cycles and a serving path on ECS / ALB / CloudFront / Route 53. If they demand numbers I pick one that matches their question — not the list. I do not rank this internship against IQVIA or Horizon.

Follow-ups
What was the direction?

One product where language, saved reports, live KPIs, and tenant isolation are the same system — not four tools taped at a demo.

Isn’t that just a startup pitch?

The mechanism is the pitch: shared renderer, deterministic tiles, RLS on generated SQL. A pitch without those is a slide.

Recite your metrics.

I will not. Ask which outcome you care about. Reports time, uptime, analyst productivity, bot-DB cache, dashboard overhead, tile latency — those are different studies. Dumping them is not Think Big; it is a resume read-aloud.

Deeper probes
What corner did you miss?

Client-side aggregation on large slices — I sent a crash down the line. Thinking big about charts without a server path was incomplete. I fixed that so it would stay fixed.

Ylogx already used this hour?

Then Think Big should be StratifyLabs. Ylogx primaries in a ConvBI-heavy hour stay Ownership, Frugality, Dive Deep.

Must remember
  • One product: NL + reports + KPIs + RLS. No metric dump.
  • Intern, not founder, not AWS owner. Do not rank internships.
Missing — do not invent
  • Company vision-deck quotes; customer logos; a TAM slide.

How to use LPs 9–16

This is rehearsal, not a scoring sheet. Speak as Adarsh. Coaching notes can sit in third person. Do not name the poster Leadership Principle out loud. Do not invent metrics, mentee names, manager fights, missed deadlines, Qdrant, Haar, p95, TTL, or bills.

LPs 9–16 share projects with 1–8. The first sentence must change. One project per spoken answer. Do not stack IQVIA + Ylogx + Horizon in one breath. Timeline is chronology, not a ranking. Never say an internship was “the deepest.”

Must remember — spoken form
  • 90–120 seconds for the first STAR. Situation and Task are short. Action is the meat. Result is one or two sentences, then stop.
  • I vs we. Horizon and ConvBI are we. I is video+ZED, Nest RLS middleware, inherited chatbot map, renderer prototype, DeepQuery nodes I can walk, Argus training loop I ran.
  • Do not name the poster LP. Answer the question they asked.
  • No documented manager fight. Do not manufacture one for Backbone. Design disagreement plus a prototype or an eval plan is what you have.
  • No documented missed deadline, critical-feedback packet, or personal-failure fable. If they ask, use real defects with cost: Argus 73% mAP was not shippable; IQVIA DOM truncation made the agent click the wrong zoom; Ylogx client-side aggregation crashed the tab. Those are not fake slips.
  • Hackathons: eight events; CodeRecet 1st; MLH Best Project; Magnathon 2.0 runner-up. You do not have one locked reversible bet. Say that. Do not invent midnight hardware or a cut feature.
  • CGPA flag: resume.md 8.42 vs September 2026 summary PDF 8.12. Align before you speak a number.

Recommended same-hour spread (speak first, then leave that project’s first sentence alone):

  • Bias for Action → Horizon ERC date (video+perception on sensors we had)
  • Frugality → Y6 Redis / cache −35% versus a bigger RDS
  • Earn Trust → GiftedBooks grounded RAG + README mismatch
  • Dive Deep → Y2 data:null + Y3 dialect + cache key (anecdote versus hop)
  • Have Backbone → IQVIA hybrid versus vector-only, commit on evals
  • Deliver Results → Horizon ERC 17th/80+ as we, your video+perception on the date — flag 17 versus ~18
  • Earth’s Best Employer → Horizon GStreamer / ZED knowledge sharing
  • Success and Scale → Argus 20+ cameras after 89% mAP and 24 FPS

If Horizon already opened Bias, Deliver becomes Y8 product outcomes, Earth becomes IEDC pairing, and Horizon-as-sensors Frugality stays on the bench. If GiftedBooks already filled Customer, Earn Trust may keep the README sentence or switch to Y5 RLS honesty — do not restart the 3–10 minute loop. If Argus already filled Are Right or Standards, Backbone stays IQVIA hybrid, Deliver stays Y8 or DeepQuery A-runs, Scale stays ALB/ECS+RLS or DeepQuery filter. Ylogx primaries in a ConvBI-heavy hour are still Frugality and Dive Deep. Do not dump 40%, 99.9%, +65%, −35%, +60%, and sub-210ms in one paragraph.

9. Bias for Action

Claude Bias for Action follow-up drill — Claude’s wording, not the locked bank

Speed matters. Many decisions are reversible. Calculated risk taking.

Coaching: speak-first is Horizon on the ERC calendar — ship video+perception on the ZED and cameras we already had, rather than waiting for extra hardware or a custom fusion stack you did not own. Reversible piece: pipeline stages were swappable. Story 2 is the hackathon pattern plus the honesty that one named reversible bet is not locked. Story 3 is Y1 — take the orphaned bot. Story 4 is IQVIA DOM under demo pressure: raise limits, do not rebuild the agent. Keep internships in separate answers.

Horizon — ship video+perception on the sensors we had strongest

Speak-first Bias. Emphasis is the date and a reversible integration, not rover ownership and not Frugality’s “we did not buy more IMUs.” Deliver later is 17th as we. Earth later is teaching the pipe. Do not open those with this first sentence in the same hour.

Situation

February to June 2024 I was core software on Team Horizon’s ROS2 Mars rover for the European Rover Challenge 2024. ERC does not move because a student team wishes it had another depth sensor or a custom fusion box. We had cameras, a ZED 2 with stereo and an IMU, and a Jetson-class compute path. Waiting for extra hardware, or for a fusion architecture nobody on my lane was going to write, would have burned the calendar we actually had.

Task

Get a live operator POV and ZED-based environment scanning into the navigation conversation in time to compete. Done was not “I also invented fusion.” Done was a pipe we could run, swap, and debug on the hardware in the bay.

Action

I shipped the GStreamer video path on ROS2 — resume 60 FPS, including the multi-feed operator POV — instead of waiting for a cleaner camera kit. I integrated the ZED 2 we already had for environmental scanning — resume 2M+ point-cloud samples per second — into visualization in RViz and Gazebo, and I fed that perception into the costmap / navigation flow. The ZED SDK can use stereo plus the onboard IMU for visual-inertial tracking. That is the camera’s stack. I did not build a custom multi-sensor fusion architecture, I did not own the predictive planner, and I did not own the full costmap implementation. The calculated risk was: integrate the stages we had and keep them swappable — video, ZED perception, planner-owned costmap — so if a stage was wrong we could replace that hop without waiting for a purchase. Waiting for extra sensors was the irreversible-looking pause I refused. Buying nothing and shipping nothing until fusion existed would have been the timid version of “careful.”

Result

We took the rover to ERC 2024. Resume: 17th of 80+ as a core software member. Public Horizon materials sometimes say about 18th globally and #1 in India. I flag that; I do not fight the interviewer for a place. +40% obstacle-detection is a weak definition in our notes — compared to other video-feed tools, not an Argus-style labeled mAP. −55% simulated collision events is the planner team’s number on test tracks. I do not claim that algorithm. Bias here is “we had a competing vehicle on the date,” not a personal collision percent.

Spoken 90–120s. “ERC has a date. I was core software, not team lead. We had cameras and a ZED 2 — stereo plus an IMU — and I did not wait for extra sensors or for a custom fusion stack I was not going to own. I shipped a GStreamer operator POV at 60 FPS and I integrated ZED scanning at 2M+ points per second into the nav conversation. Pipeline stages were swappable, so the risk was reversible at the hop, not a one-way hardware bet. I did not write the planner or a fusion architecture. The ZED SDK can do visual-inertial tracking; that is not me inventing fusion. We placed 17th of 80+ on the resume; some public notes say about 18th. I flag that. I will not hang −55% collisions on my name.”

Likely interviewer questions
What was the calculated risk?

Integrating perception we already had, knowing a stage might be wrong, instead of pausing the calendar for more sensors or a fusion project. The reversible part is the hop: video, ZED, planner-owned costmap could be swapped. The irreversible-looking part would have been arriving at ERC with a beautiful architecture diagram and no POV.

Why not wait for better hardware?

Because the challenge date does not care. Extra lidar or another IMU would have been a procurement and integration story we did not have time to make true. Frugality can reuse “we used the ZED we had” later — this answer is speed on a fixed date.

Did you do sensor fusion?

No custom fusion. ZED 2 has stereo and an IMU; the SDK can combine those for tracking. I integrated that perception. If I say “I built fusion,” I am lying.

What would you have reversed if it was wrong?

A video stage, a ZED integration hop, or how perception entered the costmap conversation — not the whole rover. I do not invent that we swapped a named plugin on a named night.

Were you reckless on safety?

No. Calculated means I stayed inside a media pipeline and a vendor perception stack I could explain, and I did not silently own the planner. Reckless would have been claiming the collision number or shipping a pipe nobody else could restart.

17th or 18th?

Resume 17th/80+. Public materials sometimes ~18th. I volunteer the discrepancy. Bias is not the place integer.

Deeper probes
Codec, bitrate, glass-to-glass latency?

Not locked. I will not invent them. I speak GStreamer, 60 FPS on the resume, multi-feed POV.

Jetson SKU? RTX 3050 Ti?

Notes mention Jetson-class compute and a laptop GPU class in passing. I do not lock a SKU in this room. I will not mint one to sound precise.

Same story as Deliver?

This is “I moved on the date with swappable stages.” Deliver is “we placed, here is what I actually delivered.” If I already told this opening, Deliver should be Y8 or Argus.

Must remember
  • Date + sensors we had + swappable hops. Not planner, not full costmap, not custom fusion.
  • 17 vs ~18: flag. +40% weak. −55% is planner team’s number.
Missing — do not invent
  • A named extra sensor we almost bought; a night we swapped a plugin; official ERC source of record for 17 vs 18.
Eight hackathons — pattern yes; one locked reversible bet missing backup

Coaching: this card exists so you do not invent a heroic cut. Placements are real. A specific risky decision is not locked. If they want Bias as a single bet, either return to Horizon or say the gap.

Situation

I have eight national and regional hackathons on the resume. Placements I will speak: CodeRecet 1st, MLH Best Project, Magnathon 2.0 runner-up. Those weekends are speed by construction. That is not the same as a memorized reversible decision I can defend under a probe.

Task

If they ask for one calculated risk — alternatives, why reversible, what I would undo — I owe them a named event. I do not have that sentence locked today.

Action

I will describe the pattern I can actually stand on: we shipped a slice that ran in front of judges instead of waiting for a perfect stack. I will name the three placements. I will not mint a midnight hardware swap, a deleted model, or a teammate argument. If they need one bet, I point at Horizon’s “sensors we had” or Y1’s “I did not wait for reassignment,” which are locked. I treat the missing hackathon bet as an honesty move, not as a hole to fill with fiction.

Result

Those placements stand. The missing artifact is one event + one reversible choice with alternatives. I would rather leave that blank than invent it.

Spoken. “I have eight hackathons — first at CodeRecet, Best Project at MLH, runner-up at Magnathon 2.0. The pattern is ship a working slice on a weekend clock. If you want one concrete reversible bet from a named night, I have not locked that story and I will not invent it. The calculated-risk story I can defend is Horizon: integrate the ZED and video we had before ERC, stages swappable, no custom fusion. Or Ylogx: I took the orphaned chatbot instead of waiting for a reassignment.”

Follow-ups
Just pick CodeRecet and tell me the risk.

I will not. A guessed risk is a lie. I can say we placed first. I cannot currently walk alternatives and a rollback from that weekend without manufacturing them.

Isn’t a hackathon automatically Bias for Action?

It is a time box. Amazon’s question is still a decision you owned. A medal is not a mechanism.

Did you take a technical shortcut you regretted?

Not a locked sentence. I will not invent tech debt from a weekend to sound reflective.

How is this different from Deliver?

Placements can support Deliver as outcomes. This card is explicitly about the missing risk narrative. Do not use medals as a fake decision.

Deeper probes
Give me a teammate name from Magnathon.

No. Names are how a thin story becomes a lie.

Could IEDC pairing fill this?

No. IEDC is Earth / Hire. Do not launder a campus team into a hackathon bet.

Must remember
  • 8 / CodeRecet 1st / MLH Best Project / Magnathon 2.0 runner-up. Specific reversible bet: missing.
  • Do not invent one. Point at Horizon or Y1 if they need a decision.
Missing — do not invent
  • Exact hackathon + risky choice + alternatives + what you reversed.
Y1 — take the orphaned chatbot without waiting for reassignment backup

Coaching: Ownership in 1–8 was “the gap was mine” plus the hop map. Here the sentence is speed: I did not wait for a ticket that said the bot was mine. Do not replay data:null as the opening unless they ask what you found after you moved. Dive Deep owns the hops.

Situation

At Ylogx, November 2024 to October 2025, I was already on ConvBI when the SQL-RAG chatbot became a gap after another team member left. The bot was the path from a business question to generated SQL to a structured answer next to reports. Waiting for a formal reassignment would have left that path without an owner on a small intern team.

Task

Move first: reproduce it, then keep it alive. I was an intern. “Not my job” was a clean ticket label and a slow product.

Action

I stood the stack up locally and walked the request — LangChain state, dynamic prompts, schema lookup, FastAPI proposing SQL, Nest executing under the caller’s role, the UI parser — instead of waiting for someone to assign the epic. Boundary logs came so the next failure had a hop name. That is how I later hit data:null as a state-format miss and MySQL-shaped SQL on Postgres. Those fixes are Dive Deep / Are Right. This answer stops at: I took the service before the org chart caught up. I did not rewrite it into LangGraph. LangGraph is IQVIA.

Result

The NL path stayed a product path. I do not invent the calendar day the teammate left. I do not hang +65% on “because I moved fast.”

Spoken. “A teammate left and the SQL-RAG chatbot was a hole. I did not wait for reassignment. I reproduced LangChain → prompts → schema → FastAPI SQL → Nest execution → parser, and I put logs on the boundaries so I could name the hop. Speed was owning the path. I was still an intern. I did not become tech lead and I did not migrate it to LangGraph.”

Follow-ups
Why was waiting the worse risk?

On a small team, an unowned production path is customer-visible. Taking it was reversible in the sense that someone else could still be assigned later — I would have handed them a map instead of a ghost.

Did anyone tell you to take it?

I do not invent a manager order or a fight. I saw the gap and I started from a local repro.

What did you not know?

The state shape and which hop dropped the field the parser expected. Library docs do not contain our contract.

Is this the same as Ownership?

Same internship, different first sentence. Ownership is “the gap was mine.” This is “I moved before the assignment.” One opening per hour.

Deeper probes
Leave date? Time-to-productive?

Not locked. I will not mint days.

Did you break something by moving fast?

The defects I later owned — format mismatch, dialect — were already in the path. I do not invent a new outage I caused by inheriting it.

Must remember
  • Move first = local repro + hop map. Not LangGraph. Not +65% as this STAR’s prize.
  • No leave date. No manager fight.
Missing — do not invent
  • Assignment email, day count, Jira key.
IQVIA DOM — raise limits under demo pressure; do not rebuild the agent notes

Coaching: handwritten notes, speakable, no IQVIA percent. Highest Standards / Dive Deep can reuse the same defect with a different first sentence. Here the move is reversible config under time pressure, not a redesign.

Situation

At IQVIA, April 2026 to present, Kochi, I had a stakeholder path where the agent had to drive UI. Notes: the DOM the agent saw was truncated. It clicked the last chart’s zoom instead of the control we needed. Rebuilding the agent in the hallway would have been theater.

Task

Unblock the demo with a change I could undo, without pretending the agent architecture was the bug.

Action

I treated it as a visibility budget, not as “the agent is dumb.” I raised DOM max characters and max DOM elements from 50 to 80, and I set reasoning to medium because low failed in those notes. I did not rebuild the agent. I did not invent a new planner. The risk was calculated: if 80 was too wide I could turn it back; if I rewrote the agent under demo heat I would have owned a new, untested brain. After the config change, the path demoed. I do not hang a product latency or a success percent on that afternoon.

Result

The stakeholder path ran. The defect class is truncated DOM, not “IQVIA RAG quality.” Redis and Celery are listed and not wired — I do not claim a queue saved the demo.

Spoken. “In an IQVIA stakeholder path the agent clicked the last chart’s zoom. The DOM it was allowed to see was truncated. I did not rebuild the agent under demo pressure. I raised max DOM elements from 50 to 80, raised the character budget, and used medium reasoning because low failed. That is a reversible config. The path then demoed. I do not have an IQVIA percent for that day.”

Follow-ups
Why not rebuild the agent?

Because the click was consistent with a blind agent, not with a missing node. A rewrite is a new product. A limit bump is a reversible bet.

Is 80 the right number?

It is the number that unblocked that path in the notes. I do not claim an ablation. If they want the exact character cap I will open the config rather than guess.

Low reasoning failed — tokens?

Notes say reasoning medium; low did not work. I do not invent token counts.

Was this a missed deadline?

No. It is a demo defect I fixed. I do not manufacture a slipped date around it.

Deeper probes
Stakeholder title?

Not locked. I will not mint a VP.

Same as Dive Deep DOM?

Dive Deep is logs and screenshots proving truncation. This is “I changed config now.” One opening per hour.

Must remember
  • Truncated DOM → last-chart zoom. 50→80, reasoning med. Do not rebuild the agent. No IQVIA %.
Missing — do not invent
  • Exact max-char number if not in front of you; stakeholder name; a latency win.

10. Frugality

Claude Frugality follow-up drill — Claude’s wording, not the locked bank

Accomplish more with less. Constraints breed resourcefulness. No extra points for headcount/budget.

Coaching: speak-first is Y6 — repeats are cache-shaped; do not buy a bigger RDS; tenant belongs in the key; resume Redis versus this Nest Map. Story 2 is Y4 reuse versus a second chart stack. Story 3 is Horizon using the ZED stereo+IMU we had — you did not build custom fusion. Story 4 is StratifyLabs browser inference versus a GPU farm. If Invent already spent Y4, skip story 2. No bills. No extra points for imagining headcount you did not have.

Y6 — cache-aside −35% versus a bigger RDS strongest

Speak-first Frugality. Are Right already used Y6 as “I measured instead of guessing the DB is slow.” Here the sentence is constraint: more warehouse is not a prize. Dive Deep can still use cache key as one hop inside the combined anecdote story — do not open both with Redis in the same hour if you can help it.

Situation

On ConvBI, repeat chatbot questions still cost a warehouse round trip. The unconstrained answer is a larger RDS, more connections, more spend I will not quote. Repeat English is not a capacity personality. It is the same work twice.

Task

Cut bot-database work we had already paid for, without buying instance size and without turning cache into a cross-tenant leak. I was not going to get points for headcount or a bigger bill.

Action

I treated repeats as the constraint. Suitable bot queries could hit a cache-aside path instead of Postgres again. The key includes role and organization, not query text alone, so ORG_A cannot be served ORG_B’s payload because they asked the same sentence. On a miss, Nest still executes as the caller with RLS — FastAPI only proposes SQL. Resume: Redis reduced query latency by 35% on that bot-DB family. This Nest checkout has an in-process Map and a 5-minute fieldsCache. I say “resume Redis hop versus this snapshot Map.” I do not say I put Redis in this Nest file. I do not invent a hit-ratio dashboard. I do not upgrade −35% into a p95 or a TTL SLA. The 5-minute field cache is this tree, not a resume percentile.

Result

Resume −35% bot-database latency for that family. Methodology is weak until I can show baseline, population, and window. I still will not tell a story where the frugal move was “we scaled RDS.” 99.9% is serving uptime, not this cache study.

Spoken 90–120s. “Repeat bot questions were costing warehouse work we had already done. The expensive answer was a bigger RDS. I did not have a budget prize for that. I put a cache-aside path on repeats and I keyed it by role and org, not by English alone, so a faster answer could not become someone else’s numbers. On a miss we still execute as the caller with RLS. The resume says Redis cut that bot-DB latency by 35%. If you open this Nest checkout you will see an in-process Map and a 5-minute fieldsCache — I will not pretend Redis lives in that file. I will not quote a bill I avoided.”

Likely interviewer questions
Why not a bigger database?

Because the hot shape was repeats. A larger instance still runs the same JOIN twice and still does not fix a leak. Constraints here were intern time and the warehouse we had, not a credit card I will invent.

How is the key safe?

Role plus org in the key. Query text alone is a leak machine. I would rather miss than serve the wrong tenant.

Redis or Map — which is the truth?

Both, in different snapshots. Resume cache-aside is Redis −35%. This checkout is Map / 5-minute fieldsCache. Earn Trust if they open GitHub: I say the split out loud.

Does cache skip RLS?

It must not. Miss path is the caller. Hit path is already identity-keyed. Chat CRUD can use executeWithoutRLS — that is not the warehouse fact path I am caching as a security story.

Is −35% a capacity test?

I treat the methodology as weak. I will not dress it as a paper. I will not invent p95.

CloudFront as Frugality?

Static assets can sit on CloudFront. Private JSON is not an edge object. I do not turn CDN into a warehouse cache story.

Deeper probes
What is fieldsCache exactly?

In this Nest tree, an in-process Map with a 5-minute window for dataset fields. Table-name-shaped keys in notes. It is not the resume −35% Redis hop.

Did you add replicas?

Not the story I tell. I do not invent an Aurora decision or a bill.

Same as Are Right Y6?

Are Right is “I dropped the vibe.” This is “I refused to buy the obvious extra.” One first sentence per hour.

Must remember
  • Repeats → cache-aside. Key role+org. Resume Redis −35% vs snapshot Map. No bill. No p95/TTL SLA.
  • FastAPI proposes; Nest executes under SET ROLE. executeWithoutRLS is chat CRUD, not “cache skips RLS.”
Missing — do not invent
  • Baseline method for −35%; production Redis topology; hit ratio.
Y4 — reuse ElementRenderer versus a second chart stack backup

Coaching: Invent’s sentence was the contract. Here the sentence is “I will not spend a second visualization world.” Backbone later is prototype-as-argument. If Invent already used Y4, do not open Frugality with this prototype.

Situation

The ConvBI chatbot was starting to return useful rows. The report builder already drew elements. A dedicated “AI chart” library would have doubled test surface and invited visual drift. That is extra spend we did not need — not money I will quote, time and complexity.

Task

Show charts and tables without a second stack. Constraint was the renderer we already had.

Action

I pointed a structured JSON contract — chart type, data, dimensions, metrics — at the existing ElementRenderer. I prototyped it so the cheaper path was visible. FastAPI still only proposed SQL; Nest still executed. I did not hire a chart island and I did not add a second npm visualization world as the default.

Result

One drawing path for bot and builder. I do not invent the chart-type enum. I do not invent a license fee I saved.

Spoken. “We already had an ElementRenderer on the report builder. A second chart stack for the bot would have been extra surface we did not get points for. I made the bot speak type, data, dimensions, metrics and I reused the renderer. I showed a prototype instead of asking for another library. Same intern team, same product — less world to maintain.”

Follow-ups
What did you refuse to spend?

A parallel visualization codebase. Not a dollar figure. Constraint bred reuse.

Did this fix the aggregation crash?

No. That crash was client-side aggregation on a large slice. Different defect. Do not glue them.

What if they had rejected reuse?

I would have implemented the path they chose and kept the contract notes. That commit sentence belongs to Backbone. Here I say: I made the cheap path easy to accept.

Same as Invent?

Invent is “the interface was the invention.” This is “we did not buy a second island.” One opening per hour.

Deeper probes
Exact TypeScript props?

I will walk the renderer from the repo rather than guess field names.

Manager fight over the library?

I do not have one. Do not invent it.

Must remember
  • Frugal = one renderer. Proof = prototype. No library bill. No manager fight.
Missing — do not invent
  • Chart-type list; a rejected purchase order.
Horizon — ZED stereo+IMU we had, not more sensors backup

Coaching: not Bias’s calendar speech. Not Deliver’s place. You did not build custom fusion. Constraint = the camera already on the mast.

Situation

Mars-rover perception can become a shopping list: more depth sensors, a second IMU, a fusion computer. We already had a ZED 2 — stereo plus an IMU — and cameras for the operator POV.

Task

Get environment scanning and video from what was in the bay. Extra sensors were not a prize I was going to collect.

Action

I used the ZED we had for scanning and I used GStreamer for the POV we had to have. The SDK can use stereo and the IMU for tracking. That is vendor capability, not a fusion architecture I wrote. I did not pitch a sensor-buy as my contribution. I integrated perception into the costmap conversation the planner team owned.

Result

A competing rover on the sensors we already carried. I do not quote a hardware invoice. I do not claim −55% as mine.

Spoken. “Frugality on Horizon was using the ZED 2 we already had — stereo and an IMU — plus the cameras, instead of turning perception into a shopping list. I integrated that scanning and I shipped the GStreamer POV. I did not write custom fusion. I did not own the planner. I will not invent a sensor we almost bought.”

Follow-ups
Isn’t that just ‘we were poor students’?

It is resourcefulness on a constraint. The mechanism is vendor stereo+IMU plus a media pipeline, not a sad budget speech. I will not invent the budget.

Why mention IMU if you did not fuse?

Because interviewers hear “ZED” and assume I wrote visual-inertial fusion. I mention the IMU to give credit to the camera and to refuse the custom-fusion claim.

Same as Bias Horizon?

Bias is the ERC date and swappable hops. This is “we did not buy our way out.” If Bias already used Horizon, skip this card.

Deeper probes
What sensor did you reject?

I do not have a locked rejected SKU. I will not mint lidar envy.

+40% as frugality proof?

No. Weak definition. Do not lean on it.

Must remember
  • Use ZED we had. No custom fusion. No sensor invoice. −55% not yours.
Missing — do not invent
  • A declined purchase; IMU sample rates I cannot show.
StratifyLabs — browser inference versus a GPU farm backup

Coaching: original project, not makeup. Invent/Think Big used platform and simplify. Here the sentence is “I did not rent a farm so students could iterate.” README is a Next.js scaffold — resume and stratifylabs.design win. DeepQuery URL-intel is the Scale cost-bound card; do not also open this hour with 857 URLs unless they pull IQVIA.

Situation

CV iteration usually assumes a local GPU or a rented one. That is headcount-and-budget thinking I did not have, and it is a terrible loop for a student who wanted to try a model this afternoon.

Task

Get inference and reuse without standing up a GPU farm.

Action

I shipped browser-based WebGL inference and a marketplace with 50+ pre-trained models and dataset hosting so the default was reuse, not retrain. Resume −30% ML iteration cycles. I do not claim A100 parity. I do not quote GPU hours I avoided. If they open GitHub and see a scaffold README, I say resume wins and I would fix the README.

Result

−30% and 50+ as resume family. Methodology for −30% is weak. No MAU. No bill.

Spoken. “StratifyLabs was me refusing a GPU farm as the price of trying a model. I put inference in the browser with WebGL and I put 50+ models on a marketplace so the next experiment was reuse. We reported a 30% cut in iteration time. I do not have a GPU invoice I saved. The GitHub README currently looks like a Next.js scaffold; the resume and the live site are the product I will talk about.”

Follow-ups
Why not hosted GPU APIs?

That is another account and another bill I will not quote. Browser inference was the constrained path for experimentation.

Did you train all 50 models?

No. Marketplace of pre-trained models and datasets. I do not invent trainers’ names.

README looks empty.

Scaffold README. Resume wins. That is also Earn Trust if they stay on honesty.

Why not DeepQuery scrape-cap as this fourth story?

Because 857→120 is the Scale / Dive Deep IQVIA card. This keeps Frugality on a personal product without mixing internships.

Deeper probes
How was −30% measured?

Not locked. I will not invent a diary N.

Same as Think Big?

Think Big is the platform direction. This is “I did not buy compute to look serious.” One opening per hour.

Must remember
  • Browser inference + marketplace reuse. −30%, 50+. README scaffold. No GPU bill.
Missing — do not invent
  • Baseline for −30%; which models I trained.

11. Earn Trust

Claude Earn Trust follow-up drill — Claude’s wording, not the locked bank

Listen, speak candidly, treat others respectfully. Vocally self-critical even when awkward. Benchmark against the best.

Coaching: speak-first is GiftedBooks — grounded RAG plus 99.5% plus the GitHub README that currently describes AegisAI. Say the mismatch before they weaponize the repo. Story 2 is Y5: do not say “Postgres rejects.” Story 3 is Y4: prototype instead of a speech; you would have committed if they had rejected reuse. Story 4 is Horizon 17 versus ~18, planner correction, and the other honesty floors if they ask — still one spoken project first. Do not rank internships.

GiftedBooks — grounded RAG, 99.5%, README says AegisAI strongest

Speak-first Earn Trust. Customer already used the 3–10 minute study loop. Here the sentence is candid trust: their PDF is the evidence, and I will tell you the README is wrong. Scale later is “more students must not mean more hallucination.” If Customer already spent GiftedBooks, keep this only if they pull trust — lead with the README and the refuse-to-invent, not the +35% parade.

Situation

I built GiftedBooks at giftedbooks.study as a VR learning suite. A tutor that invents a syllabus spends student trust. The awkward second fact: the GitHub README on that repo currently describes AegisAI, which is a different personal-safety project on my resume. If I hope they never open GitHub, I am not earning trust. I am hiding.

Task

Make the product trustworthy in the only way I can defend — retrieve from the student’s own file — and be vocally self-critical about the repo mismatch and about what I did not measure.

Action

I split jobs. PDF-upload RAG: authenticate, ingest their file, store vectors with user and document metadata, retrieve a small user-scoped set, generate from those chunks. Cross-user retrieval would have looked smart and been a betrayal. PYQ topic ranking stayed deterministic analytics, not the model predicting the exam. Resume API path is sub-300ms; I treat that as retrieve-and-answer latency, not faithfulness. Uptime on the resume is 99.5% — that is GiftedBooks, not Ylogx 99.9%. I do not have a labeled citation eval. I designed so the model should stay on retrieved chunks and I would rather abstain than invent a derivation the PDF does not support; I will not claim I scored that. Then I say the README: resume wins; I would fix the README; I do not import AegisAI features into GiftedBooks to make one story larger.

Result

User testing we reported: doubts from hours into a 3–10 minute window, +35% reading efficiency, +50% session engagement, 2.5× faster content comprehension versus traditional methods in that testing. I do not claim an RCT or a student headcount. I do not claim LangSmith here. The trust I am willing to be awkward about is the README and the missing citation eval — that is benchmarking myself against “the best would have measured grounding,” not against a fake gold set I will invent.

Spoken 90–120s. “Earn the student’s trust first: their uploaded PDF is the source of truth. I retrieve a small user-scoped set and I answer from those chunks. I will not mix another student’s notes. Previous-year questions are analytics, not the model inventing the paper. In our user testing, doubts that used to take hours landed in a 3–10 minute window; we also reported +35% reading efficiency and +50% engagement. Uptime on the resume is 99.5%. I do not have a citation eval, so I will not pretend grounded means measured. The awkward part: the GitHub README currently describes AegisAI. The resume and giftedbooks.study are GiftedBooks. I would fix the README rather than hope you never open it.”

Likely interviewer questions
Why tell me the README is wrong?

Because you will find it. Vocally self-critical means I say it. Hiding it is the opposite of this principle.

Is 99.5% the same as Ylogx 99.9%?

No. Do not swap them. 99.5% is GiftedBooks. 99.9% is ConvBI serving.

Did you cite or abstain in production?

The design intent is stay on chunks or do not invent. I do not have a labeled abstain rate. If I claim a score, I am lying.

Sub-300ms — faithfulness?

No. Latency is not proof the chunk was the right derivation. I do not invent p95.

User-testing N?

Not locked. I will get the protocol rather than mint a sample size.

How do you treat people when the repo is messy?

I do not blame a teammate I will invent. It is my repo mismatch. I own the fix.

Deeper probes
Vector store topology?

Not a speech I will invent. FAISS on the skills line is not a cluster diagram. No Qdrant.

Same as Customer or Scale?

Customer is the study loop. Scale is hallucination at width. This is candor plus grounding. One opening per hour unless they pull the README after Customer.

StratifyLabs README too?

Yes if they open that repo: Next.js scaffold, resume wins. Do not stack both READMEs as the first story unless they are already on GitHub honesty.

Must remember
  • Grounded, user-scoped RAG. 99.5% is GiftedBooks. README = AegisAI, resume wins.
  • 3–10 min / +35% / +50% / 2.5× / sub-300ms = user-testing / resume family. No RCT. No citation score. No Qdrant.
Missing — do not invent
  • Testing N; chunker and store ops; whether 99.5% is window or target; abstain rate.
Y5 — three-tier RLS; do not say Postgres rejects backup

Coaching: Ownership was “I took the boundary.” Standards was “LLM is not a control.” Here the sentence is candor about empty versus 403 versus permission denied. Listen to the interviewer’s words; if they say “reject,” correct them respectfully.

Situation

ConvBI put multiple organizational tiers on one PostgreSQL. A demo that returns rows is easy to over-claim: “the database rejected the bad query.” That sentence is tidy and often false.

Task

Speak the isolation path I actually implemented, including the cases that look like success and are empty, and the tables that are not under RLS.

Action

I worked the Nest side: JWT identity; RBAC on feature and table; per-request Sequelize transaction; SET ROLE to the user’s non-owner db role; set_config for app.organizationId from the verified JWT, never from SQL the model wrote. No db role → fail closed to rls_no_access. A generator emits CREATE POLICY. Postgres filters rows. A legal SELECT for ORG_B while the GUC is ORG_A returns zero rows — HTTP can still be 200. That is not “Postgres rejected.” Missing GRANT is a permission error. Application hasTableAccess is HTTP 403. Chat CRUD can use executeWithoutRLS after RESET ROLE. I say that out loud so I do not earn trust on a slogan and lose it on a repo walk. FastAPI proposes SQL; Nest executes.

Result

Three-tier row isolation on the shared warehouse path the resume claims. 99.9% is uptime, not a leak SLA. I do not invent a pentest count.

Spoken. “I will not earn trust by saying Postgres rejects a cross-tenant SELECT. On our warehouse path, RLS filters. If the session org is A and the SQL asks for B, you can get 200 and zero rows. Missing GRANT is permission denied. App table checks are 403. No db role fail-closes to rls_no_access. Chat metadata can go through executeWithoutRLS — I will not tell you every table is RLS. FastAPI writes SQL; Nest runs it as the caller.”

Follow-ups
Zero rows means access denied?

No. Zero rows can mean the filter hid everything. Do not call that a reject.

Did you write every GRANT?

I can defend middleware, generator, fail-closed role. I was not the DBA of record for every production GRANT. I vs we stays honest.

FORCE RLS?

I do not claim it unless I can show it in the live tree.

Redis in this Nest package?

Not in this snapshot. Resume Redis is the cache hop. Map / fieldsCache is this tree. I say that here if they open GitHub — same candor family as GiftedBooks README.

Deeper probes
Named leak in production?

Not locked. I will not invent an incident ticket.

Same as Backbone Y5?

Backbone is “I argued RLS-in-DB versus app WHERE.” This is “I will not over-claim the mechanism.” One opening per hour.

Must remember
  • Filter ≠ reject. 403 is app. GRANT miss ≠ RLS hide. executeWithoutRLS exists. rls_no_access fail-closed.
Missing — do not invent
  • FORCE RLS in prod; client role names; a pentest report.
Y4 — prototype instead of an argument; I would have committed backup

Coaching: trust = show the screen, listen, no invented fight. If they had rejected reuse, commit wholly is Backbone — say it here as the respectful close, do not manufacture the rejection.

Situation

People can hear “reuse ElementRenderer” as blocking a nicer AI UI. A slide fight would have spent trust. I did not have a manager blow-up to report, and I will not write one.

Task

Make the cheaper path visible and stay someone they could work with if they still wanted a new library.

Action

I built a prototype on the structured contract and let them click it. I listened to what they needed to see. I did not turn it into a personality contest. Counterfactual I will own: if they had rejected reuse, I would have implemented their path and kept tests on one drawing surface as a later cleanup — I would not have sulked in the intern corner. That rejection did not happen as a documented event.

Result

They could see one renderer. Trust was the click, not a speech about taste.

Spoken. “I did not win reuse with a speech. I prototyped the bot payload into ElementRenderer so the team could click it. I do not have a manager fight on paper. If they had said no, I would have built the path they chose. I still think two chart worlds would have drifted — but I would not have quietly refused to ship.”

Follow-ups
Who disagreed?

I do not invent a name. The discarded option was a second island. That is a design fork, not a performance-review story.

Were you disrespectful by pushing reuse?

The respectful move was a prototype they could reject. A manifesto would have been louder and less useful.

Same as Invent / Frugality / Backbone Y4?

This is candor and commit-if-rejected. Change the first sentence or pick another project if Y4 is spent.

Deeper probes
Did they reject it?

Not as a locked event. Do not say they did.

Critical feedback from your manager on this?

I do not have a documented critical-feedback packet. I will not mint one.

Must remember
  • Prototype, listen, no fight. Counterfactual commit only — not a fake no.
Missing — do not invent
  • A named opponent; a rejected-reuse meeting.
Horizon 17 vs ~18, planner line, honesty floors backup

Coaching: spoken project is Horizon. Other floors stay in follow-ups so you do not stack internships. Volunteer the discrepancy. Correct planner ownership without being asked to be a hero.

Situation

My resume says Team Horizon placed 17th of 80+ at ERC 2024. Public Horizon materials have said about 18th globally and #1 in India. If I pick a fight over a place, I look brittle. If I absorb the planner and −55% collisions, I look worse — I steal a teammate’s number.

Task

Put the documents next to each other and put my hands only on video + ZED integration.

Action

I volunteer 17 versus ~18 and I say I will align the resume with the source of record. I say out loud: I did not implement the predictive planner, the full costmap, or custom fusion. −55% simulated collisions is the planner team’s number. +40% obstacle is a weak video-tool comparison. That is listening to what the artifacts actually say, not what makes me larger.

Result

A place I will not brawl over, and a boundary I will not steal. Other honesty floors if they ask — not as a second internship speech: Argus 73% was not shippable; Ylogx Redis versus this Map; GiftedBooks README; CGPA 8.42 versus 8.12.

Spoken. “I will not pick a fight over Horizon’s place. Resume says 17th of 80+; public notes sometimes say about 18th. I flag that and I will align the source of record. I also will not earn trust by owning the planner. I shipped video and ZED perception. −55% collisions is not my algorithm. +40% obstacle is a weak definition. If you want other floors: I refused to talk about Argus as done at 73%, and I will tell you Redis is resume while this Nest file is a Map.”

Follow-ups
Which place is true?

I do not know which document wins until I align them. I will not pick one to sound confident.

Why correct the planner if I did not ask?

Because the resume line is easy to over-read. Vocally self-critical is cheaper than getting caught later.

Ylogx metric floors in one line?

Do not dump six numbers. If they ask: Redis −35% is resume; Map is checkout; validator is not semantic truth; 40% and 99.9% are product-family, not one bug’s A/B.

Argus floor?

73% mAP was a running model and not a floor I would stand on. That story’s home is Are Right / Standards / Scale. Here it is only an honesty floor if they ask how I treat a flattering number.

Deeper probes
#1 India — do you lead with that?

No. I mention it as part of the public-materials set. I do not campaign on it.

CGPA 8.42 or 8.12?

resume.md 8.42; a September 2026 summary PDF 8.12. I flag it. I do not bluff.

Must remember
  • Volunteer 17 vs ~18. Not planner. −55% theirs. +40% weak.
  • Other floors only if asked. Do not stack internships in the opening.
Missing — do not invent
  • Official ERC PDF in your pocket; a teammate you “called out.”

12. Dive Deep

Claude Dive Deep follow-up drill — Claude’s wording, not the locked bank

Operate at all levels, stay connected to details, audit frequently, skeptical when metrics and anecdote differ. No task is beneath them.

Coaching: speak-first is one Ylogx hour — data:null, dialect, and cache key — because the anecdote is always “the model is slow / hallucinated / the DB is empty.” Story 2 is IQVIA DOM from logs. Story 3 is DeepQuery grade/confidence versus artifacts. Story 4 is BRD tiktoken 1500/200 and hybrid versus vector. Stay connected to the hop. No task beneath you includes reading the payload and the SQL, not only the LLM trace.

Y2 + Y3 + cache key — anecdote versus the hop strongest

Speak-first Dive Deep. Same internship, three hops, one spoken product. Do not open Frugality with Redis in this hour if this is your first story. Are Right Y3 was “I dropped the belief.” Here you stay in the artifacts until the slogan dies.

Situation

On ConvBI the room’s stories were tidy: the model is slow, the model hallucinated, the database is empty. Operators saw empty charts. Those sentences can be true. They were not the first full truth on the failures I actually opened.

Task

Audit the path at every level — UI payload, generated SQL, rows in Postgres, prompt examples, cache key — and refuse the metric-or-anecdote that did not match the file.

Action

I reproduced hops. LangChain state into prompts, schema lookup, FastAPI proposing SQL, Nest executing as the caller, the parser the UI trusted. Y2. The UI showed data:null while the warehouse still had rows. That is a state-format mismatch: the next hop did not receive the field it parsed, so the renderer had nothing. I fixed the format path. An empty chart was not an empty database. Y3. I extracted SQL and ran it. Rows existed. The SQL carried MySQL-oriented patterns against PostgreSQL. Prompt examples were teaching the wrong dialect. I fixed prompts and added deterministic validation. I still say the validator does not make the number semantically true. Cache. When the anecdote was “Postgres is slow,” repeats were cache-shaped. The key must include role and org, not English alone. Resume Redis −35% on that bot-DB family; this Nest checkout is an in-process Map and 5-minute fieldsCache. I will not “dive deep” by inventing a hit-ratio dashboard. No task beneath me meant reading the null field and the SQL text, not only the model’s English.

Result

Those classes stopped being mysteries. I do not invent ticket counts. I do not pin +65% or 40% on a single null. The deep habit is: when the anecdote and the artifact disagree, believe the hop.

Spoken 90–120s. “People said the model was slow, or it hallucinated, or the database was empty. I opened the hops. One failure was data:null in the UI while Postgres still had rows — the state format between generation and the parser was wrong, so the chart had nothing to draw. Another was MySQL-shaped SQL on Postgres; I ran the SQL, saw the dialect, and fixed the prompt examples plus validation. Validation still does not mean the total is the business total. When the story was ‘the DB is slow,’ repeats were a cache problem, and the key has to carry role and org or you leak. Resume says Redis cut that bot-DB latency 35%. If you open this Nest file you will see a Map. I will not invent a dashboard to sound deeper than the logs.”

Likely interviewer questions
What anecdote did you kill first?

Empty database, on the data:null class. Rows were there. The payload was not.

Show me data:null.

Structured response, data field null, warehouse not empty. Format contract between stages. I do not invent a Jira key or a sample JSON I cannot open.

Show me a MySQL-ism.

I speak the class. I will not mint a backtick or a LIMIT dialect token if I cannot see the log. I will open the prompt examples.

Is −35% the dive?

The dive is the hop and the key. −35% is a resume family number with a weak methodology. I do not hide that.

Did you only stay in application code?

No. I ran SQL on Postgres. I looked at RLS versus cache so a faster path could not skip identity. Operating at all levels meant UI, app, SQL, and session — not a vibe about GPT.

Validator versus truth?

Deterministic checks catch invalid or dialect-unsafe SQL. A legal SELECT can still answer the wrong question. I say that every time.

Deeper probes
Could it have been schema cache?

Yes as a hop I would check. In the cases I tell, the SQL existed and the dialect or the state field was wrong. I do not merge every failure into one myth.

Logging where?

Boundaries: after generation, after Nest execution, before the UI consumed the object. I do not invent Datadog or a log-volume percent.

Why not IQVIA first?

Because this is the Ylogx primary for Dive Deep. IQVIA DOM and DeepQuery 0% are backups if this hour already spent ConvBI.

Must remember
  • Anecdote dies on the hop: format, dialect, identity-keyed cache.
  • Validator ≠ semantic truth. Redis vs Map. No +65%/40% pinned to one null.
Missing — do not invent
  • Exact SQL string; exact prompt line; −35% baseline notebook.
IQVIA DOM — truncation from logs and screenshots notes

Coaching: Bias already used “I changed config under pressure.” Here you prove the defect from evidence. No IQVIA %.

Situation

Stakeholder path: the agent zoomed the last chart. The anecdote is “the agent is bad at UI.” Notes and screenshots said the DOM dump was truncated.

Task

Match the click to what the model was allowed to see, not to a personality theory.

Action

I compared the visible page to the DOM budget. Max elements sat at 50; the control we needed was not in the slice the agent received, and the last chart’s zoom was. I raised max DOM elements 50→80, raised max characters, set reasoning medium because low failed. I did not rebuild the agent. I did not invent Haar cascades or a computer-vision click model. After the budget matched the control, the path demoed.

Result

A defect I can name: truncated DOM, wrong zoom. Not a resume latency. Redis/Celery still not wired — I do not drag a queue into the postmortem.

Spoken. “The anecdote was that the agent could not click. The screenshots said the DOM was truncated — it saw the last chart’s zoom and not the control we needed. I raised max elements from 50 to 80 and I used medium reasoning because low failed. I did not rebuild the agent. I still do not have an IQVIA percent for that demo.”

Follow-ups
How do you know it was truncation?

The click matched the last visible control in a short DOM. That is cheaper than “the model is stupid.” I do not invent a pixel coordinate.

Is 80 always enough?

It was enough for that path. I do not claim an optimal element cap.

Same as Bias DOM?

Bias is reversible speed. This is evidence versus anecdote. One opening per hour.

LangSmith?

I use traces on IQVIA graphs. I do not invent a LangSmith score for this click.

Deeper probes
Exact max-char value?

I will open the config. I will not guess a second number besides 50→80 elements.

Was a human beneath you in that debug?

Reading a truncated dump is the job. I do not outsource that to a slogan about agents.

Must remember
  • Logs/screenshots → truncated DOM → last-chart zoom. 50→80, reasoning med. No IQVIA %.
Missing — do not invent
  • Pixel coords; token counts; stakeholder title.
DeepQuery — ranking/confidence contradicted the scrape artifacts backup

Coaching: Learn used orchestration. Are Right used “do not blame retrieval.” Here metrics versus anecdote: grade D / 0% confidence looked like a dead search; the folder still had pages. Ranking also means url_intelligence: 857→120 is a filter, not a failure to find the web.

Situation

DeepQuery is a 12-node LangGraph: planner, light_search, clarifier, context_builder, query_generator (on the order of 12–15), fan-out DDGS + Bing + Firecrawl concurrent, aggregator, url_intelligence (filter, target often 120–180), scrape waves, cross_page_reasoning, decision_engine, synthesizer. Some saved runs ranked as failures: confidence 0%, short answers, grade D. The anecdote is “ranking failed; we did not retrieve.”

Task

Audit artifacts before I “fixed search.” 200+ websites on the resume is the discovery-pool class, not 200 scraped LLM pages.

Action

I opened the folder. Strong-run example in the same family: 857 URL pool → 120 filtered → about 137 pages, long report. Weak runs: on the order of 236–256 words, 0% confidence, but facts and pages were still collected. That contradiction is synthesis JSON parse or a truncated save after scrape and reasoning already succeeded — not empty retrieval. Blaming url_intelligence or Firecrawl would have been diving into the wrong level. Benchmark write-up I use: 12 runs, 10 graded A, 2 graded D with 0% confidence. Azure OpenAI, local CLI, not a hosted product. Redis/Celery listed, not wired.

Result

I treat 0% as a synthesizer contract problem until a file says otherwise. I do not quote an IQVIA product percent or latency. I do not claim I already shipped a forever fix.

Spoken. “I had DeepQuery runs that ranked as 0% confidence and grade D. The anecdote is retrieval died. The artifacts still had pages. A strong run in my notes went 857 URLs to 120 filtered to about 137 pages. The weak ones were short — a couple hundred words — after scrape had already worked. That is a synthesis JSON parse, not an empty web. If I had loosened URL ranking or paid for 857 scrapes I would have dived into the wrong hop. I do not have an IQVIA success percent.”

Follow-ups
What ranking are you talking about?

Two: the run’s confidence/grade, which contradicted the page folder; and url_intelligence ranking URLs before scrape so 857 does not become 857 LLM pages. Do not confuse them in one sentence unless they ask both.

Why not scrape all 857?

Because filter-before-scrape is the think hop. Scale will use the secondary-cost sentence. Here: the metric “more URLs” would have disagreed with “pages already existed.”

Is 0% calibrated uncertainty?

In these artifacts it matches parse defaulting confidence, not a philosophical I-don’t-know.

12 / 10 / 2 — resume numbers?

Benchmark write-up in notes. Not an IQVIA product SLA. I do not invent more runs.

Deeper probes
Exact exception string?

Not locked. I will not mint a traceback.

Did you patch synthesizer?

I can speak the diagnosis. I will not invent a merge date or a repair percent.

Must remember
  • 0% + short text + pages present ⇒ parse, not empty retrieval. 857→120→~137. 12 runs / 10 A / 2 D. No IQVIA %.
  • 200+ sites = pool class. Fan-out is DDGS+Bing+Firecrawl. Redis/Celery not wired.
Missing — do not invent
  • Exception text; whether a fix is merged; hosted topology.
BRD — tiktoken 1500/200, not char-length; hybrid versus vector backup

Coaching: Invent split jobs. Learn asked why hybrid. Here you defend the detail: token budget and why cosine is not DEPENDS_ON. No labeled IR set — say so.

Situation

Hybrid RAG over 200+ page BRDs. The lazy chunker is character length. The lazy retriever is vector-only. Both disagree with how the documents actually work: token windows, identifiers, and requirements that DEPENDS_ON each other.

Task

Stay connected to chunk math and retrieval mode, and not claim a quality percent I did not measure.

Action

Eight-node ingest: extract, chunk 1500 tokens / 200 overlap on cl100k_base tiktoken, embed 3072-dim, Azure hybrid + semantic on index brd-documents, requirements, relationships, Neo4j Document / Requirement / Entity with DEPENDS_ON. I did not chunk on character length because the model and the embedding budget are token-shaped; a 1500-character slice is a different object than a 1500-token slice. Hybrid is BM25 plus vector kNN plus a semantic reranker plus a 2-hop walk — lexical section numbers lose to cosine; “depends on” is a graph, not a neighbor. Test-case path is a separate 5-node graph with asyncio.gather. Redis/Celery not wired; jobs are in-memory maps. LangSmith traces; no labeled precision/recall.

Result

A pipeline I can audit node by node. I do not quote IQVIA latency or recall. Local intern system, not a multi-region service.

Spoken. “I do not chunk BRDs by character count. Ingest uses 1500 tokens with 200 overlap on cl100k_base, then 3072-dim embeddings. Characters would silently disagree with the token window. I also do not retrieve vector-only. Requirements have DEPENDS_ON in Neo4j, and BRD identifiers still need BM25. Hybrid plus a 2-hop walk is the detail. I do not have a labeled IR set, so I will not invent nDCG. Redis and Celery are in the file and not in the runtime.”

Follow-ups
Why 1500 / 200?

They are the configured token budget. I can defend that they exist. I do not invent an ablation that proved 1500 optimal.

Chunk tokenizer versus embed tokenizer?

Chunks use cl100k_base. Embeddings use the Azure deployment’s tokenizer. That is a common approximation, not proof they are identical.

Why not vector-only?

Exact phrases and IDs lose to cosine. Dependency is a walk. Backbone will use the disagreement sentence if they want a fight-that-wasn’t.

Two graphs?

LangGraph is workflow. Neo4j is knowledge. I keep the words separate.

Deeper probes
Cypher for the 2-hop?

I will open the service rather than quote memory as gospel.

Did you evaluate hybrid versus vector?

No labeled set. Curiosity stops at the evidence I have. I will not mint a winner table.

Must remember
  • 1500/200 cl100k_base, 3072-dim, hybrid + 2-hop DEPENDS_ON. Not char-length. No IR labels. Redis not wired.
Missing — do not invent
  • Ablation; reranker name; recall.

13. Have Backbone; Disagree and Commit

Claude Have Backbone follow-up drill — Claude’s wording, not the locked bank

Respectfully challenge when you disagree. Conviction. Do not compromise for social cohesion. Once decided, commit wholly.

Coaching: you do not have a documented high-conflict manager disagreement. Do not invent one. Speak-first is IQVIA hybrid versus vector-only plus commit-on-evals. Story 2 is Y4 evidence prototype. Story 3 is Y5 RLS-in-DB versus app-only WHERE. Story 4 is Argus: refuse to multiply 73% across 20 cameras — standards plus backbone, no manager scene. If they demand a fight, say the gap and stay on a design fork.

Keep straight — no manager fight
  • There is no locked shouting match, skipped review, or “I overrode my manager.” Design disagreement + prototype or eval plan is what you have. Past tense on a fight you did not have is a lie.
IQVIA — hybrid versus vector-only; commit on evals strongest

Speak-first Backbone. Learn/Invent used hybrid as curiosity and job-split. Here you challenged vector-only because requirements DEPENDS_ON, and you say how you would commit if the team had picked vectors anyway.

Situation

On the IQVIA Hybrid RAG processor, the socially easy design is embed the BRD and retrieve neighbors. A 200+ page BRD is full of identifiers and requirements that depend on each other. Similarity is not dependency. Vector-only is cohesive in a meeting because everyone has shipped a vector demo.

Task

Challenge that default without turning it into a personality contest, and be ready to implement whichever retrieval mode the team locked — including evals I do not yet have.

Action

I argued for hybrid: BM25 plus vector kNN plus semantic rerank on Azure AI Search, plus Neo4j Document / Requirement / Entity walked on DEPENDS_ON, because a test case that misses a prerequisite is a silent defect. I did not claim a recall number — there is no labeled IR set. Conviction was the failure mode, not a fake nDCG. Chunking stayed 1500/200 cl100k_base, 3072-dim, 8-node ingest, 5-node tests. Redis/Celery not wired; I did not dress the argument with a queue. Commit: if the team had picked vector-only, I would have implemented vector-only and put my energy into an eval harness so we could still see what we lost — I would not have quietly left a second hybrid path running for social comfort, and I would not have sabotaged the index. That rejection is a counterfactual I am willing to say. I do not invent that they overrode me in a review.

Result

The system I can walk is hybrid plus graph. I still do not have a published winner table. Honesty is part of backbone: I will not fake the score that would have “won” the argument.

Spoken 90–120s. “Vector-only on a BRD is the comfortable demo. I disagreed. Requirements DEPENDS_ON each other, and section IDs lose to cosine, so I argued hybrid search plus a 2-hop graph walk. I did not have a labeled IR set, so I did not invent nDCG to win the room. If the team had locked vector-only, I would have built that and I would have committed to evals so we could see the miss class — I would not have kept a shadow hybrid for my ego. I do not have a manager fight on paper. Redis and Celery are not wired; I will not use them as props.”

Likely interviewer questions
Who did you disagree with?

The default design, not a named manager I will invent. I can speak the fork: vector-only versus hybrid+graph.

Did you refuse to implement their choice?

No event like that is locked. The commit I offer is hypothetical and clean: I would implement and evaluate.

Isn’t hybrid just more complexity?

It is more hops. The conviction is the miss: a dependent requirement that never appears in the top-k neighbors. I still owe evals I have not built.

Social cohesion — did you fold?

I did not fold the architecture I can show you into vector-only to sound agreeable. I also did not manufacture a hill I died on.

What would you have measured if they picked vector-only?

Whether prerequisite requirements still appeared in the context used for tests. I do not invent that I already ran that A/B.

Same as Learn hybrid?

Learn is “I wired the modes.” This is “I challenged the easy mode and I would commit.” One opening per hour.

Deeper probes
Tell me about a time you fought your manager.

I do not have that story documented. I will not invent it. I can give you a design disagreement and how I would commit.

LangGraph versus Neo4j — did people confuse them?

I keep the words separate in the room. That is clarity, not a fight.

DeepQuery 0% — did you argue with someone?

I argued with the anecdote, not a person I will name. Dive Deep owns that card.

Must remember
  • Disagree = hybrid+DEPENDS_ON versus vector-only. Commit = implement + evals if they pick vectors. No manager fight. No fake nDCG.
Missing — do not invent
  • A review where you were overruled; a labeled bake-off.
Y4 — renderer versus a new library; evidence, then commit backup

Coaching: if Invent/Frugality/Trust already spent Y4, skip. Backbone sentence is conviction without a scene.

Situation

A new chart library for the bot is easy to want. Two renderers would drift. I disagreed with that spend of complexity.

Task

Challenge with something they could click, and be ready to commit if reuse lost.

Action

I prototyped structured JSON into ElementRenderer. That was the respectful challenge. I do not have a locked rejection. If they had chosen a new library, I would have implemented it and I would not have left a half-dead reuse path to make a point.

Result

One renderer in the product I can show. No fight on paper.

Spoken. “I disagreed with a second chart stack. I did not give a speech. I showed a prototype on ElementRenderer. If they had rejected reuse I would have committed to their library. I do not have a manager argument to sell you.”

Follow-ups
Conviction without data?

The data was the existing renderer and the drift cost. Not a user study I will invent.

Did you compromise for cohesion?

I did not add a second island just to end a meeting. I also did not invent a meeting that needed ending.

Same as Earn Trust Y4?

Trust is candor. This is disagree-and-commit. Pick one first sentence.

Deeper probes
Who was in the room?

Team and manager could click it. I do not invent quotes.

Did the crash change your mind?

The crash was client aggregation. Different defect. Do not glue them into a fight.

Must remember
  • Prototype is the challenge. Commit is counterfactual if reuse lost. No fight.
Missing — do not invent
  • A rejected-reuse decision record.
Y5 — RLS in Postgres versus app-only WHERE backup

Coaching: Ownership/Standards/Trust used pieces of Y5. Here the fork is where the predicate lives. No manager fight.

Situation

The cohesive intern demo is: add organizationId in the application WHERE, or ask the model to add it. That ships a green chart. It fails on the first missed handler or a JOIN the UI never rendered.

Task

Challenge that default. Isolation has to hold when the SQL is ugly.

Action

I argued RLS in Postgres: per-request transaction, SET ROLE to the non-owner, GUC from JWT, fail-closed rls_no_access, policies from a generator. I discarded trusting the LLM with authorization and discarded app-only WHERE as the real control. Once the path was SET ROLE on warehouse facts, I would not keep a second ad-hoc WHERE style “so nobody feels bad.” Chat CRUD may still use executeWithoutRLS — I say that so I am not pretending a purity I did not ship. If the team had locked app-only WHERE, I would have implemented it and I would have kept writing down the leak class until we revisited — I do not invent that they did lock it.

Result

Three-tier RLS on the shared warehouse path. I do not invent a quote from a security review.

Spoken. “I disagreed with app-only WHERE and with ‘the model will add the org filter.’ That is social cohesion around a demo. I wanted RLS in Postgres on a per-request SET ROLE, GUC from the JWT, fail-closed if there is no db role. Zero rows is a filter, not a reject. I do not have a manager fight. If they had locked application filters I would have built that path and I would not have secretly forked a second policy.”

Follow-ups
Isn’t RLS heavier?

Yes. The conviction is a JOIN the UI never showed. I will not pretend it was free.

Did you compromise?

executeWithoutRLS on chat metadata is a scoped exception I will name. Warehouse facts should not ride it. That is honesty, not folding the control.

Same as Earn Trust Y5?

Trust is empty versus 403. This is the fork and the commit. One opening per hour.

Deeper probes
FORCE RLS as backbone?

I do not claim FORCE RLS unless I can show it. Backbone includes not overstating the control.

Anyone push back?

Discarded options, not a performance-review scene. I will not mint a villain.

Must remember
  • Fork = RLS-in-DB vs app WHERE / LLM auth. No fight. Filter ≠ reject. executeWithoutRLS named.
Missing — do not invent
  • Overrule meeting; FORCE RLS in prod.
Argus — refuse to put 73% mAP on 20+ cameras backup

Coaching: original, not makeup — the refuse-to-widen is documented. Are Right was “73% is not done.” Standards was the 89%/24 FPS gate. Here the sentence is: I would not compromise the safety bar so the demo could get wider. No stakeholder shouting match is locked.

Situation

Argus is YOLOv9 PPE detection. 73% mAP drew boxes. The socially easy story is wire 20+ cameras and improve later. That is cohesion around a live wall of video.

Task

Hold the bar. A weak detector times twenty is a wider miss, not a product.

Action

I refused to treat 73% as deployable width. I went back to a 15,000+ image set until reported mAP moved 73% to 89% at 24 FPS. Then a Dockerized multi-feed pipeline, PostgreSQL audit logging, automated alerts. I do not invent a safety officer I argued with. I do not invent that someone ordered me to ship 73%. Conviction was the miss on a person, not a personality. If a team had locked “cameras first,” I would have said the defect out loud and I would not have quietly claimed the wall was safe — I do not have that overruling on paper.

Result

Width after 89% and 24 FPS. Pilot: recorded safety incidents −50% after alerts. I need the incident definition if they press. I do not add a second invented 2× study as a new fact; notes sometimes flip the family.

Spoken. “I would not put a 73% PPE model on 20 cameras to make the wall look finished. That is compromising a safety bar for a cohesive demo. I trained on 15k+ images to 89% mAP at 24 FPS, then we widened. I do not have a manager fight. The resume’s pilot says recorded incidents dropped 50% after alerts. I need how ‘incident’ was coded if you press the number.”

Follow-ups
Did anyone demand 73% in production?

Not a locked scene. The temptation exists on every CV demo. I used the metric and the miss cost.

Is 89% enough?

It was the bar I used to allow width. I do not claim class-wise evenness. I do not invent the class list.

Same as Are Right / Standards / Scale?

This is refuse-to-compromise width. If Argus already opened the hour, use IQVIA hybrid for Backbone.

Deeper probes
IoU, split, GPU?

Not locked. I will not invent them.

This feels thin without a conflict.

Then Backbone first story should be IQVIA hybrid. I will not fatten Argus with a fake argument.

Must remember
  • Refuse 73% × cameras. 15k+, 89% @ 24 FPS, then 20+. No manager fight. Pilot −50% needs definition.
Missing — do not invent
  • A person who ordered cameras-first; class AP; hardware.

14. Deliver Results

Claude Deliver Results follow-up drill — Claude’s wording, not the locked bank

Focus on key inputs, right quality, timely. Despite setbacks, rise to the occasion, never settle.

Coaching: speak-first is Horizon as we on the ERC date with your video+perception — flag 17/18. Story 2 is Y8 as product outcomes with an honest I/we split. Story 3 is Argus 73→89 then cameras. Story 4 is DeepQuery shipped plus benchmark A runs, no IQVIA %. Do not manufacture a missed deadline.

Keep straight — no manufactured failure
  • You do not have a documented missed deadline, critical-feedback packet, or personal-failure fable. Do not manufacture one. If they ask for setback or feedback, use real defects with cost: Argus 73% was not good enough; IQVIA DOM made the wrong click; Ylogx client-side aggregation crashed the tab. Those are defects, not fake slips.
Horizon ERC — we placed; I delivered video+perception on the date strongest

Speak-first Deliver. Bias already used “I moved on sensors we had.” Here the sentence is the result on the calendar: we competed, I can name my inputs. Earth later is teaching the pipe. If Bias already opened Horizon, use Y8.

Situation

ERC 2024 has a date. Team Horizon built a ROS2 Mars rover, February to June 2024. A rover that cannot show the operator a POV, or that has no ZED scanning in the nav conversation, is not delivered — it is a crate of parts. I was core software, not team lead, not planner owner.

Task

Deliver the key inputs I owned in time: GStreamer video and ZED perception into the stack the rest of the team could drive.

Action

I focused on those inputs. GStreamer on ROS2, resume 60 FPS, multi-feed operator POV. ZED 2 environmental scanning, resume 2M+ points per second, into RViz/Gazebo and into the costmap conversation. Right quality meant a pipe others could run, not a fusion novel. I did not take the planner, the full costmap, or custom fusion. Setback language I will not fake: I do not have a missed ERC deadline on paper. The real quality gap I will name if they ask for struggle is the weak +40% obstacle definition and the collision number that is not mine — I still delivered the perception hop on the calendar we had.

Result

We placed 17th of 80+ on the resume. Public materials sometimes ~18th and #1 India. I flag the discrepancy; I do not brawl. −55% simulated collisions is the planner team’s number. I do not move ERC onto Ylogx or IQVIA.

Spoken 90–120s. “We took a Mars rover to ERC 2024. I am not going to deliver that sentence as if I built the vehicle. I delivered the operator video — GStreamer, 60 FPS, multi-feed POV — and I integrated ZED scanning at 2M+ points per second into the nav conversation. I did not write the planner or custom fusion. The resume says 17th of 80+; some public notes say about 18th. I flag that. −55% collisions is not my algorithm. The timely part is: those hops were on the rover when we competed.”

Likely interviewer questions
What were the key inputs?

Video pipe and ZED perception integration. Not mechanical, not the trajectory chooser.

Did you miss the date?

I do not have a documented miss. I will not invent one to sound humble.

17 or 18?

I volunteer both and I will align the source of record. The delivery story does not depend on the integer.

Despite setbacks — give me one.

I will not mint a broken axle night. Real defects I can use in this interview family: a 73% Argus model was not shippable; an IQVIA DOM budget made a wrong click; a Ylogx report crashed the tab. Those are other projects. On Horizon I will not invent a slip.

Never settle — +40%?

I will not settle for boasting a weak definition. That is the opposite of this principle.

Were you team lead?

No. Core software member. We for the place. I for video+ZED.

Deeper probes
Glass-to-glass latency?

Not locked. I will not invent it.

Same as Bias?

Bias is reversible speed on sensors we had. This is the result on the date. One opening per hour.

Critical feedback from ERC judges?

Not locked. I will not mint a judge quote.

Must remember
  • We placed; I = video+ZED. Flag 17/18. Not planner. −55% theirs. +40% weak. No invented miss.
Missing — do not invent
  • Official place PDF; a slipped ERC milestone; judge feedback.
Y8 — product outcomes; split what is mine backup

Coaching: Ownership Y8 was “I did not stop at localhost.” Think Big was product shape. Here you deliver numbers as product outcomes and you draw I versus we. Do not dump every percent. If Horizon already delivered, this is the backup.

Situation

ConvBI needed reports, NL analysis, and KPI tiles that operators could use, isolated, on a serving path. I was an intern, not AWS account owner, not founder.

Task

Land the pieces I actually owned at the right quality, and not claim the whole scoreboard as a personal A/B.

Action

Personal inputs I will stand on: inherited-bot stabilize (Y1 map, format, dialect), ElementRenderer reuse (Y4), RLS middleware + generator + fail-closed (Y5), cache key with role+org (Y6), deterministic dashboard GET with no LLM, intern initiative on Docker / ECS / ALB / CloudFront / GitHub Actions. FastAPI proposes SQL; Nest executes under SET ROLE. Team / product outcomes on the resume: 40% faster report generation, 99.9% uptime, 30 dashboards, +60% reduction in manual reporting overhead, SQL-RAG +65% analyst productivity, Redis −35% bot-DB, sub-210ms tile family, 2× release versus manual steps. I pick one or two if they ask Deliver — usually “reports and tiles shipped, uptime held, isolation already on.” I do not recite the list. I do not pin 40% or 99.9% on the client aggregation crash; that crash was a defect I fixed with a server path and click-to-load.

Result

A product operators could use on ECS. Methodology for each percent is a Dive Deep question. I do not quote a bill. I do not invent a missed intern deadline.

Spoken. “At Ylogx I need to split the scoreboard. What I can call mine is the bot path I inherited and stabilized, the renderer reuse, RLS on the request, the identity-keyed cache, deterministic dashboards, and an intern deploy path onto ECS and ALB. Product-family numbers on the resume — report time, uptime, dashboard count — are we, not a personal A/B. I will pick the one that matches your question instead of reciting the list. FastAPI writes SQL; Nest runs it as the caller. I was not the AWS account owner.”

Follow-ups
Give me one number.

If they want serving: 99.9% uptime as resume family. If they want reports: 40% faster generation as product family. If they want analysis: +65%. I will not give all three unless they ask for the scoreboard — and then I will label them product, not “because of me.”

Sub-210ms p95?

Resume says sub-210ms. I do not upgrade it to p95.

Did you miss a client deadline?

Not documented. The crash was a quality defect, not a date I will invent.

2× release?

CI/CD versus manual steps on the resume. I need the before/after procedure if they press. I will not invent minutes.

Deeper probes
Who clicked production AWS?

Not locked. Intern initiative on the path, not account root.

Same as Ownership Y8?

Ownership is “not my job was wrong.” This is outcomes plus I/we. One opening per hour.

Must remember
  • I: bot stabilize, renderer, RLS, cache, deterministic tiles, intern deploy path. We/product: 40%, 99.9%, 30/+60%, +65%, −35%, sub-210ms, 2×.
  • Do not dump. Crash ≠ 40%. No missed deadline fable. No bills. No p95.
Missing — do not invent
  • Uptime window; percent methodologies; who had AWS root.
Argus — 73→89, then cameras backup

Coaching: Deliver = quality then width, on purpose. If Are Right/Standards/Backbone/Scale already used Argus, skip.

Situation

A 73% mAP PPE model ran. Delivering “cameras” at that quality would have been delivering a miss factory.

Task

Right quality first, timely width second. Never settle for a demo mAP on a floor.

Action

15k+ images, YOLOv9, 73% to 89% at 24 FPS, then Dockerized 20+ streams, Postgres audit, alerts. I do not invent the split or the GPU.

Result

Width behind a model I would stand in front of. Pilot −50% recorded incidents after alerts. Need the coding guide if they press.

Spoken. “I did not deliver Argus as 20 cameras at 73% mAP. I delivered 89% at 24 FPS first, then width. The pilot’s recorded incidents dropped 50% after alerts. I need that definition if you press. I will not invent a missed go-live.”

Follow-ups
Was 73% a setback?

It was a quality bar I refused. Cost was “not shippable for floor safety.” That is a real defect, not a fake deadline.

24 FPS why?

A late box is a miss in motion. Quality includes timely inference.

Same as Scale?

Scale is secondary effects of widening a bad model. This is the delivery sequence. One opening per hour.

Deeper probes
Site and duration?

Not locked. I will not mint them.

Haar cascades?

No. Do not invent Haar.

Must remember
  • 73→89 @ 24 FPS, then 20+. Pilot −50%. No Haar. No invented go-live miss.
Missing — do not invent
  • Split, GPU, incident codebook, site.
IQVIA DeepQuery — shipped pipeline + benchmark A runs backup

Coaching: Learn was curiosity. Dive Deep was 0% parse. Scale is filter-before-scrape. Here: you shipped a 12-node CLI and you have A-grade runs in the write-up. No product percent.

Situation

Deep research as a chatty agent is easy to demo and hard to deliver. I needed a state machine operators could rerun.

Task

Ship the graph: plan, cheap grounding, clarify, 12–15 queries, fan-out, filter, waved scrape, reason, decide, synthesize. Local CLI, Azure OpenAI.

Action

I delivered those nodes, including url_intelligence so the scrape set is chosen — target often 120–180 from a pool that can be hundreds. HITL is clarify and refine, not a human inside every node. Benchmark write-up: 12 runs, 10 graded A, 2 graded D at 0% confidence that I read as synthesis parse, not empty retrieval. Strong example: 857→120 filtered→~137 pages. I did not wait for Redis/Celery; they are listed and not wired. I do not claim a hosted IQVIA research product.

Result

A pipeline I can operate and a write-up with A runs. I do not quote an IQVIA success or latency percent. I do not invent that I missed a launch date.

Spoken. “I shipped DeepQuery as a 12-node LangGraph on a local CLI — plan, light search, clarify, about 12–15 queries, fan-out across DDGS, Bing, and Firecrawl, filter before scrape, then reason and synthesize. In the benchmark write-up, 10 of 12 runs graded A. Two sat at 0% confidence; those still had pages — that was parse, not a dead scrape. A strong run went 857 URLs to 120 filtered. I do not have an IQVIA product percent. Redis and Celery are not wired.”

Follow-ups
Is 10/12 your SLA?

No. It is a write-up. I will not promote it to an IQVIA metric.

200+ websites?

Resume class for the discovery pool, not 200 LLM-scraped pages every run.

Setback?

The D runs and the DOM click on a different IQVIA path are real defects. I will not turn them into a missed deadline.

Deeper probes
Hosted?

Local CLI. I will not invent multi-region.

Same as Learn?

Learn is what I had to learn. This is what shipped and how the runs graded. One opening per hour.

Must remember
  • 12-node shipped. 10 A / 2 D parse. 857→120. No IQVIA %. Not wired Redis/Celery.
Missing — do not invent
  • Launch date; product SLA; merge of a synthesizer fix.

15. Strive to be Earth’s Best Employer

Claude Earth’s Best Employer follow-up drill — Claude’s wording, not the locked bank

Safer, more productive, higher performing, diverse, just workplace. Empathy. Ask if fellow employees are growing/empowered/ready. Vision for their success even elsewhere.

Coaching: this is thin. You were not a manager. Speak-first is Horizon knowledge sharing so someone else could operate GStreamer/ZED. Story 2 is IEDC Tech Team member pairing — no mentee count. Story 3 is Y9 git lanes. Story 4 is a labeled intern-buddy make-up. Do not invent mentee outcomes. Hire and Develop already used IEDC as primary in 1–8 — change the first sentence here to empathy and “can they run it when I am gone.”

Horizon — share GStreamer/ZED so others can operate and debug strongest

Speak-first Earth. Ownership was “I owned the pipe.” Hire backup was pairing. This sentence is: the workplace is safer and more productive if the POV is not trapped in my headset. Vision for their success even on launch day without me.

Situation

On Horizon the video and ZED path was easy to make a single-person mystery. A competition pit is not a just workplace if only one intern can bring the operator view up. ERC does not care that I understood GStreamer if the next software member cannot debug a silent feed.

Task

Ask whether fellow members were ready to run and debug the pipe — not whether they admired my launch-day heroics. I was not their manager. I was a core software peer.

Action

I paired on launch: start the GStreamer path, show the multi-feed POV, show where ZED data entered visualization, and say out loud that the planner was not mine so nobody inherited a lie. Empathy here is time: I did not make them wait on me to touch a gst pipeline. Knowledge sharing was the interface and the failure class — “feed is up, ZED is quiet, planner is not this repo” — not a lecture. I do not invent a wiki URL. I do not invent a named junior who became perception lead. I wanted them able to operate this even if I was on another station, or later on another team.

Result

The rover’s video story was less trapped in one head. ERC 17th/80+ (flag ~18th) is a team result, not a coaching KPI. I have no mentee count because I will not invent one.

Spoken 90–120s. “I do not have a manager title on Horizon. What I could do for the people next to me was make the video pipe something they could start and debug. I paired on launch: GStreamer up, multi-feed POV, where ZED entered the view, and I said the planner was not mine so I did not train them on a lie. If the feed died I wanted them ready without waiting for me. I do not have a named person and a before/after I can defend. 17th of 80+ is we; some public notes say about 18th. I will not turn that place into a mentorship score.”

Likely interviewer questions
How did you know they were growing?

I asked whether they could bring the POV up without me narrating every flag. I do not have a locked survey. I will not invent a readiness score.

Who did you train?

Other software members on the launch path. No locked name. I will not mint one.

Safer workplace — really?

Safer as in fewer single-point-of-failure moments in the pit, not an EHS program I will invent. A silent camera when only I know gst is an unsafe operational habit.

Vision for their success elsewhere?

If they took GStreamer or ZED into another rover or a job, that is success I wanted. I do not invent that career path.

Were you team lead?

No. Peer. Same honesty as IEDC member.

Written runbook?

I will not invent a wiki. Pairing on launch is what I can defend.

Deeper probes
Hours taught?

Not locked. I will not mint them.

Same as Hire Horizon?

Hire was develop-the-skill. This is “are they empowered to run it when I am gone.” One opening per hour.

Same as Bias / Deliver Horizon?

If those already used the rover, use IEDC here.

Must remember
  • Pair on launch. Teach the boundary. No named mentee. Not lead. Flag 17/18 if the place comes up — do not make it a coaching KPI.
Missing — do not invent
  • Names, runbook URL, hours, a promotion story.
IEDC Tech Team member — pairing, not a lead narrative backup

Coaching: Hire primary in 1–8 was this card. Here emphasize empathy and whether they can ship without you finishing their module. Still member. Still no mentee count. Hackathon medals are yours, not a coaching scoreboard.

Situation

IEDC CUSAT Tech Team member — not president, not hiring manager. People showed up with half-built ideas and half-broken Git. If I tell this as an employer program with headcount, I am lying. We were not employing them.

Task

Help them become able to ship their piece. Ask if they were ready to drive. Do not take the repo so I could look generous.

Action

I paired: they drive, we reproduce, we name the hop, they take the next change. If they wanted me to finish the module so they could present, that is not empowerment. I would do the hard part with them once. I did not assign ratings. I did not run a diverse-hiring loop I will invent — I can say I tried not to only help the loudest person in the room, without minting a DEI program.

Result

I can say I took pairing seriously as a member. I cannot say N mentees reached production. Eight hackathons with CodeRecet 1st, MLH Best Project, Magnathon 2.0 runner-up are my placements, not their outcomes.

Spoken. “I am an IEDC Tech Team member, not a manager. I do not have a mentee count and I will not invent one. I paired: they drive, we name the hop, they do the next change. Finishing their module so they could present is the opposite of asking whether they are ready. If you need a named person and a before/after, that is missing and I will not fill it live.”

Follow-ups
Tell me about someone you developed.

I will describe the pattern. I will not invent a mentee.

Were you the IEDC lead?

No. Member.

Did you coach hackathon teams?

Medals are mine. I will not convert them into a coaching program.

Empathy in one line?

I do not make their demo depend on my hands. That is respect, not a slogan.

Deeper probes
Give them a name.

No.

CGPA if they opened education?

8.42 on resume.md versus 8.12 on a September 2026 PDF. Flag it. Not an employer story.

Must remember
  • Member, not lead. Pairing mechanism. No mentee count. Hackathon medals are yours.
Missing — do not invent
  • A name, a skill gap, a measurable improvement.
Y9 — git lanes so teammates stop colliding backup

Coaching: Hire used process-as-develop. Here: a more productive, less blamey workplace. No conflict percent. No fight. No missed deadline.

Situation

On ConvBI, two people in the same files meant merge pain and a habit of fearing the chatbot or the builder. That is a worse workplace than a missing feature.

Task

Make lanes clear enough that the next intern could own a change without a hero merge — growing, not blocked.

Action

I pushed for clearer branch separation so bot, reports, dashboards, and RLS did not sit on one sticky branch. The employer move was “this is why Friday night hurt” plus a simpler lane, not Git theory, not becoming GitHub org owner.

Result

Fewer collide-and-blame cycles as a class. I do not invent a conflict count.

Spoken. “People were stepping on the same files. That is not a high-performing intern week. I pushed for clearer branches — bot versus builder versus dashboards versus RLS — so someone else could ship without waiting on my merge. I do not have a conflict percent and I did not become the GitHub owner. I do not have a fight to sell you.”

Follow-ups
How is this Earth’s Best, not just Git hygiene?

Because the fellow intern’s time and dignity sit in that merge. Process is how you ask if they are empowered when you cannot hire.

Rebase law?

I do not invent a religion. I speak clearer separation.

Blow-up?

Collisions. Not a fight. Not a missed deadline.

Deeper probes
Protected branches?

Not locked.

I vs we?

I argued for lanes and kept my work on one. We still merged as a team.

Must remember
  • Collisions → lanes. No %, no fight, no missed deadline, no mentee.
Missing — do not invent
  • Branch names; incident count; org-owner title.
MAKE-UP — hypothetical intern buddy program makeup
MAKE-UP / HYPOTHETICAL — DO NOT PRESENT AS FACT. There is no documented intern buddy program, no buddy name, and no mentee outcome. If they ask how you would grow someone on your last team, you may think aloud in future tense. You may not slip into past tense. You may not give this person a name. You may not invent that they shipped RLS or got a return offer.

Situation

Hypothetical. A new intern joins a ConvBI-like team and will touch Postgres and the bot path.

Task

Hypothetical. Ask whether they are safe, growing, and able to succeed even if they leave at summer’s end — not whether they make you look like a lead.

Action

I would sit them on one request: JWT → transaction → SET ROLE → GUC from JWT → a SELECT that asks for the other org and comes back with zero rows. I would make them draw executeWithoutRLS and say which tables must never use it. I would pair on one crash class — client aggregation — so they do not send a tab crash down the line. I would not finish their PR so I could present. I would not invent that I already ran this program. I would want them ready on another team later, including one that is not mine.

Result

None in reality. The hoped-for result would be a person who can fail closed without me in the room. I do not have that story.

Spoken (future tense only). “I do not have an intern buddy program to tell you about. If I were designing one, I would not start with coffee chats. I would sit them on one isolated request and one UI defect class, they would drive, and I would care whether they could do the next one elsewhere. I will not put a name on that person because they do not exist in my facts.”

Follow-ups (still hypothetical)
Can I tell this as “I ran a buddy program”?

No. If you hear past tense, stop.

Why have this card?

So you can answer “how would you grow someone?” as a design and not panic-invent a mentee.

What if they insist on a real coaching story?

Return to Horizon launch pairing or IEDC pairing. Repeat: no names, no counts.

Deeper probes
Give the buddy a name?

No. A name is how makeup becomes a lie.

Could Y1 teammate-left be a buddy story?

No. That person left. You inherited code, not a mentee.

Must remember
  • Badge makeup. Red box. Future tense. No name. Do not present as fact. No invented mentee outcomes.

16. Success and Scale Bring Broad Responsibility

Claude Success and Scale follow-up drill — Claude’s wording, not the locked bank

Humble about secondary effects. Leave things better. Create more than you consume.

Coaching: speak-first is Argus — do not scale a bad model. Story 2 is Ylogx ALB/ECS with RLS already on. Story 3 is DeepQuery filter so 857 URLs do not become 857 LLM pages. Story 4 is GiftedBooks grounded / cite-or-abstain so more students do not mean more hallucination. Humble: you did not invent the internet, ECS, or YOLO. You tried not to multiply a defect. No bills.

Argus — 20+ cameras only after 89% and 24 FPS strongest

Speak-first Scale. Secondary effect of width at 73% is a false sense of safety on every feed. Standards used the gate sentence. Are Right used refuse-73%. Deliver used sequence. If any of those already opened Argus, use Ylogx ECS+RLS or DeepQuery filter here.

Situation

Once a PPE detector runs, success looks like more cameras. Scale without humility is twenty streams of the same miss. A person without a helmet is not averaged away by mAP theater.

Task

Widen only after the model was something I would multiply. Leave the floor better than a demo webcam. Do not consume “safety” as a brand while creating more unlogged misses.

Action

I held 89% mAP and 24 FPS as the gate, from a 15k+ image loop that left 73% behind. Only then Dockerized multi-feed, Postgres audit logging, automated alerts on 20+ cameras. Alerts on garbage detections would have scaled noise, not responsibility. I do not invent the coding guide. I do not invent a city-wide rollout. Humble: YOLOv9 and Docker are not my inventions; the responsibility I will own is the order — quality, then width — and the audit trail so a detection is not a vibe.

Result

Width behind a model I would stand in front of. Pilot recorded incidents −50% after alerts. I still need the incident definition. I do not claim I created more safety than I can measure.

Spoken 90–120s. “The secondary effect of scaling Argus too early is twenty cameras agreeing on a miss. I would not put a 73% model on that wall. I held 89% mAP and 24 FPS, then we went to 20+ streams with Postgres audit and alerts. Alerts on a bad detector would have scaled noise. The pilot’s recorded incidents dropped 50% after alerts — I need that definition if you press. I did not invent YOLO. I did try not to multiply a defect and call it a deployment.”

Likely interviewer questions
What secondary effect did you fear?

A wider false sense of safety, and alert fatigue if detections were junk. That consumes trust and creates risk.

Did you leave the floor better?

In the pilot the resume reports, recorded incidents dropped after alerts. I will not invent a second site or a year-two study.

Create more than you consume?

Audit logs and a quality gate are what I added. I consumed training time and a 15k+ set. I will not dress that as a sustainability report.

Would you scale 89% at Amazon?

I would ask what miss is acceptable class-wise. I would not import Argus’s number as a universal SLA. I do not invent Amazon’s PPE policy.

2× after alerts?

Stay with resume −50% recorded incidents in pilot. Do not add a second invented multiplier.

Same as Standards?

Standards is the defect-down-the-line sentence. This is humility about width. One opening per hour.

Deeper probes
Hardware at 20 cameras?

Not locked. I will not invent a GPU SKU.

Label quality at scale?

I know labels matter. I do not have an inter-annotator number.

Haar? Qdrant?

No. Do not invent them.

Must remember
  • Do not scale a bad model. 89% + 24 FPS then 20+. Pilot −50%. No Haar/Qdrant. No second multiplier.
Missing — do not invent
  • Class AP, hardware, incident codebook, multi-site rollout.
Ylogx — ALB/ECS with RLS already on; do not scale leaks backup

Coaching: Ownership/Deliver used deploy and tiles. Here the secondary effect is: more healthy tasks times a missed SET ROLE is more leak surface. Isolation was already the request path — scale must not skip it.

Situation

NL analytics and dashboards only matter if more users do not mean more tenants in one response. Success on ConvBI looked like ECS tasks behind an ALB, Docker, CloudFront for static assets, GitHub Actions. The irresponsible version is scale the bot and hope organizationId stays in the prompt.

Task

Grow serving without growing JOIN-shaped leaks. Leave the warehouse better than a single-intern localhost.

Action

I worked an intern deploy path: ECS, ALB, Docker, CloudFront, Route 53, CI/CD. RLS was already on the warehouse request — JWT, SET ROLE, GUC, fail-closed rls_no_access. More tasks still open a per-request transaction as the caller. FastAPI still only proposes SQL. I did not shard. I did not operate EKS. I did not put private JSON on the CDN. Cache keys still carry role and org so a hot path cannot scale a cross-tenant hit. Resume Redis −35%; this Nest snapshot is a Map — I say that if they open the repo. I do not quote an AWS bill I “saved by scaling.”

Result

Serving path the resume family associates with 99.9% uptime and sub-210ms tiles. Those are product numbers, not proof that scale is morally done. I do not invent a tenant-count hockey stick.

Spoken. “If we scale ConvBI without isolation, we scale leaks. I worked an intern path onto ECS and an ALB with Docker and CI/CD, and the warehouse request still SET ROLEs the caller and sets the org from the JWT. FastAPI does not become the database user just because traffic went up. I did not shard and I was not the AWS account owner. I will not quote a bill. CloudFront is for static assets, not private JSON.”

Follow-ups
What secondary effect?

More tasks, more generated SQL, more chances to forget the session. RLS on the request is how we tried not to multiply that.

Did you skip SET ROLE for speed?

That would consume trust and create a leak. I will not tell that story as a win.

PgBouncer? EKS?

I did not ship those in this repo story. I will not invent them.

Deeper probes
99.9% as scale proof?

Uptime family, not a leak SLA. Do not swap with GiftedBooks 99.5%.

Same as Deliver Y8?

Deliver is outcomes. This is secondary effects of width. One opening per hour.

Must remember
  • Scale tasks, not skip SET ROLE. No bill. No EKS/shard claim. Redis vs Map if they open GitHub. 99.9% ≠ leak SLA.
Missing — do not invent
  • Tenant counts; AWS invoice; pool size.
DeepQuery — filter before scrape; 857 must not become 857 LLM pages backup

Coaching: Frugality could have used this; we kept Stratify on Frugality. Here the sentence is secondary cost and junk context, not a bill you will invent. Humble: you did not invent the web.

Situation

Fan-out across DDGS, Bing, and Firecrawl can create hundreds of URLs. Resume class is research across a 200+ website discovery pool. Success that scrapes every URL consumes tokens, time, and context, and it creates a junk report. A strong run in notes had an 857 URL pool.

Task

Bound what the synthesizer is allowed to eat. Leave the run better than “we searched the internet.” Create a chosen page set, not a landfill.

Action

url_intelligence sits before waved scrape. Filter first; target often 120–180. Example: 857 → 120 filtered → about 137 pages. Query generation stays on the order of 12–15, not an unbounded query farm. HITL re-enters at url_intelligence on refine — a human is not approving every URL in the 857. I do not quote a bill. I do not quote an IQVIA percent. Two 0% confidence runs still had pages; scaling scrape would have been the irresponsible fix. Redis/Celery not wired — I did not scale a queue I never connected.

Result

A think hop in front of Firecrawl. Benchmark write-up 10 A / 2 D. I still do not claim I created more signal than I can measure with a labeled set.

Spoken. “If DeepQuery scales by scraping every URL we discovered, we scale junk and we consume a context window we did not earn. A run in my notes had 857 URLs. We filtered to 120 and scraped on the order of 137 pages. URL intelligence sits before the scrape wave on purpose. I will not invent a bill I avoided. I will not quote an IQVIA success percent. If I had answered 0% confidence by scraping more, I would have multiplied the wrong hop.”

Follow-ups
What secondary effect?

857 LLM pages: cost I will not quote, slower runs, and a synthesizer stuffed with near-duplicates. Filter is humility about fan-out.

200+ websites versus 120?

200+ is the resume discovery-pool class. 120 is a filtered scrape set on that example. Do not say I scraped 200+ LLM pages every time.

Is this Frugality?

It can be. This hour’s Frugality primary is Y6. This card is “do not scale a landfill.”

Deeper probes
Who invented URL filtering?

Not me as a category. I put the hop in this graph. Humble about secondary effects includes not claiming I invented search.

Same as Dive Deep 0%?

Dive Deep is grade versus artifacts. This is width of scrape. One opening per hour.

Must remember
  • 857→120→~137. Filter before scrape. 200+ = pool. No bill. No IQVIA %. 0% ≠ scrape more.
Missing — do not invent
  • Dollar cost; tokens saved; a hosted quota dashboard.
GiftedBooks — grounded RAG so more students do not scale hallucination backup

Coaching: Customer was the 3–10 minute loop. Earn Trust was README plus candor. Here the sentence is secondary effects at width: more students on an ungrounded tutor is more invented syllabus. Cite-or-abstain is design intent, not a scored eval.

Situation

A VR tutor that works for one demo PDF can look ready to share. Scale without grounding means every new student is a new chance to invent a derivation. That consumes trust faster than it creates learning.

Task

Leave each new session better than a generic chatbot. Isolation and chunks are how width stays honest.

Action

I scoped retrieval to the authenticated student’s document metadata. I generated from a small retrieved set. I refused cross-user retrieval — that would have scaled a privacy bug and called it personalization. PYQ ranking stayed analytics so the model would not scale fake exam predictions. Design intent: stay on chunks or do not invent — cite-or-abstain in spirit. I do not have a labeled abstain rate or a citation eval. Resume: sub-300ms retrieve-and-answer path, 99.5% uptime, user-testing 3–10 min / +35% / +50% / 2.5×. I do not invent a student headcount I scaled to. README currently says AegisAI — if they are already on this project I say it; I do not hide it. I do not import Azure Search or Neo4j here; those are IQVIA.

Result

A loop I would rather multiply than an ungrounded tutor. I still have not measured faithfulness. Humble: I did not invent RAG. I tried not to multiply hallucination.

Spoken. “If GiftedBooks gets more students and the tutor is not grounded, we scale hallucination. I retrieve from that student’s own PDF and I answer from those chunks. I will not mix another student’s notes just because it looks smarter. Previous-year questions are analytics, not the model inventing the paper. I want cite-or-abstain — if the file does not support it, do not invent — and I will not pretend I scored that. User testing put doubts in a 3–10 minute window. Uptime on the resume is 99.5%. I do not have a headcount. The GitHub README currently describes AegisAI; I would fix it.”

Follow-ups
What secondary effect?

Wrong formula, wrong board, wrong student’s notes. Width multiplies whichever of those you allowed.

Did you measure abstain?

No. Design intent only. Earn Trust already said that. Do not grow a score here.

Same as Customer / Earn Trust?

This is hallucination at width. If GiftedBooks already opened the hour, keep Argus or ECS+RLS as Scale.

Deeper probes
Qdrant? LangSmith?

No Qdrant. No LangSmith on this project. I will not invent them.

99.5% versus 99.9%?

GiftedBooks versus Ylogx. Do not swap.

Must remember
  • Width × ungrounded = hallucination. User-scoped chunks. Cite-or-abstain is intent, not a score. 99.5% here. README mismatch if asked. No Qdrant. No headcount.
Missing — do not invent
  • Student N; citation eval; store topology.

Resume Metrics Defense — Bar Raiser first-pass + push chain

Adarsh Vishwakarma. Amazon SDE I R4 Bar Raiser rehearsal. Speak in first person. A number is a claim about a mechanism, not a trophy. If I cannot say what the number measures, I do not open with it.

META RULE — calibrated confidence. Bar Raiser tests calibrated confidence. Mechanism first, then what the number actually measures, then the honesty floor. Empty result ≠ Postgres rejected the statement. Distinguish RLS filter (statement succeeds, rows invisible) vs GRANT deny (permission error) vs Nest hasTableAccess (HTTP 403). I do not invent sample sizes, p95, cache TTL as a resume number, monitoring windows, n, or control groups. I do not speak interviewer scoring voice. I pick the metric that belongs to the question. I do not dump 40%, 99.9%, +65%, −35%, +60%, and sub-210ms in one paragraph.

Ylogx / ConvBI is the main exam in this hour if they stay on the intern. IQVIA has no percent on the resume. Horizon percents are ownership-sensitive. Project percents stay on their product. Hackathon placements are placements, not a measurement story.

Speak this live — what I actually say in the room

The cards below stay as written. This block is the spoken script. First person. One metric, one path. I do not mix 40% with the tab crash, with tile p90, or with 99.9%. I do not open with “I have no protocol.” I open with what changed, then how the number was taken, then what would make me take it off the resume.

Family map — say this once if they dump numbers. 40% = custom report builder cycle time. 99.9% = SPA + Nest serving stayed up for daily use. +65% = analyst no longer waits for a SQL person on the chatbot. −35% = Redis on repeat bot→DB hops only. 30 / +60% / sub-210ms = predefined KPI tiles, handwritten SQL, no model. Crash = a client-aggregation defect I caused; it is not how any percent was measured.

Jump: 40% · 99.9% · +65% · −35% · 30 / 60 / 210 · RLS · CI/CD

40% faster report generation — say this

60-second open (memorize this, then stop). “The 40% is only the custom report builder. Before that builder, a one-off report meant: know the tables, write or wait for SQL, dump to Excel, join, chart, export, send. After, an operator who is not a SQL person opens the canvas, drops fields, picks INNER or LEFT or RIGHT or FULL, puts slicers on year or month, hits execute-query on Nest — same SET ROLE transaction as everything else — and Chart.js draws it. Default cap is one thousand rows, max five thousand, so the browser is not a warehouse dump. They save the JSON and reopen it next period. The 40% is cycle time on that loop — time from ‘I need this cut’ to a usable report in the product — versus the Excel ritual. It is not Postgres getting 40% faster. It is not the thirty KPI tiles. It is not sub-210 millisecond JSON. It is not Redis. It is not chatbot productivity.”

Seven points I use if they push. Stay on the builder. Do not mention the crash unless they ask a mistake.

  1. Baseline, named. Old path = person who knows the books + spreadsheet join + chart + file send. New path = authenticated builder session that ends in a rendered report and a saved config. Same warehouse. Different loop.
  2. What the 40% is a percent of. Human minutes on a typical custom cut (sales / working-capital / statement-style slice the operator already knew they wanted). Not API p99. Not “first pixel of the SPA.” Not chatbot time-to-first-token.
  3. How we knew it moved. Internship QA and client review cycles: the same class of one-off pack that used to leave the product for Excel started finishing inside the builder. Product-family number on the resume. I was in those reviews. I did not sit with a clipboard on forty analysts. I will not invent n — I will also not pretend the number is decoration. The loop we shortened is the one I can walk in the code.
  4. What in the system actually removed time. No round-trip to an engineer for SQL. Joins and slicers in the UI. Execute through Nest queryDB on req.dbTransaction. Shared ElementRenderer. Save/load JSON so the next month is not a rebuild. Row cap so they are not waiting on a million-row dump that the old Excel path used to choke on.
  5. What I personally can defend. Canvas path, join types, slicers, execute under RLS, renderer, saved config. I do not claim I was the only person who ever touched the canvas. I claim I can operate and change that path.
  6. Hard walls — if I cross them the 40% is a lie. Pinning 40% on the tab-crash fix. Pinning 40% on dashboard GET latency. Pinning 40% on Redis. Saying the chatbot is the report builder. Weakening RLS so a chart renders faster. Measuring a happy-path demo of one pie chart and calling it generation time for a signed-off pack. If the old path was already a builder, the percent is theater — it was not; it was Excel.
  7. What would make me take 40% off the resume. Operators still defaulting to emailing workbooks for the cuts the builder was meant to own. Mixing “time to first chart” with “time to a signed-off pack” without saying which. If they want a stopwatch log and a population, I say: I do not have that sheet in front of me; the claim is the builder-versus-Excel cycle, and that is the claim I will defend or retract — I will not swap in a different story to save the number.

If they ask “prove 40%.” “I can prove the mechanism and the before/after loop. I cannot produce a time-and-motion study. The resume number is that loop getting about two-fifths shorter. If that is not enough rigor for how you score percents, I will not invent a study. I will walk the builder.”

If they mention the crash in the same breath. “That was a different defect. I put aggregation on the client, a large slice killed the tab, I moved heavy aggregation off the client and added click-to-load. Result was a stable UI, not the 40%. I will not use a crash to explain a generation-time percent.”

99.9% uptime — say this

60-second open. “99.9% is serving-path availability for the deterministic product under daily production load. In calendar terms that is on the order of forty-three minutes of unavailability in a thirty-day month if you treat it as continuous time — I use that so we both know the bar, not because I memorized a status page. In the number: can the operator load the CloudFront SPA and get KPI or report JSON from Nest. Out of the number: OpenAI timeouts, a bad generated SELECT, a Tally zip that failed to ingest. Hop I can walk: browser, CloudFront for static JS only, Route 53, ALB, ECS Fargate tasks running Docker — NestJS and FastAPI as separate services. Nest owns JWT, the transaction, SET ROLE, reports, and tiles. FastAPI proposes SQL; it does not execute tenant facts. Tiles are handwritten SQL with month and year on the query string. They do not wait on ChatOpenAI. That split is why an availability number on dashboards is even speakable. I helped ship that path. I was an intern. I was not the AWS account owner and I was not on a pager rotation I can recite.”

Seven points I use if they push. Do not say 99%. Do not mix GiftedBooks 99.5%. Do not mix the crash.

  1. Definition, out loud. 99.9% ≈ 43 minutes down per 30 days. 99% would be about seven hours. I will not round 99.9 to 99. I will not upgrade to four nines.
  2. Numerator I will defend without a fake Datadog. Daily production use of SPA + Nest tile/report APIs. Health: Terminus /health pings Postgres; /health/simple is process-up without the database. ALB uses those checks so a dead task is replaced instead of serving 500s forever. GitHub Actions on qa and main → ECR → ECS. Prod: I approve, about three minutes, then wait-for-service-stability. That is how we stayed on a version that boots, not how I invent an incident list.
  3. Why daily load did not mean “the LLM is in the SLO.” Known KPIs never call the model. If the model is down, chat degrades; dashboards still answer. If I put ChatOpenAI on GET /dashboards/sales, 99.9% becomes a vendor story and I take it off my mouth.
  4. What actually protects the nines (intern-true, not heroics). Static and API split (CloudFront is not the database). Rolling ECS replace behind ALB, not SSH-and-hope. Health checks that fail a bad task. CI/CD instead of a snowflake laptop. Fail-closed RLS does not take the site down — empty is not 500. Chat metadata can RESET ROLE so a missing chat GRANT does not 500 the whole app. I do not claim multi-region, Datadog, or a named on-call.
  5. Risk class I will name. Deploys, a bad task, Postgres unreachable, ALB failing open to a dead target. Not “it never went down.” Not “a teammate took it down.” I do not have a dated outage memorized. I will not invent one to sound humble and I will not say never-down to sound strong.
  6. Hard walls. Counting a crashed browser tab as downtime. Counting a chat 500 as the dashboard product being down. Claiming I owned observability. Speaking CodeBuild if this intern tree is GitHub Actions. Mixing GiftedBooks 99.5% or any other product. Saying 99% because 99.9 felt precise.
  7. What would make me take 99.9% off the resume. If serving depended on the model. If we ran a single task with no health replace. If “uptime” meant “I did not hear a complaint.” If they need the exact calendar window and probe host — I do not have those memorized; I will not pick “thirty days” to sound sharp. The claim I will stand on is: deterministic serving path, daily production load, CloudFront + ALB + ECS, tiles off the LLM.

If they ask “how did you measure 99.9%.” “I did not own the monitoring stack. I will not invent Grafana. What I can show is the serving shape and the health/deploy path that make 99.9% a possible claim. The resume states it under daily production load. If you need the raw time series, I do not have it in this interview. I will not replace it with a story about never going down.”

If they ask “were you on-call.” “No. I shipped and I can walk health and deploy. I will not perform ownership of a pager I did not sit.”

+65% SQL-RAG productivity — say this

45-second open. “Plus 65% is only the chatbot path. An analyst who cannot write SQL used to find a person, wait, get a CSV. Now they ask in English, FastAPI proposes a SELECT from an allow-list of public fact tables — on the order of ten, not information_schema — Nest executes that SELECT as the caller after SET ROLE, and we render a structured chart. The 65% is that wait going away. It is not model accuracy. It is not Redis. It is not the report builder’s 40%. It is the weakest Ylogx number scientifically — I have the path, I do not have a diary study — and I will not dress it up as a paper.”

Seven points.

  1. Baseline = wait for a SQL person. New = question → propose → Nest execute under RLS → chart.
  2. Unit = human productivity on retrieval, not milliseconds, not faithfulness.
  3. FastAPI never executes tenant SQL and never sees the JWT.
  4. Allow-list + SELECT-only reduce dialect accidents. They do not make 65% true and they do not make the number correct. Isolation is SET ROLE + USING.
  5. Empty result is not “Postgres rejected.” USING hid rows, or the cut is empty, or the WHERE matched nothing. GRANT is an error. 403 is Nest.
  6. Do not stack −35% Redis into this sentence unless they ask about repeats.
  7. Falsify: still waiting on a person for every real question; counting demo chats; executing as table owner and calling that productivity. If they want n, I say the study is not in front of me and I walk the path instead of inventing a control group.

−35% bot-database latency (Redis) — say this

45-second open. “Minus 35% is cache-aside on the bot-to-warehouse hop for repeat suitable questions. It is not dashboard latency. It is not 40%. Key includes role and org, not the query text alone, so a USER in ORG_A cannot be served ORG_B’s answer. Miss still executes as the caller with RLS. This Nest snapshot in front of me has no Redis client — it has a five-minute in-process Map for dataset field metadata, keyed by table name. I say both in one breath. I will not point at a Redis line in this file.”

Seven points.

  1. Hop = bot → DB repeats. Not tiles. Not builder first paint. Not LLM first token.
  2. Mechanism = cache-aside. Hit returns a payload already produced as that caller. Miss = SET ROLE again.
  3. Key = role + org (+ payload from that session). Text-only key is a leak and a polluted latency story.
  4. Checkout honesty: resume Redis vs this Map. Earn Trust is naming the split.
  5. Five minutes I can point at = fieldsTtlMs on fieldsCache, not a resume Redis TTL I will invent.
  6. Would-do on tiles is a different sentence: tenant in the key, never the shipped −35%.
  7. Falsify: measuring ChatOpenAI; measuring dashboards; counting cold starts as Redis; keying only by English or SQL text.

30 dashboards / +60% / sub-210ms — say this

45-second open. “This is the predefined KPI family, not the custom builder. Nine dashboard types in the registry — sales, receivables, payables, stock, collections, P&L, balance sheet, cashflow, overview — some multi-page. The resume counts about thirty tile surfaces, not thirty Nest controllers. Each GET is handwritten SQL, month and year on the query string, no ChatOpenAI. Plus 60% is click-the-tile versus exporting the same Excel pack every period. Sub-210 milliseconds is that JSON hop — I treat it as a p90-style serving figure; I do not have p95 or p99 memorized and I will not upgrade it. CloudFront caches the SPA, not the warehouse.”

Seven points.

  1. 30 = outcome tile/page count. Nine = controller families. Speak both. Do not invent tiles to force 24 = 30.
  2. +60% = recurring KPI overhead, human minutes. Same science family as 40%, different loop (known pack vs one-off custom report). Do not add 40 and 60.
  3. Sub-210ms = Nest deterministic GET. Not HTML from the edge. Not chat-query. Not Tally ingest. Not Redis −35%.
  4. Why it can be fast: no model, SQL already written, month/year params, ECS behind ALB.
  5. Recharts on predefined pages. Chart.js on builder/chat ElementRenderer. Resume names Recharts — I say the split if they open the builder.
  6. last-updated in this checkout can run as an owner aggregate — I name that gap if they open the handler. I do not use it as proof of 210ms or of RLS.
  7. Falsify: LLM on GET /dashboards/sales; calling nine controllers thirty products; measuring CloudFront HTML and calling it SQL; stacking this with 40% as one study.

RLS + 3 tiers — say this if they treat it like a metric

“That line is not a percent. RBAC is JWT role, feature flags, table grants. RLS is per-request transaction, SET ROLE to a non-owner db_role_name, tenant GUCs, USING. If SQL asks for the other org, the statement still succeeds and those rows are invisible. Empty is not a reject. I wrote the middleware and the CREATE POLICY generator. I did not check in a hand-written sales.sql. Table owner bypasses RLS — that is why FastAPI must not execute. Legal JOIN plus HTTP 200 plus wrong tenant is the leak class the validator will not catch.”

Do not hang 40%, 99.9%, or +65% on RLS. Isolation is how the product is allowed to exist. It is not how generation time or uptime were scored.

CI/CD 2× release time — say this

“Before: snowflake deploy, SSH, hope. After: GitHub Actions on qa and main, ECR, ECS, prod waits for my approve then service stability. 2× is release cycle time on that path, not 99.9%, not 40%. I am not the account owner. Docs that say CodeBuild are a lag versus the workflow files I speak.”

Room discipline. If they ask one number, I answer that number’s seven points and I stop. If I feel myself saying crash, Redis, 210ms, and 40% in one paragraph, I reset: “I mixed families. The number you asked is ___ and the path is ___.”

What a Bar Raiser expects when they hear a ConvBI number

If I say a percent, they are not scoring the percent. They are listening for six things. If I cannot fill them, I stop after the mechanism.

  • Mechanism. What changed in the system? Guided builder vs export. Deterministic KPI GET vs LLM. SET ROLE + USING vs app WHERE. Cache-aside vs warehouse hop.
  • Baseline. Versus what? Manual pull / join / chart in Excel. Waiting on a person to write SQL. Manual zip-and-email of a workbook. Manual SSH/docker deploy. I name the old workflow, not a fake A/B cell.
  • Unit. Human minutes on a workflow, or milliseconds on an API hop. I do not mix them. 40% and +65% and +60% are human-time families. Sub-210ms and −35% are hop families. 99.9% is serving-path availability, not latency.
  • Who measured. Internship / product-family number on the resume, or a checkout fact I can point at. I was not the monitoring-stack owner. I do not invent a Grafana board I did not sit on.
  • What would falsify it. If the old workflow was already a builder, 40% is theater. If KPI GET waits on ChatOpenAI, sub-210ms is a lie. If I execute as table owner, “RLS” is a slide. If the cache key is query text alone, −35% can be a leak.
  • I vs we. We for the product and the warehouse. I for Nest RLS middleware, the policy DDL generator, the inherited chatbot execute path, the report-builder / ElementRenderer work I can walk. Not AWS account owner. Not DBA of every GRANT. Not “I invented ConvBI.”
Same-hour rule: Ylogx primaries in the broader loop are Ownership, Frugality, Dive Deep — not six ConvBI trophies. RLS is the strongest technical claim. +65% is the weakest science. 99.9% is the easiest to over-own.
1. 40% faster report generation ylogx · priority

Claim as printed. Architected a full-stack AI Business Intelligence platform (FastAPI, NestJS, PostgreSQL) featuring a custom report builder, reducing report generation time by 40% and sustaining 99.9% uptime under daily production load. I split 99.9% into its own card. This card is only the 40%.

What it actually measures. Workflow time — human minutes from “I need this cut of the books” to a usable report — guided report builder versus the old manual pull / join / chart / export loop. It is not backend p99, not tile JSON latency, and not the client-aggregation crash study. Checkout: report canvas, slicers, saved JSON configs, shared ElementRenderer (Chart.js on the builder / chatbot path; predefined KPI pages also use Recharts).

The old loop was: know which tables, pull, join, chart, export. I worked a guided report builder on the same warehouse the dashboards use — pick fields, join, slice, render — so an operator who is not a SQL person can finish a custom report without that export ritual. The resume says that generation time dropped 40%. That is workflow time, not a Postgres p99 I memorized. I do not pin 40% on the tab-crash fix. That fix was server-side aggregation plus click-to-load so a large slice would not kill the browser. Different story, same product.

Related STAR — not the 40% study

Situation. Dynamic reports could aggregate across chart types. I put that aggregation on the client. A large slice crashed the tab and made the agent path unstable.

Task. Keep heavy aggregation off the client when the slice is large, and make the fix structural.

Action. Server / preload path for the heavy cut. Explicit click to load full data. Multi-chart generation stayed as data, not screenshots. I did not weaken RLS to make the chart easier.

Result. The UI rendered. The agent stayed stable. This is not how 40% or 99.9% were measured.

Follow-ups

What was the baseline, in units a human would feel?

The baseline was an operator or analyst building a one-off report by hand: export from the books or a warehouse pull, join in a spreadsheet, chart, send. Minutes to hours depending on the cut — I do not invent a stopwatch log. The new path is: authenticate, open the builder, place fields, apply slicers, render through ElementRenderer, save the JSON config. 40% is “that loop got shorter,” not “the SELECT got 40% faster.”

Is this API latency? Did you measure p99?

No. I will not upgrade 40% into a latency SLO. Sub-210ms is the serving-path family for deterministic KPI JSON. This number is human workflow. If they want a percentile on the builder execute hop, I say I do not have one memorized and I will not invent it.

Walk the builder. What did you personally touch?

I can walk the canvas: draggable columns, chart drop zone, slicers, save/load report JSON on Nest, execute through queryDB on req.dbTransaction so RLS still applies. Rendering is ElementRenderer — Chart.js for builder and chatbot charts. Predefined dashboards are a different surface (Recharts on those pages). Resume names Recharts; if they open the builder I say Chart.js. I do not claim I was the only person who ever touched the canvas. I claim I can defend the path and the shared renderer.

Why not let the chatbot be the report builder?

Because a known cut should not wait on ChatOpenAI. The builder is a structured config. The chatbot proposes SQL for a question you have not designed a tile for. Same renderer can draw both. If I collapse them, I pay LLM latency and dialect risk on every “show me last month by region.” That would also poison any latency number I later claim on tiles.

The crash STAR — is that your 40%?

No. I sent aggregation to the client. That was my defect. Cost was a crashed tab. Fix was server path plus click-to-load. I will not pin the resume’s 40% on that incident. If they want a mistake with a cost, that crash is speakable. If they want the 40%, I stay on guided builder versus manual export.

Who measured 40%, and what would falsify it?

It is a product-family number on the intern resume. I do not have a protocol, a population, or a dated time-and-motion sheet in front of me. Falsifiers: the old path was already a builder; we only measured a happy-path demo; we mixed “time to first chart” with “time to a signed-off pack.” If they want n, I say it is missing — I do not invent it.

Deeper probes

Does the builder bypass RLS because you already picked the table in the UI?

No. Picking a table is not isolation. Execute still runs on the request transaction after SET ROLE. hasTableAccess can 403 before Postgres. A legal SELECT that asks for the other org still comes back empty if USING hides those rows. I do not weaken RLS to fix a chart crash.

How large was the slice that crashed the tab?

Not locked. Large enough to crash the tab. I do not invent row counts, the browser, or whether a named client saw it live.

I vs we on the 40%?

We shipped a product with a custom report builder. I can defend the builder path, the shared renderer, and the crash class I caused and closed. I do not say “I personally timed forty analysts.” I do not hang 40% on “because I listened in a meeting.”

Honesty floor: 40% is guided-builder workflow time versus manual pull/join/chart — not p99, and not the crash study.

Missing — do not fill with fiction. Stopwatch protocol, population, dates, p99 of execute-query, row count of the crashing slice, a named client.

LP lane. Allowed to support Invent and Simplify (shared ElementRenderer, builder vs chatbot vs tiles) or a Customer sentence about the operator who cannot write SQL — if this hour did not already spend Customer on GiftedBooks. Must not steal Ownership-of-RLS, Dive Deep-on-Redis, or 99.9% in the same opening. Must not be the payload of Are Right, A Lot (that is Argus 73→89 if they want judgment).

When they hear 40% they expect: mechanism = builder vs export; baseline = manual pack; unit = human minutes; who measured = resume product family, not me with a clipboard I will invent; falsify = already-had-a-builder or measured the wrong hop; I vs we = we the product, I the path I can walk.

2. 99.9% uptime easy to over-own

Claim as printed. Sustaining 99.9% uptime under daily production load — same bullet as the report builder / platform sentence.

What it actually measures. Serving-path reliability of the deterministic product: KPI dashboard GETs and static CloudFront assets staying up under daily use. It is not an LLM availability SLO (chat waits on FastAPI + the model). It is not a leak-ticket SLA. It is not “I owned Datadog.” Serving shape I can defend: CloudFront (SPA) → ALB → ECS Fargate tasks, Nest health endpoints. I was an intern on that path. I was not the monitoring-stack owner. I have no incident log memorized.

99.9% on the resume is serving-path reliability for the deterministic product — dashboards and the SPA — under daily production load. KPI GET is handwritten SQL, month and year on the query string, no ChatOpenAI on that hop. We served it CloudFront, ALB, ECS. I helped ship that path. I did not own the AWS account or a pager rotation I can recite. I will not invent an observation window or a ticket count. If they want a named outage, I do not have one memorized.

Follow-ups

What is in the 99.9% and what is out?

In: can the operator load the SPA and get tile JSON from Nest. Out: model timeouts on SQL-RAG, a single bad generated SELECT, a Tally zip that failed to ingest. If I include the LLM in the same SLO I am mixing a non-deterministic hop into a number that only makes sense for deterministic serving.

How did you measure it? What window?

I do not have a probe host, a window, or a status-page export I can defend. I will not invent “thirty days” or “four nines in staging.” The resume states 99.9% under daily production load. If they want the instrument, I say it is missing.

Were you on-call? Did you own CloudWatch / Datadog?

No Datadog in this intern tree. Nest has Terminus /health and /health/simple. I am not going to perform “I owned observability.” I can describe health checks and the deploy path. I cannot describe a pager I did not sit.

What would take you off 99.9%?

Putting the model on the KPI GET. A single-task deploy with no room to bounce. Serving the SPA from a laptop. Treating a 500 on chat-query as if the dashboard product were down. I do not invent a real incident to sound humble.

Is the client-aggregation crash part of 99.9%?

No. A crashed tab is a client defect. 99.9% is serving path. I will not pin uptime on that crash and I will not pin 40% on it either.

Docs mention CodeBuild. Is that your 99.9% path?

This checkout ships GitHub Actions → ECR → ECS on qa and main. Latex that draws CodeBuild is a docs lag. I speak the workflow files. I do not describe CodeBuild as the intern 99.9% path unless they have that figure open — and then I show the conflict.

Deeper probes

99.9% of what denominator?

I cannot defend a denominator I do not have. Requests? Minutes? Synthetic checks? I say that rather than pick one to sound precise.

Did you promise 99.9% to a customer?

I do not invent an SLA conversation. The number is on the resume as a production-load claim. I treat it as serving reliability, not a contract I can quote.

I vs we?

We ran production. I worked deploy and the Nest service. I was not the account owner and not the person I will invent who watched a 30-day graph.

Honesty floor: 99.9% is deterministic serving-path reliability — I am not the monitoring owner, and I have no window or incident log to recite.

Missing — do not fill with fiction. Observation window, probe host, error budget, incident list, Datadog, on-call rotation, SLA text.

LP lane. Weak LP payload. If forced, a humble Ownership sentence about keeping tiles deterministic so the serving path is even capable of an availability claim. Must not steal RLS, Redis, or “I owned production reliability.” Must not be Think Big. Must not be used as proof of Highest Standards — Argus 89% before cameras is that card.

When they hear 99.9% they expect: mechanism = CloudFront/ALB/ECS + no LLM on KPI GET; baseline = “the product stayed up for daily use,” not a fabricated pre-intern outage rate; unit = availability, not ms; who measured = not a stack I will invent; falsify = LLM on the tile hop or no health/deploy story; I vs we = intern on the path, not account owner.

3. +65% data-analysis productivity (SQL-RAG chatbot) weakest Ylogx science

Claim as printed. Built a LangChain SQL-RAG chatbot that improved analyst data-retrieval productivity by 65%; implemented Redis caching to reduce query latency by 35%. Redis is the next card. This card is only +65%.

What it actually measures. Workflow consolidation: an analyst who cannot write SQL asks in English, FastAPI (LangChain, allow-listed tables) proposes a SELECT, Nest executeChatQuery runs that SQL on req.dbTransaction after SET ROLE, ElementRenderer draws the structured chart payload. Versus: find someone who can write SQL, wait, paste a CSV. This is the weakest Ylogx number scientifically. It is not a controlled study. I do not have n, a control group, or an instrumented diary study.

The customer was an analyst who needed their own numbers and could not write SQL. I worked the path: natural language in, FastAPI proposes a SELECT from an allow-listed schema, Nest executes it as the caller — same transaction, SET ROLE, RLS — and we render a structured chart, not a blob of text. The resume says that improved data-retrieval productivity by 65%. I treat that as a project-level observed or estimated workflow win, not as an experiment. I am not claiming LangGraph. I am not claiming the model was allowed to SET ROLE. I will not invent a control group to make 65% look like a paper.

Follow-ups

What does +65% actually mean — time, tickets, queries per day?

I do not have the instrument locked. The honest meaning is: fewer human hops between a question and a chart on their own tables. I will not pick “minutes” or “tickets” in the room to sound sharper than the resume.

Walk executeChatQuery without theater.

Chat UI persists the user line on /chat (that CRUD uses executeWithoutRLS / RESET ROLE — metadata, not facts). Then POST /queryDB/chat-query. Nest calls the FastAPI sidecar. Extractor returns SQL plus chart metadata. Nest runs a SELECT-only execute on req.dbTransaction. FastAPI never executes tenant SQL as owner and never sees the JWT. Allow-list is the sidecar’s public fact tables — on the order of ten, not “the whole information_schema.”

How do you know the number is true if the SQL is generated?

I do not. The validator and the allow-list reduce dialect mistakes and random tables. They do not make the metric true and they do not make the number correct. Isolation is SET ROLE + USING, not the prompt. If they want trust, that is RLS. If they want +65%, that is workflow access, not faithfulness.

Why is this the weakest Ylogx number?

Because productivity percents want a baseline, a population, and a definition of “a retrieval.” I have the mechanism. I do not have the study. 40% at least points at a builder-versus-export loop I can describe. RLS is a mechanism I can pressure-test. +65% is the one I will not dress up.

Did Redis cause the 65%?

No. Redis −35% is hop latency on repeat suitable bot queries. +65% is “I did not wait for a SQL person.” I do not stack them in one breath unless they ask what happened on repeats.

What would falsify +65%?

If analysts still waited on a person for every real question. If we counted demo queries. If we measured “messages sent” instead of “got the number they needed.” If the path executed as owner and we called that productivity — that would be a different, worse lie.

Deeper probes

You inherited the chatbot. Is +65% yours?

+65% is the product-family number for the SQL-RAG surface. Inheritance is an Ownership story (I could operate it, explain it, change it). I do not hang +65% on “because I inherited it.” I do not invent the calendar day a teammate left.

LangChain or LangGraph?

Ylogx is LangChain SQL-RAG. IQVIA is LangGraph. I say that split once. I do not move Deep Research onto this intern.

Empty chat result — did Postgres reject the analyst?

Empty can mean: no rows visible under RLS, or the question mapped to a real empty cut, or the model wrote a WHERE that survived USING and still matched nothing. It does not mean “Postgres rejected.” Permission denied is GRANT. 403 is hasTableAccess. I keep those three separate even on the bot path.

Honesty floor: +65% is workflow consolidation for a non-SQL analyst — not a controlled study, and I will not invent n.

Missing — do not fill with fiction. Population, control, instrument, diary study, faithfulness eval, LangSmith on Ylogx, ticket counts.

LP lane. Allowed: Customer Obsession if GiftedBooks did not already take Customer this hour — customer = non-SQL analyst, not “I used LangChain.” Backup Ownership if the question is inheritance. Must not steal GiftedBooks 3–10 min, must not steal RLS as the opening, must not steal Dive Deep-Redis unless they ask repeats. Must not be sold as science.

When they hear +65% they expect: mechanism = NL → propose → Nest execute under RLS → render; baseline = wait for a SQL person; unit = human productivity, not ms; who measured = resume, methodology weak; falsify = still waiting, or counting demos; I vs we = I the execute path, we the product number.

4. RLS + RBAC 3 organizational tiers strongest technical claim

Claim as printed. Designed multi-tier RBAC and Row-Level Security (RLS) across 3 organizational roles, enforcing tenant data isolation in a shared PostgreSQL instance.

What it actually measures. A mechanism, not a percent. Three JWT roles on the warehouse path: SUPER_ADMIN / ADMIN / USER (GUEST exists in the enum; facts are not a guest toy). RBAC = JWT role, feature flags, hasTableAccess, table grants via policy modules. RLS = per-request Sequelize transaction, SET ROLE to a non-owner db_role_name, set_config('app.*', …, true) from the verified JWT, CREATE POLICY … USING tenant = current_setting('app.organizationId') when that column exists, fail-closed rls_no_access. A malicious WHERE org_B still succeeds and returns zero rows if USING hid them. Personal: Nest middleware + policy DDL generator. Not a hand-written DBA migration in this repo. Chat metadata CRUD: executeWithoutRLS + RESET ROLE. SUPER_ADMIN: RESET ROLE + app.is_SUPER_ADMIN. Policy names: policy_${scope}_${slug}_${Date.now()}.

RBAC decides whether you may call the operation and which tables you may touch. RLS decides which rows exist for the session. I bind a non-owner Postgres role and tenant GUCs from the JWT on a per-request transaction, and I execute generated SQL there. Policies USING the session org, not the query text. If the SQL asks for ORG_B, Postgres still runs; ORG_B rows are invisible. Empty is not a reject. Permission denied is GRANT. 403 is Nest. I wrote the middleware and the CREATE POLICY generator. I did not check in a hand-written sales.sql, and I will not guess a production policy name.

Full pressure-test script is Part E. Use this card for the metric; use Part E when they refuse “intended behavior.”

Follow-ups

What are the three tiers, exactly?

Resume “3 organizational roles” maps to SUPER_ADMIN, ADMIN, USER. SUPER_ADMIN RESET ROLE and is_SUPER_ADMIN=true — intended bypass. ADMIN SET ROLE first SYSTEM db_role_name, org GUC set, is_admin=true; no db role → rls_no_access (comment in code: previous RESET ROLE leaked). USER SET ROLE first mapped db role, policy modules → allowed tables; else fail closed. GUEST is a fourth enum value; I do not sell guests a warehouse reader.

Empty JSON — did Postgres reject the query?

No. USING is a security-barrier filter. The statement succeeds. Rows that fail USING are invisible. The caller’s WHERE then runs on what is already visible. GRANT failure is an error. Nest hasTableAccess is 403 before the engine. rls_no_access is documented as no table grants — that path is permission denied, not an empty filter. Generator USING (false) on a GRANTed table you should not see is the empty-success path for a module you do not have.

What did you implement versus integrate?

I implemented Nest integration and the DDL generator: rls.middleware.ts, policyManagement.service.ts (CREATE ROLE / GRANT SELECT / CREATE POLICY / ENABLE RLS), roleManagement.service.ts (db role + GRANT policy role TO db role), execute on req.dbTransaction. I wired fail-closed to the name rls_no_access. I did not find CREATE ROLE rls_no_access in this tree. I did not maintain a checked-in warehouse policy file. I am not the DBA who applied every GRANT by hand.

Is every table under RLS?

No. Chat metadata CRUD opens a new transaction and RESET ROLE inside executeWithoutRLS so persistence is not blocked when the fact role has no chat grants. Warehouse facts must not ride that path. Feature and role admin also RESET ROLE for DDL. If I say “everything is RLS,” I correct myself in the room.

FORCE RLS? Tenant column on sales?

This generator ENABLE ROW LEVEL SECURITY. It does not emit FORCE. Owner connections can bypass. The org GUC is attached when information_schema has organizationId (camelCase uuid). This checkout’s warehouse prompt schema for sales lists client_id. I will not testify that production sales has organizationId. I will say: the mechanism keys off that column if present; I am not reciting a live \d sales.

What would falsify “three-tier isolation”?

Executing facts as table owner. RESET ROLE then SELECT sales on the tenant path. Cache keyed only by SQL text. FastAPI reachable and executing. USING (true) on a fact table. App-only WHERE that a JOIN can walk around. Those are leak classes. I do not invent a customer-visible breach to prove I care.

Deeper probes

There is also a string-inject WHERE organizationId in execute. Is that RLS?

No. That is an application belt if the column exists. If they already stipulated “the backend accepted the SQL and sent it,” I speak only SET ROLE + USING. If they open the file, I name the inject as a belt, not as proof of RLS.

Policy name in production?

Generated policy_${scope}_${sanitizedName}_${Date.now()}, sliced to 63 chars. I do not remember a production name. I will not invent one.

I vs we?

We for the shared warehouse and the three tiers as a product. I for the request path and the generator in this Nest tree. Not “I am the DBA.” Not “I invented Postgres RLS.”

Honesty floor: I own middleware + generator + execute-on-txn; empty is a filter, GRANT is an error, 403 is Nest — I will not guess sales.organizationId when the prompt schema lists client_id.

Missing — do not fill with fiction. Penetration-test count, leak ticket, FORCE in prod, CREATE ROLE rls_no_access in this repo, a remembered prod policy name, live \d sales.

LP lane. Allowed: Ownership (intern still owned isolation on bot + reporting), Dive Deep (fail-closed vs RESET leak class), Highest Standards (LLM is not a control). Must not steal Horizon ownership, 99.9%, +65%, or Redis in the same opening. Must not be Customer Obsession’s first sentence if GiftedBooks is free. One RLS hour is enough — do not also open with Y1 inheritance as a second Ownership trophy.

When they hear “3 tiers” they expect: mechanism = JWT RBAC then SET ROLE + GUC + USING; baseline = app-only WHERE / owner session; unit = isolation correctness, not a percent; who measured = no leak-count theater; falsify = owner execute or RESET then facts; I vs we = I the Nest path, we the warehouse.

5. 35% lower bot-database latency via Redis resume Redis · checkout Map

Claim as printed. Implemented Redis caching to reduce query latency by 35% (same bullet as +65%).

What it actually measures. Resume: cache-aside hop time on the bot→warehouse path — not dashboard tiles, not report-builder first paint. Key includes role + org, not query text alone, so a cached payload cannot become another tier’s answer. Miss still executes as the caller. This Nest snapshot: no redis / ioredis in the service. What is here is QueryDBService.fieldsCache — in-process Map, key fields:${tableName}, 5 minutes, SHA-1 etag of the fields JSON. That is dataset-fields metadata, not the resume Redis hop. I say both sentences if they open the repo.

Repeat suitable bot questions were paying a warehouse hop they did not need. The resume cache-aside is Redis on that bot-database path, key by role and org, not by SQL text alone, so a USER in ORG_A cannot be served ORG_B’s answer. On a miss, execution is still the caller with RLS. That hop family is the −35%. This Nest checkout does not have a Redis client. It has an in-process Map for dataset fields, five minutes, keyed by table name. I will not point at a Redis line in this file. I will not invent a hit-ratio dashboard.

Follow-ups

Why key role + org, not the query string?

Query text is attacker-controlled on the bot path. Two callers can ask the same English or the same SELECT. If the key is the text, the cache is a cross-tier read. Role + org (and a payload that was produced under that session) keeps the cache from becoming a bypass. FieldsCache in this tree is weaker — table name only — and it is column metadata, not fact rows. I do not sell fieldsCache as the resume Redis design.

Does a hit skip RLS?

A correct cache-aside hit returns a payload that was already produced as that caller. It must not return another caller’s rows. A miss goes through SET ROLE again. I do not say “cache skips RLS.” I say “cache must not become a second executor.”

Is −35% dashboard latency?

No. Tiles are deterministic SQL. Sub-210ms is that family. −35% is bot-database. I keep the lanes.

They opened queryDB.service.ts and there is no Redis.

Correct. Resume Redis versus this snapshot Map. Earn Trust is saying that in one breath, not hoping they do not scroll.

What is the Redis TTL?

I do not have a resume TTL. I will not invent one. The five-minute number I can point at is fieldsTtlMs on fieldsCache in this tree.

What would falsify −35%?

Keying only by query text (leak, and a polluted latency story). Measuring first-byte of the LLM. Measuring dashboards. Counting cold starts as “Redis.” If there was never a Redis hop in the intern product — then the resume line and this snapshot are a split I already name.

Deeper probes

Is fieldsCache a security problem?

It caches field names/types for a table, five minutes, process-local. It is not a row cache. Table-name key means I do not treat it as tenant-isolated fact data. I still would not put sales rows in that Map.

10× this hop?

A real Redis with role and org in the key, invalidation on policy change, and I still execute misses as the caller. I do not invent a hit ratio I will hit in year two.

I vs we?

Resume cache-aside is a product claim I can explain. This Map is in a file I can open. I do not claim I am the company Redis owner.

Honesty floor: resume −35% is Redis cache-aside on bot-DB with role+org in the key; this Nest snapshot is a 5-minute in-process fields Map — I say both.

Missing — do not fill with fiction. Redis TTL as a resume number, hit ratio, probe host, p95 of the cache hop, a redis package in this Nest tree.

LP lane. Allowed: Dive Deep or Frugality (do not pay the warehouse twice; do not cache the wrong tenant). Must not steal RLS as the same Dive Deep opening. Must not steal +65%. Must not be Invent and Simplify’s first sentence (that is renderer / Deep Research / GStreamer).

When they hear −35% they expect: mechanism = cache-aside, key role+org; baseline = every bot question hits the warehouse; unit = hop ms, not human minutes; who measured = resume, not a dashboard I invent; falsify = text-only key or measuring the LLM; I vs we = I can explain both snapshots, we the intern product.

6. 30 real-time KPI dashboards, +60% operational efficiency, sub-210ms speak as one family

Claim as printed. Engineered 30 real-time KPI dashboards (React.js, Recharts) for three business units, reducing manual reporting overhead by 60% with sub-210ms P95 response times. I do not memorize a p95/p99 ladder. I treat sub-210ms as a p90-style resume serving figure. If a PDF variant prints P95, I still will not defend a percentile I cannot show a probe for.

What it actually measures — three units, do not mix.

  • 30. Outcome tile/page count, not 30 Nest controllers. This tree: nine dashboard families — sales, receivables, payables, stock, collections, P&L, balance sheet, cashflow, overview. Architecture page counts in the tex: overview 1, sales 6, receivables 5, payables 3, stock 2, collections 3, P&L 1, BS 1, cashflow 2 (those pages sum to 24). Resume 30 is the spoken outcome. I will not invent six tiles to close 24 versus 30.
  • +60%. Human workflow: click-to-answer on a known KPI versus Excel export / email pack. Same science family as 40% — weaker if they want a protocol.
  • sub-210ms. API JSON for those deterministic GETs (month/year query string, handwritten SQL in dashboards.service.ts). CloudFront is the static SPA. I do not claim CloudFront cached the warehouse.
Known KPIs should not wait on a model. We shipped nine dashboard families — sales, receivables, payables, stock, collections, P&L, balance sheet, cashflow, overview — multi-page tiles that the resume counts as thirty surfaces, not thirty controllers. Each GET is deterministic SQL. The resume says that cut manual reporting overhead 60% — click the tile versus export a workbook — and that those responses sat in a sub-210 millisecond serving figure. I do not have p95 or p99 memorized. I do not put ChatOpenAI on that hop. If they open the controller I name nine types and I will not invent a tile census to force the tex pages to thirty.

Follow-ups

Thirty dashboards or nine?

Resume 30 tiles/pages. Registry: nine types, some multi-page. I speak both. I do not pretend there are thirty @Get handlers.

Sub-210ms — p95? p99? Which hop?

Printed family is sub-210ms on the deterministic KPI JSON path. I do not upgrade it. I do not invent a probe host. CloudFront is static. The number is not “HTML from the edge.” It is not chat-query. It is not Tally ingest.

Is +60% the same study as 40%?

Same human-time family, different loop. 40% is custom report generation. +60% is recurring KPI overhead — stop exporting the same pack. I do not stack them as independent scientific results in one sentence.

Three business units — name them?

I do not invent three legal-entity names. The product surfaces cover sales, working-capital (receivables/payables/collections/stock), and financial statements (P&L, BS, cashflow) plus overview. If they want customer names, I do not have them in the lock.

last-updated — is that on the RLS transaction?

Proper design: yes, MAX(last_updated_time) is still a fact read. This checkout has a gap: last-updated can run as an owner aggregate. I name the gap if they open that handler. I do not use last-updated as proof of sub-210ms isolation.

What would falsify this family?

LLM on GET /dashboards/sales. Calling nine controllers “thirty products.” Measuring CloudFront HTML and calling it 210ms SQL. Claiming 60% with no old Excel loop. Inventing tiles to make 24 equal 30.

Deeper probes

Recharts or Chart.js?

Resume: React + Recharts. Predefined KPI pages: Recharts. Builder / chatbot ElementRenderer: Chart.js. Both are in the frontend package. I do not pick a fake single library.

Would putting Redis on tiles help 210ms?

Tiles are already deterministic and cheap compared to the bot+LLM path. A row cache without role+org would be a leak. I do not move −35% onto dashboards to make the hour tidier.

I vs we?

We the KPI product. I can walk a family: query params, SQL, no model, RLS transaction on the tile execute. I did not personally draw thirty unique visual designs I will recite.

Honesty floor: nine families / multi-page tiles ≈ resume 30; +60% is click-versus-Excel; sub-210ms is a serving figure I will not upgrade to a memorized p95.

Missing — do not fill with fiction. Tile census that closes 24 vs 30, p95/p99, probe host, three named business units, a controlled 60% study.

LP lane. Allowed: Invent and Simplify (deterministic tiles + shared renderer) or Ownership of the intern serving path — pick one. Must not dump with 40% and 99.9% as three trophies. Must not steal RLS. Must not steal GiftedBooks sub-300ms (different product, different 99.5%).

When they hear 30 / 60 / 210 they expect: mechanism = handwritten SQL GETs, nine families; baseline = Excel pack; units = count of surfaces, human minutes, hop ms — stated separately; who measured = resume; falsify = LLM on GET or 30 controllers; I vs we = I walk the registry, we the overhead number.

7. CI/CD 2× release time resume variants

Claim as printed (resume variants). Led AWS deployment using ECS, CloudFront, Docker, and ALB; built GitHub Actions CI/CD pipelines, eliminating manual deployment steps and reducing release time by 2x.

What it actually measures. Human release time: git push → Actions builds the image, pushes ECR, renders the task definition, deploys ECS — versus a manual build/ssh/docker/console path. Checkout: convbi-prod.yml on main, convbi-qa.yml on qa. Prod workflow includes a manual approval step in the file; that is still not “I SSHed to production.” I was not the AWS account owner. Latex that draws CodeBuild is not this tree’s runnable path.

Before the pipeline, a release was a person building an image and pushing it through console steps I am not going to romanticize. I worked GitHub Actions that build, push ECR, and deploy the ECS task so a merge is the release motion. The resume says that eliminated those manual steps and cut release time in half. I am not the account owner. I do not invent a lead-time dashboard. If they open the repo, they will see qa and main workflows, not the CodeBuild figure in an older doc.

Follow-ups

What does 2× mean — minutes, frequency, failures?

Human time to get a tested commit onto the environment, versus manual deploy. I do not have a before/after stopwatch. I will not invent “we went from two hours to one.”

Did you own AWS?

No. I worked the intern deploy path: Dockerfile, Actions, task definition as a file in the repo (I will not paste secrets from it). Account, IAM, billing — not mine to claim.

Is 2× the same as 99.9%?

No. Faster release is not uptime. A bad pipeline can ship outages faster. I keep them on different cards.

CodeBuild?

Docs lag. Runnable path is GitHub Actions → ECR → ECS. I show the conflict if they have the latex open.

What would falsify 2×?

If “manual steps” were already one button. If we measured only image-build CPU time. If I claim I led AWS as an account owner.

I vs we / “Led AWS deployment”?

Resume verb is strong. Spoken: I worked the intern CI/CD and container path on a team that already had AWS. I do not perform “I led the cloud org.”

Deeper probes

Secrets in the task definition?

Would-do is Secrets Manager. I do not recast current env inlining into a hero story and I do not paste values.

Rollback?

I can talk about redeploying a previous task definition. I do not invent a blue/green I cannot point at.

Honesty floor: 2× is eliminating manual deploy via Actions → ECR → ECS — I am not the AWS account owner and I do not have a lead-time study.

Missing — do not fill with fiction. Before/after minutes, change-fail rate, CodeBuild as the live path, account ownership, a war-room.

LP lane. Allowed: Ownership of the intern release path, or Frugality of human deploy time. Must not steal 99.9%, RLS, or Think Big. Must not be Hire and Develop.

When they hear 2× they expect: mechanism = Actions/ECR/ECS vs console; baseline = manual deploy; unit = human release time; who measured = resume variant; falsify = already automated, or I claim the account; I vs we = intern pipeline, not cloud owner.

8. IQVIA — 200+ websites Deep Research no % on resume

Claim as printed. LangGraph Deep Research ranked / gathered across 200+ websites. There is no IQVIA percent on the resume. Do not import Ylogx percents.

What it actually measures. Size of the discovery pool a run can fan out to — not “we scraped 200 sites every time,” not accuracy. Filter happens before scrape. Speakable strong-run example from notes: 857 URLs → 120 filtered → pages collected after that. 200+ is the resume class. 857→120 is an example, not a guarantee.

Deep Research is a state machine, not a chatty agent. We fan out across search engines, then URL intelligence picks what is worth paying to scrape — a pool can be hundreds; a strong run in my notes went 857 URLs down to 120 before scrape. The resume class is ranking information across 200+ websites. That is coverage of the research graph, not a quality percent. I do not have an IQVIA accuracy number and I will not invent one.

Follow-ups

Did you scrape 200+ sites every run?

No. 200+ is the class of corpus we could rank across. The scrape set is the filtered set. Example: 857→120. Weak runs still collected pages and then failed at synthesis — that is a different card.

Why filter before scrape?

Scrape is the expensive hop — fetch plus extract plus later tokens. Breadth without a think hop is a bill. I do not invent the dollar amount.

Is 857→120 on the resume?

No. Resume is 200+. 857→120 is a concrete run I can talk about if they ask how a pool becomes a scrape set. I do not promote it to a printed KPI.

Firecrawl / Bing / DDGS — is that the 200+?

Those are engines in the fan-out. 200+ is the ranked-website class, not “three vendors.” valAgent on GitHub is not this claim.

What would falsify 200+?

If we only ever hit one SERP page and called it 200. If I quote a success percent. If I move this onto Ylogx LangChain.

Deeper probes

0% confidence but pages exist — is that empty retrieval?

No. That pattern matched synthesis JSON parse / truncated save after scrape already succeeded. I do not blame the filter hop first.

I vs we?

I can operate and explain the graph. IQVIA is a current intern on a team. I do not claim I founded Deep Research as a hosted product.

Honesty floor: 200+ is a discovery-pool class; 857→120 is an example filter-before-scrape — no IQVIA percent.

Missing — do not fill with fiction. Accuracy %, latency SLO, hosted multi-region product, a guarantee that every run hits 200 scrapes.

LP lane. Allowed: Learn and Be Curious or Think Big (breadth plus a bound). Must not steal Ylogx +65%, must not steal BRD hybrid-RAG as the same opening, must not invent a percent to look like ConvBI.

9. IQVIA — 180+/200+ page BRD/PDF no % on resume

Claim as printed. Processing 200+ page BRD/PDF documents (spoken variants also say 180+). Still no percent.

What it actually measures. The pipeline can ingest a long specification — not “we send 200 pages to one prompt.” Chunking I can defend in code: 1500 tokens, 200 overlap, cl100k_base. Cost and context scale with chunks (LLM per chunk), not with the cover-page count. Hybrid retrieve + graph walk later; I do not re-embed the BRD on every question.

A 200-page BRD does not fit in one honest prompt. We ingest once: chunk at 1500 tokens with 200 overlap, embed, index, extract requirements, persist relationships. Questions hit hybrid retrieval plus a short graph walk, not “stuff the PDF again.” Page count is the document class on the resume. What I pay for is tokens per chunk and per question, not 200 times a page screenshot. I do not have an IQVIA quality percent.

Follow-ups

Why isn’t cost proportional to page count?

Pages are a human unit. The model sees tokens. A dense table page is not the same as a sparse cover. We chunk by tokens. Empty pages get skipped in extract. I will not invent a dollars-per-page figure.

Why 1500 / 200?

They are the configured budget on cl100k_base. I can defend that they exist. I do not invent an ablation that proved 1500 is optimal unless I ran one.

Is this the same graph as Deep Research?

No. Deep Research browses the web. BRD is document intelligence on your indexed spec plus Neo4j relationships. LangGraph is the workflow in both; Neo4j is the knowledge graph on the BRD path. I do not confuse them.

Redis/Celery on this project?

They appear in requirements and are not the wired job runner I will claim. Jobs I can defend are in-memory maps. I say that. I do not move Ylogx Redis −35% here.

What would falsify 200+ page processing?

If we only ever demoed a 12-page PDF. If I claim one-shot stuffing. If I quote recall I do not have — there is no labeled IR set on this project I will invent.

Deeper probes

How many chunks reach the writer?

A small evidence set after retrieve/rerank/walk — not the whole BRD. I do not invent a fixed k as a resume number. I will not say “always 8” to sound like a paper.

I vs we?

I can walk ingest versus test-case graphs as separate graphs. Team intern. Not a multi-tenant BRD SaaS I invented for the hour.

Honesty floor: 200+ pages is the document class; cost is LLM-per-chunk, and 1500/200 is configured math — not an ablation I will invent.

Missing — do not fill with fiction. Precision/recall, dollars, a hosted SLA, an ablation for 1500, IQVIA %.

LP lane. Allowed: Learn and Be Curious or Dive Deep on hybrid + graph. Must not steal Deep Research 200+ websites as the same sentence, must not steal GiftedBooks sub-300ms, must not steal ConvBI RLS.

10. Horizon — 17th globally flag 17 vs ~18

Claim as printed. European Rover Challenge 2024: 17th place globally among 80+ international teams as core software team member.

What it actually measures. Team placement at ERC 2024. Public Horizon materials sometimes say about 18th globally and #1 India. I flag the discrepancy. I do not fight the interviewer about a place. I was a volunteer core software member — video + ZED environment scanning — not team lead, not “I placed 17th.”

We took the rover to ERC 2024. The resume says 17th of 80+ as a core software member. Some public Horizon write-ups say about 18th and first in India. I flag that. I do not argue a rank. The placement is a team result. My work was the video pipeline and ZED-based environment scanning, not the whole rover and not a planner I did not write.

Follow-ups

17 or 18?

Resume 17th/80+. Public materials sometimes ~18th. I flag it. I do not pick a fight and I do not invent a third number.

Were you the software lead?

Core software member. We the rover. I the video+ZED slice. I do not absorb navigation ownership.

Is 17th an LP result?

It is a competition place. It is not a mechanism. If they want Invent and Simplify, that is GStreamer versus raw frames. If they want Ownership, that is the slice I actually built — not the rank.

80+ teams — did you count?

That is the resume’s field size. I do not invent a start-list spreadsheet.

What would falsify this line?

Saying I skippered the team. Saying I wrote the planner. Pretending public ~18th does not exist. Moving 17th onto Ylogx.

Deeper probes

#1 India — do you claim it?

It appears in some public Horizon materials. I can mention it as theirs. I do not need it as my punchline.

I vs we?

We placed. I contributed perception-side video and ZED scanning. That is the whole honesty move.

Honesty floor: resume 17th/80+ as a member; public ~18th exists — I flag, I do not absorb the team.

Missing — do not fill with fiction. Official PDF in my pocket, a judge sheet, a story that I drove the ranking.

LP lane. Allowed as chronology / team context only. Must not steal Ownership (use GStreamer or Ylogx RLS), must not steal +40% obstacle, must not be Think Big’s payload.

11. 60 FPS GStreamer horizon

Claim as printed. Engineered a real-time GStreamer video streaming pipeline (ROS2) delivering 60 FPS with low-latency camera feed for semi-autonomous rover operation.

What it actually measures. Camera-feed pipeline rate the operators could use for POV / multi-feed — GStreamer over ROS2, not “the planner ran at 60 Hz,” not ZED points/sec. Low-latency is qualitative on the resume; I do not invent a millisecond budget.

The operators needed the rover’s cameras, not a folder of late frames. I worked a GStreamer pipeline on ROS2 so we could keep a live multi-feed POV. The resume says 60 FPS. That is the video path. It is not the costmap rate and it is not 2 million points per second. I do not invent an end-to-end latency number I did not lock.

Follow-ups

60 FPS of what — capture, encode, display?

The spoken claim is the streaming pipeline delivering a 60 FPS camera feed. I will not invent a per-hop breakdown I cannot point at. If they want capture versus display, I say that split is not locked.

Why GStreamer, not raw OpenCV imshow over SSH?

We needed a real pipeline: multiple feeds, a controller who is not on the rover, latency we could live with. Raw frames across the link was the thing we were simplifying away. That is Invent and Simplify — pipeline versus dump.

Jetson or laptop?

Rover side: NVIDIA Jetson Orin class compute on the platform we ran. I also used a laptop-class GPU (RTX 3050 Ti class) in the ZED/dev story. I do not merge “60 FPS video” into “2M points on the 3050.”

Did 60 FPS cause the 40% obstacle number?

No. Do not drag +40% into this card. 60 FPS is the feed. +40% is a weak comparison I will not lean on.

What would falsify 60 FPS?

If we only ever previewed a file at 60 FPS on disk. If I claim the Nav2 loop ran at 60. If I invent a p95 frame-time.

Deeper probes

Codec / bitrate?

Not locked as a resume number. I do not invent H.264 levels to sound like a streaming SDE.

I vs we?

I the video pipeline. We the rover integration. Not the planner.

Honesty floor: 60 FPS is the GStreamer camera feed — not planner Hz, not ZED points/sec, no invented latency budget.

Missing — do not fill with fiction. Per-hop ms, bitrate, a frame-time percentile, 60 Hz control loop.

LP lane. Allowed: Invent and Simplify (pipeline vs raw frames). Must not steal 17th, +40%, −55%, or Ylogx tiles.

12. 40% obstacle detection weakest Horizon number

Claim as printed. Improved obstacle detection accuracy by 40% through custom perception algorithms integrated into the ROS2 navigation stack.

What it actually measures. I will not invent a definition. In our own notes the comparison was this video-feed / GStreamer-based perception path versus other video-feed tools we had used — not a labeled detection benchmark I can defend like Argus mAP. That is why this is the weakest Horizon number. I do not invent IoU, a frame count, or a control group to rescue it.

The resume says obstacle detection accuracy improved 40%. I treat that as the weakest Horizon line. The comparison in our notes was against other video-feed tooling, not a labeled mAP study I can open. I worked the feed and ZED-based environment scanning. I did not own the predictive planner. If they push the percent, I say the definition is weak and I will not dress it up.

Follow-ups

Accuracy of what — precision, recall, IoU?

Not locked. I will not pick one in the room. Argus is where I have mAP. This is not Argus.

Custom perception algorithms — yours?

I owned video + ZED scanning integrated into the stack we ran. I did not implement the predictive / planner algorithms. I will not absorb “custom perception” into a solo paper.

Is this the same 40% as Ylogx reports?

No. Different year, different unit, different product. I never move them.

Why keep it on the resume if it is weak?

It is printed. Earn Trust is how I handle a printed weak number: mechanism I own, definition I will not invent, stop. Deleting it in the room looks like hiding. Boasting it looks worse.

What would make you drop it from speech?

If they are already on Argus mAP. If they ask for a benchmark protocol. If the hour is Ylogx. I do not lead with this percent.

Deeper probes

Did you learn the number was weak?

Yes. That is the point of rehearsing it. I can say I learned not to treat a tooling comparison as a detection paper.

I vs we?

We the stack. I will not steal the planner to make 40% look like mine.

Honesty floor: +40% obstacle is a weak tooling-comparison percent — I will not invent the metric definition to save it.

Missing — do not fill with fiction. IoU, labeled set, n frames, the exact competing tool list as a study, planner ownership.

LP lane. Allowed only as Earn Trust / Learn if they bring the number. Must not support Are Right, A Lot (that is Argus). Must not steal 60 FPS or −55%. Must not open any hour.

13. ZED 2 — 2M+ points/sec order-of-magnitude

Claim as printed. Built a 3D SLAM mapping pipeline using ZED 2 stereo camera (2M+ point cloud samples/sec), visualized in RViz and Gazebo; …

What it actually measures. Order-of-magnitude sensor/SDK capability under the configuration we used — not a throughput benchmark I instrumented on a counter, not 60 FPS, not “I wrote a 2 million point kernel.” ZED 2 produces a dense stereo cloud; the SDK advertises that class of rate when the host can take it. Dev/host GPU in our story: laptop-class RTX 3050 Ti. Rover compute was Jetson Orin class. FPS ≠ points/sec. I do not convert 60×something into 2M to look clever.

ZED 2 is a stereo camera that can throw a dense cloud — the resume says 2 million-plus samples per second. That is an order-of-magnitude figure under the configuration, not a counter I sat on. We visualized in RViz and Gazebo. I used a laptop-class RTX 3050 Ti in that loop; the rover had Jetson-class compute. 60 FPS is the GStreamer feed. I do not equate frames to points. I did not write a custom fusion stack to “make it 2 million.”

Follow-ups

Did you measure 2 million on a profiler?

No. I will not invent a nvprof screenshot. Order of magnitude under config. If they want a measured rate, I say it is missing.

3050 Ti — is that rover production?

Laptop-class GPU in the mapping/dev path I can speak. Rover is Jetson Orin class. I keep them straight. I do not claim a 4090.

Is 2M+ the same as 60 FPS?

No. Different units. A 720p frame is hundreds of thousands of pixels; a stereo cloud is a different pipeline. I will not multiply FPS by resolution to “prove” 2M.

SLAM — did you write it?

I built the mapping pipeline using ZED 2 and the visualization path. I do not claim a from-scratch SLAM paper. ZED’s own positional tracking / cloud is in the story. I will not absorb a teammate’s SLAM node to sound like a researcher.

What would falsify 2M+?

Treating it as a measured Prometheus gauge. Converting FPS into points. Claiming I implemented the stereo matcher.

Deeper probes

Resolution / depth mode?

Not locked as a resume number. I do not invent VGA versus HD5 to hit 2M on a whiteboard.

I vs we?

I the ZED scanning / visualization integration. We the rover. SDK rate is Stereolabs’ class, not my algorithm trophy.

Honesty floor: 2M+ is SDK-class order of magnitude on a 3050 Ti / Jetson-class host — not a profiled counter, and not 60 FPS.

Missing — do not fill with fiction. Measured samples/sec, exact depth mode, a custom stereo implementation.

LP lane. Allowed: Dive Deep on sensors if they are already on Horizon. Must not steal −55% fusion, must not steal Argus 24 FPS, must not be Ownership of the whole nav stack.

14. 55% fewer simulated collisions do not steal planner

Claim as printed. … implemented costmap-based path planning with sensor fusion, reducing simulated collision events by 55% on test tracks.

What it actually measures. Simulated collision events on test tracks went down in the team’s story when the stack used costmap + the sensor picture (ZED cloud / feeds) so the rover was less willing to take a stupid cell. Correct ownership: I did not build the planner. I did not build a custom fusion algorithm I will name as mine. I supplied video + ZED environment scanning that fed the picture the stack planned on. “We” the navigation stack. “I” the perception feed. 55% is a team simulation outcome I will not upgrade into “my A*.”

The resume ties a 55% drop in simulated collisions to costmap-based planning and sensor fusion on test tracks. I need to be precise about ownership. I did not write the planner and I did not write a custom fusion library. I worked the video feed and ZED-based scanning so the environment the stack saw was actually there. A better occupied cell is why you stop driving through a rock in Gazebo. The percent is a team simulation result. I will not invent the track count.

Follow-ups

What is a collision event in that 55%?

Simulated contact / crash on test tracks in our notes. I do not have a locked operational definition I will recite as a paper. I will not invent “n trials.”

Which planner? Which fusion?

Costmap-based path planning in the ROS2 nav stack we ran. I will not name a predictive algorithm as mine. Fusion in the resume line is the stack using more than one sensor picture — not a filter I published.

Did your GStreamer work cause the 55%?

The feed is an input. I do not hang 55% on 60 FPS. I do not hang 55% on 2M+ either.

Simulated only — real ERC collisions?

The printed metric is simulated test tracks. I do not invent an ERC collision log.

What would falsify 55%?

Me claiming I implemented the planner. Changing “simulated” to “field.” Inventing a trial protocol. Moving 55% onto Ylogx uptime.

Deeper probes

They said “you implemented fusion.”

I correct in the room: I integrated ZED/video into the stack we used. I did not own a custom fusion implementation. Earn Trust over a prettier resume verb.

I vs we?

We reduced collisions in sim. I owned the feed/scanning slice. That sentence is the whole test.

Honesty floor: 55% is a team sim outcome on costmap/fusion I did not implement — I owned video + ZED scanning.

Missing — do not fill with fiction. Trial count, planner name as mine, fusion equations, field collision rate.

LP lane. Allowed as a careful Ownership boundary (what I did not take). Must not support Ownership of navigation. Must not steal Argus −50%. Must not steal +40% obstacle.

15. StratifyLabs −30% / 50+ project

Claim as printed. Reduced ML iteration cycles by 30% via browser-based WebGL inference; shipped a model marketplace with 50+ pre-trained models …

What it actually measures. −30%: human iteration time — train/try in the browser lab versus local GPU setup friction. 50+: catalog size of the marketplace, not 50 customers. GitHub README on that repo currently looks like a Next.js scaffold. Resume and stratifylabs.design win. I say the mismatch if they open GitHub.

StratifyLabs is a browser CV lab plus a marketplace. The resume says browser WebGL inference cut ML iteration cycles 30% because you did not wait on a local GPU setup, and the marketplace shipped with 50+ pre-trained models. 50+ is the catalog, not users. If they open GitHub and see a scaffold README, I flag it — resume and the live site are the product I am defending. I do not invent a student n for the 30%.

Follow-ups

30% of what cycle?

Iteration: change something, see a model run, try again — versus install, driver, local GPU. I do not have a diary study. I will not invent minutes.

50+ models or 50+ users?

Models in the marketplace. I do not invent MAU.

README is a scaffold.

Earn Trust: I would align the repo. I do not import scaffold features and I do not hide the mismatch.

Gemini voice agents — is that the 30%?

No. Voice agents are a surface inside the lab. −30% is WebGL inference iteration. I do not stack Gemini onto ConvBI ChatOpenAI.

What would falsify −30% / 50+?

Counting README boilerplate as 50 models. Measuring page load and calling it iteration. Claiming a GPU cloud I did not run.

Deeper probes

Is the URDF editor part of the 30%?

No. URDF / 3D prototyping is a surface in the lab. −30% is WebGL inference iteration versus local GPU setup. I do not hang a robot-editor feature on a cycle-time percent.

I vs we?

This is my project. I still say “the product” for marketplace copy. I do not invent a co-founder to sound humble or a user study n to sound scientific.

Honesty floor: −30% is browser-iteration versus local GPU friction; 50+ is catalog size — README scaffold is a mismatch I flag, not a feature I import.

Missing — do not fill with fiction. User count, diary study, minutes saved, a labeled marketplace inventory I will recite from memory.

LP lane. Allowed: Think Big (lab + marketplace + inference in one product). Must not steal GiftedBooks Customer, must not steal Argus Standards, must not steal Ylogx 40%.

16. GiftedBooks — sub-300ms, 99.5%, +35%, +50%, 2.5×, 3–10 min project family

Claim as printed. PDF-upload RAG assistant delivers contextual Q&A at sub-300ms latency with 99.5% uptime. PYQ-analysis topic prioritization improved reading efficiency by 35% and session engagement by 50%. Average student doubt resolution from several hours to under 10 minutes, enabling 2.5× faster content comprehension versus traditional study methods in user testing.

What it actually measures — do not mix units.

  • sub-300ms. API retrieve-and-answer hop on the grounded RAG path — not model faithfulness, not a memorized p95, not ConvBI sub-210ms.
  • 99.5%. Project uptime family — not Ylogx 99.9%. I am not inventing a window.
  • +35% / +50% / 2.5× / 3–10 min. Project-reported user-testing outcomes on reading efficiency, engagement, comprehension versus traditional study, and doubt wait (hours → 3–10 minute window; resume also says under 10 minutes). Not a randomized trial. GitHub README currently describes AegisAI — resume and giftedbooks.study win.
The customer was a student stuck in a study loop: find the chapter, get stuck, wait hours for a person. I made their uploaded PDF the source of truth — ingest once, retrieve a small user-scoped set, answer from those chunks on a sub-300ms API path — and I kept previous-year-question ranking as analytics, not as the model inventing the syllabus. In the user testing we reported, doubts that used to take hours landed in a 3–10 minute window, with +35% reading efficiency, +50% engagement, and 2.5× comprehension versus traditional methods in that testing. Uptime on the resume is 99.5%. I do not have a student headcount. If they open GitHub and see AegisAI, I flag the README.

Follow-ups

Is sub-300ms p95? Fairness of the answer?

The resume says contextual Q&A at sub-300ms. I speak it as the retrieve-and-answer API path. I do not upgrade it to p95. Latency is not proof the chunk was the right derivation. I do not have a labeled citation eval on the resume.

Who was in the user test? What is n?

Missing. I will not invent a classroom size. The resume says “in user testing.” If they want the protocol, I say I will get the sample and the instrument — I do not make them up in the room.

Hours to 3–10 minutes — clocked how?

Reported average doubt resolution versus waiting on a human. I do not invent a time-and-motion sheet. 3–10 min is the window we reported; resume also says under 10 minutes. I do not pick a fake mean like 4.2.

99.5% versus Ylogx 99.9%?

Different products, different claims. I never stack them. I do not invent two monitoring stacks to look consistent.

README says AegisAI.

Mismatch on the current GitHub copy. GiftedBooks is VR labs, PDF RAG, PYQ. AegisAI is a different personal-safety project. I would fix the README. I do not blend SOS routing into this story.

What would falsify this family?

A generic tutor that never used the student’s file. Mixing users’ PDFs. Calling PYQ an LLM prediction of the next paper. Inventing n. Moving these percents onto IQVIA or Ylogx.

Deeper probes

FAISS is on the skills line — cluster topology?

I do not invent FAISS ops topology because it is on the skills line. Authenticated user, their chunks, small retrieve set. IQVIA Azure Search + Neo4j stays on IQVIA.

I vs we?

I built the product. “We reported” is the testing voice. I do not invent a research lab.

Is 2.5× the same study as +35% / +50%?

Same user-testing family on the resume. I do not split them into three independent papers. I also do not add them into one fake “compound lift.”

Honesty floor: sub-300ms is the RAG API hop; the percents and 3–10 min are project user-testing — I do not invent n, and AegisAI on the README is a mismatch I say out loud.

Missing — do not fill with fiction. Student headcount, protocol, p95, citation eval, monitoring window, chunker/embedding details I will not guess.

LP lane. Allowed: Customer Obsession (speak-first if the hour is free). Must not steal Ylogx +65% as a second Customer opening, must not steal Think Big unless this hour did not already spend GiftedBooks, must not steal Argus Standards.

17. Argus — 73→89 mAP, 15k, 24 FPS, 20+ cameras, −50% / 2× judgment family

Claim as printed. Trained a YOLOv9 PPE-compliance detection model on 15,000+ images, improving mAP from 73% to 89% at 24 FPS real-time inference. Dockerized multi-feed pipeline processing 20+ simultaneous camera streams with PostgreSQL audit logging; automated PPE violation alerts reduced recorded safety incidents by 50% in pilot deployment. Companion lock also uses 2× compliance as the “do not ship 73%” outcome family — I do not invent a second study to explain 2× if they only have −50% on the PDF in front of them; I treat 2× as “compliance workflow became usable after 89%,” not as a new percent I will derive in the room.

What it actually measures.

  • 73→89 mAP. Reported mean average precision on the PPE detector. I do not invent per-class AP, split, or augmentations.
  • 15,000+. Training-image order of magnitude, not a public COCO subset I will name if I cannot.
  • 24 FPS. Real-time inference rate of the detector — not Horizon 60 FPS, not ZED points/sec.
  • 20+ cameras. Pilot multi-feed width after the model was good enough — not the thing that produced 89%.
  • −50% recorded incidents. Pilot deployment outcome after alerts. Not a national safety paper. Not Horizon −55%.
The first YOLOv9 I could run sat at 73% mAP. For a slideshow that is a result. For a floor where a missed helmet is a person, 73% is not shippable. I went back to data — 15,000+ images — until reported mAP moved to 89% at 24 FPS. Only then did we go to 20+ cameras and audit logging. The pilot says recorded safety incidents dropped 50% after automated alerts. I do not invent a safety officer I argued with. The judgment was refusing to confuse a running model with a safe one.

Follow-ups

Why not ship 73% and add cameras?

More streams at 73% multiplies misses. Width is not the fix. 20+ cameras are what you earn after 89% and 24 FPS. That is the Standards sentence.

mAP of what classes? What split?

PPE-compliance detector. I do not invent helmet/vest/shoe AP or an 80/20 split I cannot show. If they want the eval sheet, I say it is not in front of me — I do not draw a fake PR curve.

24 FPS on which GPU?

Not locked as a resume number. I will not invent a 3090 to sound like a CV shop. 24 FPS is the reported real-time inference rate.

−50% incidents — n sites, how long?

Pilot deployment on the resume. I do not invent site count or weeks. Recorded incidents after alerts, not “injuries in the country.”

Haar cascades? First attempt?

I do not confirm Haar as the first attempt unless I can stand on it. The speakable refuse-to-ship is 73% YOLOv9 mAP. I do not add a folklore first model to sound more senior.

What would falsify this family?

Shipping 73% because the demo looked busy. Claiming 20+ cameras produced the mAP. Moving −50% onto Horizon collisions. Inventing per-class AP.

Deeper probes

2× compliance — where is it?

It lives in the prep lock as the “workflow became usable” companion, not as a third independent trial I will derive. If the PDF in the room only has −50% incidents, I stay on −50%. I do not mint 2× in the air.

Postgres audit — is that ConvBI RLS?

No. Argus audit logging is a different product. I do not import SET ROLE into a PPE story.

I vs we?

I trained and refused to ship 73%. We for a multi-camera pilot if others wired cameras. I do not invent a factory partner name.

Honesty floor: 73→89 mAP at 24 FPS on 15k+ images is the judgment; 20+ cameras came after; −50% is a pilot — I do not invent split, GPU, or site n.

Missing — do not fill with fiction. Per-class AP, train/val split, GPU SKU, pilot weeks, site count, Haar-as-fact if not locked.

LP lane. Allowed: Are Right, A Lot and Insist on the Highest Standards (same family — pick one opening this hour, not both as two trophies). Must not steal Horizon +40%, must not steal GiftedBooks, must not steal Ylogx 40%.

18. Hackathon placements not a methodology

Claim as printed. Won 1st place (CodeRecet), Best Project (Major League Hacking), and Runner-up (Magnathon 2.0 — IEEE) across 8 national and regional hackathons.

What it actually measures. Placements. Judges liked a build enough to rank it. That is not a measurement methodology, not +65%, not mAP. If they push “so you win things,” I pick one concrete build I can walk — Argus on Devfolio is the speakable one (YOLOv9 PPE, 73→89, 24 FPS). I do not invent a CodeRecet stack I cannot defend. I do not convert eight hackathons into a coaching program or a mentee count.

The resume lists eight hackathons, including CodeRecet first, MLH Best Project, and Magnathon 2.0 runner-up. Those are placements, not a scientific method. If they want substance, I walk one build — Argus, the PPE detector I refused to ship at 73% mAP. I do not invent what I coded in a 24-hour I cannot reconstruct, and I do not turn placements into “I raise the bar for every hire.”

Follow-ups

What did you build at CodeRecet?

I will not invent a stack to fill a blank. If I cannot walk it, I say so and I offer Argus or GiftedBooks — products I can still open. Guessing a weekend repo is how Earn Trust dies.

Is Argus a hackathon project?

It lives on Devfolio and it is the concrete build I will defend. Placements are the ribbon. Argus is the mechanism.

Eight hackathons — did you coach those teams?

Those are my placements. IEDC Tech Team is a member, not a mentee program. I will not convert ribbons into Hire and Develop.

Why should a Bar Raiser care?

They should not, as a number. They should care if I can take one weekend-shaped product and still explain a decision with a cost — Argus 73% was that. Ribbons without a build are noise.

What would falsify this line?

Inventing a CodeRecet architecture. Claiming I was a judge. Claiming eight wins. The resume says 1st / Best Project / runner-up across eight events — not eight firsts.

Deeper probes

MLH Best Project — which repo?

Not locked in this fragment as a named repo I will guess. I point at a product I can walk. I do not mint a GitHub URL in the room.

I vs we?

Hackathon teams are we. My resume line is my placements. If I cannot name who wrote which file, I do not say “I built all of it overnight.”

Honesty floor: placements are ribbons — I defend one concrete build (Argus), and I will not invent a CodeRecet methodology.

Missing — do not fill with fiction. Per-event stack, team lists, judge quotes, a fake CodeRecet architecture.

LP lane. Allowed as color only, or as a door into Argus Standards. Must not steal Hire and Develop, must not steal any Ylogx percent, must not be Think Big’s payload.

Part E — RLS ownership pressure-test script

This is the hour they stop accepting “intended behavior.” Speak checkout, not latex organization_id / sales_data examples. Candidate voice. Empty ≠ reject.

Lock before they start. Assume the statement actually reached Postgres on the request transaction after SET ROLE / set_config. Postgres does not inspect “this WHERE asked for ORG_B, therefore deny.” JWT org is not a policy by itself. Nest login is typically the table owner — owners bypass RLS unless FORCE (this generator does not emit FORCE). Isolation depends on not executing as owner.
E0. The prompt they will actually say script

Assume a bug: a malicious authenticated user gets the backend to accept SELECT * FROM sales WHERE organization_id = 'ORG_B' and send it to PostgreSQL. You said you implemented RLS. Specifically:

  1. What does PostgreSQL itself do?
  2. What RLS policy did you have conceptually?
  3. What database/session context did you set before execute?
  4. Why would PostgreSQL return zero rows for ORG_B even though the SQL asks for ORG_B?
  5. Were you personally responsible for implementing that PostgreSQL mechanism, or did you integrate someone else’s layer?

If I say “Postgres rejects it,” they will come back: RLS filtering can make rows invisible; RBAC/privileges can error; Nest can 403 before Postgres; a NULL/empty result is not evidence of reject; and I still have not answered I vs integrate.

Follow-up 23 (Earn Trust + Ownership). Stop describing intended behavior. If I do not remember exact syntax, that is acceptable. They want: (1) what I implemented; (2) Postgres versus Nest; (3) one concrete policy example; (4) if I mainly did application integration, say that — they would rather hear “I don’t remember” than a guess.

E1. What PostgreSQL itself does — 20–40s then push do not say reject
If that SELECT reaches Postgres on the bound transaction, Postgres does not read the WHERE and deny the statement. First it checks GRANT for current_user on sales — fail is permission denied, that is privilege, not RLS. If SELECT is granted and RLS is on and I am not a bypasser, it applies every applicable CREATE POLICY FOR SELECT USING. USING is a security-barrier filter. Rows that fail are invisible. The command still succeeds. Then the caller’s WHERE runs only on already-visible rows. It cannot unhide ORG_B. So RLS is 200 and zero rows. Missing GRANT is an error. Nest hasTableAccess is 403 before the engine. Empty JSON is not proof Postgres rejected anything.

Follow-ups

Walk the four steps without a slogan.
  1. Privilege. No SELECT → error. rls_no_access lives here (no table grants). That is not an empty filter.
  2. RLS. Applicable USING expressions. False → row invisible. Statement succeeds.
  3. Caller WHERE. Only on the visible set. WHERE organization_id = 'ORG_B' cannot resurrect a row that failed USING.
  4. Column mismatch. If the WHERE names a column that does not exist → undefined-column error (bug), not a security deny. This repo’s sales prompt schema lists client_id, not organization_id. I say that.
USING (false) versus no GRANT versus 403 versus rls_no_access.

Generator grants SELECT on the dashboard table set so missing-module does not 500 as permission denied; USING (false) → 200 and []. Proper-default alternative is no GRANT → permission denied. Nest hasTableAccess is extra app RBAC — HTTP 403, “Access to this table is restricted.” GUEST on data is 401 in this file. rls_no_access is fail-closed SET ROLE when there is no db_role_name — permission error on facts, not a successful empty RLS hide.

JOIN another org in generated SQL.

Each table’s USING is independent. A JOIN cannot resurrect a hidden row. That is why the engine is the gate, not the model’s WHERE.

RESET ROLE then SELECT sales.

Owner / login role. Improper on the tenant fact path. Chat metadata does RESET ROLE on purpose inside executeWithoutRLS. Facts must not. SUPER_ADMIN RESET ROLE is the intended bypass, with app.is_SUPER_ADMIN=true.

They already stipulated the backend accepted the SQL.

Then I do not brag about the string-inject belt. I speak only SET ROLE + GUC + USING. If they open executeRawSelectQuery, I name the optional organizationId inject as a belt, not as RLS.

Direct FastAPI /chatbot.

Proper: not reachable from the internet. This checkout: CORS *, no JWT — a gap. Even if reachable, it returns SQL text; rows still require Nest execute under SET ROLE. FastAPI must not become the executor.

Deeper probes

FORCE ROW LEVEL SECURITY?

Not emitted. ENABLE only. Table owner bypasses. That is why SET ROLE to a non-owner is the isolation, and why RESET ROLE on facts is a leak class. I name the gap rather than claim gold-standard FORCE.

FinishTransaction — rollback on 403?

Docs wanted COMMIT on OK, ROLLBACK on error. Live finish-transaction.middleware.ts commits on res.on('finish'), rollback only if commit throws. I show the conflict if they have the file open. I do not recite the latex as shipped.

Honesty floor: RLS hides rows and succeeds; GRANT errors; Nest 403s — empty is not a reject.
E2. Session context set before execute checkout

On every authenticated request, RLSMiddleware opens a Sequelize transaction (req.dbTransaction). Chat/query/KPI execute uses that same transaction. set_config(..., true) is transaction-local.

For a normal USER with a mapped role I run the equivalent of:

SET ROLE "<first db_role_name>";
SELECT set_config('app.is_SUPER_ADMIN', 'false', true);
SELECT set_config('app.is_admin', 'false', true);
SELECT set_config('app.current_user_id', '<jwt guid>', true);
SELECT set_config('app.user_role', 'user', true);
SELECT set_config('app.organizationId', '<caller org UUID>', true);

ADMIN with a SYSTEM db_role_name: SET ROLE that name, is_admin=true, user_role=ADMIN, admin_hierarchy_filter=true, org from the admin’s organization. ADMIN without a db role, or USER without one: SET ROLE "rls_no_access" — comment in code: previous RESET ROLE leaked. SUPER_ADMIN:

RESET ROLE;
SELECT set_config('app.is_SUPER_ADMIN', 'true', true);
SELECT set_config('app.is_admin', 'true', true);
SELECT set_config('app.current_user_id', :userId, true);
SELECT set_config('app.user_role', 'SUPER_ADMIN', true);
SELECT set_config('app.organizationId', '', true);

Follow-ups

Why SET ROLE at all?

Because the Nest login is the privileged/owner role. Owner bypasses RLS without FORCE. The policy TO the policy role applies because we GRANT that policy role TO the db role we SET.

First db_role_name only?

Postgres has one session role. The middleware uses the first mapped db_role_name. I say that. I do not invent multi-role SET ROLE.

Does FinishTransaction RESET ROLE?

No. It commit/rollback only. Leftover-role class: a pooled connection reused with a previous SET ROLE if a path forgets the request transaction or skips RESET. Chat persistence opens a new transaction and RESET ROLE inside executeWithoutRLS.

GUEST?

I do not SET a warehouse reader for a guest and call it isolation. Action/data paths forbid guests. I do not sell four tiers when the resume says three.

Is JWT org enough without set_config?

No. Policies read current_setting('app.organizationId'), not the HTTP header. If I forget set_config, USING cannot see the caller.

last-updated on this session?

Proper: yes. This checkout: last-updated can be an owner MAX — gap. I name it if they are in that handler.

Deeper probes

GUC names in latex versus code.

Latex has drawn app.user_guid / app.organization_id. Live middleware: app.current_user_id, app.organizationId, app.is_SUPER_ADMIN, app.is_admin, app.user_role, app.admin_hierarchy_filter. I speak the file they opened.

Cookie MD versus Bearer.

Live JWT is Authorization Bearer + localStorage. Cookie-auth markdown is a migration write-up, not this checkout’s running path.

Honesty floor: session = per-request txn + SET ROLE or fail-closed rls_no_access + GUC from JWT — not from SQL text.
E3. Conceptual policy from the generator — not the latex example checkout

I did not check in a hand-written sales.sql. When an admin creates a policy in the API, PolicyManagementService emits: CREATE ROLE policy_<scope>_<slug>_<timestamp> NOLOGIN (name sliced to 63); GRANT SELECT on the dashboard table set to that role; then per table DROP POLICY IF EXISTS / CREATE POLICY / ENABLE ROW LEVEL SECURITY; then GRANT policy role TO db_role_name.

DROP POLICY IF EXISTS "<policyRole>_<table>_policy" ON "<table>";
CREATE POLICY "<policyRole>_<table>_policy" ON "<table>"
  FOR SELECT
  TO "<policyRole>"
  USING (<rlsCondition>);
ALTER TABLE "<table>" ENABLE ROW LEVEL SECURITY;
CaseUSING
Table not in the policy’s modulesfalse → 0 rows, success
Table in modules, no extra filterstrue, and if information_schema has organizationId: ("organizationId" = current_setting('app.organizationId')::uuid)
Table in modules + admin filtersthose predicates AND the same org GUC if that column exists

Do not quote the docs example (sales_data, organization_id::text, rls_restricted_role). Live text is camelCase organizationId as uuid.

One concrete shape I can point at in code — not a remembered prod name — if sales is in modules and has organizationId:

CREATE POLICY "policy_organization_salesview_<ts>_sales_policy" ON "sales"
  FOR SELECT
  TO "policy_organization_salesview_<ts>"
  USING (
    (true) AND ("organizationId" = current_setting('app.organizationId')::uuid)
  );

Name is policy_${scope}_${sanitizedName}_${Date.now()}. I do not remember a production policy name. If sales is not in the module list: USING (false).

Follow-ups

Earn Trust on sales — client_id versus organizationId.

This checkout’s warehouse prompt schema for sales lists client_id, not organizationId / organization_id. The org GUC is only added when that column exists. If sales has no organizationId: the generated USING is not “match session org”; Nest also skips injecting organizationId; then Postgres would not hide ORG_B by that GUC — I would get a column error on organization_id, or a real leak if some other column is used. I will not testify that production sales has organizationId. I will say: the mechanism keys off that column if present; I am not reciting a live \d sales.

Why GRANT all dashboard tables then USING (false)?

So a missing module does not become a 500 permission error on a JOIN the UI still names. Product choice: empty success versus hard deny. Proper-default is no GRANT. I can say both. I shipped the generator’s empty-success path.

DDL on which connection?

Policy create RESET ROLEs on a privileged transaction to CREATE ROLE / GRANT / CREATE POLICY. That must not be mixed with a tenant SELECT after RESET on the same session. Tenant facts stay on the middleware transaction.

Did you type CREATE POLICY in psql?

The path I own is the Nest generator + middleware. I do not remember a separate DBA script in this checkout. I will not recite latex as if I shipped it by hand.

CREATE ROLE rls_no_access in this repo?

I wired the fallback to that name. I did not find CREATE ROLE rls_no_access in this tree. I will not claim I created that role in this service.

Application belt versus RLS.

executeRawSelectQuery is SELECT-only, hasTableAccess, then may string-inject WHERE ("sales"."organizationId" = '<jwt org>') if the column exists. That is not RLS. Belt. If they stipulated the backend already accepted the SQL, I do not use the belt as my proof.

Deeper probes

Shipped versus proper — say the table.
  • Shipped: JWT + SET ROLE + generated USING + execute on req.dbTransaction for queryDB and KPI dashboards.
  • Gap: no API feature guard / RolesGuard on every route; no FORCE; last-updated owner aggregate; FinishTransaction always commit; chat via RESET ROLE; FastAPI CORS *; GET report-by-id / orgs scoping gaps; upload trusts body client_id.

I would rather name the gap than call empty JSON a reject.

I implemented versus I integrated.

I implemented the application that creates and attaches those Postgres policies, and the session setup so they run. I did not maintain a checked-in warehouse CREATE POLICY file. I integrated Postgres RLS as a feature of Postgres — I did not invent the engine. I did not only “call a library someone else wrote and never open.” Middleware + generator is the personal sentence.

Honesty floor: I wrote middleware + CREATE POLICY generator; I did not check in hand-written policy SQL; I will not guess sales.organizationId when this repo’s warehouse schema lists client_id.
E4. Follow-up 23 — ownership, said out loud Earn Trust

1. What I implemented. Nest integration and the DDL generator, not a DBA-owned .sql migration in this repo:

  • rls.middleware.ts — per-request txn, SET ROLE / RESET ROLE, set_config('app.*'), fail-closed SET ROLE "rls_no_access"
  • policyManagement.service.ts — CREATE ROLE / GRANT SELECT / CREATE POLICY / ENABLE ROW LEVEL SECURITY
  • roleManagement.service.ts — CREATE ROLE db_role_name NOLOGIN and GRANT policy role TO db role
  • Query path runs on req.dbTransaction

I did not find CREATE ROLE rls_no_access in this tree. I wired the fallback to that name.

2. Postgres versus Nest.

PostgresNest
Roles, GRANT, CREATE POLICY, ENABLE ROW LEVEL SECURITY, USING / privilegesJWT → org/role, open txn, SET ROLE + GUCs, execute on that txn
Hides rows or errors on privilegePolicy/role APIs that emit that DDL; hasTableAccess; optional org string inject

3. One concrete policy — the policy_organization_salesview_<ts> shape above. Not a remembered prod name.

4. Explicit. I implemented the application that creates and attaches those policies, and the session setup so they run. I did not maintain a checked-in warehouse CREATE POLICY file. If they ask whether I typed CREATE POLICY in psql by hand: the path I own is the Nest generator + middleware. I do not remember a separate DBA script in this checkout.

Follow-ups

You keep describing intended behavior.

Intended: USING hides ORG_B. Shipped for bot and KPI execute: that session + generator. Not shipped: FORCE, last-updated on the txn, API feature guards. I would rather name the gap than call empty JSON a Postgres reject.

Did a leak happen in production?

The RESET ROLE fallback for admin-without-db-role is commented as a leak class we closed to rls_no_access. I do not invent a customer-visible breach or a ticket ID.

Is cache part of isolation?

No. Resume Redis key must include role+org. This snapshot’s fieldsCache is not a fact cache. Isolation does not become a cache story unless they ask −35%.

Three tiers — is SUPER_ADMIN “RLS”?

SUPER_ADMIN is an intentional bypass (RESET ROLE + GUC). The three-tier claim is that USER and ADMIN are isolated on the shared warehouse, and SUPER_ADMIN is a gated escape, not a public route.

Which LP is this answer allowed to carry?

Ownership and Dive Deep — pick one opening. Highest Standards if they ask why the LLM is not the control. Must not steal 99.9%, +65%, Redis, or Horizon in the same breath.

Deeper probes

What is missing that I will not invent?

A remembered production policy name. \d sales. CREATE ROLE rls_no_access in this repo. FORCE in prod. A pentest count. A leak ticket. p95. A monitoring window.

One-request walk they can interrupt.

Bearer JWT → middleware txn → SET ROLE + GUC from JWT → FastAPI proposes SQL (chat) or handwritten SQL (tile) → Nest execute on that txn → USING filters → empty or caller rows → FinishTransaction commit. Chat message persist is a different txn with RESET ROLE. I can stop at any hop and not skip to “so we are secure.”

Honesty floor: empty result is RLS USING making ORG_B invisible under current_setting('app.organizationId') after SET ROLE; permission denied is missing GRANT; 403 is Nest hasTableAccess.

Part F — one-sentence recovery

I will defend the mechanism and what the number measures; I will not invent n, a percentile, or a monitoring window, and I will not call an empty SELECT a Postgres reject.

If they were on RLS and I slipped into “reject,” I replace the sentence with: empty result is USING hiding ORG_B under the JWT GUC after SET ROLE; GRANT is the error; 403 is Nest.

End of metrics fragment. Same-hour: one ConvBI number family, one project family, no percent dump. Strongest mechanism is RLS. Weakest Ylogx science is +65%. Weakest Horizon science is +40% obstacle. Hackathons need Argus, not a ribbon.

Optimize + projects — how to speak this hour

This is rehearsal for Adarsh Vishwakarma, Amazon SDE I Bar Raiser leftover hour. Speak as I. Coaching can sit in third person. This is not a scoring sheet. Do not name a poster Leadership Principle unless they already asked that card. Do not invent metrics, probe hosts, bills, p95 studies, cache hit ratios, mentee names, or a hackathon stack I cannot walk.

Throw first: Speak this live — optimize + projects is the room pack — question, then one paragraph. Coaching cards under #optimize and #projects stay for lookup. Do not memorize the coaching bullets and then tack on a 15-second line.

Two jobs sit here. #optimize is APIs, queries, and pipelines — what I shipped, what I understand honestly, what I would do next. #projects is the project bank: 90s overview, architecture, decisions, challenges, scale, improvements, questions, probes, and which three LPs that project is allowed to be primary on.

Must remember — spoken form
  • I vs we. ConvBI and Horizon were teams. I for Nest RLS, the inherited chatbot path, the renderer prototype, the crash fix, video+ZED. We for the rover and the product. If I cannot draw the line, I drop the sentence.
  • One project per spoken answer. Timeline is chronology, not a ranking. IQVIA Apr 2026–present. Ylogx Nov 2024–Oct 2025. Horizon Feb–Jun 2024. Never say an internship was “the deepest.”
  • This workspace resume.md is not the whole lock. It has Ylogx, Horizon, StratifyLabs, GiftedBooks, Argus, Aegis. It does not currently list IQVIA. IQVIA facts come from DeepQuery / BRDprocessor docs and the interview lock. ResumeWithSummarySep2026.pdf may omit Aegis and disagrees on CGPA (md 8.42 vs that PDF 8.12). If they open a PDF, I speak the file they opened and I flag the mismatch.
  • sub-210ms. resume.md currently writes “sub-210ms P95.” Older coaching said do not upgrade a bare sub-210ms to a percentile I cannot defend. I speak “resume sub-210ms on dashboard GETs.” I do not invent probe host, window, or a Grafana panel. Measuring a real p95 is a would-do, not a second number.
  • Redis −35% is the resume bot-DB cache-aside hop. This Nest checkout has no Redis client. fieldsCache is an in-process Map, 5 minutes, key fields:${tableName}.

Stack why — listed vs shipped

Live Code is Java on Zoom. Internships and projects shipped Python FastAPI, TypeScript NestJS/React, and ROS2. I say that split once. I do not rewrite Ylogx into Spring or IQVIA into a JVM service to sound like the round.

Speak this table if they grind skills
  • Java. Coding-round fluency. Not the intern warehouse. Not the research agent.
  • Kubernetes. Skills-line knowledge. Ylogx shipped Docker → ECR → ECS Fargate behind an ALB. I was not a cluster owner. I do not describe EKS as the intern path.
  • GraphQL. Skills-line. ConvBI dashboards, chat, reports, and admin are REST/JSON. Swagger at /api. I did not put GraphQL on this intern path. It becomes relevant when nested over-fetch is the measured pain. That was not the first bottleneck.
  • Auth0. Skills-line identity. Ylogx evidence is Nest JWT (Authorization: Bearer + localStorage in this checkout) mapped to RBAC and a Postgres role. I do not claim I operated an Auth0 tenant for the internship. Cookie-auth markdown is a migration write-up, not jwt.middleware.ts.
  • FAISS. Skills-line vector knowledge and the smaller GiftedBooks vector-plus-metadata lane. IQVIA Hybrid RAG used Azure AI Search (BM25 + vector kNN + semantic reranker) plus Neo4j. I do not say FAISS was the IQVIA store.
  • Prisma / Mongo. Skills or adjacent. Warehouse evidence is PostgreSQL + Sequelize. Pool max 20, min 0, acquire 30s, idle 10s.
  • LangGraph vs LangChain. Ylogx chatbot is LangChain SQL-RAG. DeepQuery and BRDprocessor are LangGraph. I never say “my IQVIA agent” as if they were one system, and I never put LangGraph on Ylogx.

Spoken 15s. “Live Code is Java. The intern I can walk is TypeScript Nest and Python FastAPI on Postgres, plus ROS2 on Horizon. Kubernetes, GraphQL, Auth0, and FAISS are listed knowledge. If you want a shipped orchestrator I point at ECS. If you want hybrid search I point at Azure AI Search, not FAISS.”

Speak this live — optimize + projects

Existing coaching cards stay below. This pack is what I throw. One question, one paragraph, first person. I do not mix 40% with the crash, tiles, Redis, or 99.9%. DeepQuery is not BRDprocessor. Horizon plus-40% is not Ylogx 40%. Metrics percents: same throws as Speak this live — metrics.

ConvBI / Ylogx

Ylogx intern · Nov 2024–Oct 2025 · NestJS + FastAPI + Postgres RLS

Tell me about the Ylogx / ConvBI product.

“Ylogx, November 2024 to October 2025, I was an intern on a multi-tenant BI product — folders named ConvBI or Projas are that intern, not a second job. Operators needed three things on the same warehouse: known KPI tiles every morning, a custom report canvas when the tile did not exist, and a natural-language path if they could not write SQL — without one org reading another. We split the runtimes. Nest owns JWT, RBAC, dashboards, query execution, reports, Tally upload. FastAPI only proposes SQL with LangChain and gpt-4.1 at temperature 0; it never sees the JWT and never executes tenant facts. I owned the request isolation path: per-request transaction, SET ROLE to a non-owner role or rls_no_access, tenant GUCs from the verified JWT, policies from a generator. I inherited the chatbot after a teammate left. I prototyped structured JSON so the bot reused the report builder’s ElementRenderer. Pick the number that belongs to the question — I will not dump 40%, 99.9%, +65%, Redis, and sub-210ms in one breath. We for the product. I for RLS, the inherited bot path, the renderer, and a crash I caused when I aggregated a large slice on the client.”

Walk a “revenue this quarter” chat request end to end.

“The operator types the question in the chat UI. That user line is persisted on a chat-metadata path that RESET ROLEs — that is conversation storage, not warehouse facts. Then Nest POSTs /queryDB/chat-query. FastAPI, with LangChain on an allow-list of about ten public fact tables — sales, P&L, receivables, payables, stock, cashflow, and the rest of that list, not information_schema — proposes a SELECT and chart metadata. FastAPI never runs that SELECT. Nest trims, requires the string to start with select, collects table names, 403s on hasTableAccess, may inject organizationId if that column exists, then sequelize.query on the same request transaction that already has SET ROLE and the org GUC. ElementRenderer draws the chart. If the SQL asks for another org, Postgres still succeeds; those rows are invisible under USING. Empty is not a reject. Permission denied is missing GRANT. 403 is Nest before the engine.”

Why SET ROLE on every request instead of one database user?

“The Nest login is typically the table owner or a privileged role. Owners bypass RLS unless FORCE ROW LEVEL SECURITY, and this generator does not emit FORCE. Isolation depends on not executing as owner. Connections are pooled, so a process-wide SET ROLE leaks User A into User B. I open a Sequelize transaction per authenticated request, SET ROLE to that caller’s mapped db_role_name or fail closed to rls_no_access, set_config for app.organizationId and the other GUCs with transaction-local true, run warehouse SQL on req.dbTransaction, and finish when the response finishes. JWT org is not a Postgres policy by itself. App WHERE cannot save a RESET ROLE leak.”

A malicious authenticated user gets SELECT * FROM sales WHERE organization_id = 'ORG_B' accepted by the backend. What does PostgreSQL do?

“If that statement actually reaches Postgres on the request transaction after SET ROLE, Postgres does not say “this WHERE asked for ORG_B, therefore deny.” First it checks GRANT SELECT — fail is permission denied, that is RBAC, not RLS. If SELECT is granted and RLS is on and the session user is not a bypasser, it applies CREATE POLICY … USING. USING is a security-barrier filter. Rows where it is false are invisible. The statement still succeeds. The caller’s WHERE then runs only on already-visible rows and cannot unhide a row that failed USING. So RLS is HTTP can still be 200 and zero rows. Empty JSON is not proof Postgres rejected anything. I will not testify that production sales has organizationId — this checkout’s warehouse prompt schema lists client_id. The mechanism keys off organizationId if that column exists. If they already stipulated the backend accepted the SQL and sent it, I speak SET ROLE plus USING, not the app inject.”

What part of RLS/RBAC did you implement versus integrate?

“I implemented the Nest integration and the DDL generator, not a DBA-owned sales.sql in this repo. rls.middleware.ts opens the transaction, SET ROLE or RESET ROLE, set_config app.*, fail-closed SET ROLE rls_no_access. policyManagement.service.ts emits CREATE ROLE, GRANT SELECT, CREATE POLICY, ENABLE ROW LEVEL SECURITY. roleManagement.service.ts creates the db role and GRANTs the policy role to it. Query execution uses req.dbTransaction. I wired the fallback to the name rls_no_access; I did not find CREATE ROLE rls_no_access in this tree and I will not claim I created that role in psql by hand. Policy names are generated policy_scope_slug_timestamp. I do not remember a production name. SUPER_ADMIN RESET ROLE plus is_SUPER_ADMIN is an intentional bypass, not the public route.”

How do you stop the model from reading another org?

“The model never SET ROLEs. It returns SQL text and chart fields. Nest executes as the caller on the transaction that already has the role and the org GUC. Allow-list keeps application tables off the prompt. SELECT-only trim is a cheap reject, not a full parser. hasTableAccess is 403 before Postgres. App organizationId inject is a belt if the column exists — it is not RLS. Isolation is SET ROLE plus USING. A legal JOIN plus HTTP 200 plus the wrong tenant is the leak class a validator will not catch. Cache text-only would also be a leak; resume Redis must include role and org.”

Why is there no LLM on the dashboard GET?

“A KPI tile is a known aggregation. DashboardsService holds handwritten SQL. The browser sends month and year on the query string. Nest runs that on the SET ROLE transaction and returns JSON. CloudFront serves the SPA; tile JSON still goes through ALB and ECS, not as an edge object. Putting ChatOpenAI on overview would add model time, non-determinism, and a bad-SQL failure class to the path we quote as sub-210 milliseconds and as 99.9% serving. Flexibility lives on the report builder and the bot. New KPI shapes need a deploy. That is the point. Resume 30 is tile surfaces; this registry is nine families, some multi-page. I speak both. I do not invent six tiles to force 24 to equal 30.”

Where is Redis minus 35%, and what is in this Nest checkout?

“Minus 35% is cache-aside on the bot-to-warehouse hop for repeat suitable questions. It is not dashboard latency and it is not the builder 40%. The key includes role and org, not the query text alone, so a USER in ORG_A cannot be served ORG_B’s answer. A miss still executes as the caller with RLS. This Nest snapshot has no Redis client. What is here is QueryDBService.fieldsCache — an in-process Map, five minutes, key fields colon tableName — column metadata, not fact rows. I say both in one breath. I will not point at a Redis line in this file. I will not invent a hit-ratio dashboard.”

What is the 40% faster report generation, without the crash story?

“Forty percent is only the custom report builder. Before that builder, a one-off report meant know the tables, write or wait for SQL, dump to Excel, join, chart, export, send. After, an operator who is not a SQL person opens the canvas, drops fields, picks INNER or LEFT or RIGHT or FULL, puts slicers on year or month, hits execute-query on Nest — default LIMIT 1000, max 5000 — same SET ROLE transaction, Chart.js draws it, they save the JSON and reopen it. That cycle time is the 40%. It is not Postgres getting 40% faster. It is not the thirty KPI tiles. It is not sub-210 millisecond JSON. It is not Redis. If they drag in the tab crash, that was a different defect: I aggregated on the client, a large slice killed the tab, I moved heavy aggregation off the client and added click-to-load. That made the UI stable. That is not the 40%.”

What does 99.9% uptime mean on this intern?

“Ninety-nine point nine is serving-path availability for the deterministic product under daily production load — on the order of forty-three minutes down in a thirty-day month if you treat it as continuous time. In the number: can the operator load the CloudFront SPA and get KPI or report JSON from Nest. Out: OpenAI timeouts, a bad generated SELECT, a Tally zip that failed to ingest. Hop I can walk: browser, CloudFront for static JS only, Route 53, ALB, ECS Fargate Docker, Nest and FastAPI as separate services. Tiles do not wait on ChatOpenAI, so a model outage does not take the dashboards down. Health: Terminus /health pings Postgres; /health/simple is process-up. GitHub Actions on qa and main to ECR to ECS; prod waits for my approve about three minutes then service stability. I helped ship that path. I was not the AWS account owner and I was not on a pager I can recite. I will not say 99%. I will not mix GiftedBooks 99.5%. A crashed tab is not downtime.”

Why Nest plus FastAPI instead of one service?

“Python is where LangChain and the SQL extractor live. Nest is the typed application boundary: JWT, transaction, SET ROLE, dashboards, reports, uploads, admin. If FastAPI executed tenant SQL as a privileged engine user, a fluent SELECT could dump another org, and owners bypass RLS. Propose in the sidecar, execute in Nest as the caller. Two hops on chat. Tiles stay one hop. If the sidecar is down, tiles still work; bot returns bad gateway. Gunicorn timeout in the AI image is 180 seconds — that is not a tile SLA. This is LangChain SQL-RAG. LangGraph is IQVIA. I never put LangGraph on this intern.”

Which tables use executeWithoutRLS, and why must warehouse facts never ride that path?

“Chat conversation CRUD opens a new transaction and RESET ROLE inside executeWithoutRLS so persistence is not blocked when the fact role has no chat grants. Feature and role admin also RESET ROLE for DDL. Warehouse facts — sales, P&L, tiles, execute-query, chat-query SELECT — must stay on req.dbTransaction after SET ROLE. If I put facts on executeWithoutRLS I am executing as owner and calling it RLS. SUPER_ADMIN RESET ROLE is a gated escape, not a public reader. I say the exception out loud so I do not claim everything is RLS.”

If we 10× dashboard QPS, what actually breaks first?

“Each authenticated request holds a pool slot until finish. Pool max is 20, min 0, acquire 30 seconds. First limit is pool wait versus RDS max_connections under held transactions, then query shape, then more ECS tasks watching max_connections. I did not shard Postgres. I would not put Redis on tiles unless the key includes tenant, and that would-do is not the shipped minus 35%. I would not scale with a CDN in front of the database. I do not invent an autoscaling policy or multi-region active-active. Indexes on filter columns and stop SELECT star on uncapped GETs before I talk about Kafka.”

Why not cache dashboard JSON? Why not GraphQL or Kafka?

“A cache key without role and organizationId is a tenant bug. I would not cache tiles until the key is tenant-safe. GraphQL is a skills-line. Every browser feature here is a REST resource; the sidecar is one POST. Nested over-fetch was not the first bottleneck. Kafka is not on this intern path. I do not describe EKS as the intern orchestrator — we shipped Docker to ECR to ECS Fargate behind an ALB.”

Is the SELECT prefix a security control? Is org injection RLS?

“Prefix check is not a parser. It is a cheap reject. Comments, stacked statements, or functions can still be a later hardening item. Regex table extract can miss exotic SQL. Org injection is an application belt if the column exists. Isolation is still SET ROLE plus policy USING. If a table has no organizationId, injection no-ops and RLS must carry the row filter. I do not sell the inject as proof of RLS when they already stipulated the backend accepted the SQL and sent it.”

IQVIA DeepQuery

Current intern · Apr 2026–present · LangGraph research CLI · not the BRD system

Tell me about DeepQuery end to end.

“IQVIA, April 2026 to present — current intern. DeepQuery is a LangGraph deep-research CLI I built, not a hosted product and not the BRD processor. An analyst gives a topic. I plan sub-questions, do a light search so clarification is grounded, optionally ask the human auto, hybrid, or manual, generate a bounded set of queries, fan out to DDGS, Bing, and Firecrawl, dedup URLs, then I score URLs before I scrape. We often aim to keep the scrape set in a 120 to 180 band. I scrape in waves with a concurrency cap, reason across pages, and a decision node either stops or loops. I synthesize a long markdown report with sources and a confidence score. A strong saved run went 857 URLs to 120 filtered to about 137 pages, 99% confidence, thousands of words. I do not have an IQVIA percent on the resume. I for the graph. Local CLI, Azure OpenAI. No vector database in this tree.”

Why LangGraph instead of a linear script?

“Research is cyclical. The decision engine can send control back to search_fanout or scrape_controller. LangGraph gives me explicit nodes, conditional edges, and one DeepQueryState object passed between steps — planner, light search, clarifier, context builder, query generator, fan-out, aggregator, URL intelligence, scrape controller, cross-page reasoning, decision, synthesizer. Parallel search branches and reducers that append mean a Bing or Playwright miss does not erase DDGS. resume_from after HITL means I do not regenerate planner questions twice. A linear chain loses that loop and that resume.”

How does fan-out search work, and why three engines?

“search_fanout runs fan_out_search. For each generated query, parallel_search fires DDGS, Bing HTML, and Firecrawl concurrently, then dedupes by URL. Query tasks run in parallel via asyncio.gather. One provider is a blind spot and a single timeout. Branch-local failure: a Playwright or Bing miss must not wipe the other hits. Search returns snippets. Crawling is scrape_controller plus Firecrawl scrape_url in waves — full page markdown, metadata, link extraction, content-hash dedup. I do not scrape the internet. I search, then I filter, then I scrape a band.”

What is URL intelligence, and when is relevance applied?

“Before scrape I score cheap signals: useless URL path patterns, domain trust, keyword overlap with the topic and subtopics, trusted-domain boosts, per-domain cap, target count often 120 to 180. No full page body required. That is url_intelligence. After scrape, cross_page_reasoning reads the markdown and builds facts and knowledge blocks; the synthesizer consumes those. Filter yield on a strong run was 120 over 857. A good page on an untrusted-looking domain can be dropped — refinement HITL re-enters at url_intelligence if the analyst wants another wave. I do not put a human on every URL in an 857 pool. I do not invent a production spam-ML model I did not ship. Path plus domain plus keyword plus cap is a cheap ranker, not a legal blocklist I will oversell.”

Where is HITL, and how does refinement work?

“main.py runs a pre-clarify graph first. The user picks auto, hybrid, or manual. Hybrid and manual answers go in user_clarification_answers. The full graph starts at context_builder with planner outputs pre-filled. After printing results the user can enter a refinement string. State is copied forward — facts, URLs, scraped pages — refinement_query is set, resume_from is url_intelligence, decision is next_wave. The graph re-filters, scrapes more, re-reasons, re-decides, re-synthesizes. HITL is not a human on 857 URLs and not a click on every scrape.”

What triggers search_new versus next_wave versus stop?

“decision_engine uses hard rules on completeness, facts, pages, gaps, and max iterations; otherwise LLM JSON with a decision and optional new_queries. Router maps search_new to search_fanout, next_wave and follow_links to scrape_controller, stop to synthesizer. Caps in ResearchConfig: max_iterations, max_scrape_urls, url_filter_target, max_urls_per_domain, char budgets for query context, cross-page, and synthesis, wave_size default 15, concurrent_workers default 3. It cannot loop forever. If it should stop, it should stop or abstain, not keep paying Firecrawl.”

A run shows 0% confidence but many scraped pages. Did retrieval die?

“No. Open facts and pages first. Weak runs in the artifact table still had on the order of 79 to 161 pages and short reports — 236 to 256 words, grade D — while strong runs in the same family had 99% confidence and four to six thousand words. That pattern is synthesizer JSON parse failure or a truncated save after scrape and reasoning succeeded, not an empty web. Confidence in metadata is not retrieval quality. Blaming url_intelligence or Firecrawl would have been the wrong fix. elapsed_seconds is sometimes missing from metadata — I do not invent wall clock.”

Why Playwright / Firecrawl, and where is memory stored?

“Some useful pages only exist after browser execution. Firecrawl is the scrape hop. Playwright-class rendering is why a static fetch is not enough on those sources. In-run memory is LangGraph state — facts, visited_urls, knowledge_blocks. Post-run is responses slash topic underscore timestamp on disk. There is no external vector DB in this code. LangSmith is on the IQVIA lock for inspectable runs; I do not invent a DeepQuery-hosted eval percent. Artifacts on disk are how I debug this CLI.”

Is this the same system as Hybrid RAG?

“Same intern, different system. DeepQuery browses the public web. BRDprocessor indexes a BRD you already uploaded. Different graphs, different stores, no crawl on the BRD path. I never say my IQVIA agent as if they were one binary. Ylogx chatbot is LangChain SQL-RAG, not LangGraph.”

How do you not scrape the whole internet, and what would you improve?

“Fan-out then URL intelligence then a scrape band, waves, worker cap, char budgets, decision stop. Example 857 to 120 to about 137 pages. 10× topics is more runs with the same caps, not a cluster I will invent. I would harden synthesizer parse and retry so confidence cannot go 0% after a good scrape, cache completed scrapes by URL plus content hash across runs, and persist elapsed time honestly. Still a local CLI unless they ask a product conversation — then I say it is not shipped as SaaS.”

IQVIA BRDprocessor

Same IQVIA intern · Hybrid RAG over BRDs · Azure AI Search + Neo4j

Tell me about the BRD Hybrid RAG system.

“Same IQVIA intern, different system. QA and BA people upload a BRD — 180-plus or 200-plus page class on the lock — and need requirements and test cases they can inspect. I built a FastAPI pipeline: extract text, chunk at 1500 tokens with 200 overlap on cl100k_base, embed at 3072 dimensions in batches of 16, write Azure AI Search index brd-documents, extract requirements per chunk — that extract is the cost driver — analyze relationships, persist Neo4j Document, Requirement, Entity, DEPENDS_ON. Retrieval is hybrid BM25 plus vector kNN plus semantic reranker plus a 2-hop Neo4j walk. Test-case generation is a separate 5-node graph with asyncio.gather, not the ingest graph wearing a hat. Redis and Celery appear in requirements and are not wired; jobs are in-memory maps. I say that. No labeled precision or recall. 100MB upload cap. I for the graphs I can walk.”

Why hybrid search, not vector-only or FAISS?

“The information had more structure than pure semantic similarity. Rare clause IDs like R-141 or REQ-1044 are lexical — vector-only misses the token. Stuffing a 200-page PDF is not retrieval and cites the wrong annex. Azure hybrid is BM25 on content plus vector kNN on 3072-dim embeddings plus a semantic reranker. FAISS is a skills-line. Internship evidence is Azure Hybrid plus Semantic plus GraphDB. I do not say FAISS was the IQVIA store.”

Why Neo4j 2-hop instead of stuffing dependency chunks?

“DEPENDS_ON is an edge. Stuffing all related chunks loses the hop and blows context. get_requirement_graph_context walks DEPENDS_ON up to 2 hops, limit 50 paths. Test-case RAG uses hybrid_search plus that graph context — not the model remembers the PDF. Two stores to keep consistent. Graph is only as good as extraction. I did not shard Neo4j.”

Walk chunking. Why 1500 / 200?

“After pdfplumber or python-docx extract, I merge pages and split with RecursiveCharacterTextSplitter, length_function count_tokens on tiktoken cl100k_base, CHUNK_SIZE 1500, CHUNK_OVERLAP 200 — about 13% overlap — separators from coarse blank lines down to space so a shall-statement is less likely to split mid-sentence. Section headers stick to following chunks. 512 would starve tables and surrounding headings. More chunks means more extraction calls, because extract_requirements is one chat call per chunk, sequential. Overlap duplicates tokens on purpose. I do not have a labeled split-error set. Upload cap 100MB is a denial-of-service bound, not a quality SLA. PDF and DOCX only.”

What actually costs money in this pipeline?

“Per-chunk requirement extraction, then test-case generation. Embed batch 16 is cheaper relative to that. Formulas in the tree: embed about ceil of C over 16; extract C chat calls; analyze one chat call; tests about F generation plus F embed with parallelism max 3. gpt-4o at temperature 0 for extract and analyze, 0.1 for tests. I will not quote a bill I did not sit. LangSmith is how we inspect traces. I still will not quote recall I do not have.”

Is Redis or Celery in production on this service?

“They are in requirements.txt and config. They are not connected to routes. Jobs are in-memory maps. MemorySaver dies on process restart. That is the 10× lie if I claim a durable queue. Would-do is wire Redis or Celery or any durable job store, and make /ready actually check Azure and Neo4j — docs call that a stub. I say the gap instead of fashion.”

Same LangGraph as DeepQuery?

“Same library family, different graphs, different stores, no web crawl. DeepQuery is plan-search-scrape-synthesize on the public web. This is ingest plus test-case on a document you already have. I do not open both as I used LangGraph in the same hour as if that were the invention.”

What happens if an embedding batch fails?

“embed_chunks_batch tries batches of 16, then one-by-one, then a zero-vector fallback. I say the fallback out loud: a zero vector is a retrieval defect I would watch, not a silent success. Azure upload is in batches of 100 into brd-documents. Dimensions must match 3072 on the index field.”

How do you know it works?

“LangSmith traces and spot-checked tests against the BRD. I do not have a labeled IR benchmark on the resume. Clause-ID hit rate is how I would measure hybrid versus vector-only. I did not ship that labeled set. Backbone here is committing on evals I actually have, not inventing recall to win the argument versus vector-only.”

Why two graphs instead of one mega-agent on the whole PDF?

“Ingest and test generation are different jobs with different side effects — Azure plus Neo4j writes versus read-plus-generate. One model on the whole PDF blows the window and mixes discovery with graph writes. asyncio.gather on the test graph is fan-out for generation, not Firecrawl. I would parallelize extract only with idempotent requirement IDs. I do not hang an IQVIA percent on a stakeholder demo where DOM truncation made the agent click the wrong zoom — that is a separate notes story: I raised DOM max chars and max elements 50 to 80.”

Team Horizon ERC

Feb–Jun 2024 · core software, not team lead · video + ZED, not the planner

Tell me about Team Horizon and what you owned.

“February to June 2024 I was core software on Team Horizon’s ROS2 Mars rover for the European Rover Challenge. We designed a vehicle with cameras, compute, navigation, and control. I did not own the rover and I was not team lead. I engineered a GStreamer pipeline so the operator had a real-time multi-feed POV — resume 60 FPS — instead of raw frames through the app. I integrated the ZED 2 stereo camera as environment input — resume 2M-plus point-cloud samples per second on a GPU-class laptop in that family — into RViz, Gazebo, and the navigation conversation. I did not implement the predictive planner, the full costmap, or a custom multi-sensor fusion architecture. We placed 17th of 80-plus on the resume. Public Horizon materials sometimes say about 18th and number one in India. I flag that. Resume also has plus 40% obstacle detection and minus 55% simulated collisions. I treat plus 40% as weak — compared to other video-feed tools in our notes, not an Argus mAP. We for the rover and the place. I for video and ZED.”

Did you build the planner or the costmap?

“No. I understand how downstream navigation uses perception. I did not own the predictive planner implementation and I did not own the full costmap. A costmap is a grid of traversal costs — lethal on obstacles, high nearby, low in free space. I will not invent a scoring function I did not write. If they ask me to walk planner optimizations, I stop. That work is not mine. I integrated ZED spatial information into that conversation so the stack had environment to consume.”

Why GStreamer instead of pushing raw frames?

“A remote vehicle is a media problem. GStreamer gives me stages I can tune separately: capture, encode, transmit, decode, display. A simple socket that dumps frames dies on the field when bandwidth or a decode stall hits. Multi-feed is how we gave a Mars-rover POV instead of one camera fighting the UI. If the operator saw delay I would look at encode and transmit first, not rewrite the navigator. I will not invent a ProtoBuf mesh or a Jetson benchmark I did not lock. Resume names GStreamer, ROS2, ZED 2.”

Defend 60 FPS and 2M-plus points per second.

“Sixty FPS is the resume pipeline claim for the operator POV — GStreamer versus other video-feed tools we compared in our notes, not a p95 I memorized, and not a resolution I will invent. 2M-plus is the ZED SDK point-cloud rate when the device is used with proper GPU-class compute in that family — I integrated the cloud; I did not author the device firmware. I will not upgrade either number into a study protocol. Stage-level capture-to-display latency is a would-do so 60 FPS has a definition I can point at.”

Defend plus 40% obstacle and minus 55% collision.

“Plus 40% obstacle is the weakest Horizon science. In our notes it is compared to other video-feed tools making environment scanning more usable for the stack, not a detector mAP like Argus 89%. Minus 55% is simulated collision risk on the resume — the rover is less likely to take a path it should not, given the spatial map feeding costmap. I did not write the planner that consumes that map. I will not lean on plus 40% the way I lean on 89% mAP. If they want a number I will walk, I walk GStreamer and ZED integration.”

17th or 18th? Were you the software lead?

“Resume says 17th of 80-plus. Public Team Horizon materials sometimes say about 18th globally and number one in India. I flag both. I do not pick a fight. I was core software, not team lead, not owner of the rover. Ownership on a competition rover meant the POV came up and ZED data reached the people who did own nav. Pairing on launch so the next software member can bring POV up — that is the Earth’s Best corner, not a mentee headcount I will invent.”

Did you implement sensor fusion and prediction?

“No. Conceptually a planner takes pose, kinematics, and environment, samples trajectories, scores collision and cost, picks a path. That is how I talk about what my perception feeds. I did not implement that algorithm. ZED already handles stereo depth and spatial mapping. I will not complete the story by claiming fusion weights I did not ship.”

Is this StratifyLabs?

“No. This is a field rover on a competition date. StratifyLabs is a browser computer-vision lab with a marketplace. Gazebo on Horizon is not WebGL on StratifyLabs. I do not import rover place into a SaaS metric.”

Argus PPE

Personal project · YOLOv9 · quality gate before 20+ cameras

Tell me about Argus.

“Argus is my industrial safety project — YOLOv9 PPE-compliance. I had a model that drew boxes at 73% mAP. That is a slideshow result. It is not a floor product. I did not ship it and I did not scale cameras on it. I went back to data and training on 15,000-plus images until I had 89% mAP at 24 FPS. Only after that gate did we Dockerize a multi-feed pipeline for 20-plus cameras, write structured detection events to Postgres, and alert. The resume’s pilot says recorded violations dropped 50% after alerts. I need the incident definition if you press that number. I for the detector gate and the refuse-to-ship. We once the feeds and alerts were a deployment. This is not a hackathon demo I will relabel as Amazon PPE policy.”

Why was 73% not shippable? Why not just collect more images?

“Floor safety. A miss is a person. Scaling 73% across 20 cameras multiplies misses and trains people to ignore alerts. More data can help, but data quality, class balance, labeling, and the error category all matter. I would investigate the dominant miss rather than assume dataset size alone was the solution. I do not have train-val split, epochs, or class-wise metrics memorized and I will not invent them. Haar cascades are not this resume story.”

Why 89% and 24 FPS before 20 cameras? Why one-stage YOLO?

“Quality and real-time are the gate. Width multiplies whatever I already shipped. One-stage YOLO was the throughput constraint — 24 FPS across many feeds versus a prettier clip on one recording. I do not invent a two-stage Detectron benchmark I did not run. TensorFlow is a skill. Resume detector is YOLOv9. OpenCV stays decode and resize. I do not claim Kubernetes. I claim containerized multi-feed after the gate.”

How does mAP relate to minus 50% violations? Why Postgres?

“mAP is the detector gate. Minus 50% is an operational pilot after alerts. I keep them separate. I need what counted as a violation if you press minus 50%. Postgres is so I can answer camera 7, Tuesday 18:04, no-helmet, box. Files without event rows cannot answer that. Video bytes do not live in the relational event table. Drop stale frames if a camera falls behind — I defend the 24 FPS budget, not a new FPS I invent.”

If Amazon’s miss budget is different from 89%, what do you do?

“I ask what miss is acceptable on that floor. I do not import 89% as Amazon’s PPE SLA. Would-do is class-wise precision and a held-out camera. If I already used Argus for Are Right this hour, I do not open Highest Standards with the same 73% sentence — I use gate-before-width or I switch project.”

GiftedBooks

Personal · giftedbooks.study · grounded PDF RAG + PYQ · not Aegis

Tell me about GiftedBooks. Who was the customer?

“I built GiftedBooks as a VR learning suite at giftedbooks.study. I — not a company intern. The student I designed for was stuck in a study loop: find what the exam actually uses, read it, get stuck, wait hours for a human. I did not start from put an LLM in VR. I split two jobs. One: the student uploads their PDF; I chunk and embed once with user and document metadata; at question time I retrieve a small scoped set and answer from those chunks. Resume API path is sub-300 milliseconds — that is retrieve-and-answer, not proof the derivation is faithful. Two: a PYQ topic-prioritization engine as deterministic analytics over past papers, not the model guessing the exam. Those sat inside 3D labs and avatars so the student stayed in one place. User testing we reported: doubts from hours to a 3–10 minute window, plus 35% reading, plus 50% engagement, 2.5× comprehension, 99.5% uptime. I do not invent sample size. The GitHub README on that repo currently describes AegisAI. Resume and the site win. I would fix the README. I do not import Aegis features into this story.”

Why not a generic ChatGPT wrapper? Walk a student question.

“A wrapper has no source of truth and no isolation. Trust is cite-or-abstain on the student’s own PDF. Student authenticates, uploads, ingest once. Question time: scoped top-k for that user and document, grounded answer. No cross-user retrieval. PYQ ranking is a separate deterministic path. Isolation is metadata on the vectors, not Ylogx SET ROLE. Azure Search is IQVIA. LangSmith is not on this resume. Skills-line FAISS is the smaller vector-plus-metadata lane — I do not invent a cluster.”

What does sub-300ms measure? What about 99.5%?

“Sub-300 milliseconds is the retrieve-and-answer API path, not faithfulness of a derivation. Latency is not quality. 99.5% is GiftedBooks serving. 99.9% is Ylogx. I keep them separate. Width of a hallucination is not a score I will dress as 99.5%. If they open GitHub and see AegisAI, Earn Trust is saying the README is wrong before they find it.”

What would you change if you rebuilt the customer loop?

“A citation eval I can point at, and I would fix the README the same week I ship. Too-small chunk loses a derivation; too-large misses latency and isolation. 10× PDFs per user: ingest-once and metadata isolation stay, bound top-k. Resume has no student headcount. I did not shard.”

StratifyLabs

Personal · stratifylabs.design · browser CV lab · −30% is iteration, not FPS

Tell me about StratifyLabs.

“I built StratifyLabs at stratifylabs.design as a browser computer-vision lab. I — personal product, not an intern. The pain was iteration: a notebook or a native simulator per person turns every small experiment into environment setup or a GPU queue. I put a 3D simulation lab in the browser with a URDF editor and WebGL. Small supported models infer in the tab so a camera move can be checked without a server round-trip. Resume: that cut ML iteration time 30% — iteration time, not FPS. I shipped a marketplace with 50-plus pretrained models and datasets so the next experiment starts from a catalog item, not a retrain. Gemini-powered RAG voice characters sit on current scene context. Big training stays off the click path. The current GitHub README looks like a Next.js scaffold. Resume and the site win. I would align the repo. I do not claim 50 GPUs or a user-growth number.”

Is 30% FPS? Does 50-plus mean GPUs?

“No and no. Thirty percent is ML iteration time versus notebook or native setup. Argus 24 FPS and Horizon 60 FPS own their frame-rate lines. Fifty-plus is marketplace catalog items — models and datasets — not GPUs. Why marketplace: reuse beats retrain for the next experiment. Drop the catalog and you have a toy lab. That is the Think Big corner.”

Why browser inference and simulation? Same as Horizon?

“Browser inference lowers experimentation friction. Simulation is cheaper than a real-world camera every iteration. Horizon is a field rover on an ERC date with GStreamer and ZED. This is a SaaS lab in a tab. Gazebo is not WebGL. I do not import rover 17th into StratifyLabs. Three.js is a skill; I defend URDF plus WebGL and the lab. Large models exhaust tab memory — they belong off the click path. I do not invent a WASM benchmark.”

Where does Gemini sit? Did this use Ylogx RLS?

“Voice characters with current scene and URDF context. Stale scene context makes the bot describe objects that no longer exist — would-do is pass the current scene graph and an eval I did not ship. The bot must not hallucinate objects or read another user’s dataset. Resume does not say Ylogx RLS shipped here. Isolation still matters. Deep RLS evidence stays on Ylogx. karyanode is a separate GitHub module and does not inherit these outcomes.”

Room discipline. If I hear myself mixing families, I reset: the question you asked is this path. Probes are the next details in the same pack — I throw that paragraph, I do not switch internships to look broader.

Optimization techniques — APIs, queries, pipelines

Ultra-detail for the technical grind. Every card is tagged Shipped (I built or the architecture does this in a tree I can open), Understand (honesty / docs-vs-code / resume hop vs this checkout), or Would-do (next mechanism, not a silent claim). Why → what changed → trade-off → how I would measure → the follow-up they ask → a 15-second line.

ConvBI / Ylogx — deepest

Product problem: operators who are not SQL experts still sit on shared warehouse facts. Three jobs at once — known KPI tiles, a custom report canvas, natural-language analysis — without one organizational tier reading another. Nest owns identity, RBAC, dashboards, query execution, reports, Tally upload, admin. FastAPI owns SQL proposal only. React is the SPA. Postgres is relational truth with RLS.

Browser (React SPA, CloudFront)
  ├─ GET /dashboards/*     → Nest fixed SQL  → JSON tiles     [no LLM]
  ├─ POST /queryDB/execute-query → Nest JOIN + LIMIT → canvas
  └─ POST /queryDB/chat-query
        → FastAPI ChatOpenAI gpt-4.1 temp 0 → SQLQueryAndDetails
        → Nest executeChatQuery
             SELECT-only trim → hasTableAccess → optional org injection
             → sequelize.query on req.dbTransaction AFTER SET ROLE
convbi-ai: SQLDatabase.get_table_info() + table_descriptions
           validate_and_sync_schema  |  never executes tenant SQL

Shipped

Deterministic dashboard GETs — no LLM on the tile hot path Shipped
  • Why. A KPI tile is a known aggregation. Putting ChatOpenAI on overview would add model time, non-determinism, and a failure class (bad SQL) to a path that should just return numbers. Resume family: 30 dashboards, +60% manual-reporting overhead, sub-210ms.
  • What the architecture does. DashboardsService holds hand-written SQL aggregations. Browser sends month/year query strings. Nest runs them on req.dbTransaction after SET ROLE. Response is JSON only. CloudFront serves the SPA; tile JSON still goes CloudFront → ALB → ECS, not as an edge object. Sequelize pool (max 20) borrows a connection per in-flight request.
  • What I did. I can walk the tile path and defend “no model on GET.” I do not claim I hand-wrote every one of the resume’s 30 tiles. This checkout’s controller registry is nine dashboard types; some are multi-page. Resume 30 tiles. If they open the registry I say nine types.
  • Trade-off. New KPI shapes need a deploy, not a prompt. That is the point. Flexibility lives on the report builder and the bot, not on the tile that finance opens every morning.
  • How I would measure. Server duration on the dashboard GET (LoggingInterceptor already wraps controller time; Sequelize benchmark: true can log SQL timing when SQL_LOGGING is on). I would want p50/p95 by route and month/year cardinality. I do not have that panel to quote. Resume sub-210ms is the number I am allowed to say. I do not invent a probe host.
  • Follow-up they ask. “Why not cache the dashboard JSON?” Because a cache key without role + organizationId is a tenant bug. I would not cache tiles until the key is tenant-safe. See would-do.

Spoken 15s. “Dashboards are deterministic GETs. No LLM. Pooled Postgres, JSON only, CloudFront for the SPA. Resume says sub-210ms. I will not put the model on that path to look modern.”

Chat path — propose in FastAPI, execute in Nest under SET ROLE Shipped
  • Why. Natural language needs a model. Tenant SQL must not run as the table owner. Owners bypass RLS unless FORCE — this generator does not emit FORCE. Isolation depends on not executing as owner.
  • What the architecture does. Nest executeChatQuery POSTs { query, options } to CHATBOT_API_URL (default https://chatbot.projas.in/chatbot). FastAPI SQLQueryAndDetailsExtractor uses ChatOpenAI(model="gpt-4.1", temperature=0) and a Pydantic SQLQueryAndDetails parser. Nest then executeRawSelectQuery on the same request’s dbTransaction. FastAPI never sees the JWT and never runs the warehouse SELECT as the caller.
  • What I did. I inherited the chatbot path after a teammate left (Ownership Y1). I own walking Nest execute + RLS + structured JSON into ElementRenderer. I am not claiming I wrote every prompt line on day one.
  • Trade-off. Two hops (Nest → sidecar → Nest → Postgres). Tile path stays one hop. If the sidecar is down, tiles still work; bot returns BAD_GATEWAY. Gunicorn timeout in the AI image is 180s — that is not a tile SLA.
  • How I would measure. Split logs I already emit: chatbot HTTP durationMs vs SQL durationMs vs total executeChatQuery time. Resume +65% is analyst productivity on the SQL-RAG story, not sidecar p95. I do not invent a LangSmith board on Ylogx.
  • Follow-up they ask. “Can the model SET ROLE?” No. The model returns SQL text. Nest binds the transaction that already has the role.

Spoken 15s. “The model proposes a SELECT and chart metadata. Nest executes it as the caller, on the request transaction, after SET ROLE. FastAPI never runs tenant SQL.”

convbi-ai reads schema; it does not execute tenant SQL Shipped
  • Why. If the sidecar executed as a privileged engine user, a fluent SELECT could dump another org. Schema context is cheap compared with that failure.
  • What the architecture does. SQLDatabase.get_table_info() feeds the prompt. validate_and_sync_schema diffs live info against config.table_descriptions and can auto-sync the config dict. Allow-list in include_tables: accounting_transaction, bs, cashflow_bank, cashflow_others, inventory_stk_masters, inventory_stk_vouchers, outstanding_payable, outstanding_receivable, pl, sales. Ten public fact tables. Not application tables.
  • Trade-off. Drift between prompt schema and warehouse still happens; the validator logs and can rewrite descriptions. Auto-sync is convenience, not a migration tool. A wrong column name still produces a failed SELECT that Nest catches and returns as an empty chart plus message.
  • How I would measure. Rate of executeChatQuery.sql.errorMeta vs successful row counts. Schema-validator log lines after a warehouse load. I do not have a labeled “SQL exact-match” eval on the resume.
  • Follow-up they ask. “Does the validator guarantee the SQL is right?” No. It keeps the prompt’s table map honest. Semantic correctness is still Nest + RLS + the operator’s eyes.

Spoken 15s. “The sidecar reads allow-listed schema through LangChain SQLDatabase and syncs descriptions. It returns SQL and chart fields. It does not execute the tenant query.”

SELECT-only trim, hasTableAccess, optional org injection Shipped
  • Why. A generated string is not a security control by itself. I need a cheap reject, an app-level table gate, and then Postgres RLS as the row gate.
  • What changed / what the code does. executeRawSelectQuery does sql.trim().toLowerCase() and rejects unless it startsWith('select'). A FROM/JOIN regex collects table names. Each name must pass hasTableAccess or HTTP 403. For non-SUPER_ADMIN, if the table has organizationId, Nest injects "alias"."organizationId" = '…' into WHERE (or before GROUP BY / ORDER BY / LIMIT). Then sequelize.query with QueryTypes.SELECT on dbTransaction.
  • Trade-off. Prefix check is not a parser. SELECT …; DELETE is a residual class if we ever stopped treating this as one statement. Regex table extract can miss exotic SQL. App org injection is belt-and-suspenders; isolation is still SET ROLE + policy USING. If a table has no organizationId column, injection no-ops and RLS must carry the row filter.
  • How I would measure. Count of executeRawSelectQuery.rejected and 403 table-restricted responses in CloudWatch-style ECS logs. Deny fixtures: ORG_A session asking for ORG_B returns zero rows (RLS), not “Postgres rejected.”
  • Follow-up they ask. “Is org injection the isolation?” No. JWT org is not a policy. SET ROLE exists because the Nest login is typically owner/privileged. App WHERE cannot save a RESET ROLE leak.

Spoken 15s. “I trim and require SELECT. I 403 tables the role cannot see. I may inject organizationId. Then I run on the SET ROLE transaction. The row filter is Postgres, not the prompt.”

Schema allow-list for the chatbot Shipped
  • Why. The model should not see user, role, policy, or chat-metadata tables. Those are application tables. Some of them are written via executeWithoutRLS after RESET ROLE on purpose. Mixing them into SQL-RAG is a leak class.
  • What changed. FastAPI include_tables is the ten fact tables above. Nest systemAccessibleTables / module registry decide what a role can query. Chat conversation rows are a different path.
  • Trade-off. A new warehouse table is invisible to the bot until it is allow-listed and described. That is slower than “dump information_schema.” It is the correct slowness.
  • How I would measure. Attempts to reference a non-listed table in generated SQL should fail at extract or at hasTableAccess — I would count those, not invent a precision score.
  • Follow-up they ask. “Why not pass the whole schema?” Prompt size, wrong-table joins, and application-table leakage.

Spoken 15s. “The bot only sees an allow-list of fact tables. Application tables stay off that prompt. A new table is a deliberate add, not a surprise.”

RLS — per-request transaction, fail-closed, finish-transaction Shipped
  • Why. Pooled connections reuse sessions. A process-wide SET ROLE leaks User A into User B. App WHERE cannot see which role the socket still holds.
  • What the architecture does. JwtMiddleware then RLSMiddleware. Open a Sequelize transaction. SET ROLE to the mapped db_role_name, or rls_no_access if missing (fail-closed — an earlier RESET ROLE path was a leak class). Transaction-local set_config for app.organizationId from the verified JWT. Tenant SQL uses req.dbTransaction. FinishTransactionMiddleware registers res.on('finish') before the handler; this snapshot commits on HTTP finish (docs sometimes say rollback-on-error — speak the file).
  • What I did. I implemented the request path and the CREATE POLICY generator in Nest. I did not check in a hand-written warehouse sales.sql. I was not the DBA who applied every GRANT by hand.
  • Trade-off. Every authenticated request holds a pool slot until finish. Slow handlers reduce concurrency. SUPER_ADMIN RESET ROLE is an explicit privilege, not “RLS everywhere.” Chat metadata CRUD uses executeWithoutRLS — I say that out loud.
  • How I would measure. Isolation is deny-fixture evidence, not a resume latency. Pool wait time vs max: 20 under load is a would-measure. No pool-wait SLA on the resume.
  • Follow-up they ask. “Why not FORCE ROW LEVEL SECURITY?” This generator does not emit FORCE. Isolation depends on not executing as owner. I do not claim FORCE in prod.

Spoken 15s. “Each request begins a transaction, SET ROLE to that user’s non-owner role or rls_no_access, and runs warehouse SQL there. I fail closed. I commit when the response finishes.”

Report builder + shared ElementRenderer Shipped
  • Why. Operators needed joins and charts without a second chart island for the bot. Two renderers diverge. Resume 40% faster report generation is the product-family number — I do not pin it on one prototype.
  • What changed. Pick tables → join type → columns → drop-zone aggregation/chart. Save is JSON report config. Chatbot returns structured fields: chartType, data, relevantColumns, axes, showChart. Same ElementRenderer draws it (isChatbotChart). This snapshot: Chart.js on that renderer; Recharts also in the package and on some predefined pages. Resume wording is Recharts. I do not pick a fake single library.
  • What I did. I proposed the structured contract and prototyped reuse (Invent Y4). FastAPI still only proposes. Nest still executes.
  • Trade-off. The renderer is only as good as the payload. A table with two metrics becomes showChart=false by prompt policy. Unknown chart types normalize toward bar in the architecture notes.
  • How I would measure. Time-to-first-chart for a join report vs a blank SQL workflow — that is the spirit of the 40% family. I do not have the study protocol on the resume. I will not invent N.
  • Follow-up they ask. “Did reuse fix the crash?” No. Crash was client-side aggregation of a large slice. Reuse is one drawing path. Different defect.

Spoken 15s. “The builder is pick, join, drop-zone. The bot returns the same shape of JSON. One ElementRenderer draws both. I did not buy a second chart world.”

Client aggregation crash — server/preload + click to load Shipped notes
  • Why. I put aggregation on the client. A large slice crashed the browser and made the agent path unstable. That was my defect. Cost was a tab, not a number I will mint.
  • What changed. Heavy aggregation moved to a server / preload path for the AI-requested report. Explicit click to load full data instead of stuffing the tab. Multi-chart generation stayed as data, not screenshots. I did not weaken RLS to make the chart easier.
  • Trade-off. An extra click. The default is no longer “dump the slice.” A hotfix that left aggregation on the client would have come back.
  • How I would measure. Tab crash rate and time-to-interactive after the click. I do not have row counts or a browser name locked. I say “large enough to crash the tab.”
  • Follow-up they ask. “Is this the 40% or the 99.9%?” No. Those are product-family resume numbers. This story is the defect class and the stay-fixed shape.

Spoken 15s. “I aggregated a large slice in the browser and crashed it. I moved heavy work to the server and required a click to load full data. I did not touch RLS to fix a UI bug.”

CloudFront + ECS + ALB + GitHub Actions Shipped
  • Why. SPA bytes and API JSON have different cache and health stories. Laptop deploys drift. Resume: led AWS deploy, 2× release time, 99.9% uptime.
  • What the architecture does. Frontend image: Node 20 build → nginx. Nest: Node 18 alpine, USER node, port 5000. FastAPI: Python 3.12, gunicorn 8 Uvicorn workers, port 80, timeout 180. convbi-qa.yml on push qa auto ECR → ECS. convbi-prod.yml on main plus a 3-minute manual approval, then ECS wait-for-service-stability. ALB health: Nest /health pings Postgres; /health/simple does not. Route 53 / CloudFront on the resume hop list.
  • What I did. Intern path included the Actions files and the task definition wiring. I do not invent war-room hours around the 3-minute approval.
  • Trade-off. Prod tag latest plus SHA is mutable-tag risk. Compose is local. Latex CodeBuild figures are not this checkout’s pipeline. Kubernetes is listed knowledge, not what shipped.
  • How I would measure. Resume 99.9% and 2× release. I do not invent outage minutes or a deploy-duration dashboard. Stability wait is the mechanism I can point at.
  • Follow-up they ask. “Why not Kubernetes?” Control-plane operations are not on the intern bullet. ECS matched one API, one SPA, one sidecar.

Spoken 15s. “I shipped Docker images through GitHub Actions to ECS behind an ALB. CloudFront holds the SPA. QA auto-deploys; prod waits for approval. I do not call that Kubernetes.”

LoggingInterceptor + generated-SQL logs (Y3 class) Shipped
  • Why. When a bot answer looks empty, the tidy belief is “the model hallucinated” or “the DB is empty.” Those are two different bugs. I needed the SQL string and the duration.
  • What the architecture does. Global LoggingInterceptor logs method, URL, user, duration. executeChatQuery logs chatbot duration, sql.generated, SQL duration, row count, and sql.errorMeta. Sequelize can log SQL when SQL_LOGGING is true. ECS logs land in CloudWatch as the AWS destination — I do not claim a Datadog board or a saved Insights query I will recite.
  • Trade-off. SQL text in logs is an operational secret class (org filters, business facts). Normalize/truncate helpers exist (SQL to 2000 chars). I would not paste a production SQL log in this room.
  • How I would measure. Correlation of empty-chart responses with failed SQL vs zero-row RLS. That is Dive Deep, not a new percent.
  • Follow-up they ask. “Did logging prove the −35%?” No. −35% is resume cache-aside. Logging is how I split model time from SQL time.

Spoken 15s. “I log the generated SQL and the two clocks — sidecar and execute. If the chart is empty I can tell failed SQL from RLS zero rows. I do not guess ‘the model hallucinated.’”

Understand — honesty, not a second resume

Resume Redis −35% vs this checkout’s fieldsCache Map Understand
  • Why this card exists. If they open package.json I will not point at ioredis. If they open the resume I will not pretend the Map is Redis.
  • What the resume hop is. Cache-aside on repeat bot questions so the warehouse is not hit again. Key must include role + organizationId, not query text alone, or a cached payload becomes another tier’s answer. On a miss, execution still runs as the caller with RLS. Resume: Redis reduced query latency by 35% on that bot-DB story.
  • What this Nest tree does. fieldsCache: Map, TTL 5 minutes, key fields:${tableName}, SHA1 etag of the field list. It caches dataset field metadata for the report builder, not dashboard JSON and not bot result rows. One process: 10 ECS tasks = 10 maps.
  • Trade-off. A process Map is simple and wrong for tenant-shared result cache. Redis is the shared hop I speak from the resume, not from this file.
  • How I would measure. Resume −35% is the allowed number for the Redis hop. I do not invent hit ratio or a TTL as a resume number beyond this 5-minute field cache.
  • Follow-up they ask. “Show me Redis.” I say “resume Redis hop versus this snapshot Map” and I walk the Map key.

Spoken 15s. “Minus 35% is resume Redis cache-aside on the bot path, and the key has to carry role and org. This Nest file caches table fields in a five-minute Map. I keep both sentences ready.”

FinishTransaction commits on finish; 30 tiles vs nine types; sub-210ms wording Understand
  • FinishTransaction. Docs: commit on OK, rollback on error. File: always tx.commit() on res.finish, rollback only if commit throws. I speak the file. Would-do: inspect statusCode.
  • Dashboard count. Resume 30 KPI dashboards. Controller: nine types, some multi-page. I do not hide the registry.
  • sub-210ms. resume.md currently says P95. I still will not invent how it was probed. Would-do is measure dashboard p95 properly.
  • Cookie MD vs Bearer. COOKIE_AUTH_IMPLEMENTATION_COMPLETE.md is not the running middleware.
  • Follow-up they ask. “Which is true?” The live file they opened, then the resume family number, then the gap.

Spoken 15s. “If you open the repo I speak the file — finish commits, nine dashboard types, Bearer JWT, a field Map. If you open the resume I speak Redis, 30 tiles, sub-210ms. I do not mash them into one sentence.”

Would-do — next mechanisms, not silent claims

Shared Redis with a tenant key; do not cache dashboards without tenant Would-do
  • Why. Repeat bot questions and field metadata should survive task replace. A cache without role + organizationId is a cross-tenant read.
  • What I would change. One Redis (or shared store) for bot-result and field caches. Key = hash(sql or question) + role + organizationId + schema generation. Dashboards stay uncached until that key exists. I would not cache a tile as sales:2024-01 alone.
  • Trade-off. Cache invalidation becomes a product. Stale KPI is a trust bug. I would rather miss and hit RLS than hit and leak.
  • How I would measure. Hit ratio and p95 of bot SQL time on cache hit vs miss — new measurements, not the resume −35% restated. Cross-tenant canary: User B must not receive User A’s payload.
  • Follow-up they ask. “Did you ship that key?” Resume Redis is the hop. This checkout’s Map key is table name only. I say the gap.

Spoken 15s. “I would put a shared Redis in front of repeat bot SQL, and the key would include role and org. I would not cache a dashboard until that key exists.”

Circuit breaker on FastAPI; invalidate on warehouse load; measure p95 tiles Would-do
  • Circuit breaker. Sidecar timeout / 5xx should open a breaker so Nest stops paying 180s per chat while tiles stay healthy. Fallback: message, no empty chart pretending to be data.
  • Invalidate on warehouse load. Tally zip → S3 → gateway is async. Field cache and any future Redis must drop when the load finishes, or the builder shows yesterday’s columns.
  • p95 dashboards. I would add route-level p95 on the deterministic GETs. That is a measurement I do not currently have as a defended study. I will not announce a new number in the room.
  • Other hygiene I already say if they grind. Secrets Manager instead of inline task-definition env. FinishTransaction rollback on non-2xx. Turn synchronize: true off in prod-shaped deploys. ALB must use /health, not /health/simple.
  • How I would measure. Breaker open rate, stale-schema incidents after ETL, dashboard p95 by route. No invented baselines.
  • Follow-up they ask. “Then why is 99.9% on the resume?” Serving path + Actions + health. Not a promise that every would-do is done.

Spoken 15s. “I would trip a breaker when the sidecar dies, bust cache when the warehouse loads, and actually measure dashboard p95. I am not claiming those panels exist today.”

IQVIA DeepQuery

Local CLI + artifact folders. Azure OpenAI. LangGraph state machine — not a chatty agent, not a hosted IQVIA SaaS. No IQVIA latency percent on the resume. Example strong run from saved artifacts: 857 URL pool → 120 filtered → about 137 pages. This workspace resume.md does not currently list IQVIA; I still walk the system if they ask the internship.

planner → light_search → clarifier → context_builder
       → query_generator (12–15) → search_fanout (DDGS + Bing + Firecrawl)
       → aggregator (URL dedup) → url_intelligence (cheap signals)
       → scrape_controller (waves, cap, MD5) → cross_page_reasoning
       → decision_engine (stop / search_new / next_wave)
       → synthesizer (report + confidence)
HITL: pre-clarify auto|hybrid|manual; refinement re-enters url_intelligence
URL intelligence before scrape Shipped
  • Why. Scrape is the expensive hop (Firecrawl + tokens). Search hits are cheap. Thinking after you have paid is how you get a bill I will not invent.
  • What changed. After aggregation, url_intelligence scores path (useless-route regex), domain trust, keyword overlap with the plan, per-domain cap, target count often in a 120–180 band. Only then scrape_controller takes unvisited filtered URLs.
  • Trade-off. A good page on an untrusted-looking domain can be dropped. Refinement HITL re-enters here if the analyst wants another wave. I do not put a human on every URL in an 857 pool.
  • How I would measure. filter_yield = filtered / all_urls. Example: 120/857. Pages that later become citations vs dropped domains. No IQVIA %.
  • Follow-up they ask. “Isn’t that just a denylist?” Path + domain + keyword + cap is a cheap ranker, not a legal blocklist I will oversell.

Spoken 15s. “I score URLs on path, domain trust, and keyword overlap before I pay for scrape. The pool can be hundreds. The scrape set is the chosen band.”

Concurrent fan-out, URL dedup, MD5 content dedup Shipped
  • Why. One engine misses. Sequential search multiplies wall clock. The same URL from DDGS and Bing is not two sources. The same markdown body on two URLs is not two facts.
  • What changed. Per query, parallel_search runs DDGS (thread pool), Bing HTML (httpx + BeautifulSoup), Firecrawl search if configured. Fan-out typical max_results_per_query=35. Aggregator dedups by URL and skips visited_urls. Scraper MD5-dedups markdown bodies.
  • Trade-off. Fan-out without a later filter is just a larger bill. Dedup can collapse mirrors that actually disagree — ranking/agreement still has to happen in reasoning.
  • How I would measure. Unique URLs vs raw hits; duplicate MD5 rate; facts per scraped page. Artifact folders already store the lists.
  • Follow-up they ask. “Why three engines?” Branch-local failure: a Playwright/Bing miss must not erase DDGS. LangGraph reducers append survivors.

Spoken 15s. “Each query fans out to DDGS, Bing, and Firecrawl. I dedup URLs, then I MD5 the markdown so I do not scrape the same article twice.”

Wave scrape, concurrency caps, char budgets, decision stop Shipped
  • Why. Unbounded scrape and unbounded context make a fluent, expensive, incomplete run.
  • What changed. Waves of wave_size (default 15), concurrent_workers (default 3) semaphore. Page body capped. Cross-page reasoning reads inside cross_page_char_budget. Decision engine hard-stops on completeness threshold, enough facts/pages, few gaps, or iteration_count >= max_iterations. Else it may search_new (up to 4 queries), follow_links, or next_wave.
  • Trade-off. Caps can stop before a niche source. That is preferred to a loop that sounds busy. HITL refinement is the escape hatch.
  • How I would measure. Iterations, pages, confidence, word count on metadata.json. I do not invent elapsed_seconds if the save omitted it (docs flag that gap).
  • Follow-up they ask. “Can it loop forever?” No. Max iterations is explicit. Otherwise it should stop or abstain, not keep paying.

Spoken 15s. “I scrape in waves with a worker cap, I truncate what the LLM may read, and the decision node has to stop on completeness or max iterations.”

857 → 120 as a cost bound; 0% confidence is synthesis parse Shipped Understand
  • Why. Breadth without a think hop is a crawler. A 0% file looks like retrieval death if I do not open the artifacts.
  • What the artifacts show. Strong run in the same family: 857 URLs → 120 filtered → ~137 pages, 99% confidence, long report. Weak runs: on the order of 236–256 words, 0% confidence, grade D, but facts and pages were still collected. That pattern matches synthesis JSON parse failure or a truncated save after scrape and reasoning succeeded.
  • Trade-off. Confidence in metadata is not retrieval quality. Blaming url_intelligence or Firecrawl would have been the wrong fix.
  • How I would measure. Parse-success rate of the synthesizer JSON separately from page count. I would not use 0% as a scrape KPI.
  • Follow-up they ask. “So retrieval died?” No. I open scraped_pages and facts.json before I believe the confidence field.

Spoken 15s. “A strong run went 857 URLs to 120 filtered to about 137 pages. A 0% confidence file can still have pages — that one was a synthesizer parse, not an empty web.”

IQVIA BRDprocessor — Hybrid RAG

Document intelligence, not web browse. Two graphs: 8-node ingest, 5-node test-case. Azure AI Search index brd-documents. Neo4j Document / Requirement / Entity / DEPENDS_ON. No labeled precision/recall set. Redis and Celery are in requirements and are not wired.

tiktoken 1500 / 200 so requirements do not split mid-sentence Shipped
  • Why. Clause IDs and “shall” sentences die if a chunk ends mid-requirement. Stuffing the PDF blows the useful window and cites the wrong annex.
  • What changed. RecursiveCharacterTextSplitter with length_function=count_tokens on cl100k_base. CHUNK_SIZE=1500, CHUNK_OVERLAP=200 (~13% overlap). Section/page metadata kept. Upload cap 100MB, PDF/DOCX only.
  • Trade-off. More chunks → more extraction calls. Overlap duplicates tokens on purpose. 100MB is a denial-of-service bound, not a quality SLA.
  • How I would measure. Chunk count vs tokens; rate of requirement IDs that span two chunks. I do not have a labeled split-error set.
  • Follow-up they ask. “Why not 512?” Rare clause IDs and tables need surrounding heading. 1500 is the configured Azure-document-sized choice in this tree, not a mystic number I will mystify.

Spoken 15s. “I chunk on tiktoken 1500 with 200 overlap so a requirement does not split mid-sentence, and I refuse a 100MB-plus upload.”

Hybrid BM25 + kNN + reranker vs vector-only; Neo4j 2-hop vs stuffing chunks Shipped
  • Why. Vector-only misses exact tokens like R-141 or REQ-1044. Stuffing 200+ pages is not retrieval. Dependencies are edges, not vibes.
  • What changed. Azure hybrid: BM25 on content plus vector kNN on 3072-dim embeddings plus semantic reranker. Neo4j get_requirement_graph_context walks DEPENDS_ON up to 2 hops, limit 50 paths. Test-case RAG uses hybrid_search plus that graph context — not “the model remembers the PDF.”
  • Trade-off. Two stores to keep consistent. Graph is only as good as extraction. FAISS was an alternative I did not ship here.
  • How I would measure. Clause-ID hit rate on a labeled set — I do not have that set. LangSmith is how we inspect, not a recall number.
  • Follow-up they ask. “Why not FAISS?” Listed skill. Internship evidence is Azure Hybrid + Semantic + GraphDB.

Spoken 15s. “I retrieve with BM25 and vectors and a reranker, then I walk two hops of DEPENDS_ON in Neo4j instead of stuffing every chunk into the prompt.”

Batch embed 16; extract-per-chunk is the cost driver; asyncio.gather on tests Shipped
  • Why. Embeddings batch. Requirement extraction is one LLM call per chunk — that dominates. Test cases can fan out.
  • What changed. embed_chunks_batch size 16; on batch failure, embed one-by-one; zero-vector fallback; 0.2s sleep between batches. Extract loops chunks in an outer batch of 10 but still calls the LLM sequentially per chunk. Test-case graph uses asyncio.gather (notes: batches of 3 concurrent on generation). Azure index upload batches 100.
  • Trade-off. Sequential extract is simpler and slower. Parallel extract would need tighter idempotent dedupe on requirement_id (already deduped).
  • How I would measure. Docs’ own accounting: 80 chunks ≈ 5 embed batches + 80 extracts + 1 analysis. I would time those stages separately. No IQVIA $.
  • Follow-up they ask. “Can you just embed faster?” Embed is not the driver. Extract is.

Spoken 15s. “I batch embeddings at 16. The cost driver is extracting requirements from every chunk. Test-case generation fans out with asyncio.gather.”

Redis/Celery in requirements — not connected Understand Would-do
  • Why the honesty. Jobs today are in-memory maps and FastAPI BackgroundTasks. A process restart loses status. Claiming Celery would last one follow-up.
  • What I would change. Wire a broker and a result backend so ingest and test jobs survive the API process. Keep LangGraph checkpoints out of “I have durable workflow” until they are durable.
  • Trade-off. Operational surface. In-memory was enough to demo the graphs. It is not a queue.
  • How I would measure. Job completion after a process bounce. I do not invent that I already have it.
  • Follow-up they ask. “Is this production multi-tenant SaaS?” It is an intern document pipeline with Azure and Neo4j. I do not grow a second personality.

Spoken 15s. “Redis and Celery are in the requirements file and they are not wired. Jobs live in memory. Wiring them is a would-do I will say out loud.”

Horizon — ERC rover

Core software member, not team lead. I owned video + ZED environment input. I did not own the predictive planner, the full costmap implementation, or a custom fusion stack. Resume 17th/80+; public materials sometimes ~18th and #1 India — flag, do not fight. +40% obstacle line is a weak definition versus other video-feed tools, not Argus-style mAP.

GStreamer stages independently tunable vs raw frames Shipped
  • Why. The operator needed a media pipeline — capture, encode, transmit, decode, display — not an application thread copying pixels. Resume 60 FPS on that pipe. Probe host, resolution, and which stage that 60 FPS is are not locked.
  • What changed. GStreamer on ROS2 so each stage can be tuned (bitrate, latency, caps) without rewriting the rover app. Multi-feed POV instead of one jammed framebuffer.
  • Trade-off. Pipeline complexity vs “it works on localhost.” Field networks punish a naive raw-frame socket.
  • How I would measure. Resume 60 FPS. I will not upgrade it to a p95. I would measure capture-to-display separately if we instrumented stages — I do not claim I have that trace.
  • Follow-up they ask. “Did you optimize the planner with this?” No. I will not absorb planner work I did not write.

Spoken 15s. “I used GStreamer so capture, encode, and transmit were stages I could tune, instead of shoving raw frames through the app. I did not write the planner.”

ZED SDK mapping as environment input, not custom fusion Shipped Understand
  • Why. The rover needed a spatial sense of terrain. Building a custom stereo stack was not the intern job I owned.
  • What changed. ZED 2 SDK point cloud — resume 2M+ samples/s — visualized in RViz/Gazebo and fed as environment input into the navigation conversation. Costmap / −55% simulated collisions is a team test-track result. I integrated perception. I did not implement custom sensor-fusion or the trajectory chooser.
  • Trade-off. Vendor SDK vs full ownership of depth. Field calibration still matters. I do not pretend I invented SLAM.
  • How I would measure. Cloud rate and whether navigation received a usable cloud. −55% stays on simulated test tracks. +40% I treat as weak.
  • Follow-up they ask. “Walk me through your fusion math.” I redirect to the SDK cloud and the integration boundary. I do not invent equations.

Spoken 15s. “I integrated the ZED 2 cloud as environment input to navigation. I did not write a custom fusion stack or the predictive planner.”

Argus

Industrial PPE. YOLOv9. Gate before width. Resume: 15,000+ images, 73% → 89% mAP, 24 FPS, then 20+ cameras, Postgres audit, pilot recorded violations −50% after alerts. I need the incident definition if they press −50%.

Do not scale cameras before 89% / 24 FPS; 15k+ vs ship 73% Shipped
  • Why. A 73% detector on 20 feeds multiplies misses and trains people to ignore alerts. Floor safety is not a demo GIF.
  • What changed. I refused to ship 73%. I iterated data/training to 15,000+ images until 89% mAP and still 24 FPS. Only then Dockerized multi-feed and Postgres event rows (camera, class, confidence, time, box) plus alerts. Video blobs do not live in Postgres.
  • Trade-off. Time-to-width vs a trusted alert. A heavier two-stage model can win a clip and lose camera 12. Threshold tweaks hide violations.
  • How I would measure. Held-out mAP and end-to-end FPS. Operational −50% is after alerts, a different metric. I do not invent class-wise precision.
  • Follow-up they ask. “Why not 95%?” Not on the resume. I do not claim it.

Spoken 15s. “I did not put a 73% model on twenty cameras. I held 89% mAP and 24 FPS, then I scaled feeds and logged events in Postgres.”

Docker multi-feed + Postgres alerts Shipped
  • Why. Safety needs an audit query, not a dashboard animation. Many cameras need the same image, not a laptop notebook.
  • What changed. Containerized pipeline, 20+ streams, structured events, alert after persist. I do not claim Kubernetes or detector sharding.
  • Trade-off. Event rows vs storing video in the database (backups die). Files without rows cannot answer “camera 7 at 18:04.”
  • How I would measure. Events per camera per hour; alert lag vs 24 FPS budget. No retention SLA on the resume.
  • Follow-up they ask. “Did Argus use Ylogx RLS?” No. Different product. Camera access still needs auth.

Spoken 15s. “After the gate I Dockerized multi-feed, wrote detection events to Postgres, and alerted from those rows — not from video in the database.”

StratifyLabs / GiftedBooks

Browser / WebGL inference cuts the server round-trip Shipped
  • Why. A notebook or GPU queue per experiment kills iteration. Resume: −30% ML iteration time (not FPS, not Argus 24 FPS).
  • What changed. Small supported models infer in the tab next to a WebGL / URDF scene. Heavy training stays off the click path. Marketplace of 50+ pretrained models and datasets so the next person does not retrain from zero.
  • Trade-off. Browser memory. Large models belong off the tab. A bot grounded in a stale scene describes objects that are gone.
  • How I would measure. Time from scene edit to a new detection — that is the 30% family. 50+ is catalog items, not 50 GPUs. StratifyLabs GitHub README is a Next.js scaffold; resume and stratifylabs.design win.
  • Follow-up they ask. “Is this Horizon Gazebo?” No. Horizon is a field rover. This is a browser CV lab.

Spoken 15s. “I run small inference in the browser so a scene change does not wait on a server GPU queue, and the marketplace is there so people reuse a model instead of retraining.”

GiftedBooks — PYQ ranking vs equal topics; retrieve vs unbounded LLM Shipped
  • Why. Students treat every chapter as equal until the exam punishes them. A generic tutor invents a syllabus. Whole-book prompts miss the sub-300ms retrieve path and mix editions.
  • What changed. PDF ingest once (chunk/embed, user+document metadata). Question time: scoped top-k, generate from those chunks. API path resume sub-300ms — retrieve-and-answer, not faithfulness proof. PYQ topic ranking is deterministic analytics over past papers, not an LLM predicting the exam. Isolation: no cross-user retrieval.
  • Trade-off. Latency is not citation quality. I do not claim LangSmith here. GitHub README currently describes AegisAI — resume and giftedbooks.study win.
  • How I would measure. Resume user-testing: doubts hours → 3–10 min, +35% reading, +50% engagement, 2.5× comprehension, 99.5% uptime. If they want N and protocol I say I will pull them — I do not invent them.
  • Follow-up they ask. “Why not LLM the PYQ too?” Because that presents speculation as a map of the paper.

Spoken 15s. “I retrieve from the student’s own PDF on a short API path, and I rank past-paper topics as analytics — I do not let the model invent the syllabus or run unbounded on every request.”

Project / technical question bank

For each project: a 90s spoken overview with an I/we line, architecture, decisions, challenges, scale, what I would improve, 6–8 questions I should be able to answer, 2–3 probes, and the three LPs this project is allowed to be primary on. Backup means a second story that hour, not a fourth trophy.

1. ConvBI / Ylogx — NestJS, React, FastAPI, Postgres RLS, AWS

90s spoken overview. “Ylogx, November 2024 to October 2025, I was an intern on a multi-tenant BI product — folders named ConvBI or Projas are that intern, not a second job. Operators needed KPI tiles, a report canvas, and a natural-language path over accounting tables without one org reading another. We split the runtimes. NestJS owns JWT, RBAC, dashboards, query execution, reports, Tally upload. I owned the request isolation path: per-request transaction, SET ROLE, fail-closed to rls_no_access, policies from a generator. React is the SPA on CloudFront. FastAPI only proposes SQL with LangChain and gpt-4.1 at temperature 0. Nest executes SELECT on that transaction after a trim check and hasTableAccess. I inherited the chatbot after a teammate left. I prototyped structured JSON so the bot reused the report builder’s ElementRenderer. I also sent a large slice through client aggregation and crashed the browser — I moved that to the server and a click-to-load. Resume family I will not dump in one breath: 40% faster reports, 99.9% uptime, SQL-RAG +65%, Redis −35% bot DB, 30 dashboards +60%, sub-210ms, three-tier RLS. Pick the number that belongs to the question. We for the product. I for RLS, the inherited bot path, the renderer, the crash.”

Architecture

[SPA CloudFront] --REST/JSON-- [Nest ECS :5000]
                                  |  Jwt → RLS tx SET ROLE → services
                                  |-- dashboards (fixed SQL)
                                  |-- queryDB (joins, chat execute)
                                  |-- reports JSON
                                  |-- fileUpload Tally → S3
                                  '-- chat CRUD (executeWithoutRLS)
                    POST /chatbot  [FastAPI ECS :80]
                                  LangChain SQLDatabase allow-list
                                  ChatOpenAI gpt-4.1 t=0
                                  never executes tenant SQL
                               [Postgres RLS + Sequelize pool 20]
  • Auth in this checkout: Bearer JWT, localStorage, refresh excluded from RLS middleware. Cookie MD is not the running file.
  • Warehouse facts on req.dbTransaction. Chat metadata may RESET ROLE.

Technical decisions + trade-offs

  • REST not GraphQL or Kafka — every browser feature is an HTTP resource; the sidecar is one POST.
  • Propose vs execute — Python parser + Nest transaction, not ChatOpenAI inside Nest as owner.
  • RLS in Postgres vs app WHERE only — a generated WHERE cannot survive RESET ROLE.
  • Deterministic tiles vs bot — model cost stays off the morning KPI path.
  • ECS vs Kubernetes — shipped orchestrator vs listed skill.
  • Sequelize vs Prisma — this tree is Sequelize. Resume skills also list Prisma; I do not rewrite the intern.

Challenges / debugging

  • Empty chart: log generated SQL — failed execute vs RLS zero rows vs no SQL returned.
  • Admin with no SYSTEM role: old RESET ROLE leak class → rls_no_access.
  • Client aggregation crash on a large slice.
  • Docs vs code: finish-transaction, port 3000 vs 5000, CodeBuild slide vs Actions, Redis vs Map.

Scalability

  • I did not shard Postgres. First limits: pool 20 vs RDS max_connections, indexes on filter columns, stop SELECT * on uncapped GETs.
  • 10× QPS holds a transaction until finish — pool tests before more tasks.
  • fieldsCache does not survive horizontal scale. Resume Redis is the shared-cache sentence.
  • I do not invent autoscaling policies or a multi-region active-active.

What I would improve

  • Shared Redis, tenant in the key; bust on warehouse load; no dashboard cache without tenant.
  • Circuit breaker on FastAPI; measure tile p95; rollback FinishTransaction on 5xx.
  • Secrets Manager; synchronize: false in prod-shaped deploys; CORS not * on the sidecar.
Likely technical questions
Walk a “revenue this quarter” chat request.

UI persists the user line on chat CRUD (RESET ROLE). POST /queryDB/chat-query. Nest fetches FastAPI. Extractor allow-lists sales, returns SELECT + chart fields. Nest SELECT-only, hasTableAccess, optional org injection, sequelize.query on the SET ROLE transaction. ElementRenderer draws. FastAPI never ran that SELECT as owner.

Why SET ROLE per transaction instead of one DB user?

The app login is typically owner/privileged; owners bypass RLS without FORCE. A pooled socket that still holds the last role leaks. Transaction-local SET ROLE + GUC from JWT, then commit/rollback, returns a clean connection.

How do you stop the model from writing another org?

The model never SET ROLEs. Nest executes as the caller. RLS USING on organizationId vs current_setting. App injection is extra. hasTableAccess is 403. Prefix SELECT is a cheap reject, not a full parser.

Redis −35% — where is it?

Resume cache-aside on the bot-DB hop; key must include role and org. This Nest snapshot: in-process Map, 5 minutes, fields:${tableName}. I say both.

Why no LLM on dashboards?

Tiles are known SQL. Model time and wrong-SQL risk do not belong on the path we quote as sub-210ms. The bot is the NL path.

How did you deploy?

GitHub Actions → ECR → ECS. QA auto. Prod approval 3 minutes. CloudFront SPA, ALB, Terminus /health. Resume 99.9% and 2× release. I do not invent incidents.

Is this LangGraph?

No. LangChain SQL-RAG. LangGraph is IQVIA.

Did you write every CREATE POLICY by hand?

I wrote the generator and the middleware. I will not recite a latex sales example as production SQL.

Probes

  • Open queryDB.service.ts: show the trim check, the Map key, and org injection — then say injection is not isolation.
  • ORG_A session, SQL that asks for ORG_B: zero rows, HTTP can still be 200. Permission denied is missing GRANT. 403 is hasTableAccess.
  • Which tables use executeWithoutRLS, and why warehouse facts must never ride that path.

LP mapping — allowed primary (at most three): Ownership, Frugality, Dive Deep. Invent can use ElementRenderer reuse if the hour is still on Ylogx and IQVIA Hybrid is unused. Highest Standards can use the crash or “LLM is not a security control” if Argus already filled the hour. Do not make ConvBI six trophies.

2. IQVIA DeepQuery

90s spoken overview. “IQVIA, April 2026 to present — current intern. DeepQuery is a LangGraph deep-research CLI I built, not a hosted product and not the BRD processor. An analyst gives a topic. I plan, do a light search so clarification is grounded, optionally ask the human auto/hybrid/manual, generate a bounded 12 to 15 queries, fan out to DDGS, Bing, and Firecrawl, dedup URLs, then I score URLs before I scrape. We often aim to keep the scrape set in a 120 to 180 band. I scrape in waves with a concurrency cap, reason across pages, and a decision node either stops or loops. I synthesize a long markdown report. A strong saved run went 857 URLs to 120 filtered to about 137 pages. Some 0% confidence files still had pages — that was synthesizer JSON parse, not empty retrieval. I do not have an IQVIA percent on the resume. This workspace resume.md does not currently list IQVIA; I still own the walk. I for the graph. Local CLI, Azure OpenAI.”

Architecture

CLI main.py
  pre-clarify graph → HITL
  full graph (resume_from context_builder | url_intelligence)
    planner → light_search → clarifier → context_builder
    query_generator → search_fanout → aggregator
    url_intelligence → scrape_controller → cross_page_reasoning
    decision_engine ⇄ fanout | scrape
    synthesizer → responses/<topic_ts>/ artifacts
Azure OpenAI HTTP client    Firecrawl    DDGS    Bing HTML
No vector DB   No multi-tenant SaaS

Technical decisions + trade-offs

  • LangGraph vs linear chain — parallel tools, retries, checkpoints, bounded cycles.
  • Filter before scrape — cost bound vs missing a long-tail domain.
  • HITL only at clarify and refine — not a human on 857 URLs.
  • Char budgets vs completeness — decision node must stop.

Challenges / debugging

  • 0% confidence with fat artifact folders → parse/save, not scrape.
  • One engine timeout must not erase the others.
  • elapsed_seconds may be missing from metadata — I do not invent wall clock.

Scalability

  • Caps: queries, URLs per domain, scrape count, waves, workers, iterations.
  • I did not operate a sharded research index. 10× topics is more runs, not a cluster I will invent.

What I would improve

  • Hardened synthesizer parse + retry so confidence cannot go 0% after a good scrape.
  • Cache completed scrapes by URL+content hash across runs.
  • Persist elapsed time honestly. Still local CLI unless they ask a product conversation — then I say it is not shipped as SaaS.
Likely technical questions
Why LangGraph?

Parallel search branches, reducers that append, a loop with a cap, and resume_from after HITL. A linear chain loses Bing when Playwright dies.

What is URL intelligence?

Cheap scoring before Firecrawl: useless paths, domain trust, keyword overlap, per-domain cap, target band.

How do you not scrape the internet?

Fan-out then filter. Example 857 → 120. Decision stop. Char budgets.

HITL where?

Pre-clarify modes and post-run refinement at url_intelligence. Not per URL.

0% confidence?

Open facts and pages first. Weak runs had pages and short reports — synthesis parse class.

Same as Hybrid RAG?

Same intern, different system. This browses the web. That indexes a BRD you already have.

Did you use LangSmith here?

LangSmith is on the IQVIA lock for inspectable runs. I do not invent a DeepQuery-hosted eval percent. Artifacts on disk are how I debug this CLI.

Ylogx chatbot also LangGraph?

No.

Probes

  • Draw the decision edges: stop / search_new / next_wave / follow_links.
  • Name what is in a run folder without inventing a cloud bucket.
  • What cheap signal would you add next — I do not invent a production spam-ML model I did not ship.

LP mapping — allowed primary: Learn and Be Curious. Second allowed if the hour stayed on IQVIA artifacts: Dive Deep (0% parse vs retrieval). Think Big (200+ sites / 857→120) is backup only — StratifyLabs is speak-first Think Big. Invent and Backbone belong to Hybrid RAG, not this card as a third trophy.

3. IQVIA BRDprocessor Hybrid RAG

90s spoken overview. “Same IQVIA intern, different system. QA and BA people upload a BRD — 200+ page class on the lock — and need requirements and test cases they can inspect. I built a FastAPI pipeline: extract text, chunk at 1500 tokens with 200 overlap on cl100k_base, embed at 3072 dimensions in batches of 16, write Azure AI Search index brd-documents, extract requirements per chunk — that extract is the cost driver — analyze relationships, persist Neo4j Document, Requirement, Entity, DEPENDS_ON. Retrieval is hybrid BM25 plus vector kNN plus semantic reranker plus a 2-hop Neo4j walk. Test-case generation is a separate 5-node graph with asyncio.gather, not the ingest graph wearing a hat. Redis and Celery appear in requirements and are not wired; jobs are in-memory maps. I say that. No labeled precision/recall. 100MB upload cap. I for the graphs I can walk. We if I am speaking IQVIA as a team.”

Architecture

POST /api/v1/documents/upload  ≤100MB PDF/DOCX
   → BackgroundTasks → IngestionGraph (8 nodes, MemorySaver)
        extract → chunk → embed(16) → Azure upload(100)
        extract reqs (per chunk) → analyze → Neo4j MERGE
POST test-case job → TestCaseGraph (5 nodes)
        load reqs → hybrid_search → graph 2-hop → generate (gather)
Stores: Azure brd-documents  |  Neo4j KG  |  RAM jobs

Technical decisions + trade-offs

  • Hybrid + reranker vs vector-only vs stuff-the-PDF.
  • Graph hops vs stuffing dependency chunks.
  • Two LangGraphs vs one mega-graph — ingest and tests are different jobs.
  • In-memory jobs vs Celery — honesty over fashion.

Challenges / debugging

  • Clause-ID miss on vector-only — the reason hybrid exists.
  • Extract-per-chunk latency vs embed batches.
  • Demo notes (separate story): DOM truncation made an agent click the wrong zoom — I raised DOM max chars and max elements 50→80. I do not hang an IQVIA percent on that demo.
  • LangSmith traces; I still will not quote recall I do not have.

Scalability

  • Chunk math: roughly ceil(T / (1500−200)). Extract scales with chunks, not pages.
  • Process bounce loses job maps — that is the 10× lie if I claim a queue.
  • Neo4j path cap 50; Azure upload 100. I did not shard.

What I would improve

  • Wire Redis/Celery or any durable job store.
  • A labeled clause-ID / dependency eval; keep LangSmith.
  • Parallelize extract only with idempotent requirement IDs.
  • Make /ready check Azure and Neo4j for real (docs: stub).
Likely technical questions
Why hybrid not FAISS-only?

Rare IDs are lexical. FAISS is a skill. Azure Hybrid + Semantic is what I shipped.

Why Neo4j 2-hop?

DEPENDS_ON is an edge. Stuffing all chunks loses the hop and blows context.

Chunking parameters?

tiktoken cl100k_base, 1500 / 200, so a shall-statement is less likely to split.

What costs money?

Per-chunk extraction, then test generation. Embed batch 16 is cheaper relative to that.

Is Redis in prod?

It is in requirements. It is not connected to routes.

Same graph as DeepQuery?

Same library family, different graphs, different stores, no web crawl.

How do you know it works?

Traces and spot-checked tests. I do not have a labeled IR benchmark on the resume.

100MB — why?

Upload abuse bound. Quality is chunking and retrieval, not the cap.

Probes

  • Write the USING of hybrid vs a 2-hop Cypher in one sentence each.
  • What happens if embed batch fails? One-by-one, then zero-vector fallback — I say the fallback is a retrieval defect I would watch.
  • Where does MemorySaver die? Process restart.

LP mapping — allowed primary: Invent and Simplify, Backbone, Dive Deep (hybrid vs vector-only + 2-hop + eval honesty). Learn is DeepQuery’s speak-first. Do not also open this as Learn in the same hour with the same “I used LangGraph” sentence.

4. Team Horizon ERC

90s spoken overview. “February to June 2024 I was core software on Team Horizon’s ROS2 Mars rover for the European Rover Challenge. We designed a vehicle with cameras, compute, navigation, and control. I did not own the rover and I was not team lead. I engineered a GStreamer pipeline so the operator had a real-time multi-feed POV — resume 60 FPS — instead of raw frames through the app. I integrated the ZED 2 stereo camera as environment input — resume 2M+ point-cloud samples per second — into RViz, Gazebo, and the navigation conversation. I did not implement the predictive planner, the full costmap, or custom sensor fusion. We placed 17th of 80+ on the resume. Public Horizon materials sometimes say about 18th and number one in India. I flag that. Resume also has +40% obstacle detection and −55% simulated collisions. I treat +40% as weak — compared to other video-feed tools in our notes, not an Argus mAP. We for the rover and the place. I for video and ZED.”

Architecture

Cameras → GStreamer [capture → encode → tx → decode → display]
ZED 2 SDK → point cloud / spatial map → RViz / Gazebo
          → environment input into team navigation / costmap
I did not write: predictive planner, full costmap, custom fusion
Jetson-class compute (team stack)   ROS2

Technical decisions + trade-offs

  • GStreamer vs raw frames — tunable stages vs a simple socket that dies on the field.
  • Vendor ZED mapping vs writing stereo from scratch — time-to-ERC vs full ownership of depth.
  • I vs we on planner — I keep the boundary even if it makes the story smaller.

Challenges / debugging

  • Field: pipe is only useful if the next software member can bring POV up — pairing story, not a mentee count.
  • Layers must agree: ROS2 frames, media timestamps, stereo cloud. That was the learning jump.
  • Place discrepancy 17 vs ~18 — I do not fight the interviewer.

Scalability

  • More cameras are more GStreamer branches, not a data-center story.
  • I do not claim Kubernetes on the rover. I do not claim I optimized a planner I did not write.

What I would improve

  • Stage-level latency (capture-to-display) so 60 FPS has a definition.
  • Align the public place with the resume source of record.
  • Document the pipe so launch pairing is not tribal knowledge.
Likely technical questions
Did you build the planner?

No. I integrated perception. I can talk about what a planner consumes. I did not own it.

Why GStreamer?

A remote vehicle is a media problem. Stages are independently tunable.

What is 60 FPS?

Resume pipeline claim. I will not upgrade it to p95 or invent resolution.

2M+ points/s — did you write that kernel?

ZED SDK rate. I integrated the cloud. I did not author the device firmware.

+40% — defend it.

Weak definition versus other video-feed tools. I will not lean on it like 89% mAP.

17th or 18th?

Resume 17th/80+. Public materials differ. I flag both.

Is this StratifyLabs?

No. Field rover vs browser CV lab.

UDP, Jetson, ProtoBuf?

I can talk about a low-latency media path as standard CS. I do not invent a ProtoBuf mesh or a Jetson benchmark I did not lock. Resume names GStreamer, ROS2, ZED 2.

Probes

  • Name the five GStreamer stages and which one you would turn first if the operator saw delay.
  • “Walk me through your planner optimizations” — I stop. That work is not mine.
  • Who brings the POV up if you are not in the tent? Pairing, not a mentee headcount.

LP mapping — allowed primary: Bias for Action, Deliver Results, Earth’s Best Employer. Ownership and Learn are backups (boundary; layers must agree). Do not absorb planner credit to make Deliver louder.

5. Argus — industrial PPE

90s spoken overview. “Argus is my industrial safety project — YOLOv9 PPE-compliance. I had a model that drew boxes at 73% mAP. That is a slideshow result. It is not a floor product. I did not ship it and I did not scale cameras on it. I went back to data and training on 15,000+ images until I had 89% mAP at 24 FPS. Only after that gate did we Dockerize a multi-feed pipeline for 20+ cameras, write structured detection events to Postgres, and alert. The resume’s pilot says recorded violations dropped 50% after alerts. I need the incident definition if you press that number. I vs we: I for the detector gate and the refuse-to-ship. We once the feeds and alerts were a deployment. This is not a hackathon demo I will relabel as Amazon PPE policy.”

Architecture

camera frame → OpenCV decode/resize
             → YOLOv9 one-stage boxes/classes
             → confidence filter → NMS
             → event {camera, class, confidence, timestamp, box}
             → Postgres → alert
video bytes  → not in the relational event table
Docker multi-feed  20+ streams after 89% / 24 FPS gate

Technical decisions + trade-offs

  • One-stage YOLO vs two-stage — 24 FPS across many feeds vs a prettier clip on one recording.
  • Quality gate then width — 73% times 20 cameras is alarm fatigue.
  • Postgres events vs video-in-DB vs files-only.
  • OpenCV stays decode/resize. TensorFlow is a skill; the resume detector is YOLOv9.

Challenges / debugging

  • Treating 73% as progress toward launch — that was the mistake I will own.
  • Lighting and PPE variation as data coverage, not “swap architecture first.”
  • NMS too aggressive can merge two nearby workers.
  • Public API README is unavailable — I do not invent route names.

Scalability

  • Width is camera count after the gate. I do not claim Kubernetes or detector sharding.
  • 10× retention: revisit indexes and media policy. No retention SLA on the resume.
  • Drop stale frames if a camera falls behind — I defend the 24 FPS budget, not a new FPS I invent.

What I would improve

  • Class-wise precision/recall and a held-out camera — not claimed as shipped.
  • Ask the floor what miss is acceptable; I do not import 89% as Amazon’s PPE SLA.
  • Keep media in object storage conceptually; I do not invent an Argus bucket name.
Likely technical questions
Why was 73% not shippable?

Floor safety. A miss is a person. Scaling 73% multiplies misses and trains people to ignore alerts.

Why 89% and 24 FPS before 20 cameras?

Quality and real-time are the gate. Width multiplies whatever I already shipped.

Why not Detectron / two-stage?

Throughput constraint. I do not invent a two-stage benchmark I did not run.

How does mAP relate to −50% violations?

mAP is the detector gate. −50% is an operational pilot after alerts. I keep them separate. I need the incident definition if you press −50%.

Did TensorFlow serve it?

TensorFlow is a skill. Resume claim is YOLOv9.

Did you use Haar cascades?

Not on this resume story. I do not invent a Haar baseline.

Kubernetes?

Containerized multi-feed. I do not claim a cluster I did not operate.

Why Postgres not files?

I need “camera 7, Tuesday 18:04, no-helmet, box.” Files without event rows cannot answer that.

Probes

  • If I already used Argus for Are Right this hour, Highest Standards must not open with the same 73% sentence — use the gate-before-width sentence or switch project.
  • What would you do if Amazon’s miss budget is different? I ask; I do not import 89%.
  • Draw detect → persist → notify and say where video lives.

LP mapping — allowed primary: Are Right, A Lot; Insist on the Highest Standards; Success and Scale. Are Right = I changed my mind about 73%. Standards = 89% and 24 FPS before width. Scale = cameras after the gate. Do not open both Are Right and Standards with the same first sentence in one hour.

6. GiftedBooks — VR learning / PDF RAG / PYQ

90s spoken overview. “I built GiftedBooks as a VR learning suite at giftedbooks.study. I — not a company intern. The student I designed for was stuck in a study loop: find what the exam actually uses, read it, get stuck, wait hours for a human. I did not start from ‘put an LLM in VR.’ I split two jobs. One: the student uploads their PDF; I chunk and embed once with user and document metadata; at question time I retrieve a small scoped set and answer from those chunks. Resume API path is sub-300ms — that is retrieve-and-answer, not proof the derivation is faithful. Two: a PYQ topic-prioritization engine as deterministic analytics over past papers, not the model guessing the exam. Those sat inside 3D labs and avatars so the student stayed in one place. User testing we reported: doubts from hours to a 3–10 minute window, +35% reading efficiency, +50% engagement, 2.5× comprehension, 99.5% uptime. I do not invent sample size. The GitHub README on that repo currently describes AegisAI. Resume and the site win. I would fix the README. I do not import Aegis features into this story.”

Architecture

student → auth → upload PDF
        → chunk / embed once → vectors + user/document metadata
question → scoped top-k → grounded answer  (resume sub-300ms API path)
PYQ papers → deterministic topic ranking   (separate path)
VR labs + avatars → one environment
Isolation: no cross-user retrieval
Vector lane: skills-line FAISS / vector+metadata — I do not invent a cluster
Not Azure Search (that is IQVIA)   Not LangSmith on this resume

Technical decisions + trade-offs

  • Grounded RAG vs generic ChatGPT wrapper — trust vs fluency.
  • Ingest once vs whole-book prompt every question — hits sub-300ms and isolation.
  • PYQ as analytics vs LLM syllabus prediction.
  • VR as place-you-stay vs VR as the product slogan.

Challenges / debugging

  • README mismatch with AegisAI — Earn Trust is saying it before they find it.
  • Too-small chunk loses a derivation; too-large misses latency and isolation.
  • Latency ≠ faithfulness. I say that if they treat sub-300ms as quality.

Scalability

  • 10× PDFs per user: ingest-once and metadata isolation stay. Bound top-k. I did not shard. Resume has no student headcount.
  • 99.5% is GiftedBooks. 99.9% is Ylogx. I keep them separate.

What I would improve

  • Citation eval / LangSmith-style traces — would-add, not did.
  • Fix the GitHub README.
  • Lock sample size and instrument for the user-testing percents so I can defend N.
Likely technical questions
GitHub says AegisAI?

README mismatch. Resume and giftedbooks.study are GiftedBooks. Aegis is a different personal-safety project. I would fix the README. I do not blend features.

Why not a generic tutor?

It does not hold the student’s edition. That spends trust.

Is PYQ inside the LLM?

No. Deterministic ranking over past papers.

Was the store FAISS?

FAISS is a listed skill and this is the vector-plus-metadata lane. I do not invent operations topology. Azure Search is IQVIA.

Did you run LangSmith?

No resume claim. Citation eval is a would-add.

sub-300ms — p95?

Resume API path. I do not invent percentile or probe host.

Which uptime?

GiftedBooks 99.5%. Ylogx 99.9%.

How is this different from Think Big GiftedBooks?

Customer is the 3–10 minute study loop. Think Big is the learning system only if this hour did not already spend GiftedBooks on Customer.

Probes

  • What happens if two students upload the same textbook? Metadata still scopes retrieval. I do not mix notes.
  • Show me the protocol behind +35% / +50% / 2.5×. I say I will pull N — I do not mint it.
  • Why VR at all? Place to stay, not the mechanism that collapsed doubt time.

LP mapping — allowed primary: Customer Obsession, Earn Trust, Think Big. Think Big only if Customer did not already spend GiftedBooks this hour — and even then the angle is “learning system,” not a second 3–10 minute recitation. Do not also use GiftedBooks for Invent if ElementRenderer or Hybrid RAG already filled it.

7. StratifyLabs — browser CV lab + marketplace

90s spoken overview. “I built StratifyLabs at stratifylabs.design as a browser computer-vision lab. I — personal product, not an intern. The pain was iteration: a notebook or a native simulator per person turns every small experiment into environment setup or a GPU queue. I put a 3D simulation lab in the browser with a URDF editor and WebGL. Small supported models infer in the tab so a camera move can be checked without a server round-trip. Resume: that cut ML iteration time 30% — iteration time, not FPS. I shipped a marketplace with 50+ pretrained models and datasets so the next experiment starts from a catalog item, not a retrain. Gemini-powered RAG voice characters sit on current scene context. Big training stays off the click path. The current GitHub README looks like a Next.js scaffold. Resume and the site win. I would align the repo. I do not claim 50 GPUs or a user-growth number.”

Architecture

Web client
  → WebGL scene + URDF editor
  → small browser inference → immediate iteration
  → marketplace catalog (50+ models / datasets)
  → Gemini voice bot grounded in current scene / URDF
heavy training → off the interactive request path
Not Horizon Gazebo   Not Ylogx RLS   Not Argus 24 FPS

Technical decisions + trade-offs

  • Browser inference vs notebook-per-user vs native-only lab.
  • Marketplace reuse vs everyone trains from scratch.
  • Scene-grounded Gemini vs a generic chatbot.
  • Three.js is a skill; the resume claim I defend is URDF + WebGL + the lab.

Challenges / debugging

  • Large models exhaust tab memory — they belong off the click path.
  • Stale scene context makes the bot describe objects that no longer exist.
  • README scaffold vs resume — same Earn Trust pattern as GiftedBooks.

Scalability

  • Grow the catalog. Keep only suitable small inference in the tab.
  • I do not invent cluster capacity, user count, or LangSmith usage.
  • karyanode is a separate GitHub module and does not inherit these outcomes.

What I would improve

  • Current-scene eval for the voice bots.
  • Align the repository README with the product.
  • User isolation — I state the need; I do not import Ylogx RLS as if it shipped here.
Likely technical questions
Is 30% FPS?

No. ML iteration time. Argus and Horizon own their frame-rate lines.

Does 50+ mean GPUs?

No. Marketplace catalog items.

Same as Horizon?

No. Browser SaaS lab vs ERC rover.

Did you use Three.js?

Skill. I defend URDF + WebGL and the 3D lab.

Did StratifyLabs use Ylogx RLS?

Resume does not say so. Isolation still matters. Deep RLS evidence stays on Ylogx.

Why marketplace?

Reuse beats retrain for the next experiment. That is the Think Big corner — drop it and you have a toy lab.

Where does Gemini sit?

Voice characters with current scene/URDF context. It must not hallucinate objects or read another user’s dataset.

README is a Next.js starter?

Yes, currently. Resume and stratifylabs.design win. I would fix the repo.

Probes

  • What happens if someone loads a huge detector in the tab? I move it off the click path. I do not invent a WASM benchmark.
  • How would you stop the bot answering last week’s scene? Pass current scene graph; add an eval I did not ship.
  • If Invent already used Hybrid RAG, this is Think Big, not a second “I reused a renderer” story.

LP mapping — allowed primary: Think Big. Invent and Simplify is allowed as a second only if IQVIA Hybrid RAG and Ylogx ElementRenderer were not already the Invent story this hour. Learn is backup (browser-inference curiosity), not a third trophy against DeepQuery.

8. Aegis AI — personal safety resume.md PDF flag

Which PDF. This workspace resume.md has Aegis AI: geofenced SOS, AI-optimized routing to nearest help centers and hospitals, real-time location tracking, 24/7 voice-to-report, 60% faster crime-report submission and 40% faster emergency-response initiation in simulated testing. ResumeWithSummarySep2026.pdf may omit the project — if they open that PDF I do not invent Aegis into the page. GiftedBooks GitHub currently describes AegisAI; that is a README mix-up, not proof the two products are one. I never blend GiftedBooks VR/PYQ into Aegis.

90s spoken overview. “I built Aegis AI as a personal-safety mobile app — I, not an intern team. The user is a person who needs to call for help and file what happened without losing minutes to a form. I shipped geofenced SOS alerts, routing toward nearby help centers and hospitals, and live location. I added a 24/7 voice-to-report path so the report is spoken rather than typed under stress. In simulated testing we reported report submission time down 60% and emergency-response initiation time down 40%. Those percents are simulated-testing results on resume.md. I do not invent a city deployment, a user count, or a live 911 integration I cannot walk. If your PDF does not list Aegis I will not force it.”

Architecture

mobile client
  → geofence / location stream
  → SOS trigger → notify configured path
  → routing toward nearest help / hospital  (resume: AI-optimized)
  → voice-to-report → structured report
simulated testing: −60% report submit, −40% response initiation
I do not invent: carrier integration, map-provider SLA, model id

Technical decisions + trade-offs

  • Voice-to-report vs a long form under stress.
  • Geofence SOS vs always-on recording — I do not claim a surveillance product.
  • On-device vs server routing — not locked; I will not mint a stack. If they grind, I say what is on resume.md and what is missing.

Challenges / debugging

  • Evidence is thinner than Ylogx or Argus. A Bar Raiser can empty this in two probes. I redirect to a deeper project if they want mechanisms.
  • README collision with GiftedBooks — I say it first.
  • 60% / 40% are simulated testing. I do not upgrade them to a city pilot.

Scalability

  • Not locked: shard, queue, map QPS. I do not invent them.
  • Safety products fail closed on location permission and false SOS — I can discuss as standard CS, not as a shipped SLA.

What I would improve

  • Lock the stack (maps, voice STT, geofence implementation) so this card can survive a deep dive — or drop Aegis from the spoken hour if the PDF they hold omits it.
  • Separate the GitHub README from GiftedBooks.
  • Keep simulated-testing language every time I say 60% / 40%.
Likely technical questions
What did you actually build?

A mobile safety app with geofenced SOS, routing to help/hospitals, live location, and voice-to-report. Details beyond resume.md are not locked.

60% and 40% — production?

Simulated testing on resume.md. I do not say a city deployed it.

Which map / which model?

Not on the resume. I will not invent Google vs Mapbox or a model id.

Is this GiftedBooks?

No. README collision on the GiftedBooks repo. Different product.

Why is this weaker than Argus?

Argus has a detector gate I can walk. Aegis has product bullets and simulated percents. I do not rank internships; I will say this project has less mechanism lock.

Did you use Ylogx RLS?

No. Location data still needs auth and least privilege. I do not import Nest RLS.

Your summary PDF omitted this?

Then I follow that PDF. I do not recite Aegis from memory against a page that dropped it unless they ask from GitHub.

False SOS?

Standard CS: confirm step, cooldown, audit. I do not invent that I shipped a specific confirm UX unless I lock it later.

Probes

  • They open ResumeWithSummary and Aegis is gone — I do not volunteer the md-only percents.
  • They open GiftedBooks GitHub — I separate the products immediately.
  • They ask for a sequence diagram with provider names — I stop at resume nouns.

LP mapping — not speak-first on the 8-LP spread. Allowed only as a backup if they pull personal safety: Customer Obsession (person in the SOS loop) or Bias for Action (ship a narrow SOS path). Do not use Aegis as primary for Deliver Results (Horizon 17th owns that) or Highest Standards (Argus owns that). If the hour already used GiftedBooks for Customer, do not also open Aegis as Customer.

9. Hackathons gap — one concrete story not locked

What is locked. Resume achievements: 8 national and regional hackathons. Named placements: CodeRecet 1st, MLH Best Project, Magnathon 2.0 runner-up (IEEE). IEDC Tech Team member is a different card — pairing, not these prizes as a coaching program.

Gap — mark it. I do not have a locked technical walk for even one of those eight: not the problem statement, not the stack, not a decision, not a metric, not a teammate name. I will not invent a CodeRecet architecture in the room. If they ask “tell me about a hackathon,” I give placements in one sentence and either (a) ask to use a locked project with the same flavor or (b) say I need to lock one concrete before I deep-dive. Inventing a weekend stack is how I fail Earn Trust.

90s spoken overview — honest, short. “Across campus I competed in eight national and regional hackathons. The named results on my resume are first at CodeRecet, Best Project at Major League Hacking, and runner-up at Magnathon 2.0 with IEEE. Those are my placements. I will not convert them into a mentee program and I will not invent a product walk I have not locked. If you want a weekend-speed decision I can speak Horizon’s ERC date — we fused on sensors we had — or Argus refusing to ship 73%. If you want Customer from a student product, GiftedBooks is locked. I owe myself one concrete hackathon memo; I do not have it in this book today.”

Architecture

LOCKED:   8 hackathons | CodeRecet 1st | MLH Best Project | Magnathon 2.0 runner-up
NOT LOCKED: problem, repo, stack, role split, demo URL, metric, teammate names
DO NOT DRAW a fake architecture box

Technical decisions + trade-offs

  • None locked. Decision I will make in the room: do not fabricate.
  • Bias for Action on the lock is Horizon ERC date, not “we won because we hacked harder.”

Challenges / debugging

  • The challenge is the gap itself. A Bar Raiser who says “walk me through CodeRecet” should hear the gap in ten seconds, then a redirect.

Scalability

  • Not applicable. I do not scale a story I did not write.

What I would improve

  • Before the hour: lock one concrete — CodeRecet preferred because it is 1st — problem, my modules, one decision, one failure, no new percent unless it is already on a certificate I can show.
  • Keep IEDC pairing separate. Keep the eight placements as results, not coaching.
Likely technical questions
Walk me through CodeRecet.

I can say I placed first. I do not have the technical lock in this book. I will not invent the stack. I can switch to a locked project or I can come back when I have written that memo.

What did you build for MLH Best Project?

Name is locked. Mechanism is not. Same honesty.

Did you coach those teams?

Those are my placements. I will not convert them into a coaching program. Hire and Develop is IEDC Tech Team member pairing — no mentee count.

Is Argus a hackathon?

Argus is a project with a detector gate. I will not call 73% a hackathon-quality ship.

Bias for Action — hackathons?

Backup only. Speak-first Bias is Horizon: ERC date, fusion on sensors we had.

Eight is a lot — unfocused?

They are campus results, not eight internships. I do not stack them in a spoken STAR with Ylogx and IQVIA.

Can you name a teammate?

I will not invent names.

Any metric from a hackathon?

Placements only. No invented users or latency.

Probes

  • They pick one prize and stay there — I repeat the gap; I redirect.
  • They try to use hackathons as Hire and Develop — I refuse the conversion.
  • After I lock a memo, I replace this card; I do not silently grow details here.

LP mapping — allowed primary: none until a concrete is locked. Backup only: Bias for Action (second story after Horizon). Do not use as Hire and Develop, Deliver Results (Horizon 17th), or Invent. Earth’s Best / IEDC pairing stays off this list.

Same-hour project hygiene
  • One project per spoken STAR. Timeline if they ask dates: Horizon Feb–Jun 2024 → Ylogx Nov 2024–Oct 2025 → IQVIA Apr 2026–present.
  • Ylogx primaries: Ownership, Frugality, Dive Deep. IQVIA: Learn on DeepQuery; Invent + Backbone on Hybrid RAG. Argus: Are Right, Standards, Scale. Horizon: Bias, Deliver, Earth’s Best. GiftedBooks: Customer, Earn Trust. StratifyLabs: Think Big.
  • Aegis only from resume.md (or a PDF that still lists it). Hackathons are placements plus a gap.
  • Java is Live Code. ECS shipped. Kubernetes / GraphQL / Auth0 / FAISS are listed-vs-evidenced — see stack why.

Claude companion — not the locked bank

Amazon LP — Full Follow-Up Drill (all 16 principles)

Written by Claude as an interrogation companion. Wording below is Claude’s. Do not treat it as a shipped-fact lock. If it conflicts with the locked STAR above, the locked bank wins. Makeup / hypothetical lines stay makeup.

1. Customer Obsession Claude

Primary — Y7: Ylogx client review cycles Claude primary

STAR (Claude) — ConvBI went through recurring biweekly client demo/review cycles rather than a fixed upfront spec; client developers were embedded in parts of the Tally-ERP-to-RDS workflow. I treated that recurring feedback as the actual product signal — translating friction into engineering changes (like the structured chatbot response contract) rather than isolated UI patches, and using demos to validate direction before deep implementation.

Follow-up 1 — "Give me one specific piece of feedback that changed your design."
  1. The recurring signal wasn't one sentence — it was repeated friction around turning raw data into an actual answer, not a single quoted request.
  2. That signal is what pushed the team toward a structured response contract (chart type, data, axes, period) instead of a plain-text chatbot.
  3. I'd rather describe the underlying pattern honestly than invent a specific meeting I don't remember verbatim.
  4. The biweekly cadence means feedback accumulated across iterations, not a single "aha" moment I could dramatize.
  5. If pressed for one artifact: the shift from raw-row chatbot output to renderer-backed charts is the most concrete, traceable example I can point to.
Follow-up 2 — "How did you know the client actually needed this, versus you assuming it?"
  1. Client-side developers had direct visibility into the Tally-to-RDS operational workflow, so their friction was observed, not guessed.
  2. Demos before deep implementation acted as an early falsifiability check — wrong direction got caught before a full build.
  3. The product's three surfaces (reports, chatbot, dashboards) map directly onto three manual tasks they were already doing by hand.
  4. Repeated requests for "analysis," not just "data," is a pattern, not a one-off preference.
  5. I don't have a satisfaction score or NPS number to cite — I'd say that directly rather than invent one.
Follow-up 3 — "What did you do when the client disliked something you built?"
  1. Treated it as signal, not failure — the whole point of iterative dev→QA→client review→handoff.
  2. Separated requirement-level feedback (what to build) from implementation-level feedback (how it behaves) before reacting.
  3. Kept the architecture flexible on purpose (the structured response contract) so a client-driven change didn't force a rewrite.
  4. Iteration cycle absorbed correction without destabilizing already-shipped features — nothing had to be torn out.
  5. Would document the trade-off and either adjust immediately or explicitly defer to the next cycle, not silently drop it.
Follow-up 4 — "What was the actual customer-experienced outcome, separate from your internal metrics?"
  1. The 40%/65%/60% resume figures are internal proxies for one underlying customer outcome: less manual work per report or answer.
  2. I'd keep customer-experienced time savings and backend-measured latency as two different claims, not conflate them.
  3. Client demos were the checkpoint for "is this actually useful," separate from "does this technically work."
  4. The real customer outcome is fewer people needed in the loop to reach an answer — from "find someone who knows SQL" to "ask a question."
  5. I don't have a customer satisfaction number to defend beyond that qualitative shift, and I'd say so rather than invent one.
Follow-up 5 — "If a client request conflicted with good engineering practice, what would you do?"
  1. Translate the literal request into its underlying workflow need first, rather than build exactly what was asked verbatim.
  2. Fit the change into the existing architecture rather than bolt on a one-off patch, per the same principle used elsewhere.
  3. Use a working prototype to make trade-offs concrete instead of arguing abstractly — same technique as the renderer decision (Y4).
  4. Security/RLS boundaries stay non-negotiable regardless of a feature request — I would not quietly weaken them to satisfy a deadline.
  5. Escalate and discuss the trade-off explicitly rather than silently pick a side on the client's or the engineering team's behalf.
Backup 1 — S2: GiftedBooks (PDF-RAG + PYQ prioritization) Claude backup

STAR (Claude) — Students needed faster access to relevant material and answers rather than equal-weight coverage of every topic. I built a RAG assistant over uploaded PDFs and used previous-year-question analysis to prioritize what was likely to matter, rather than adding another generic chatbot beside a textbook. Reported outcomes: sub-300ms APIs, ~35% reading-efficiency improvement, ~50% engagement improvement, ~2.5× faster comprehension, doubt resolution down from hours to 3–10 minutes.

How did you know students needed this?

The product targeted the actual learning workflow — find material, understand it, resolve doubts — not a generic assistant bolted onto existing content.

What was the user-testing methodology?

I don't have the exact sample size or study design memorized; I'd call these observed outcomes rather than a controlled study.

Why PYQ analysis specifically?

It's a real, low-cost signal for topic importance that doesn't require guessing — past exam patterns are actual evidence of what matters.

What if the RAG assistant gave a wrong answer?

That's a real risk with any RAG system; I don't have a documented correction/feedback loop for this project to point to specifically.

Backup 2 — C1: Freelance/client work (subscription Discord bot) Claude backup

STAR (Claude) — Built apps, CMS, CRM, and a subscription-gated Discord automation bot for freelance clients. Learned that correctness is customer experience: a bot that correctly grants access on payment but fails to revoke it on cancellation is technically functional but operationally wrong for the client's business.

What did the customer actually care about?

The workflow outcome — did revocation actually happen — not the implementation detail of how access was granted.

How did you catch the access-revocation issue?

I'd need to recall the specific client project's exact bug before defending a detailed root-cause story here — flagging this as a gap to firm up before using it live.

Would this generalize to enterprise clients?

The lesson (test both directions of a state transition, not just the happy path) generalizes; the specific implementation was small-scale freelance work.

What would you change about how you gather requirements from freelance clients?

Ask explicitly about failure/edge-case behavior (cancellation, refunds, disputes) up front rather than only the happy-path feature request.

Backup 3 — I1/I2: IQVIA's "customer" is an internal user, not an external client Claude backup

STAR (Claude) — Both IQVIA systems are explicitly built around a named user role — DeepQuery serves a researcher asking an open-ended topic; BRDprocessor's system-context diagram names the user directly as "QA/BA user" uploading a BRD and requesting test cases. Design decisions (URL filtering before scrape, hybrid retrieval before test generation) exist specifically to get that user a usable, evidence-grounded answer without them doing the discovery/filtering work manually.

How is an internal tool 'customer obsessed'?

The QA/BA user is the customer of that system — the same discipline (don't waste their time, don't give them noise) applies whether the user is external or internal.

What's the evidence you designed for that user, not just for the model?

Confidence scoring and source citation exist so the user doesn't have to blindly trust the output — that's a user-trust design choice, not a modeling convenience.

What happens when the system produces a low-quality result for that user?

Documented failure mode: two of twelve benchmarked DeepQuery runs graded D with 0% confidence — I can name that honestly rather than claim the system never fails.

Did you talk to an actual QA/BA user?

I don't have a documented user-interview process for this system to point to — I'd say that directly rather than invent one.

2. Ownership Claude

Primary — Y1: Inherited SQL-RAG chatbot Claude primary

STAR (Claude) — At Ylogx, ownership of an important SQL-RAG chatbot became a gap after the teammate who built it left. Rather than wait for reassignment, I reproduced the system locally, traced the entire request path (LangChain state, prompt construction, schema lookup, SQL generation, backend execution, response), and added logging at each service boundary before changing anything — then stabilized it by resolving the data: null failure class, fixing a Postgres/MySQL SQL-generation mismatch, and adding validation around AI output.

Follow-up 1 — "Why did you take responsibility for something that wasn't assigned to you?"
  1. The product still depended on the service working, regardless of whose name was on the ticket.
  2. Waiting for a formal reassignment would have only extended the dependency gap, not shortened it.
  3. I judged that understanding the system myself was the fastest path to reducing risk, not the safest path for me personally.
  4. Ownership here meant learning the whole path before touching anything — not immediately rewriting what I didn't yet understand.
  5. Nobody told me to do this; I identified the gap and closed it because it mattered to what the team was shipping.
Follow-up 2 — "What didn't you know when you started, and how did that show?"
  1. I didn't initially understand how the LangChain state, prompt construction, schema lookup, and final response were actually connected end to end.
  2. My first debugging instinct could have been "the model hallucinated" — tracing the pipeline showed some failures were state-formatting bugs, not model errors.
  3. I built a request-path mental map through reproduction and logging, rather than reading every library's documentation in isolation first.
  4. I added logging specifically at service boundaries, because that's where information was actually getting lost or transformed incorrectly.
  5. I'm honest that I don't have the exact ramp-up timeframe (days vs. weeks) memorized precisely enough to state a number.
Follow-up 3 — "What's the difference between what you owned and what the team owned?"
  1. I owned chatbot stabilization, the structured-response/rendering design, and the RLS/RBAC security layer specifically.
  2. The broader product — report builder UI, full dashboard suite, Tally ingestion pipeline, AWS infrastructure — was team scope, not solely mine.
  3. I'd separate personal technical ownership from product-level resume metrics (40%/65%/60%) which reflect the whole team's output.
  4. When asked "did you build all of this," the honest answer is no — and I'd rather say that than let an inflated claim get caught later.
  5. Ownership of a security boundary specifically means I treated it as my responsibility even though I wasn't a named security team member.
Follow-up 4 — "What would you have done if you couldn't fix the chatbot in a reasonable time?"
  1. I'd escalate with a clear diagnosis — here's what's broken, here's what I've ruled out — rather than stay silent while stuck.
  2. I would not have pretended the system was stable if it wasn't, even under time pressure.
  3. Reproducing and logging first meant I had evidence to show, not just a claim that "it's hard."
  4. I'd separate "I don't understand this yet" from "this is unsolvable" before escalating either way.
  5. I don't have a specific instance where I had to escalate rather than solve it myself on this project — I'd say that honestly if asked for one.
Follow-up 5 — "Tell me about a time ownership of something led to a mistake you had to own up to."
  1. This is one of the four real gaps I haven't filled with a genuine personal incident yet — I would not invent one live in an interview.
  2. What I can defend precisely instead: the RESET-ROLE fallback pattern in the RLS middleware was an earlier design that leaked and was replaced with a fail-closed no-access role — a system-level mistake-and-fix I understand in full technical detail.
  3. I can distinguish "a mistake in a system I inherited and fixed" from "a mistake I personally introduced" — and I'd be explicit about which one I'm describing.
  4. If pushed for a personal mistake, I'd rather say "I don't have one ready that I'm confident defending in full detail" than manufacture one under pressure.
  5. This is explicitly flagged in my own prep as something to bring a real, specific incident to before the interview — not a gap I'd try to paper over live.
Backup 1 — Y5: RLS/RBAC security ownership Claude backup

STAR (Claude) — A shared multi-tenant warehouse meant incorrect authorization could expose another organization's data. I treated the security boundary as my responsibility rather than assume the AI layer or someone else would enforce it — implementing per-request Postgres transactions with non-owner role switching, JWT-sourced session variables, and fail-closed access for unmapped users.

Why is this Ownership and not just 'security work'?

I chose to make isolation deterministic at the database layer instead of trusting application-level filtering or the LLM — that's a proactive ownership decision, not an assigned security-team task.

Did anyone ask you to build it this way?

I don't have a documented mandate to point to; this was a design decision I made and can fully defend technically.

What's the worst-case failure if this design were wrong?

Cross-tenant data exposure — which is exactly why I fail closed (no mapped role → no access) rather than fail open.

Who verified this was actually secure?

I don't have a formal pen-test or third-party audit to cite — I'd say that honestly rather than claim one.

Backup 2 — Y9: Git conflicts → branch discipline Claude backup

STAR (Claude) — During development, multiple interns modifying related code produced repeated merge conflicts. I proposed and moved toward clearer branch separation and deliberate merging instead of continuing to resolve conflicts ad hoc in one shared branch.

Why was this your problem to fix?

I was directly affected by the friction and had a concrete process improvement to offer, so I proposed it rather than just complain about it.

Did you blame the other developers?

No — I framed it as a workflow gap, not a people problem, which is also why the fix stuck.

What would you do differently on a larger team?

Establish branch conventions, smaller PRs, and CI checks earlier, before conflicts accumulate.

What's the exact branch strategy you proposed?

I don't have the exact branch names or conflict specifics memorized precisely enough to walk through verbatim.

Backup 3 — H2: ZED-2 perception ownership boundary Claude backup

STAR (Claude) — On Team Horizon's Mars rover, my primary ownership was the real-time video pipeline and ZED-2-based environmental perception feeding the navigation/costmap pipeline — explicitly not the predictive planner or the full costmap implementation, which other team members owned.

Did you build the whole rover?

No, directly — my ownership was perception and video; I'd rather state that boundary up front than have a follow-up expose it.

Why draw that line so precisely?

Because claiming ownership I didn't have would collapse the moment they asked a planner-specific technical question.

What did you do when your perception output didn't match what the navigation team needed?

I don't have a specific documented incident here to walk through in full detail — this is exactly the kind of "actual incident" I still need to bring a real memory to.

Is owning 'part' of a system still Ownership in Amazon's sense?

Yes — Amazon's definition is about acting on behalf of the whole outcome within your scope, not claiming credit for scope you didn't own.

3. Invent and Simplify Claude

Primary — Y4: Reusing the ElementRenderer for chatbot charts Claude primary

STAR (Claude) — The chatbot needed to present results as charts and tables, not raw text. I designed a structured response contract (chart type, data, axes, metrics, date range) and proposed reusing the report builder's existing ElementRenderer instead of building a second visualization system — proving it with a working prototype rather than arguing for it abstractly.

Follow-up 1 — "Why not just build a purpose-built chatbot chart component?"
  1. A second renderer means two implementations to keep behaviorally consistent, tested, and maintained going forward.
  2. The existing renderer already solved most of the rendering problem — the only new work was the contract that fed it.
  3. I checked the data contracts were actually compatible before proposing reuse, rather than forcing an awkward fit.
  4. Reuse reduces the chatbot's own surface area of things that can break independently of the report builder.
  5. If the contracts hadn't been compatible, I'd have built a separate component — reuse was the right call here specifically, not a default preference.
Follow-up 2 — "What exactly is in the structured response contract?"
  1. Chart type — which visualization the frontend should render.
  2. Relevant data — the actual rows/values to plot.
  3. Axes/dimensions — what maps to X and Y (or category/value) for the chosen chart type.
  4. Metrics/aggregation — what computed value is being shown (sum, average, count, etc.).
  5. Date range/period context — so the same chart type can represent different time windows without a new contract shape.
Follow-up 3 — "How did you prove the reuse would actually work, rather than just assert it?"
  1. Built a working prototype that fed the chatbot's structured response into the existing renderer, not a slide deck argument.
  2. Compared implementation effort directly — new renderer vs. adapting the contract to the existing one.
  3. Demonstrated the prototype to the team and manager so the evidence was visible, not just described.
  4. That's the same technique I used for the technical disagreement under Have Backbone — prototype over argument.
  5. I don't have exact performance-benchmark numbers from that prototype comparison to cite precisely.
Follow-up 4 — "What did you simplify away, and what did you deliberately not simplify?"
  1. Simplified away: a second chart-rendering codebase, a second set of chart-type bugs, a second QA surface.
  2. Did not simplify: the security boundary — chatbot-generated SQL still went through the same RLS/RBAC path as everything else, no shortcut there.
  3. Did not simplify: validation of AI-generated SQL before execution — that stayed a separate deterministic layer, not folded into "just render whatever comes back."
  4. The simplification was specifically at the presentation layer, not the trust boundary — an important distinction if pushed on security implications.
  5. I'd flag explicitly that "simpler" here meant fewer independent systems, not fewer safety checks.
Follow-up 5 — "Tell me about a time you invented something with less obvious reuse potential — where you had to build something genuinely new."
  1. The structured response contract itself was new — no prior contract existed for "AI-generated data meant for a deterministic renderer."
  2. Designing that contract required anticipating chart types and metrics the chatbot hadn't produced yet, not just matching existing report-builder shapes.
  3. On IQVIA's DeepQuery, the twelve-node LangGraph pipeline is a genuinely new orchestration structure, not a reuse of an existing framework's default flow.
  4. The URL-intelligence-before-scrape design in DeepQuery is a novel cost-control invention specific to that system's needs, not copied from elsewhere.
  5. I don't have a resume-scale "product I invented from nothing" story beyond these — I'd rather point to the strongest real example than manufacture a bigger one.
Backup 1 — I1: DeepQuery's twelve-node research pipeline Claude backup

STAR (Claude) — Instead of one model handling planning, searching, filtering, scraping, and synthesis undifferentiated, I worked within (and can defend in full technical depth) a LangGraph state machine of twelve discrete nodes sharing one state object — critically, url_intelligence scores and filters candidate URLs on cheap signals before any expensive page fetch, which is the actual cost-control invention.

Why not just let the model decide what to scrape?

Scraping is the expensive step; filtering on cheap signals (path patterns, domain trust, keyword overlap) before that step is what keeps cost bounded even with a large discovery pool.

What's genuinely 'invented' here vs. standard LangGraph usage?

The specific node sequence and the think-before-expensive-action pattern (URL intelligence before scrape, cross-page reasoning before synthesis) is the design choice, not the framework itself.

How do you know the filtering doesn't throw away good sources?

I don't have a labeled precision/recall evaluation of the filter step to cite — that's a real gap in rigor I'd name honestly.

What would you invent next if you kept working on this?

Persisting elapsed-time metrics per node and adding an LLM-judge rubric on a golden query set — both explicitly identified as not-yet-implemented extensions.

Backup 2 — S1: StratifyLabs browser-based inference Claude backup

STAR (Claude) — Instead of routing every inference request to a server, I moved inference into the browser to cut experimentation friction, alongside a 3D simulation lab and a marketplace of reusable models/datasets — three different simplifications of the same experimentation loop.

Why browser inference specifically?

Removes a network round-trip from the fastest-iterating part of the workflow — trying a model against new input.

What's the trade-off of browser inference?

Constrained by client-side compute/model size versus a full server-side deployment — I don't have the exact model-size ceiling memorized.

Why a marketplace instead of just better documentation for retraining?

Reuse eliminates repeated training cost entirely; documentation only reduces the friction of doing it again.

What's the measured iteration-time improvement mechanism?

I can defend the mechanism (fewer round-trips, more reuse) more confidently than the exact 30% figure — see the metrics-defense doc.

Backup 3 — Y8: Deterministic dashboards instead of LLM-generated KPIs Claude backup

STAR (Claude) — Rather than route every KPI request through the chatbot's LLM path, dashboard GETs stayed on deterministic SQL with no model call — a simplification that removed an entire class of AI-response failure modes from the highest-traffic path.

Isn't 'not using AI' the opposite of invention?

The invention is recognizing which parts of the system should be deterministic and which should be probabilistic — that's a design decision, not an absence of one.

Why does this matter for latency?

No external model call in the critical path is specifically what makes sub-~210ms achievable on that path.

What if a KPI calculation actually needed natural-language flexibility?

That's exactly what the chatbot path is for — the two paths are deliberately separated, not merged.

How would you defend this if someone said it's 'just SQL, not engineering'?

The engineering is in the boundary decision — knowing where determinism belongs is as much a design skill as building the AI path itself.

4. Are Right, A Lot Claude

Primary — S3: Argus 73% → 89% mAP Claude primary

STAR (Claude) — A YOLOv9 PPE-compliance detector's baseline (73% mAP) technically worked but wasn't good enough for a safety-compliance use case. I judged that insufficient rather than shippable, expanded the training set to 15,000+ images, and iterated on training until reaching 89% mAP with real-time 24 FPS inference across 20+ camera feeds.

Follow-up 1 — "Why did you believe 73% mAP wasn't good enough?"
  1. The application was safety-compliance detection — a model that technically works but misses real cases has direct consequences, not just a lower demo score.
  2. I treated model quality as an engineering requirement tied to the use case, not a number to clear an arbitrary bar.
  3. mAP at 73% implies a meaningful share of missed or misclassified detections across the evaluation set.
  4. Safety-compliance systems have asymmetric costs — a missed PPE violation is worse than a slightly noisier alert.
  5. I don't have the exact per-class breakdown of what 73% was missing memorized precisely enough to describe the specific failure classes.
Follow-up 2 — "What evidence changed your assessment, versus you just wanting a better number?"
  1. The dataset itself — comparing detection failures across a larger, more representative 15,000+ image set showed real gaps, not assumed ones.
  2. I iterated on the training process, not just threw more data at an unchanged pipeline blindly.
  3. mAP is a standard, well-defined metric — it's not a subjective judgment call I made up.
  4. Real-time inference constraint (24 FPS) stayed fixed while accuracy improved — so the gain wasn't bought by sacrificing speed.
  5. I don't have the exact IoU threshold or evaluation protocol memorized well enough to defend it at the level of a research paper.
Follow-up 3 — "How do you know the improvement wasn't just overfitting to the larger training set?"
  1. This is a fair concern with any dataset-size increase, and I'd acknowledge it directly rather than dismiss it.
  2. I don't have the exact train/validation split or hold-out methodology memorized precisely enough to walk through it rigorously.
  3. What I can defend: the model was deployed and evaluated against live camera feeds, not just a static held-out set — real-world signal, even without formal generalization stats.
  4. I'd flag this as a genuine gap in rigor I'd want to close (a proper train/val/test protocol) rather than claim certainty I don't have.
  5. This is exactly the kind of question where "I don't know the specific methodology" is the right answer, not a guess.
Follow-up 4 — "Why not just collect even more images instead of stopping at 15,000?"
  1. More data helps, but data quality, class balance, labeling quality, and evaluation methodology all matter alongside raw volume.
  2. I'd investigate the dominant error category first rather than assume dataset size alone is always the bottleneck.
  3. There's a point of diminishing returns where the next unit of labeling effort matters less than fixing a systematic labeling error.
  4. 15,000+ was the scale that got the model to the needed 89% mAP for this deployment — that was the actual stopping criterion, not an arbitrary number.
  5. I don't have a documented ablation study showing where returns diminished — I'd say that honestly rather than invent one.
Follow-up 5 — "Tell me about another time you used data to change your mind rather than confirm what you already believed."
  1. The Postgres/MySQL SQL-generation issue (Y3): my first instinct could have been "the model hallucinated," but pulling the actual generated SQL and running it directly showed a different, more specific root cause.
  2. I inspected the prompt's examples and found stale MySQL-oriented patterns — evidence that redirected the fix from "add more validation" to "fix the prompt first."
  3. In both cases, I verified against ground truth (the database, the eval set) before committing to a fix, rather than acting on the first plausible theory.
  4. Actively seeking disconfirming evidence — checking whether the data actually existed before assuming a database problem — is the same instinct in both stories.
  5. I'd rather show the pattern (verify before committing) across two different stories than force one story to cover everything.
Backup 1 — Y3: PostgreSQL vs. MySQL SQL generation Claude backup

STAR (Claude) — Generated SQL against a Postgres database sometimes used MySQL-oriented syntax. Instead of assuming "the model hallucinated," I extracted the actual generated SQL, ran it directly, and inspected the prompt's examples — finding stale MySQL-style examples in the prompt chain as the real root cause — then fixed the prompt and added a validation layer.

What made you check the prompt instead of just adding more validation?

The generated query itself showed a consistent pattern (MySQL syntax), which pointed at generation, not randomness.

Does your validator now guarantee correct SQL?

No — it reduces specific invalid-output classes; it's not a semantic-correctness guarantee, and I'd say that directly.

How long did this take to diagnose?

I don't have the exact time-to-diagnosis memorized.

What would have happened if you'd just added validation without fixing the prompt?

The validator would keep catching and retrying the same class of error indefinitely, wasting latency and calls instead of fixing the source.

Backup 2 — I2: Choosing hybrid retrieval over vector-only for BRDprocessor Claude backup

STAR (Claude) — Rather than default to vector-only similarity search, I judged that requirement documents needed relationship-aware retrieval too — because requirements can formally depend on each other or share entities — which motivated combining Azure AI Search's hybrid retrieval (BM25 + vector + semantic rerank) with 2-hop Neo4j graph context.

Why not just trust vector similarity — it usually works?

Semantic similarity doesn't capture formal dependency relationships between requirements; that's a structural fact about the domain, not a preference.

How do you know the graph context actually helped generation quality?

I don't have a controlled ablation (with vs. without graph context) to cite — I'd flag that as unverified rather than claim it.

Isn't this over-engineering for a simple retrieval problem?

The domain has real dependency structure (BRD requirements reference each other); ignoring that would be under-engineering, not simplification.

What's the actual retrieval recipe?

BM25 keyword search plus vector kNN (k=5) plus a semantic reranker, filtered by document, combined with a depth-2 graph query — genuinely hybrid, not a single mechanism relabeled.

Backup 3 — Y6: Redis-style caching decision on the chatbot path Claude backup

STAR (Claude) — Rather than assume "the model is slow" was the whole latency story, I measured the actual bot-database path and found repeated queries and schema lookups re-hitting Postgres — which is what motivated cache-aside caching keyed by role and organization, not query text alone.

What assumption were you disconfirming here?

That model latency was the dominant cost — measurement showed database re-work on repeat questions was a real, fixable contributor.

Why key by role/org instead of just the query string?

Keying by query text alone risks a cache hit crossing tenants if two orgs ask similarly worded questions — a security-correctness decision, not just a performance one.

What's the exact hit-ratio evidence?

I don't have the precise hit-ratio numbers from that period memorized.

What would you have done if measurement showed the model actually was the bottleneck?

I'd have looked at prompt size, retries, or model choice instead — the point is I measured before assuming which lever to pull.

5. Learn and Be Curious Claude

Primary — I2: Hybrid RAG / BRDprocessor at IQVIA Claude primary

STAR (Claude) — IQVIA needed retrieval over large BRD/PDF documents (180–200+ pages) for downstream requirements analysis and test-case generation. I had to learn the difference between semantic/hybrid retrieval and relationship-oriented graph retrieval, how LangGraph passes state across two separate orchestration graphs, and how chunking strategy (1500-token windows, 200-token overlap, tokenizer-aware) actually affects downstream generation quality.

Follow-up 1 — "What specifically did you not know when you started this?"
  1. I hadn't previously combined a vector/keyword hybrid search engine with a graph database in one retrieval pipeline.
  2. I didn't know how LangGraph's MemorySaver checkpointing worked, or that it's in-memory only — not durable across process restarts — until I worked with it directly.
  3. I hadn't previously had to reason about tokenizer-aware chunking (cl100k_base) versus naive character-based splitting, and why that distinction matters for chunk-boundary quality.
  4. I didn't initially understand why sequential per-chunk LLM calls during ingestion (versus the semaphore-bounded concurrency during test generation) was the deliberate design, not an oversight.
  5. I hadn't worked with Azure AI Search's semantic ranker configuration or HNSW vector-index tuning parameters before this project.
Follow-up 2 — "How did you actually go about learning this, mechanically?"
  1. Read the ingestion graph's node-by-node state transitions to understand what each of the eight nodes actually reads and writes.
  2. Traced a document through the whole pipeline conceptually — extract, chunk, embed, index, extract-requirements, analyze, build-graph, finalize — before touching the retrieval side.
  3. Compared the two retrieval mechanisms directly: what BM25+vector+semantic rerank gives you that a 2-hop graph query doesn't, and vice versa.
  4. Looked at documented failure modes and gaps (things like unwired Redis/Celery, unapplied filters) to understand what was real versus aspirational in the system.
  5. Built understanding from the request path outward, the same technique I used to learn the inherited Ylogx chatbot — a consistent personal learning method, not a one-off.
Follow-up 3 — "Why does hybrid retrieval + graph context actually improve generation, mechanically?"
  1. BM25 captures exact keyword/terminology matches that pure semantic similarity can miss (e.g., a specific requirement ID or defined term).
  2. Vector kNN captures conceptual similarity even when wording differs.
  3. Semantic reranking reorders the combined candidate set using a more expensive, more accurate relevance model on a smaller shortlist.
  4. The 2-hop graph query surfaces formally related requirements (dependencies, shared entities) that similarity search alone wouldn't necessarily rank highly.
  5. I don't have a controlled evaluation isolating each component's individual contribution — I'd flag that honestly rather than claim I measured it.
Follow-up 4 — "What was the hardest conceptual jump in this project?"
  1. Realizing that two different things are both called "graph" in this system — the LangGraph orchestration state machine and the Neo4j knowledge graph — and they solve completely different problems.
  2. Understanding that chunk boundaries computed with one tokenizer (cl100k_base) aren't necessarily identical to how the embedding model internally tokenizes — a subtle but real approximation.
  3. Recognizing that requirement extraction's sequential per-chunk LLM calls, not the page count itself, is the actual cost and latency driver on a large document.
  4. Distinguishing "the system succeeded and produced facts/pages" from "the system's final synthesis step corrupted the output" — two documented D-graded runs had this exact failure signature.
  5. Learning that a retrieval system's correctness (did it find the right evidence) and its final-generation quality (did it use that evidence well) are separate things that can fail independently.
Follow-up 5 — "What's something you're currently curious about but haven't fully learned yet in this domain?"
  1. Rigorous retrieval evaluation — building a labeled relevant-chunk set to compute real precision/recall/nDCG instead of only logging hit counts.
  2. Per-node timing instrumentation across LangGraph callbacks, which is an explicitly identified but not-yet-implemented extension on the DeepQuery side.
  3. Whether an LLM-judge rubric (relevance, citation accuracy) against a golden query set would meaningfully change how I'd trust the synthesis step.
  4. How to make LangGraph checkpointing durable across restarts, rather than relying on in-memory MemorySaver for a production-durability guarantee.
  5. I'd rather name specific, real open questions than claim a vague "I'm curious about everything" — these are the ones I can actually defend as genuine gaps I'm aware of.
Backup 1 — Y1: Learning the inherited Ylogx chatbot Claude backup

STAR (Claude) — I initially didn't understand how the inherited LangChain state, dynamic prompts, ORM lookup, SQL generation, backend execution, and frontend response fit together. I learned the system by reproducing it locally and tracing boundaries with logging, rather than making random fixes or reading every library's documentation in isolation.

How did you know where to start?

I started at the request entry point and followed data through each transformation, rather than starting from an assumption about where the bug was.

What if tracing hadn't revealed the answer?

I'd have added more granular logging at the next-most-likely boundary rather than guess at a fix.

How long did the learning phase take?

I don't have the exact timeframe memorized precisely.

Is this the same method you used on IQVIA's systems?

Yes — tracing the request/data path before changing anything is a consistent personal method across both internships.

Backup 2 — H2: Robotics domain jump (ROS2, GStreamer, ZED) Claude backup

STAR (Claude) — Robotics required learning across areas outside prior web-development experience: ROS2 integration, GStreamer video pipelines, ZED stereo/spatial perception, and how perception output becomes useful to a downstream navigation stack.

What was hardest to learn?

Realizing camera feed, depth data, coordinate frames, mapping, visualization, and navigation are genuinely separate layers that only work together when their interfaces agree.

How does ZED's stereo depth actually work, conceptually?

Disparity between the two camera images at corresponding features gives depth; the SDK accumulates that over time with positional tracking into a 3D spatial representation.

What didn't you learn / own on this project?

The predictive path-planning implementation and full sensor-fusion architecture — I did not build those, and I'd say so directly.

Why learn robotics at all if it's outside your primary stack?

Curiosity about real-time, embedded-constrained systems that behave very differently from typical web backend work.

Backup 3 — S1: StratifyLabs — 3D simulation, WebGL, browser inference Claude backup

STAR (Claude) — Building a CV experimentation platform required learning browser-based inference constraints, 3D simulation tooling, and a WebGL-based URDF editor for robot-model prototyping — areas outside standard full-stack web development.

What was the learning curve for WebGL specifically?

I don't have granular specifics of that learning process memorized precisely enough to walk through step by step.

Why does browser-based inference require different thinking than server-side?

Client-side compute and model-size constraints change what's actually deployable, versus a server where you can scale hardware.

What did you learn about simulation environments that you didn't know before?

That simulated environments meaningfully increase iteration opportunities versus always testing against real-world capture.

How does this connect to your other Learn & Curious stories?

Same underlying pattern — building the mental model of a new domain (robotics simulation, hybrid retrieval, an inherited codebase) before making changes to it.

6. Hire and Develop the Best Claude

Claude’s honest note. this is genuinely your weakest LP by documented evidence. I'm not going to manufacture a mentee or a coaching outcome to hit a quota — that's exactly the kind of thing a Bar Raiser is trained to probe until it collapses. Below is the real, if thin, material, plus the honest fallback framing.
Primary — M1: IEDC CUSAT / Team Horizon peer involvement Claude primary

STAR (Claude) — Through Team Horizon and IEDC CUSAT's Tech Team, I worked in team/community environments with other students on complex technical systems, contributing both technically and as a team member.

Follow-up 1 — "Tell me about one specific person you personally developed."
  1. I don't have a specific, verifiable name/incident I'm confident defending in detail — I'd say that directly rather than invent one.
  2. What I can speak to honestly is participation in a team/community structure (IEDC Tech Team), not a documented one-on-one coaching outcome.
  3. I would not claim measurable improvement in someone else's skills without being able to describe exactly what I did and what changed.
  4. This is explicitly one of the areas I know is under-documented in my own preparation, and I'd rather flag that than bluff.
  5. If genuinely pressed, the honest answer is: "I don't have a strong example ready for this specific principle — my strongest team-culture-adjacent story is elsewhere."
Follow-up 2 — "What does 'raising the bar' mean to you, even without a formal mentee?"
  1. On the renderer decision (Y4), I raised the bar by insisting on a working prototype as evidence rather than accepting an opinion-based decision.
  2. On the RLS/RBAC security boundary (Y5), I raised the bar by refusing to let application-level filtering alone be "good enough."
  3. On Argus, raising the bar meant not shipping a 73% mAP model just because it technically worked.
  4. These are standards-raising, not people-developing — I'd be honest about that distinction rather than blur it into a Hire & Develop answer.
  5. I don't have a story where I specifically changed another person's capability level, and I won't pretend otherwise.
Follow-up 3 — "Have you ever given someone difficult feedback?"
  1. I don't have a specific, real incident of this ready to defend in detail.
  2. I'd rather answer honestly here than construct a plausible-sounding but fabricated scenario.
  3. What's true: I resolved a Git-conflict workflow issue (Y9) by proposing a process change, which is adjacent but not the same as individual feedback.
  4. I would name this gap directly if asked, and pivot to what I can defend with confidence.
Follow-up 4 — "Why do you think you don't have a strong example here?"
  1. My documented experience is intern-level individual contributor work across three internships plus personal projects — not a role with direct reports or formal mentees.
  2. Team/community involvement (IEDC, Team Horizon) existed, but I don't have a specific tracked outcome from it.
  3. I'd rather be honest about the shape of my experience so far than inflate an intern-level story into a people-development narrative it isn't.
  4. This is exactly the kind of gap I'd want to close with a real experience before more senior interviews, not paper over now.
Backup — Honest placeholder (do not present as fact) Claude makeup
makeup — do not present as fact MAKE-UP / HYPOTHETICAL — DO NOT PRESENT AS FACT. If you have a real memory of helping a specific person (a junior teammate on Team Horizon, a hackathon teammate, a fellow IEDC member) learn something concrete — name, what they struggled with, what you specifically did, what changed — that becomes your real backup here. Until you supply that, do not use a second story for this LP; one honest, thin answer is safer than two answers that don't hold up under a follow-up.

7. Insist on the Highest Standards Claude

Primary — Y5: RLS/RBAC security boundary Claude primary

STAR (Claude) — I refused to let "the generated SQL looks fine" be the security model for a multi-tenant BI application. I separated authentication → RBAC → database role → RLS → query execution into distinct, deterministic layers, with fail-closed behavior for any user without a mapped database role — even after that fail-closed pattern replaced an earlier RESET ROLE fallback that had actually leaked.

Follow-up 1 — "Why wasn't application-level filtering enough?"
  1. A logically correct JOIN can still surface another organization's rows even when the application's WHERE clause looks correct.
  2. Application code can have bugs; I wanted the database itself to be the final, unavoidable enforcement boundary.
  3. Trusting generated SQL or an application-level filter as the only check means one missed code path becomes a full data leak.
  4. RLS makes the guarantee independent of which application code path reached the database — every path goes through the same policy.
  5. This is precisely the distinction I'd draw if pressed: RBAC decides if you may call the operation; RLS decides which rows exist for that session, in the database itself.
Follow-up 2 — "What if the LLM explicitly generates SQL asking for another organization's data?"
  1. The session's role and tenant context are set from the verified JWT before the query ever runs — never from the SQL text itself.
  2. A WHERE organization_id = 'ORG_B' clause only ever operates on rows already visible after the RLS policy filter — it can't unhide a filtered row.
  3. The result is the query succeeding with zero rows for that organization, not an error and not a leak.
  4. This means the "attack surface" of a compromised or buggy generation step is bounded by the database layer, not by how well the prompt behaves.
  5. I can name the three distinct failure modes precisely — RLS-filtered empty result, missing-grant permission error, and app-level 403 — because I designed around all three deliberately.
Follow-up 3 — "You mentioned an earlier RESET ROLE pattern that leaked. Walk me through that."
  1. The earlier fallback for users without a mapped database role used RESET ROLE, which effectively ran as a more privileged connection — an owner-bypass pattern.
  2. That's a real leak class: RLS policies don't apply the same way to a bypassing role as they do to a properly scoped tenant role.
  3. The fix was a dedicated fail-closed role with no table grants at all, so "no mapped role" means "no access," not "full access."
  4. This is a genuine example of raising the bar after finding a defect — not a hypothetical, but an actual pattern change in the system.
  5. I'd rather describe this real fix in detail than pretend the system was flawless from the start — that's a stronger Highest-Standards story than a clean one would be.
Follow-up 4 — "What's still not at 'gold standard' in this system, if you're honest?"
  1. FORCE ROW LEVEL SECURITY wasn't applied — meaning owner-level connections could still theoretically bypass policies, which is a real gap.
  2. Not every fact table's policy was guaranteed to use the same real tenant column — the generator keys off a column if present, but I wouldn't testify a specific table's schema from memory.
  3. Some paths committed on HTTP finish regardless of the response status, rather than rolling back cleanly on every error path.
  4. I can name these gaps precisely because I know the system, not despite it — that's the point of "insist on highest standards": you keep finding and naming what's not yet fixed.
  5. Naming a known gap honestly is more credible than claiming a perfect implementation I can't fully defend under a deep follow-up.
Follow-up 5 — "Tell me about a different time you refused to accept 'good enough.'"
  1. Argus: 73% mAP technically worked as a detector, but I judged it insufficient for a safety-compliance use case and kept iterating to 89%.
  2. Ylogx Y3: rather than let a validation layer silently paper over MySQL-oriented SQL generation, I fixed the actual root cause in the prompt first.
  3. Y4: rather than accept "the team has an opinion," I insisted on a working prototype as evidence before a rendering-architecture decision.
  4. The common thread across all of these: I don't treat "it technically works" as the same as "it's actually correct for what it needs to do."
  5. I'd rather point to this pattern across multiple projects than force one story to carry the whole principle.
Backup 1 — Y3: Validation layer on AI-generated SQL Claude backup

STAR (Claude) — Rather than trust that a fixed prompt alone would prevent bad SQL generation, I added a deterministic validation layer before execution — while being explicit that validation reduces specific invalid-output classes and is not a semantic-correctness guarantee.

Does your validator eliminate hallucination?

No — I'd say that directly; it catches specific invalid-output classes, not all possible wrong-but-valid SQL.

What exactly does it check?

At minimum, that generated SQL satisfies expected database/query constraints before proceeding to execution.

What happens on a validation failure?

The system can regenerate/retry, with graceful failure if the retry path also fails — I don't have the exact retry-count logic memorized.

Isn't a validator just a band-aid?

It's one layer of defense among several (prompt correctness, validation, RLS) — not a substitute for fixing the root cause, which is why I fixed the prompt too.

Backup 2 — I2: BRDprocessor's documented gaps (Earn-Trust-adjacent honesty) Claude backup

STAR (Claude) — The BRDprocessor codebase has explicitly documented, known gaps — Redis/Celery listed as dependencies but not wired to routes, filter parameters accepted by the API but not applied in the filter node, exception handlers defined but not registered on the app — and I can name these precisely rather than imply a fully polished system.

Why does a system with known gaps demonstrate high standards?

Because the gaps are documented and identified, not hidden — that's the standard I'd hold myself to even under time pressure.

Which of these gaps did you personally introduce vs. inherit?

I don't have a clean attribution of which specific gaps trace to which contributor — I'd say that honestly rather than claim credit or blame precisely.

What would you fix first?

The unapplied filter parameters, since that's a correctness gap (the API implies functionality it doesn't deliver) rather than a missing-feature gap.

Isn't this just an unfinished project?

Every production system has a gap list; the standard is whether you know what's in yours, not whether the list is empty.

Backup 3 — S3: Argus real-time constraint held fixed while accuracy improved Claude backup

STAR (Claude) — While raising mAP from 73% to 89%, the 24 FPS real-time inference constraint stayed fixed — meaning the accuracy gain wasn't bought by quietly sacrificing the speed requirement the deployment actually needed.

Why does holding FPS constant matter?

A more accurate but too-slow model would fail the actual safety-compliance use case, which needs real-time alerting, not just a better offline score.

How did you validate FPS stayed at 24 in the final deployment?

I don't have the exact benchmarking harness or hardware specs memorized to defend that number rigorously.

Would you have accepted a lower FPS for higher accuracy?

Only if the use case's real-time requirement genuinely allowed it — the standard is fitness for the actual deployment, not accuracy in isolation.

What's the deployment scale this held at?

20+ camera feeds, logged to Postgres with automated alerts — the constraint had to hold across that whole deployed footprint, not just one test feed.

8. Think Big Claude

Primary — S1: StratifyLabs CV experimentation platform Claude primary

STAR (Claude) — Rather than build a single inference demo, I built a platform combining browser-based inference, a 3D simulation lab, a marketplace of 50+ reusable pretrained models/datasets, community profiles, a WebGL URDF editor, and voice-enabled RAG bots for interacting with simulated environments — attacking the whole ML-experimentation loop, not one step of it.

Follow-up 1 — "Why a platform instead of a simpler, more focused tool?"
  1. The actual bottleneck in CV experimentation isn't any single step — it's constantly switching between datasets, models, environments, and tooling.
  2. Browser-based inference, simulation, and model reuse each independently attack a different part of that iteration cycle.
  3. A narrower tool would have solved one symptom while leaving the underlying friction (context-switching, retraining from scratch) untouched.
  4. The bet was that reducing the whole loop compounds — faster inference plus reusable models plus simulated testing multiply together rather than just add.
  5. I don't have exact user-adoption numbers proving the platform bet paid off at scale — I'd defend the design reasoning more confidently than a growth number.
Follow-up 2 — "What's the boldest technical decision in this platform, and why was it risky?"
  1. Committing to browser-based inference as a core capability, not just a demo feature, meant designing around client-side compute constraints from day one.
  2. That's risky because it caps what model sizes/complexity are realistically deployable compared to a server-side-only architecture.
  3. The bet was that the friction reduction (no round-trip, instant iteration) was worth the capability ceiling for the target experimentation use case.
  4. I don't have a documented comparison of exactly which workloads were pushed server-side versus kept in-browser.
  5. If I were doing it again, I'd want a clearer boundary rule for when a workload graduates from browser to server, rather than a case-by-case decision.
Follow-up 3 — "How does this platform 'look around corners' for the customer, in Amazon's phrasing?"
  1. Instead of waiting for users to ask "can I reuse a model," the marketplace anticipates that need before every user hits it individually.
  2. The 3D simulation lab anticipates that real-world data collection is expensive and slow — a corner most CV tooling doesn't address directly.
  3. Voice-enabled RAG bots for interacting with simulated environments is a forward-looking interaction mode, not the current-generation default (typing commands/config files).
  4. WebGL-based URDF editing lowers the barrier to robot-model prototyping without needing separate specialized tooling.
  5. I'd be honest that "looking around corners" here is my framing of design intent — I don't have external validation (user research, market data) that these were the right corners to anticipate.
Follow-up 4 — "What would you have done differently if you'd thought even bigger?"
  1. I'd build in usage analytics from day one, so "did the marketplace actually get used" wasn't a retrospective gap.
  2. I'd formalize the browser-vs-server workload boundary as an explicit rule rather than case-by-case judgment.
  3. I'd design a feedback loop from the community-profile feature back into what models/datasets get prioritized for the marketplace.
  4. I'd think earlier about multi-user collaboration on the same simulation session, which I don't believe was part of the original design.
  5. I don't want to overclaim a grander vision retroactively — these are genuine "if I did it again" reflections, not things I actually built.
Follow-up 5 — "Tell me about a different time you pushed for a bigger scope than what was minimally asked."
  1. IQVIA's DeepQuery: instead of a single-search-call research tool, the system was architected as a twelve-node reasoning pipeline with iteration, filtering, and synthesis — a much bigger scope than "search and summarize."
  2. The structured chatbot response contract (Y4) wasn't scoped as "make the chatbot output prettier" — it became the shared rendering mechanism for the whole platform.
  3. On Argus, the scope wasn't "detect PPE in one test video" — it became a 20+ camera-feed deployment with logging and automated alerts.
  4. Each of these involved choosing an architecture that served a bigger, more durable need than the immediate narrow ask.
  5. I'd rather point to this pattern across three different projects than inflate one into a story it can't fully support.
Backup 1 — I1: DeepQuery's multi-source research architecture Claude backup

STAR (Claude) — Rather than a single search call summarized by a model, I worked within an architecture that treats research as a bounded, iterative system — fan-out across three search engines per query, URL-intelligence filtering, wave-based scraping, cross-page reasoning, and a decision loop that can send control back to search or scrape before finally synthesizing.

Why is this 'big' rather than just 'more thorough'?

It reframes research as a system with feedback loops (decision engine can re-search or re-scrape) rather than a one-shot pipeline — a structurally bigger idea, not just more effort.

What's the evidence this bigger architecture actually produces better outcomes than a simpler approach?

Benchmarked runs show most graded A (93–99% confidence, dozens to over a hundred facts) — but I also know two runs graded D from a synthesis failure, so I wouldn't claim the bigger architecture is failure-proof.

Isn't this over-engineered for 'just searching the web'?

The iteration/decision loop exists specifically because a single search pass often under-covers a topic — that's a real limitation being addressed, not engineering for its own sake.

What's the next 'bigger' step for this system?

An LLM-judge rubric against a golden query set and persisted per-node timing — both explicitly identified as not-yet-built extensions.

Backup 2 — Y8: Ylogx as a unified BI platform, not an isolated chatbot Claude backup

STAR (Claude) — The product wasn't scoped as a single chatbot feature — it became a unified platform spanning report building, conversational analysis, and 30 live KPI dashboards, all sharing the same security and rendering foundations rather than three disconnected tools.

What made you think 'platform' instead of 'feature'?

Once the structured response contract and RLS/RBAC layer existed, extending them to serve multiple surfaces was a bigger, more durable design than building each surface in isolation.

What's the risk of thinking this big as an intern?

Scope creep and over-engineering for a use case that might not materialize — I'd acknowledge that tension honestly.

Who decided the platform scope — you or the team?

This was product-level team scope; my personal contribution was the shared foundations (rendering, security) that made the platform coherent rather than fragmented.

What would 'thinking even bigger' have looked like here?

Possibly a self-serve policy/report template marketplace across organizations — speculative, not something actually built.

Backup 3 — S2: GiftedBooks — learning as an interactive experience, not a chat box beside a textbook Claude backup

STAR (Claude) — Rather than bolt a generic chat assistant onto existing course material, the product combined VR labs, AI avatars, a RAG assistant over uploaded PDFs, and PYQ-based topic prioritization — treating the learning experience itself as the thing being redesigned, not just adding a Q&A feature.

Why VR specifically, rather than a simpler 2D interface?

I don't have the exact reasoning/user-research behind that specific medium choice memorized in full depth.

Isn't combining VR + AI avatars + RAG + PYQ analysis just feature-stacking rather than 'thinking big'?

Each piece targets a different part of the learning workflow (engagement, doubt resolution, prioritization) rather than being independent add-ons — that's the intended coherence, though I'd want to verify that design rationale more precisely if pushed hard.

What's the actual evidence this bigger scope beat a simpler product?

The reported outcome metrics (reading efficiency, engagement, comprehension) — with the caveat from the metrics-defense doc that I don't have the exact study methodology.

What would you cut if you had to ship an MVP instead?

Likely the VR/avatar layer first, keeping the RAG assistant and PYQ prioritization as the core value — a real prioritization judgment, not something I've documented as an actual decision made.

9. Bias for Action Claude

Primary — HACK1: Eight national/regional hackathons Claude primary

STAR (Claude) — Across eight hackathons with extremely constrained time windows, I repeatedly moved from idea to a demoable prototype fast rather than over-designing on paper — using existing full-stack/AI/CV skills to prototype, integrate, and deploy under fixed deadlines. Results: 1st place at CodeRecet, Best Project at an MLH event, runner-up at Magnathon 2.0.

Follow-up 1 — "Walk me through one specific hackathon decision under time pressure."
  1. I don't currently have one specific hackathon's exact decision sequence locked in with enough detail to narrate precisely live — this is a genuine gap I've flagged in my own prep.
  2. What I can defend as a pattern: prioritize what can actually be demoed over what's theoretically more complete, given a hard deadline.
  3. I'd pick the hackathon I remember most concretely (likely CodeRecet, since it placed 1st) and reconstruct the real sequence before using this live.
  4. Until then, I'd rather be honest that this needs a specific real memory attached, not a generic hackathon-story template.
  5. This is explicitly called out in my own prep notes as something to firm up before the interview, not something to bluff through.
Follow-up 2 — "What's a reversible decision you made quickly, versus one you took more time on?"
  1. Technology/stack choices under hackathon time pressure are typically reversible early and irreversible late — I'd pick familiar tools fast specifically because switching later is expensive.
  2. Architecture decisions that affect the demo's core value proposition deserve more deliberation, since redoing them near a deadline risks not having anything to show.
  3. UI polish and secondary features are the class of decision I'd make fastest and cheapest, since they're the easiest to cut or redo.
  4. I don't have an exact worked example from a specific hackathon to point to here beyond this general prioritization logic.
  5. The underlying principle — speed on reversible decisions, more care on hard-to-undo ones — is the same one I'd apply to production work, not hackathon-specific.
Follow-up 3 — "Tell me about a time speed cost you something — where moving fast had a real downside."
  1. I don't have a specific documented hackathon incident where speed caused a concrete negative outcome.
  2. This is adjacent to one of my real prep gaps — I don't yet have a strong "something didn't go well" story with full specifics.
  3. I'd rather name that honestly than invent a plausible-sounding but fabricated setback.
  4. What I can say in general: rapid prototyping under hackathon constraints trades some correctness/robustness for speed by design — that's a known, accepted trade-off in that context, not usually presented as a "cost."
  5. If pressed further, I'd commit to bringing a real specific incident from one of the eight hackathons before relying on this follow-up live.
Follow-up 4 — "How is 'Bias for Action' different from just working fast under a hackathon deadline that forces you to?"
  1. Hackathon deadlines are externally imposed speed; Bias for Action is choosing speed when you could have taken longer but judged it wasn't necessary.
  2. The stronger evidence for this LP is Y1 — nobody forced me to take over the inherited chatbot immediately; I chose to act rather than wait for a formal reassignment.
  3. I'd distinguish "forced fast" (hackathons) from "chosen fast" (Y1) explicitly if asked to compare the two kinds of evidence.
  4. Both still demonstrate the underlying instinct — treating many decisions as reversible and not needing extensive study — even if the trigger differs.
  5. I wouldn't want to overclaim that hackathon speed alone proves the LP without this distinction.
Follow-up 5 — "What would you do differently about how you approach hackathons now?"
  1. Spend the first 15–30 minutes explicitly separating "must demo" from "nice to have" before writing any code, more deliberately than I may have done initially.
  2. Pick the smallest end-to-end slice that proves the concept works, then layer features onto something already functional rather than building components in isolation.
  3. Time-box technology decisions harder — if a choice isn't obviously right in five minutes, default to the most familiar option rather than debate it.
  4. I don't have a documented retrospective from a specific past hackathon showing exactly what I'd change — this is a general reflection, not a specific lesson learned and applied.
  5. I'd be honest that this reflects general engineering judgment more than a specific hackathon post-mortem I can point to.
Backup 1 — Y1: Taking over the chatbot without waiting for reassignment Claude backup

STAR (Claude) — Rather than wait for formal reassignment after a teammate left, I chose to reproduce and understand the inherited chatbot system immediately, treating the decision as reversible (I could always stop and escalate) rather than requiring extensive upfront study.

Why not spend more time understanding everything before touching anything?

I learned enough to reproduce and observe the system, then iterated — deliberately not trying to understand every component before taking the first useful step.

What made this decision reversible?

I wasn't making irreversible production changes on day one — reproduction and logging are low-risk, information-gathering actions.

What if you'd been wrong about the root cause on your first attempt?

I'd have had logging in place to show me that quickly, rather than a large committed change I'd need to unwind.

Isn't this the same story as your Ownership answer?

Yes, with a different emphasis — Ownership is about why I took responsibility; Bias for Action is about how fast I acted once I decided to.

Backup 2 — Y4: Prototype instead of prolonged debate Claude backup

STAR (Claude) — Rather than spend extended time arguing abstractly about chatbot chart-rendering architecture, I built a working prototype quickly to settle the question with evidence rather than continued discussion.

Why build first instead of getting alignment first?

A prototype is a faster way to generate real alignment than continued abstract argument — it converts opinion into observable evidence quickly.

What if the prototype had failed?

That would have been useful information too — either way, building fast resolved the question faster than talking would have.

How long did the prototype take?

I don't have the exact time-to-prototype memorized.

Isn't this risky if you guess wrong about what to prototype?

I checked the data contracts were plausible before starting, which bounded the risk of the prototype being a wasted effort.

Backup 3 — H1: Shipping the GStreamer video pipeline under competition deadline pressure Claude backup

STAR (Claude) — The rover's real-time video pipeline had to be usable ahead of a fixed competition date; I built and tuned the capture-encode-transmit-display pipeline under that time constraint rather than pursuing a more elaborate solution with unclear payoff.

What did you deliberately not build because of the deadline?

I don't have a specific documented "cut feature" from this project to point to precisely.

Why GStreamer specifically, under time pressure?

It gave a dedicated media pipeline with explicit stage control, rather than forcing the application layer to handle all video transport mechanics from scratch under a tight deadline.

What was the actual competition deadline, and how close did you cut it?

I don't have the exact date-to-completion timeline memorized precisely.

How do you know the pipeline was 'good enough' rather than under-tested?

I'd want to be honest that under competition time pressure, testing rigor is inherently a trade-off against the deadline — I don't have a formal test coverage claim to make here.

10. Frugality Claude

Primary — Y4: Reusing the ElementRenderer instead of a second charting system Claude primary

STAR (Claude) — Instead of building or licensing a second visualization system for the chatbot, I reused the report builder's existing ElementRenderer by designing a compatible structured response contract — avoiding duplicated code, duplicated testing surface, and duplicated future maintenance.

Follow-up 1 — "Was reuse always the right call, or did you consider the cost of forcing a fit?"
  1. Reuse only made sense because I verified the data contracts were genuinely compatible before proposing it — not as a default preference.
  2. If the renderer had required forcing unrelated requirements into one abstraction, I would have kept the systems separate instead.
  3. The cost of a bad-fit reuse (increased coupling, harder-to-reason-about renderer) would have outweighed the savings — I weighed that trade-off explicitly.
  4. I validated the fit with a working prototype before committing, which is also how I'd catch a bad-fit decision early rather than after both systems were entangled.
  5. Frugality isn't "always reuse" — it's "don't pay for a second thing when the first thing genuinely already solves the problem."
Follow-up 2 — "What resource did this actually save — engineering time, infrastructure cost, something else?"
  1. Engineering time — no second rendering codebase to design, build, and test from scratch.
  2. Maintenance burden — one place to fix rendering bugs instead of two independently drifting implementations.
  3. QA surface — one rendering behavior to validate across chart types, not two potentially inconsistent ones.
  4. Cognitive overhead for the team — one mental model for "how does a chart get rendered," not two.
  5. I don't have a dollar-cost or headcount-hours estimate for this saving — I'd describe it qualitatively rather than invent a number.
Follow-up 3 — "Give me an example where you spent more, deliberately, because frugality would have been the wrong call."
  1. The RLS/RBAC security layer (Y5) — I would not have "saved effort" by relying only on application-level filtering, because the risk (data leak) outweighs implementation cost every time.
  2. Argus's larger 15,000+ image training set — more data-collection/labeling effort than the minimal 73%-mAP baseline required, because the safety use case justified the extra cost.
  3. Adding a validation layer on top of prompt fixes (Y3) — extra engineering rather than "the prompt fix alone is probably good enough."
  4. In each case, the deciding factor was consequence severity, not effort minimization — frugality doesn't mean cheapest, it means not paying for waste.
  5. I'd distinguish this clearly if asked: frugal on genuinely redundant work, not frugal on risk-bearing correctness work.
Follow-up 4 — "How would you decide, in general, whether to reuse or build new?"
  1. Check whether the existing thing's actual contract (not just its category/label) matches what the new use case needs.
  2. Estimate the ongoing maintenance cost of a second implementation versus the adaptation cost of the first.
  3. Prototype the fit quickly rather than debate it — cheap to verify, expensive to guess wrong.
  4. Weigh consequence severity — reuse is safer to default toward for non-critical paths, riskier to default toward for security/correctness-critical paths.
  5. I don't have a formalized decision framework document for this — it's judgment applied consistently across the stories above, not a written policy.
Follow-up 5 — "Tell me about a different time you accomplished more with less."
  1. Y8's deterministic dashboards — no LLM call on the highest-traffic path, which is both a latency win and a cost/complexity win simultaneously.
  2. StratifyLabs' browser-based inference — reduces dependence on heavier server-side infrastructure for the experimentation workflow.
  3. DeepQuery's URL-intelligence filtering before scraping — spends compute/API budget only on the shortlist that survives cheap-signal filtering, not the full discovery pool.
  4. Each of these is the same underlying move: spend the expensive resource (LLM call, server infrastructure, scrape budget) only where it's actually needed, after a cheaper check has already narrowed the problem.
  5. I'd rather show this as a repeated pattern across systems than force any single story to be the definitive Frugality example.
Backup 1 — Y8: Deterministic dashboard APIs Claude backup

STAR (Claude) — KPI dashboard GETs never call the LLM — deterministic SQL only — which avoided the cost, latency, and failure-mode overhead of a probabilistic call on the highest-traffic path.

Isn't 'not using AI' just avoiding cost rather than being frugal?

It's spending the expensive resource (a model call) only where flexibility is actually needed, not on every request by default — that is the frugal design choice.

What would happen if you'd used the LLM for every KPI instead?

Higher latency, higher API cost, and a new failure mode (bad generation) on a path that previously had none.

How much did this actually save in dollar terms?

I don't have an exact cost figure — I'd defend the mechanism, not a specific savings number.

Doesn't determinism limit flexibility for users who want ad-hoc KPIs?

That's exactly what the separate chatbot path exists for — the two paths are deliberately split by need, not merged for false economy.

Backup 2 — S1: Browser-based inference reducing server dependence Claude backup

STAR (Claude) — Moving inference client-side for StratifyLabs reduced dependence on heavier external server infrastructure for the experimentation workflow, letting the iteration loop run without a constant round-trip to a paid backend.

What exactly ran client-side versus server-side?

I don't have the precise workload split memorized to defend in full detail.

What's the trade-off of pushing inference to the browser?

A ceiling on realistically deployable model size/complexity versus a fully server-side architecture.

Was this purely a cost decision, or also a latency/UX decision?

Both — removing the round-trip cuts cost and improves iteration speed simultaneously, which is why it was the right lever to pull.

How would you decide when a workload should move back to the server?

I don't have a formalized rule for this — it would be a case-by-case judgment based on the model size/complexity needed.

Backup 3 — I2: Requirement extraction as sequential, not fanned-out Claude backup

STAR (Claude) — BRDprocessor's requirement-extraction step runs one LLM call per chunk sequentially rather than fanning out concurrently, while test-case generation does use bounded concurrency (Semaphore(3)) — a deliberate difference reflecting where concurrency was actually worth the added complexity and rate-limit risk.

Why not fan out extraction the same way test generation does?

I don't have the exact reasoning behind that specific design choice from the original codebase — I can describe the pattern precisely, not claim I authored the trade-off decision myself.

Isn't sequential extraction wasteful on a large document?

It's the actual cost/latency driver on large documents — a real, known limitation, not a hidden one.

Why is test generation's concurrency capped at exactly 3?

To stay under Azure OpenAI's rate limits (TPM/RPM) — a resource-awareness constraint, not an arbitrary number.

What would you change here if you owned this decision?

I'd want to batch extraction calls where safely possible before assuming full concurrency is the only alternative to fully sequential.

11. Earn Trust Claude

Primary — Y4: Prototype instead of argument on the renderer decision Claude primary

STAR (Claude) — Rather than argue abstractly for reusing the ElementRenderer, I built a working prototype demonstrating the existing renderer could consume the chatbot's structured response, and presented the evidence to the team rather than the opinion.

Follow-up 1 — "What if your prototype had proven you wrong?"
  1. I would have said so directly and supported whichever approach the evidence actually favored — that was the whole point of testing it rather than arguing for it.
  2. A prototype that disproves your own hypothesis is still useful information, not a wasted effort.
  3. I'd rather be visibly wrong early with evidence than quietly right in an argument no one can verify.
  4. Being self-critical about your own proposal, even when it's uncomfortable, is specifically the behavior this principle asks for.
  5. I don't have a documented instance where this specific prototype disproved my hypothesis — it happened to confirm it — but I'd answer the hypothetical the same way regardless.
Follow-up 2 — "How do you build trust with a team when you disagree with the current plan?"
  1. Bring evidence, not just a stronger opinion — the prototype converted "I think X" into "here's X actually working."
  2. Present the trade-offs honestly, including the downsides of my own proposal, not just its benefits.
  3. Make the decision visible and reviewable by the team/manager rather than making a unilateral call.
  4. Commit fully to whatever the team decided once the decision was made, regardless of whether my proposal won.
  5. Listen to the counter-arguments first, rather than treat the discussion as a formality before my idea won anyway.
Follow-up 3 — "Tell me about a time you had to admit you were wrong, or self-critical, in front of the team."
  1. This overlaps with one of my genuine current prep gaps — I don't have a fully fleshed-out personal example ready for "admitted I was wrong publicly."
  2. What's adjacent and real: the RESET ROLE fallback pattern in the RLS middleware was a design that leaked and had to be replaced — a system-level correction, though I'd need to confirm exactly how personally attributable that specific mistake was before presenting it as "I was wrong."
  3. I'd rather name this honestly than manufacture a false-humility story that doesn't hold up under a follow-up.
  4. If pressed, I'd say directly: "I don't have a fully specific example of this ready — I'd want to bring you a real one rather than approximate it."
  5. This is exactly the kind of gap that benefits from bringing one real, small, true story rather than a large invented one.
Follow-up 4 — "How do you handle a situation where a teammate's work has a problem, without damaging the relationship?"
  1. Focus on the workflow/process gap, not the person — the same framing I used with the Git-conflict situation (Y9): coordination issue, not a blame issue.
  2. Bring the actual evidence of the problem rather than a general complaint, so the conversation is concrete.
  3. Propose a fix, not just a criticism — the branch-separation proposal is a real example of pairing a problem observation with a solution.
  4. Address it directly and early rather than let friction accumulate silently.
  5. I don't have a documented example of giving difficult feedback to a specific person's individual work — I'd distinguish process-level Earn Trust evidence (which I have) from interpersonal feedback evidence (which I don't have a strong example of yet).
Follow-up 5 — "What does benchmarking yourself against the best actually look like in your work?"
  1. On Argus, refusing to accept 73% mAP as "done" because the safety-compliance use case demanded better, not because a rubric required a specific number.
  2. On the RLS design, choosing database-level enforcement over the "easier" application-level-only approach, because that's what a properly rigorous implementation requires.
  3. On the IQVIA retrieval design, combining hybrid search with graph context rather than settling for vector-only because it was simpler to implement.
  4. In each case, the standard I compared against was "what would a genuinely correct/complete system look like," not "what's the minimum that passes."
  5. I don't have an external benchmark (industry standard, competitor system) I explicitly measured against in any of these — the standard was internally reasoned, and I'd say that honestly.
Backup 1 — Y9: Git conflicts → branch discipline Claude backup

STAR (Claude) — Rather than let repeated merge conflicts become a source of blame between interns, I proposed and moved toward clearer branch separation and deliberate merging — framing it as a process fix.

Did you speak candidly about the actual problem, or avoid it?

I named the coordination gap directly (shared-branch collisions) rather than letting it go unaddressed.

How did the team respond?

I don't have the exact team reaction/adoption details memorized precisely.

What if someone had resisted the change?

I'd have wanted to understand their concern rather than push the process change over objection — though I don't have a documented instance of resistance to describe.

Is this really an Earn Trust story or an Ownership story?

Both angles are legitimate — Ownership is that I took initiative on a shared problem; Earn Trust is that I addressed it candidly and without blame.

Backup 2 — Y7: Client communication during review cycles Claude backup

STAR (Claude) — Recurring client demo/review cycles required communicating honestly about what could and couldn't be delivered in a given iteration, rather than overpromising to keep the relationship smooth.

What did you tell a client when you couldn't implement something immediately?

I don't have one specific verbatim exchange memorized well enough to narrate precisely — I'd want a real instance before using this live.

How do you balance candor with not damaging a client relationship?

Being clear about trade-offs and timelines is what actually builds long-term trust, versus vague reassurance that erodes it when reality catches up.

Did you ever have to tell a client 'no'?

I don't have a specific documented instance to defend in detail.

What would you do if a client's request conflicted with the RLS/security design?

I would not compromise the security boundary to satisfy a feature request — that's a non-negotiable, and I'd escalate the trade-off explicitly rather than quietly bend it.

Backup 3 — I3: LangSmith tracing over "looks good in a demo" Claude backup

STAR (Claude) — I wanted the IQVIA systems to be genuinely inspectable — LangSmith tracing across nodes, plus documented per-stage fallback behavior for malformed LLM output — rather than a system that only looked correct in a curated demo.

Why does tracing build trust specifically?

It means claims about system behavior are checkable against actual recorded state, not just asserted.

What did tracing actually reveal that surprised you?

I don't have a specific surprising trace result memorized to describe in detail.

Isn't this just good engineering practice, not really an interpersonal trust story?

It's trust in the system's claims about itself — a legitimate, if less interpersonal, reading of the principle.

What's still not traceable/inspectable in these systems?

Per-node timing and end-to-end latency aren't currently persisted — an explicitly documented, known gap.

12. Dive Deep Claude

Primary — Y2: The `data: null` root-cause investigation Claude primary

STAR (Claude) — Users could ask the chatbot a valid business question and get data: null back even though the underlying data existed. I verified the records existed first, then traced the request across the backend and SQL-RAG pipeline, inspected intermediate states, and found a state-format mismatch between processing stages that a downstream parser silently failed on — then reproduced, fixed, and reran the failing cases.

Follow-up 1 — "How did you know it wasn't a database problem?"
  1. I independently verified the underlying records existed in Postgres before assuming anything upstream was broken.
  2. That verification ruled out "the data genuinely isn't there" as an explanation before I spent time tracing the pipeline.
  3. If the data hadn't existed, the investigation would have gone a completely different direction — I checked this first because it's the cheapest thing to rule out.
  4. The eventual root cause (state-format mismatch between pipeline stages) was consistent with data existing but being lost in transit, which matched what I'd already confirmed.
  5. This is a general habit I apply elsewhere — verify ground truth before tracing the pipeline, not after.
Follow-up 2 — "Why didn't you just change `data: null` into a clearer error message and move on?"
  1. That would have hidden the symptom rather than fixed where the information was actually being lost.
  2. A clearer error message doesn't prevent the same underlying bug from recurring on a different query shape.
  3. I wanted to identify the exact stage where the structured state broke, not just make the failure more legible.
  4. Papering over the symptom would have left a real data-loss bug live in the pipeline, just with better UX around it.
  5. Fixing the root cause meant the class of failure went away, not just this one reported instance of it.
Follow-up 3 — "What exactly was the state-format mismatch, mechanically?"
  1. A downstream stage in the LangChain pipeline expected the previous stage's output in a specific structured format.
  2. The previous stage, for certain queries, wasn't producing that exact format — a parsing/schema mismatch, not a logic error in either stage individually.
  3. The parser failed to extract the expected structured state from that malformed output.
  4. Because the failure was silent (no exception, just missing data), it surfaced downstream as data: null rather than an obvious error at the point of failure.
  5. I don't have the exact field-level diff between expected and actual format memorized precisely enough to reproduce it verbatim now.
Follow-up 4 — "How did you actually trace this — what tools/technique?"
  1. Added logging at each important service boundary — prompt input, intermediate state, generated output, final response — rather than only at the very start and end.
  2. Reproduced the failure locally with a representative failing query, so I could inspect intermediate state directly instead of guessing from production logs alone.
  3. Compared a working query's intermediate state against a failing query's intermediate state at each boundary to isolate where they diverged.
  4. This is the same technique (reproduce, log boundaries, compare traces) I used when first taking over the whole inherited chatbot system.
  5. I don't have exact log excerpts memorized to quote verbatim, but I can describe the method in full technical detail.
Follow-up 5 — "Tell me about a different time you had to dive deep into something outside your usual comfort zone."
  1. The BRDprocessor retrieval architecture (I2) — understanding hybrid search, HNSW vector-index parameters, and graph-based context retrieval well enough to reason about trade-offs, not just use them as black boxes.
  2. The ZED-2 stereo-depth pipeline (H2) — understanding disparity, positional tracking, and spatial mapping well enough to explain how raw camera data becomes usable obstacle information.
  3. The Postgres RLS mechanism (Y5) — going deep enough to precisely distinguish RLS filtering, missing-grant errors, and application-level 403s as three genuinely different failure modes.
  4. Each of these required going past "I used this technology" into "I understand exactly why it behaves the way it does under specific conditions."
  5. I'd pick whichever of these the interviewer seems most interested in probing further, rather than force this answer toward a fixed script.
Backup 1 — Y3: PostgreSQL vs. MySQL SQL-generation mismatch Claude backup

STAR (Claude) — Rather than accept "the model hallucinated" as an explanation for MySQL-syntax SQL against a Postgres database, I pulled the actual generated SQL, ran it directly, and traced it back to stale MySQL-oriented examples inside the prompt chain.

What made you check the prompt rather than the model itself?

The failure pattern was consistent (specific MySQL syntax, not random garbage), which pointed at a systematic input issue rather than model randomness.

How did you confirm the prompt was the actual cause, not just a correlated factor?

Fixing the stale examples and rerunning the same failing query class resolved the issue — a before/after test, not just an inference.

What tools did you use to extract the generated SQL?

I don't have the exact tooling/logging pipeline details memorized precisely.

Would this bug have been caught by better testing instead of deep debugging?

Possibly — but the debugging is what revealed what better testing should have specifically checked for, which is the deeper value.

Backup 2 — I2: Hybrid retrieval investigation for BRDprocessor Claude backup

STAR (Claude) — Understanding why relationship-structured requirement data needed more than semantic similarity required going deep into how Azure AI Search's hybrid retrieval (BM25 + vector + semantic rerank) and Neo4j's 2-hop graph queries each contribute differently to the evidence a test-generation prompt receives.

What would you have missed with vector-only retrieval, specifically?

Formal dependency relationships between requirements that aren't necessarily semantically similar in wording.

How deep did you go into the HNSW vector-index parameters?

I understand the parameters (m=4, efConstruction=400) as a build-time quality/speed trade-off, though I didn't personally tune them from a blank default.

What's the actual retrieval flow, step by step?

Query embedding → BM25 keyword match + vector kNN (k=5) in parallel → semantic rerank on the combined candidates → top 5 passed to the prompt, alongside a separate 2-hop graph query.

Did you measure whether the graph context actually improved output quality?

No controlled evaluation exists for this that I can cite — a genuine gap I'd name honestly.

Backup 3 — H1: Video-pipeline latency investigation Claude backup

STAR (Claude) — When the rover's video feed worked locally but wasn't sufficiently responsive once integrated into the full system, I broke the pipeline into capture, encoding, transmission, and rendering stages to identify where latency was actually accumulating, rather than guessing at a single fix.

What did you find was the actual bottleneck?

I don't have the specific stage identified with full confidence memorized — this is exactly the kind of concrete incident detail I'd want to firm up with a real memory before using this live.

Why break it into stages instead of testing the whole pipeline end to end?

End-to-end testing tells you that there's a latency problem, not where — stage-by-stage isolation is what actually locates the fix.

What tools did you use to measure per-stage latency?

I don't have the exact instrumentation/measurement method memorized precisely.

How does this compare to your Ylogx debugging approach?

Same underlying method — isolate boundaries, measure at each one, compare against a working baseline — applied to a very different (real-time, embedded) system.

13. Have Backbone; Disagree and Commit Claude

Primary — Y4: The chatbot chart-rendering disagreement Claude primary

STAR (Claude) — There were competing views on how to implement chatbot chart rendering. I believed a new, separate mechanism would add unnecessary complexity given the report builder's existing renderer. Rather than simply assert that opinion, I built a working prototype proving the existing renderer could consume the chatbot's structured response — and the team adopted the reuse approach based on that evidence.

Follow-up 1 — "Did you actually disagree with a manager, or just a peer?"
  1. Not every disagreement in this story was strictly hierarchical — the important part is that I held a different technical view and supported it with evidence rather than deference.
  2. I don't have a specific high-stakes manager-level disagreement documented with full detail — that's one of my genuine current prep gaps.
  3. What I can defend fully: the technical disagreement itself, the evidence I brought, and my full commitment to the outcome regardless of who "won."
  4. I'd rather be precise about the actual shape of this disagreement than imply it was a bigger confrontation than it was.
  5. If asked specifically for a manager-level disagreement, I'd say directly that I don't have a strong one ready yet, rather than stretch this story to cover it.
Follow-up 2 — "What if the team had rejected your proposal after seeing the prototype?"
  1. I would have documented my concern once, clearly, and then fully supported whatever direction was chosen.
  2. Disagreement is useful only up until the decision is made — continuing to relitigate it afterward would undermine the team, not help it.
  3. I'd have helped implement the chosen approach as well as I could, not passively or resentfully.
  4. The goal was reaching the right engineering decision as a team, not proving my specific proposal had to win.
  5. I don't have a real instance where my proposal was actually rejected to describe — this prototype happened to be adopted — but I'd apply the same behavior regardless of outcome.
Follow-up 3 — "How do you know when to keep pushing back versus when to let it go?"
  1. If I have concrete evidence (a prototype, a measured trade-off) and haven't yet presented it, that's when to keep pushing — the disagreement hasn't been properly tested yet.
  2. Once a decision-maker has seen the evidence and made a call, continuing to argue becomes about ego, not the outcome.
  3. I'd weigh how reversible the decision is — a more reversible choice is one I'd push back on less hard, since it can be revisited if wrong.
  4. I don't have a documented case where I pushed back longer than this story shows — I'd want a real example of sustained disagreement before claiming deep experience with that specific judgment call.
  5. The general principle: evidence-not-yet-heard justifies continued pushback; evidence-heard-and-decided-against does not.
Follow-up 4 — "Tell me about a time you committed to a decision you disagreed with, and it turned out you were wrong to have disagreed."
  1. I don't have a specific documented instance of this to walk through with full honesty and detail.
  2. This is a genuinely different angle than my strongest Have Backbone story, which involves a disagreement where I was ultimately validated by the prototype.
  3. I'd rather flag this gap directly than manufacture a humble-sounding but fabricated reversal.
  4. If pressed, I'd note that "commit fully even when I turn out to be right or wrong" is the behavior I can defend in principle, even without a specific "and then it turned out I was wrong" anecdote.
Follow-up 5 — "What's a technical opinion you hold strongly that most of your team might not agree with?"
  1. That RLS/database-level enforcement should be non-negotiable even when application-level filtering looks sufficient — I'd hold this position firmly if challenged on cost/complexity grounds.
  2. That deterministic paths (like dashboards) shouldn't route through an LLM just because "AI" is available — a position some teams might push back on for consistency's sake.
  3. That reuse (like the ElementRenderer) should require verified contract compatibility, not just category similarity — I'd push back on reuse-for-its-own-sake as much as against unnecessary duplication.
  4. I don't have a documented instance of actually being challenged on any of these specific positions by a real team — these are genuine convictions, but untested-in-conflict ones.
  5. I'd rather state real convictions honestly, with the caveat that I haven't had every one of them stress-tested in an actual disagreement yet.
Backup 1 — I2: Hybrid retrieval vs. simpler vector-only retrieval Claude backup

STAR (Claude) — I held the view that vector-only retrieval would be insufficient for requirement data with real dependency structure, and advocated for combining hybrid Azure AI Search retrieval with Neo4j graph context instead of the simpler, cheaper vector-only alternative.

Who did you actually disagree with on this?

I don't have a specific named person/discussion to point to — I'd describe this as a design judgment I made and can defend technically, rather than a documented interpersonal disagreement.

What would have convinced you vector-only was actually sufficient?

A controlled comparison showing dependency-aware answers weren't measurably better — which I don't have, so I can't claim I disconfirmed the alternative rigorously.

Isn't hybrid retrieval just 'more is better' thinking?

No — the graph piece specifically targets a structural gap (formal dependencies) that similarity search can't capture by design, not just added complexity for its own sake.

Would you commit to vector-only if a team lead insisted on it for cost reasons?

Yes, once the decision was made, while making the trade-off (missing dependency-aware retrieval) explicit and documented.

Backup 2 — Y5: Security boundary — database-level enforcement over "simpler" app-only filtering Claude backup

STAR (Claude) — I held firm that application-level filtering alone was insufficient and that Postgres RLS needed to be the actual enforcement boundary, even though app-only filtering would have been simpler and faster to ship initially.

Was this actually contested, or just your own design choice from the start?

I don't have a documented instance of someone explicitly arguing for app-only filtering that I had to overcome — I'd be honest that this may be more "strong conviction, applied" than "won a specific argument."

What if a deadline had pressured you to ship the simpler version first?

I would not have shipped app-only filtering as the final security boundary even under deadline pressure — this is a non-negotiable, not a trade-off I'd compromise for speed.

How would you have escalated if overruled?

I'd have documented the specific leak risk clearly and pushed for it to be revisited before production traffic, rather than let it go silently.

Isn't 'non-negotiable' just refusing to disagree-and-commit?

Security boundaries in a multi-tenant system are closer to a correctness requirement than a stylistic preference — I'd draw that line explicitly if challenged on it.

Backup 3 — H2: Perception-ownership boundary, stated plainly rather than implied broader ownership Claude backup

STAR (Claude) — Rather than let the rover project's broad scope imply I owned more than I did, I hold firm to stating precisely what I built (video pipeline, ZED perception) versus what I didn't (predictive planner, sensor fusion) — even when a less precise answer would sound more impressive.

Isn't this actually the opposite of 'having backbone' — isn't backbone about asserting more, not less?

Having backbone here means resisting the pressure to overclaim under a follow-up, not asserting a stronger position than the facts support.

Did anyone push you to claim more ownership than you had?

I don't have a documented instance of external pressure to overclaim — this is more a personal discipline than a resolved conflict.

What would you do if a recruiter or interviewer explicitly wanted you to claim the whole project?

I would still state the accurate boundary — overclaiming that collapses under a technical follow-up is worse than a precise, defensible claim.

How does this relate to 'commit'?

Once I've stated the accurate boundary, I commit to defending exactly that scope consistently, rather than drifting the claim depending on who's asking.

14. Deliver Results Claude

Primary — Y8: The production ConvBI platform Claude primary

STAR (Claude) — The product needed reports, conversational analytics, live KPI dashboards, security boundaries, and production reliability simultaneously. My personal contributions spanned chatbot stabilization, the structured-response/rendering design, RLS/RBAC implementation, and caching performance work, fitted into the larger NestJS/FastAPI/React/PostgreSQL system deployed on AWS.

Follow-up 1 — "Which of the reported results were actually yours versus the team's?"
  1. Chatbot stabilization (resolving the data: null class and the SQL-generation mismatch) was my direct, personal work.
  2. The structured-response contract and ElementRenderer-reuse design was mine, from proposal through prototype.
  3. The RLS/RBAC security layer — the middleware, the policy generator, the fail-closed pattern — was my direct implementation.
  4. The product-level metrics (40% faster reports, 60% operational efficiency, 30 dashboards) reflect the whole team's output, including the report builder UI, dashboard suite, and infrastructure I didn't personally build.
  5. I'd distinguish these explicitly rather than let a single number imply I built the entire platform alone.
Follow-up 2 — "What was the biggest obstacle to delivering this, and how did you get past it?"
  1. Inheriting a chatbot system with no documented handoff — the obstacle was understanding before I could deliver anything on top of it.
  2. I got past it by reproducing the system and adding boundary logging rather than guessing at fixes under time pressure.
  3. A separate obstacle was the security requirement not being negotiable even as feature work continued — I had to build RLS/RBAC correctly, not just adequately, without slowing the rest of the team down.
  4. I addressed that by making the security layer a foundational piece (transaction-scoped role switching) that other features could build on top of, rather than a bolt-on check per feature.
  5. I don't have a specific "we almost missed the deadline because of X" story to add here with full confidence — this is one of my real prep gaps (missed deadline/commitment).
Follow-up 3 — "How did you personally measure whether you were actually delivering, day to day?"
  1. For the chatbot fixes, whether the specific failing query classes I'd reproduced now returned correctly, rerun after each change.
  2. For the RLS work, whether cross-tenant test scenarios (a legal JOIN attempting to reach another org's rows) actually returned zero rows, not an assumption that policies "should" work.
  3. For the caching work, whether repeat-query latency actually dropped on the bot-database path, though I don't have exact before/after numbers memorized.
  4. I don't have a formal personal KPI/dashboard I tracked myself day to day — measurement was mostly tied to specific fixes and their verification, not an ongoing metric I monitored.
  5. I'd rather describe this honestly (fix-level verification, not a personal dashboard) than imply more process rigor than existed.
Follow-up 4 — "Tell me about a time you delivered despite a setback partway through."
  1. The RESET ROLE fallback pattern leaking is the closest real example — a shipped mechanism turned out to be a security gap, and the fix (fail-closed no-access role) had to be delivered as a correction, not a first-time build.
  2. I don't have a broader "we were behind schedule and I had to recover" story with full specifics — that's adjacent to the missed-deadline gap I still need a real incident for.
  3. What I can defend precisely: recognizing the RESET ROLE pattern was wrong and replacing it with a correct mechanism is itself a "deliver results despite a setback" story, even without a schedule-pressure angle.
  4. I'd rather use that real, specific, technically defensible setback than stretch a generic answer to sound more dramatic than what actually happened.
Follow-up 5 — "What result are you least confident defending on this whole project?"
  1. The exact 65% SQL-RAG productivity figure — I can defend the mechanism (natural-language querying collapsing a multi-step manual process) far more confidently than the specific percentage or its measurement methodology.
  2. Similarly the 40% report-generation figure — same caveat, mechanism over methodology.
  3. I would not overstate confidence on either number if pushed — I'd rather flag them honestly than let a follow-up expose overconfidence.
  4. What I am fully confident defending: the RLS/RBAC design, the chatbot debugging, and the rendering-reuse decision, all the way down to implementation detail.
  5. Naming my own least-confident claim proactively is itself the Deliver-Results-adjacent move I'd make here — knowing exactly what you can and can't stand behind is part of actually delivering, not a weakness to hide.
Backup 1 — S3: Argus — 73% → 89% mAP, deployed at scale Claude backup

STAR (Claude) — Delivered a real, deployed improvement — not just a better offline number — expanding training data to 15,000+ images, reaching 89% mAP while holding 24 FPS real-time inference, deployed across 20+ camera feeds with Postgres logging and automated compliance alerts.

What made this a 'delivered result' rather than just a model improvement?

It shipped into an actual multi-camera deployment with logging and alerting, not just a better benchmark score in isolation.

What would you say is the weakest part of this delivery?

The exact safety-violation-reduction and compliance-multiplier figures (50%, 2×) — I can defend the detection-accuracy improvement rigorously, those downstream business metrics less so (see metrics-defense doc).

How long did this take end to end?

I don't have the exact project timeline memorized.

What was the riskiest part of shipping this?

Deploying across 20+ live feeds means a regression would have real operational impact — I don't have a documented rollback/monitoring plan to describe in detail.

Backup 2 — I1: DeepQuery — 12 benchmarked runs, mostly grade A Claude backup

STAR (Claude) — Delivered a research system that measurably worked across a benchmarked set of real runs — 10 of 12 graded A (93–99% confidence, dozens to over a hundred facts, long structured reports) — while also being able to name the 2 runs that graded D and why.

Is a 10/12 success rate actually a good result to claim?

I'd present it exactly as it is — including the 2 failures and their diagnosed cause — rather than only cite the successes.

What did you personally do to drive that success rate, versus the framework doing it?

I don't have a clean personal-attribution breakdown of exactly which architectural decisions were mine versus inherited from the existing system design.

How would you improve the 2 failing runs' failure mode?

Add stricter JSON-parse validation and a retry/fallback specifically at the synthesis stage, since that's the diagnosed failure point, not the retrieval or reasoning stages.

What's your confidence in the grading formula itself?

It's a documented, weighted composite of confidence/facts/pages/sources/length — I understand its construction, though I don't have an external validation that the composite score actually correlates with human-judged answer quality.

Backup 3 — HACK1: Hackathon placements under fixed deadlines Claude backup

STAR (Claude) — Consistently delivered demoable, judged results under hard external deadlines across eight hackathons — 1st place (CodeRecet), Best Project (MLH event), runner-up (Magnathon 2.0).

What does winning a hackathon actually prove about Deliver Results?

That I can consistently produce a working, judgeable artifact under a hard time constraint — a narrower but real proof point than production delivery.

What's different about hackathon delivery versus production delivery?

Hackathon delivery optimizes for a demoable slice under time pressure; production delivery (Ylogx) optimizes for correctness and security holding up over time — I'd draw that distinction if asked to compare.

Which of the eight hackathons would you want to go deep on?

I don't currently have one locked in with full specific-decision detail — see the Bias for Action section; this is the same real gap.

What's your placement rate across all eight, including the ones you didn't place in?

I don't have full results for every one of the eight memorized — I'd defend the three cited placements specifically, not imply a claim about the other five.

15. Strive to be Earth's Best Employer Claude

Claude’s honest note. like Hire and Develop the Best, this is a genuinely weak LP for your documented intern-level experience. The material below is real but thin, and I will not inflate it.
Primary — M1: IEDC CUSAT / Team Horizon team environment Claude primary

STAR (Claude) — Participated in team/community environments (IEDC Tech Team, Team Horizon) alongside other students, contributing to a working, collaborative technical culture rather than only shipping individual output.

Follow-up 1 — "How did you personally contribute to making the team environment better, specifically?"
  1. The branch-discipline proposal (Y9) reduced a real source of friction (repeated merge conflicts) for the whole team, not just for me.
  2. I don't have a documented example of directly improving safety, inclusion, or personal growth for a specific teammate.
  3. I'd be honest that my strongest evidence here is process-improvement-adjacent, not people-development-adjacent.
  4. This principle, as Amazon defines it, is heavily about empathy and others' growth — which is a different kind of evidence than what I currently have documented.
  5. I'd rather state this gap plainly than force a thin story to sound like more than it is.
Follow-up 2 — "What does 'having fun at work' or empathetic leadership look like to you, even without direct reports?"
  1. Reducing unnecessary friction (like the Git-conflict situation) so teammates spend less energy on avoidable coordination problems.
  2. Framing problems as process gaps rather than individual failures, which keeps team dynamics healthier under pressure.
  3. Being upfront and honest in client/team communication rather than letting unspoken frustration build up.
  4. I don't have a specific documented instance of actively making work more enjoyable for someone else — this is a reasonable value statement, not a proven story.
  5. I'd rather answer this at the level of principle than dress it up as a specific achievement I can't fully back.
Follow-up 3 — "Tell me about a time you helped a struggling teammate."
  1. I don't have a specific, verifiable incident ready for this.
  2. This is the same category of gap as Hire and Develop the Best — genuine, and I won't paper over it with invention.
  3. If pressed, the honest answer is: "I don't have a strong example for this specific principle yet, from the experience I've documented so far."
  4. I'd rather offer to talk about a principle where I do have strong, specific, defensible evidence.
Follow-up 4 — "Why do you think this is a weaker area for you right now?"
  1. My documented experience is individual-contributor intern work across three companies plus personal/team projects — roles without formal people-management scope.
  2. The team/community involvement I do have (IEDC, Team Horizon) wasn't tracked with specific individual-impact outcomes.
  3. I'd rather be accurate about the shape of my experience so far than construct a manager-style narrative that doesn't match an intern-level career stage.
  4. This is a genuine area I'd expect to build real evidence for as I take on more senior or team-lead-adjacent responsibilities.
Backup — Honest placeholder (do not present as fact) Claude makeup
makeup — do not present as fact MAKE-UP / HYPOTHETICAL — DO NOT PRESENT AS FACT. As with Hire and Develop the Best: if you have a real memory of making a team environment genuinely better for a specific person — helping someone feel less overwhelmed on a project, advocating for a teammate, improving how the group worked together in a way someone else would confirm — that becomes your real second story here. Until then, one honest, thin, accurately-scoped answer is the right move, not a second fabricated one.

16. Success and Scale Bring Broad Responsibility Claude

Primary — Y5: Security as scale increases Claude primary

STAR (Claude) — A multi-tenant BI application meant that making analytics easier to access via natural language also made a security mistake easier to scale across every organization on the platform. I deliberately never let the LLM make an authorization decision — RBAC controls capability access, PostgreSQL RLS is the final, deterministic row-level enforcement boundary, entirely independent of what the model generated.

Follow-up 1 — "What broader risk were you actually preventing, beyond the immediate feature?"
  1. The obvious risk was cross-tenant data exposure — one organization seeing another's rows.
  2. The broader lesson: making a system easier to query in natural language also makes a security mistake easier to scale, because more users can now accidentally or maliciously trigger the same underlying bug.
  3. A single missed authorization check in a traditional fixed-query dashboard affects a narrow surface; the same gap behind a flexible natural-language interface affects a much larger and less predictable surface.
  4. That's why the authorization boundary needed to be deterministic and sit outside the probabilistic model entirely, not layered on top of it as an afterthought.
  5. I don't have a quantified "blast radius" estimate for what a leak would have looked like — I'd describe the risk qualitatively rather than invent a number.
Follow-up 2 — "What responsibility did you take for something you didn't directly cause?"
  1. I didn't create the multi-tenant architecture or the decision to add an LLM-driven chatbot — but I took responsibility for making sure that combination didn't become a security liability.
  2. I inherited the earlier RESET ROLE fallback pattern (which leaked) and treated fixing it as my responsibility once I understood the risk, not something to defer to whoever built it originally.
  3. This reflects "leave things better than you found them" directly — I found a real gap and closed it rather than working around it.
  4. I don't have a documented instance of someone above me explicitly assigning this responsibility — I identified it and acted on it.
  5. I'd distinguish this from Ownership (which is about acting on behalf of the whole outcome) by emphasizing the secondary/downstream-effects framing here — what happens because this system exists and scales, not just whether it works today.
Follow-up 3 — "How would this responsibility scale if the platform had 100x more organizations on it?"
  1. The deterministic RLS enforcement doesn't get weaker with more tenants — the policy mechanism is per-session, not something that degrades with tenant count.
  2. What would need attention at that scale: policy-generation correctness across a much larger and more varied set of table schemas, since I can't manually verify every table has the right tenant column.
  3. The fail-closed default (no mapped role → no access) becomes more valuable at scale, since more automated/bulk user provisioning increases the chance of a misconfigured role slipping through.
  4. I don't have a load-tested or audited answer for exactly how this holds at 100x scale — I'd flag that honestly as an untested claim rather than assert confidence I don't have.
  5. I'd want FORCE ROW LEVEL SECURITY applied and a real audit before claiming this design is bulletproof at genuinely larger scale — a known, named gap.
Follow-up 4 — "Tell me about a different project where scale created responsibility you had to think about."
  1. The rover's perception system (H2) — inaccurate environmental information doesn't just produce a bad dashboard number, it can feed into decisions with physical consequences for the rover and its surroundings.
  2. My role there wasn't owning the planner — my contribution was making sure the environmental information available to the navigation system was something it could actually reason about safely, within my scope.
  3. On Argus, deploying across 20+ camera feeds means a model regression isn't a single bad prediction — it's a systematic gap across every monitored location simultaneously.
  4. In each case, the responsibility scales with the number of decisions or users downstream of a single component, not with how hard the component was to build.
  5. I'd rather show this as a repeated design instinct across different domains (security, robotics, computer vision) than force one story to cover it all.
Follow-up 5 — "What's something you'd do differently now, knowing what you know about responsibility at scale?"
  1. I'd push earlier for FORCE ROW LEVEL SECURITY rather than treat ENABLE as sufficient, closing the owner-bypass gap before it's ever a live risk.
  2. I'd want automated deny-fixtures — tests that specifically try a cross-tenant JOIN and assert it returns nothing — built in from day one, not added after the fact.
  3. I'd document the exact tenant-column assumption per fact table explicitly, rather than let the policy generator infer it silently from schema inspection.
  4. On the rover side, I'd want a clearer, documented handoff contract for exactly what guarantees my perception output does and doesn't make to the navigation team.
  5. I don't have evidence I actually implemented any of these "would now" improvements — I'd present them honestly as forward-looking reflection, not as something already done.
Backup 1 — H1/H2: Rover perception feeding a physically consequential system Claude backup

STAR (Claude) — Unlike a bad dashboard number, inaccurate perception output on a rover can feed into navigation decisions with real physical consequences. My contribution was making sure the environmental information reaching the navigation/costmap pipeline was something it could reason about safely — while being explicit that I didn't own the planner making the final safety-critical decision.

Why does this count as 'broad responsibility' if you didn't own the planner?

Because the quality of information I provided directly bounds how good a decision the planner can make, even without me making that decision myself.

What happened if your perception data was wrong or noisy?

I don't have a specific documented incident of bad perception data causing a downstream navigation problem — I'd want a real memory here before using this live.

How did you validate your perception output was trustworthy enough to hand off?

I don't have a formal validation protocol to describe — this is an honest gap in rigor I'd name if pushed.

Isn't this really just Ownership again?

The emphasis here is the downstream/secondary effect of imperfect perception data on a system with physical consequences, distinct from simply "I owned my component well."

Backup 2 — S3: Argus at 20+ camera-feed deployment scale Claude backup

STAR (Claude) — A PPE-compliance detection model deployed across 20+ camera feeds means a systematic model weakness isn't a single bad prediction — it's a gap replicated across every monitored location simultaneously, with automated alerts and logging depending on that accuracy holding.

What would you do if you found a systematic failure mode after deployment?

I don't have a documented post-deployment monitoring/rollback story to describe — a real gap in what I can defend here.

How do you weigh false positives versus false negatives at this scale?

I don't have the specific precision/recall trade-off analysis for this deployment memorized — I'd want to check the actual eval config before answering with confidence.

What's the responsibility difference between a demo model and a 20-feed production deployment?

A demo model's errors are contained to a test session; a production deployment's errors compound across every monitored feed and every logged event, continuously.

Would you have deployed at 73% mAP if the timeline had forced it?

No — for a safety-compliance use case, I'd have pushed back on that timeline rather than ship a detector I judged insufficient, even under pressure.

Backup 3 — I2: BRDprocessor's honestly-documented gaps as a scale-readiness signal Claude backup

STAR (Claude) — Recognizing and documenting real gaps (unwired Redis/Celery, unapplied filter parameters, unregistered exception handlers) before the system scales further is itself an act of broad responsibility — naming what isn't yet safe to scale, rather than letting scale expose it first.

Isn't documenting gaps just normal software hygiene, not really 'broad responsibility'?

At small scale, an unapplied filter parameter is a minor inconsistency; at larger scale, it's a correctness gap affecting every user who assumes that parameter works — naming it early is what prevents that from becoming a real incident later.

Did you personally introduce any of these gaps?

I don't have a clean personal attribution for which specific gaps trace to which contributor — I'd say that honestly.

What's the actual risk of the in-memory job-status tracking (no Redis/Celery) at scale?

Job status is lost on process restart, and concurrent load isn't distributed across workers — a real scaling limitation for a system meant to handle many simultaneous document-ingestion jobs.

What would you prioritize fixing first if this were about to scale 10x?

The in-memory job tracking, since that's the gap most directly tied to concurrent load and durability, ahead of the unapplied filter parameters.

How to actually use this file Claude

Don't try to memorize every point verbatim — that defeats the purpose. Instead:

  1. Read each primary story's five follow-ups twice, out loud, so the shape of the answer (not the exact wording) becomes familiar.
  2. Notice the honesty pattern repeating — almost every follow-up chain has at least one point that says "I don't have X memorized" or "this is a real gap." That's intentional and load-bearing: a Bar Raiser trusts calibrated uncertainty far more than uniform confidence.
  3. Treat the backups as genuine alternatives, not filler — if a primary story gets used up early in the loop, a backup with real follow-up depth means you're not repeating yourself or downgrading to a thinner answer.
  4. The two flagged LPs (Hire & Develop the Best, Earth's Best Employer) are your one real to-do item from this whole file. Everything else here is ready. Those two need one true, specific memory each before they're ready — not more writing from me.