Behavioral and HR

Round: HR / Hiring Manager, last round. STAR-graded scorecard. HR screen 20-30 min; HM round can run 30-60 min — plan 90-120s stories with a 30s fallback. Rule of this round: Interviewers will interrupt vague stories and ask "exact numbers? exact date? what did you do? what was the outcome?" Prepare every story with dates, counts, and deltas. Your ammo: session-takeover fix (Siege) • transaction leak • Redis seat-hold race • Gravitas 3M visits / 50L INR / zero downtime / -95% tickets • Xlancr ~-50% cost + latency • coding platform 600+ users • CookOff 5-member team / 15k evals / 200/min peak / <10s verdicts • CTF 2nd place.

1. Why Walmart Asks — Values Behind Every Question

Walmart Global Tech behavioral is not small talk. Every question maps to Sam Walton's four core values + three intern signals:

The 4 official values (name them explicitly): 1. Respect the Individual — how you treat teammates, handle disagreement, give credit, listen to juniors/seniors. 2. Serve Our Customers and Members — Sam Walton's line: "the customer is our boss." Even backend/security work must tie to shopper, associate, or seller outcome (checkout works, data safe, tickets resolved). 3. Strive for Excellence — raise the bar, measure, improve, don't ship mediocrity at scale. 4. Act with Integrity — honest about mistakes, data, security trade-offs; no cover-ups, no cutting auth corners.

The 3 intern signals HMs score (the JD's soft skills: analytical problem-solving, eagerness to learn, adaptability, teamwork, communication): - Ownership: Did you own a problem end-to-end (find → fix → test → monitor), not just "helped"? - Communication: Can you explain a vuln to a non-security PM in 60s? Did you flag risks early, document, hand over? - Curiosity: Do you learn beyond coursework — CTFs, labs, blogs, red-teaming your own projects?

How the round runs: - A typical HM round: 5 min intro → 3-4 STAR probes (hardest problem, conflict, failure, ownership) → Why Walmart / Why security → logistics (relocation, MS plans) → your questions. Stories must survive at 90-120s, with a 30s version in reserve. - Campus grad bar: collaborative professionalism + delivery through scale + customer warmth. Frugality matters — "Everyday Low Cost" (internal framing — don't recite it at the interviewer) — so praise lean fixes (Redis cache vs bigger server, regression test vs manual re-check). - No number = no score: "improved performance" scores 0; "p95 roughly halved, cost ~-50%" scores.

Translation trick: End every story with: Value + Number. "That's Service to Customer — 3M visits with zero downtime — and Excellence — tickets down 95%." Use the explicit value tag for 2 answers max (hardest problem, failure) — elsewhere just close with the number.

2. STAR Crash Course + The Numbers Rule

Ground-truth timeline (memorize; never narrate a date outside this)

STAR in 2 minutes (the only format Walmart accepts)

• S — Situation (15-20s, 2 sentences): Where + when + scale. "Sep 2025, Gravitas 2025 college fest, payments portal I built, 3M page visits expected in 3 days."
• T — Task (10-15s, 1 sentence): Your responsibility. "I owned payments + seat booking; had to prevent double-booking and pool exhaustion."
• A — Action (60-90s, 60% of answer, 2-3 'I' steps): What you did, decision + why, obstacle. Use I, not we. Name tools.
• R — Result (15-30s, number + learning): Quantified outcome + durable change. Then optional L — Learning.

Timing: S+T ≤ 30s combined. A = longest. R = numbers. Total 90-120s. If they want more, they'll probe — don't front-load 3 min of context.

The Numbers Rule (non-negotiable)

• Every R needs ≥1 number: count, %, latency, money, users, date.
• Your number bank — memorize cold:
• Gravitas: 3M visits, ₹50L handled, zero downtime, -95% support tickets (admin dashboards)
• Xlancr: ~-50% cost and latency (Redis + FastAPI cache), 70% coverage via GitHub Actions
• Coding platform: 600+ users, Judge0 + Asynq + Gin + sqlc
• CookOff: 5-member team, 15k evaluations, 200/min peak, <10s verdicts
• CTF: 2nd place, Ghidra/GDB, buffer-overflow + static analysis
• Bad vs good:
• ❌ "We fixed sessions and it went well."
• ✅ "Sep 2026 at QNU: a security review found cross-tenant takeover — sessions keyed by pool only. I re-keyed to (pool,uid), made UID resolution fail-closed, added regression tests incl. cross-tenant replay; found internally, fixed pre-deploy, 0 exploitation."
• If no metric, use concrete outcome: "adopted by 3 teams". Never say "went well."

Delivery tips

• I > We: Every "we" gives credit away. Say "I proposed X; team agreed; I implemented Y."
• One obstacle per story: Frictionless stories sound fake. Add the hard part (midnight leak, disagreeing teammate, unclear spec).
• Pre-empt follow-ups: Interviewers ask "what would you do differently? how did you validate?" End with validation (tests, logs, monitoring).
• Record yourself: 2-min timer; cut S if >45s.

3. Ready-Made Story Bank — Say These Verbatim

3.1 Tell me about yourself (60-90s, InfoSec + AI-security hook)

"I'm a final-year CS student focused on application security and AI security. I build and break things — I built a coding platform serving 600+ users with Judge0 sandboxing and Asynq queues, and a fest payments portal that handled 3 million visits and 50 lakh rupees with zero downtime. Breaking my own builds taught me security: I found and fixed a cross-tenant session takeover, a transaction leak that would have exhausted our DB pool, and a Redis seat-hold race condition. That led me to LLM security — I built Siege at QNU Labs, a Go red-teaming tool with a 19-technique catalog and MCP interception proxy; at Aidan I added observability to a RAG retrieval pipeline. I also placed 2nd in a CTF with Ghidra/GDB. I'm excited about Walmart because it's Fortune 1 retail scale — cart, checkout, and AI search where a small vuln affects millions — and I want to do detection and secure design at that scale."

• Bullets to hit: school → builder → breaker (three vulns) → AI-security differentiator → CTF proof → Why Walmart scale hook. If you lose your place, this order alone recovers the answer.
• Length: keep under 90s; the 30s fallback is school → 3M visits → the session takeover → Siege → "retail scale is where I want to do security."

Why this answers the question: It proves Curiosity and Ownership in one pass — you ship at scale, then audit your own work hard enough to find real flaws. It also plants three hooks (session takeover, transaction leak, Redis race) the interviewer can pull on for the next 20 minutes.

Follow-up 1 — "What did you build versus the team?" "On the coding platform I built the backend — Judge0, Asynq, Gin + sqlc. On Gravitas I owned payments and seat booking, not the whole portal. At QNU I own Siege end-to-end. At Xlancr the cache layer, the spike and the benchmarks were mine; we co-presented." Then stop and let them choose the piece they care about.

Follow-up 2 — "Why security over pure software engineering?" "Because I broke my own app — I replayed a token and became another user. I still like building; I just want it safe by construction, and security is measurable: the PoC either works or it doesn't."

Delivery note: Slow down on the three vulns — that is the hook, and rattling them off sounds rehearsed. Pause after "zero downtime." Land the Walmart line as its own beat. Smile on "build and break."

3.2 Hardest problem solved + why hard

"Hardest was the Gravitas 2025 seat-hold race + transaction leak together, Sep 2025. Situation: fest seat booking, hundreds of concurrent holds, Redis Sorted Sets for holds with TTL. Task: I owned booking correctness. Action: First, I reproduced the race — two users holding the last seat both succeeded because check-then-set wasn't atomic; I moved it to a Lua script with atomic check-and-hold and per-seat TTL. Second, harder: under load we leaked DB transactions on error paths — the pool exhausted at peak load and checkout hung in pre-fest load testing. I audited every handler, added defer rollback + commit-or-rollback on all paths, and re-tested well above expected peak. Result: zero double-books in 3M visits, zero downtime, 50L processed, support tickets down 95% via admin dashboards. Why hard: two interacting failures — concurrency + resource leak — only visible together at peak, not in unit tests."

• Value tag: Strive for Excellence + Ownership.

Why this answers the question: It proves Ownership and Excellence — you found a failure class no unit test caught, fixed the mechanism, then proved it at a load level above the real peak. It is also your most number-dense answer.

Follow-up 1 — "How did you reproduce the race?" "Two concurrent hold requests against the last seat: both read 'free' before either wrote, so both succeeded. I moved check-and-hold into a single Lua script so Redis applies it atomically, TTL included."

Follow-up 2 — "What if Redis fails or the script errors mid-way?" "The hold fails closed — no seat reserved rather than two — and the TTL means a stuck hold can never become a permanent lock. The booking service treats that as 'try again,' not 'sold.' That is the rule I use now: when in doubt, deny."

Delivery note: S+T in 25s, then slow down for "I audited every handler" — that is the ownership line. Pause before "zero double-books." If they interrupt after the race half, still land the pool half in two sentences; the second failure is what makes it "hardest."

3.3 Vulnerability found and remediated (use session takeover)

"At QNU Labs, Sep 2026, a security review of Siege's agent-fleet session registry found a cross-tenant session takeover — essentially an IDOR in session keys. Situation: sessions keyed only by pool ID, so one tenant's token could act as another. Task: I owned the fix. Action: I wrote a PoC confirming the account switch, then fixed root cause — re-keyed to (pool,uid), made UID resolution fail-closed so missing UID denies instead of falling back, rotated live sessions, and added regression tests including cross-tenant replay, plus logging for UID-mismatch denials. Result: found internally, fixed pre-deploy, 0 exploitation — and deny-by-default per-object keys are now my default pattern."

• If probed: "Like IDOR — missing object-level check, fixed with deny-by-default per-object check."
• Value tag: Act with Integrity (found internally, reported and fixed pre-deploy, didn't hide it).

Why this answers the question: It proves Integrity and technical rigor — you found your own tool's flaw, proved it with a PoC, fixed the root cause instead of the symptom, and reported it before anyone else could.

Follow-up 1 — "Was it exploited before you fixed it?" "Pre-deploy and internal, so exposure was zero; the PoC only ever switched between two test tenants I controlled. I added UID-mismatch denial logging, so from then on attempts fail loudly instead of silently."

Follow-up 2 — "How do you stop this class of bug returning?" "Deny-by-default when identity is missing, keys that always include the tenant, and a regression test that replays a cross-tenant token and expects denial. A session key without the tenant ID is now a review blocker for me."

Delivery note: Say "essentially an IDOR" once, then drop the jargon and explain it plainly — that is the communication signal. Emphasize "found internally" and pause after "zero exploitation." Sound matter-of-fact, not proud of the bug.

3.4 Slipping deadline

"CookOff portal, Sep 2024 — 5-member team, 15k evaluations against a hard fest-start deadline, judge queue lagging past the 10s verdict target at 200/min peak. Situation: we were going to miss the fest start. Task: I was backend lead; had to ship on time without dropping correctness. Action: I cut scope with the organizer — I proposed Must (auth, queue, verdict <10s) vs Nice (live leaderboard v2, dark mode), got sign-off in one meeting, pushed 2 Nice features to v1.1, rebalanced sprints so 3 of 5 focused on the queue, and I took the hardest piece — Asynq worker scaling + Judge0 timeouts — myself. I added a daily 15-min standup and a visible burndown. Result: shipped Must before the fest start, 15k evals at <10s verdicts through the peak, Nice features shipped right after with no incidents. Lesson: I now flag slippage with a written Must/Nice + date, not just 'we're trying hard.'"

• Value tag: Service to Customer (organizer + contestants) + Communication.

Why this answers the question: It proves Communication and Service — you negotiated scope with data instead of slipping quietly, protected what the customer actually needed, and still shipped the extras one version later. The organizer is the customer; the contestants are the end users.

Follow-up 1 — "Did cutting features hurt anything?" "No — v1 carried auth and the queue SLO, which is what the fest ran on. Live leaderboard v2 and dark mode shipped in v1.1 with no incidents, and by then I had real usage data instead of guesses."

Follow-up 2 — "How did agreement come that fast?" "I brought queue-lag numbers at 200/min and a dated trade: queue now, v1.1 with a date. She could say yes without losing anything. Scope meetings usually stall because one side is asked to give something up with nothing back."

Delivery note: Lead with the deadline, not the features. Say Must/Nice as a clean pair so it sounds planned, not like an excuse. Pause after "shipped Must before the fest start," give the lesson in one line, and stop.

3.5 Disagreement with stakeholder / teammate

"On Xlancr (SWE Intern, Sep 2024 – Feb 2025), a teammate wanted to fix latency by upgrading the server; I wanted a Redis + FastAPI cache layer. Situation: p95 latency high and API costs rising. Task: I had to disagree without stalling. Action: I didn't argue in chat — I built a 1-day spike: cached hot reads with TTL + invalidation on write, benchmarked on prod-like data, and brought numbers: p95 and cost both down ~50% (roughly halved). I also listed the risk — stale reads — and my mitigation (write-through invalidation + short TTL). I presented both options and let the team choose. Result: team picked cache, we shipped in a week, the ~-50% held through the rest of my internship, and I added 70% CI coverage so invalidation was tested. Relationship intact — he reviewed my PR and we co-presented it."

• Rule: respectful, data-driven, relationship intact. Never blame.
• Value tag: Respect the Individual.

Stakeholder variant (organizer/PI, 60-90s): "CookOff organizer wanted leaderboard v2 first; I argued the queue SLO came first. I showed her the queue-lag numbers at 200/min and offered a trade: queue now, v2 in v1.1 with a date. She agreed in one meeting. That's my stakeholder playbook — data plus a trade, not a standoff."

Why this answers the question: It proves Respect and influence — you disagreed with data, let the team decide, and kept the relationship. That he reviewed your PR and co-presented is the proof, not the claim.

Follow-up 1 — "What if the team had picked the bigger server?" "I would have helped ship it — the call was theirs once the numbers were on the table. I would have written the cost curve down to revisit in a month, because that option gets more expensive as traffic grows while the cache gets cheaper."

Follow-up 2 — "Wasn't the stale-read day a real cost?" "Yes, and it was mine: invalidation was correct but under-documented, so a handoff changed the assumptions. Reads were stale, nothing was lost. Fix: write-through invalidation, short TTL, a 1-pager, CI coverage."

Delivery note: Do not rush the spike — one day, prod-like data, numbers brought to the team. Emphasize that you built before you argued. Say "relationship intact" plainly and stop; do not oversell the harmony.

3.6 Ambiguous request

"Siege at QNU Labs, started Sep 2026 — brief was 'build an LLM red-team tool.' No spec, no channels, no success metric. Task: I had to turn ambiguity into a plan. Action: I time-boxed — 3 days of recon: read OWASP LLM Top 10 2025, tried Garak and PyRIT on a demo RAG app, interviewed two researchers on what they actually needed (chained multi-turn, not one-shot). I wrote a 1-page scope: 4 delivery channels, 19-technique catalog, attack-graph executor, MCP proxy, detection-rule drafts — and got sign-off before coding. I demoed weekly with a live chain so ambiguity couldn't regrow. Result: shipped usable v1 in 6 weeks, demo flow that pivots recon→bypass→extraction→tool abuse, and a clear rebuild list. Lesson: when spec is vague, I write the 1-pager and get a yes before building."

• Discretion (say once if probed): "Siege is internal QNU tooling — I'll describe architecture and technique classes, not customers, keys, endpoints, or unpatched findings."
• Value tag: Curiosity + Ownership.

Why this answers the question: It proves Ownership and Curiosity — nobody handed you a spec and you manufactured one, then protected it with sign-off and live weekly demos. The 6-week v1 gives a dated outcome even though the brief had no metric in it.

Follow-up 1 — "How did you decide what belonged in v1?" "From what the researchers needed, not what was easy to build: chained multi-turn attacks, since one-shot probes were already covered. OWASP LLM Top 10 gave the coverage map, and the 19 techniques fell out of mapping threats to what we could execute."

Follow-up 2 — "What if the 1-pager had been wrong?" "The weekly demo would have caught it — that is why the demo was a live attack chain, not slides. The scope was a dated hypothesis, and everything I could not fit went on a known rebuild list instead of into scope creep."

Delivery note: Pause after "no spec, no channels, no success metric" so the interviewer feels the ambiguity before you show the plan. Emphasize "sign-off before coding." Keep the discretion line in reserve for customer or endpoint probes.

3.7 Failure / what you'd do differently

"My failure was the Gravitas transaction leak — I caused it. Situation: I shipped payments fast for a 3M-visit fest and only tested happy paths. Task: my error paths could exhaust the DB pool at peak. Action: a pre-fest load test hung checkout — I owned it immediately: audited every handler, added defer rollback + commit-or-rollback on all paths, a linter check, and a chaos test that forces errors on every path. Result: re-ran clean well above peak; the fest ran with zero downtime, ₹50L processed. What I'd do differently: fail-closed review checklist — every PR touching transactions must show all-path handling — which I now enforce on all my Go projects including Siege."

• Never pick a fake weakness ("I'm a perfectionist"). Pick real bug + fix + prevention.
• Value tag: Integrity (owned it) + Excellence (systemic fix).

Why this answers the question: It proves Integrity and Excellence in the right order — you owned a bug you caused before anyone asked, then changed the process so the class cannot ship again. The fix is mechanical, not a promise to "be more careful."

Follow-up 1 — "How could you have caught it earlier?" "By testing error paths, not just happy paths. The load test was the first thing that forced failures, and it should have existed before the feature was called done — which is why the checklist now demands all-path proof in review."

Follow-up 2 — "What if it had reached the fest?" "Pool exhaustion shows up as checkout hanging, so first protect the customer path — restart or shed load so checkout keeps working — then patch and re-test above peak the same night. It never got there, but that order is the runbook."

Delivery note: Start with "I caused it" — do not soften it. Short pause after "hung checkout." Keep the fix tone calm and procedural, and end on the fail-closed checklist in one line.

3.8 Leadership & teamwork (5-member team + coordinator roles)

"CookOff, 5 members, I was backend lead. Situation: mixed skill levels, 15k evals, hard deadline. Action: I split work by strength — 2 on judge workers, 1 on auth, 1 on frontend, me on queue + integration — set up GitHub Projects, PR reviews mandatory, and a 'no hero merges' rule. I paired the two juniors for 30-min walkthroughs during overlap and ran mock peak tests together. As Tech Coordinator for Gravitas 2025, I did the same — RACI sheet, daily check-in, unblock queue. Result: 15k evals, 200/min peak, <10s verdicts, zero auth incidents; by the end both juniors were shipping on their own. What I learned: leadership is unblocking + standards, not doing everything myself."

• Ownership proof: standards that outlasted you (PR template, regression suite).
• Value tag: Respect + Ownership.

Why this answers the question: It proves Respect and Ownership together — you raised the team's standard without doing their work for them, and the proof is that the juniors shipped on their own. The PR rules and mock peak tests outlasted you.

Follow-up 1 — "Tell me about a teammate who underperformed." "I have not managed a formal underperformer. Closest was two juniors slower on the judge queue than the rest; I paired with them for 30-minute walkthroughs during overlapping hours and we ran mock peak tests together, and by the end they were shipping on their own." Never turn this into a complaint about a person.

Follow-up 2 — "How do you handle credit?" "Name the work and the people together — I proposed, the team reviewed, X built the worker, Y shipped auth. On Xlancr I asked the teammate who disagreed with me to co-present the result."

Delivery note: Keep the list short so this stays under 90s. Emphasize "no hero merges" and "juniors shipping on their own" — one is a standard, the other is the outcome. Skip tool names beyond GitHub Projects and PR reviews.

3.9 Why Walmart? Why cybersecurity? Why AI security? Where do you learn?

Why Walmart: "Three reasons — scale, mission, and team. Scale: 3M visits taught me retail peaks are brutal; Walmart is that at Fortune-1 — cart, inventory reservation, real-time pricing where a race condition costs crores. I want to learn secure design at that scale. Mission: saving families money means security can't block checkout — it has to be invisible and fast, which is the hardest design constraint. Team: I read Walmart Global Tech's post on supply-chain technology helping teams prepare for severe weather — that's the kind of system where my race-condition and pool-exhaustion lessons apply — and the JD's AI-for-security scope (anomaly, phishing, malware, fraud detection) is exactly where my LLM-security work lands. I'd like to earn a return offer if the team sees a fit." Why cybersecurity: "Because I broke my own app. Finding that session takeover — seeing User A become User B with one replayed token — was visceral. I never want to ship that to millions. I like that security is adversarial and measurable: either the PoC works or it doesn't." Why AI security: "Because prompts are the new SQL injection and RAG is the new file upload — untrusted input executed by a powerful engine. Blocklists don't work — paraphrase and base64 bypass them. Siege taught me defence must be architectural: tag untrusted chunks, least-privilege tools, human approval for high-impact. Walmart's AI search and support copilots need exactly that." Where I learn: "Daily: Walmart Global Tech blog, OWASP LLM Top 10 updates, Microsoft AI Red Team papers. Weekly: HackTheBox / TryHackMe labs, CTFs — placed 2nd using Ghidra/GDB. I red-team my own projects with Garak and track CVEs via CISA KEV."

• ❌ Never: "stable big company," "good pay," "brand name." Always: scale + customer + specific team/tech.

Why-Walmart follow-up bank (the two hardest): - "Why retail, when you could do security anywhere?" "Because retail peak is the hardest reliability constraint I have already worked under — 3M visits in three days at Gravitas meant a race condition cost money live. Walmart runs that daily across cart, checkout and inventory, with security that has to stay invisible through it." - "What have you actually read about Walmart Global Tech?" "The supply-chain piece on preparing teams for severe weather — exactly where race conditions and pool exhaustion matter at national scale. Plus the JD scope: anomaly, phishing, malware and fraud detection with AI, which is where my LLM-security work lands."

Delivery note: Three reasons in order — scale, mission, team — and one artifact you actually read. Slow down on the family-money line. No perks, no "stable," no "brand." Keep the return-offer sentence last and low-key.

3.10 Strength / weakness with proof

Strength: "Debugging under load with numbers. Proof: Gravitas pool exhaustion — I reproduced it at peak load, traced it to missing rollbacks on error paths, fixed + load-tested well above peak, held zero downtime across 3M visits. I bring flame graphs and pool metrics, not guesses." Weakness: "Early on I under-documented — my Redis TTL + invalidation logic lived in my head, a teammate applied it with different assumptions, and we saw a day of stale reads — the handoff gap was mine. Sequence if asked: cache shipped fast with thin docs → stale-read day → 1-pager + CI coverage → then it held at ~-50% with 70% coverage. Fix: I now write a 1-page design + sequence diagram for every shared component and require it in PRs. In Siege I documented all 19 techniques with preconditions and mitigations — new teammates can onboard without me."

• Formula: weakness (real) → impact → fix (system) → proof.

Why it works: The strength is proven by a reproduced failure and a clean peak, not a self-description. The weakness is real, has a visible cost, and the fix is a system you still run — the only version that scores.

Follow-up 1 — "When has your debugging been wrong?" "I have chased symptoms — I looked at the seat-hold race first because it was visible and missed that the pool exhaustion was a separate cause. The fix was method: reproduce at peak, check resource metrics before touching code."

Follow-up 2 — "How do you know the documentation habit stuck?" "A new teammate can pick up Siege without me — all 19 techniques carry preconditions and mitigations, and the 1-pager plus sequence diagram is required before a shared component ships."

Delivery note: Give the strength number first, then the method. For the weakness keep the order — shipped fast, stale-read day, 1-pager, CI coverage — and stop at the proof. One admission, no second apology.

3.11 Future plans / MS / relocation

"Short-term: join as intern, ship a real detection or hardening win in 10-12 weeks (confirm actual internship length with the recruiter), earn a return offer. Medium-term: 2-3 years as a security engineer — SOC detection-as-code and AI red-teaming — then decide on MS — I'm not applying in the next cycle; I want industry depth first, and Walmart's scale is the best classroom. Relocation: fully comfortable with Bengaluru/Chennai — I've coordinated multi-day fests away from home and thrive in new teams. Long-term: staff-level secure-AI engineer for retail."

• Be decisive: "not now" beats "maybe." Show intern → FT intent (conversion matters).

Why it works: It proves Ownership and commitment — a clear intern-to-full-time intent, a decision rather than a hedge on MS, and a relocation answer with evidence. Walmart scores intern conversion, so the 10-12 week win is the line that matters.

Follow-up 1 — "Why not your MS now?" "I want depth in the work first — detection engineering and AI red-teaming are learned on real systems with real traffic. A master's is still on the table later; I am just not applying this cycle, and I would rather say that plainly than pretend both paths are equal today."

Follow-up 2 — "What if the role or location differs from what you expected?" "I would want to understand the team and the work before judging the label — Bengaluru or Chennai both work, and I have run multi-day events away from home. If it is security-adjacent and I can ship, I am interested."

Delivery note: Be decisive; "not now" beats "maybe" on MS. Confirm internship length with the recruiter, not the HM. Say BLR/MAA comfortably and move on — over-justifying relocation is what they listen for.

3.12 Two smart questions to ask + two to avoid

Ask (shows curiosity + ownership): 1. "What does the SOC stack look like for this team — Splunk vs Sentinel, and how do intern findings move from detection-rule draft to prod? I'd love to ship a Sigma/SPL rule that actually runs." - Why it impresses: It names real tooling and asks about the ship path, which signals you have used a detection pipeline or at least studied one. It also quietly offers an intern deliverable they can picture. 2. "How do red-team findings ship to prod here — is there a recent example where a pentest or AI probe changed a design? And what does a strong intern conversion project look like in 10-12 weeks?" - Why it impresses: Asking for a recent example tests whether security work actually changes systems, and the conversion question tells the HM you are playing for the full-time offer, not a summer badge.

Recruiter-only (not the HM): timeline, team matching, location, internship length, conversion process.

Avoid: 1. ❌ "What's the salary / will I get a PPO?" (ask recruiter later, not HM) — sounds mercenary. 2. ❌ "What does Walmart do?" / "Do I have to do on-call?" — shows zero research / low ownership. Instead ask "How does on-call work for interns and how do you mentor through first incidents?" if you must.

3.13 Rapid-Fire HR (60s each)

• Critical feedback? "A reviewer flagged my cache invalidation as under-documented after a day of stale reads. I didn't defend it — I wrote the 1-pager + sequence diagram the same week and made it a PR requirement." He was right, the cost was visible, and the fix became a standing rule. Never answer "I don't really get negative feedback."
• Why hire you? "Builder, breaker, AI-security overlap: 600+ users and 3M visits shipped, three real vulns found and fixed in my own stack, and Siege's LLM red-teaming maps to Walmart's AI-for-security scope." Say it in 20 seconds and stop.
• Other offers? "I'm interviewing elsewhere, but Walmart's security scale is my first choice — I'm not using offers as leverage." Then give one concrete reason (retail peak + AI-for-security scope) so it does not sound scripted. Never mention compensation here.
• Low mark / CGPA? "8.68/10 — I chose to build and ship (Gravitas, CookOff, two internships) alongside coursework; my security and systems fundamentals are strong." If they press on a specific weak subject, admit it and name what you did to close it; do not blame the grading.
• Difficult person? "On Xlancr we had different working styles — I traded a data spike instead of arguing; we shipped together and he reviewed my PR." Add the principle: separate the person from the problem and let the numbers decide. Never label anyone "difficult."
• Biggest skill gap? "Kubernetes and eBPF — my Docker/Linux ops are solid; I'm working through K8s hardening and eBPF observability now." Pair it with what is already strong — Go backend, concurrency, application security — so it reads as a plan, not a hole.
• Another failure? "Xlancr cache v1 shipped with thin docs → a day of stale reads (reads only, no writes). Fix: write-through invalidation + 1-pager + 70% CI coverage." Close on the durable change; this second-failure probe tests whether the first failure story was rehearsed or real.

4. Q&A Bank — 12 Model Answers (Steal These)

Q1. Tell me about yourself? → Use §3.1 verbatim. End with "...and that's why I'm here — retail scale + AI security." 30s version: "Final-year CS, I build at scale, I found three real vulns in my own stack, and now I do LLM red-teaming — Walmart is where I want that at retail scale."

Q2. Hardest problem? Gravitas 2025 (Sep 2025) race + pool leak caught in load test → Lua atomic hold + all-path defer rollback → 3M visits, 0 double-books, 0 downtime. Say: "Two failures interacting — a seat-hold race and a transaction leak that only showed at peak load. Fixed both, zero downtime across 3M visits." Q3. Vuln found? Siege registry keyed by pool only (Sep 2026) → PoC → re-key (pool,uid) + fail-closed + regression tests → found internally, fixed pre-deploy, 0 exploitation. "IDOR analogy." Say: "A session key missing the tenant ID — my own tool, caught in review, PoC'd, fixed pre-deploy, zero exploitation." Q4. Deadline slipping? CookOff (Sep 2024) 15k evals, verdicts slipping past 10s → Must/Nice split, 3 of 5 on queue → shipped pre-fest, <10s at 200/min. Say: "We would have missed the fest start, so I split Must and Nice with the organizer and shipped Must on time." Q5. Disagreement? Xlancr (Sep 2024–Feb 2025) cache vs bigger server → 1-day spike (~-50% p95 + cost) → shipped cache, co-presented, intact. Say: "He wanted a bigger server, I wanted a cache — I built a one-day spike and brought numbers instead of an argument." Q6. Ambiguity? Siege no-spec → 3-day recon + 1-pager (4 channels, 19 techniques) + demos → v1 in 6 wks. Say: "No spec, so I did three days of recon, wrote a 1-pager, got sign-off, and shipped a usable v1 in six weeks." Q7. Failure? My TXN leaks on error paths → caught pre-fest in load test → all-path defer + chaos test → 50L clean, 0 downtime. "All-paths proof now." Say: "I shipped payments tested only on happy paths; the load test found my transaction leak; I owned it and made all-path handling a review rule." Q8. Led team? CookOff 5 + coordinator → split by strength, PR rules, mock peaks → 15k, <10s, juniors solo wk 2. Say: "Five people, mixed levels — I split work by strength, set PR rules, and both juniors were shipping on their own by the end." Q9. Why Walmart? "3M lessons at Fortune-1 scale + invisible checkout security + GT India eng — want intern→FT." Cite a blog and one JD term — anomaly, phishing, malware or fraud detection. Q10. Why security/AI + current? "Broke my own session → hooked. Prompts=new injection. Current: OWASP LLM Top 10, MS red-team papers, HTB, CTF 2nd, Garak." Say: "Security became real when I replayed a token and became another user. Prompts are the new injection — blocklists fail, so defence has to be architectural." Q11. Strength/weakness? Strength: load debugging (pool fix). Weakness: undocumented TTL → now 1-pager per component. Say: "Strength: I debug under load with metrics — I reproduced the pool exhaustion at peak. Weakness: I under-documented early; now every shared component ships with a 1-pager." Q12. MS/relocate/5yr? "No MS next cycle, BLR/MAA yes. 5yr: detection + AI red-team for retail." + ask §3.12. Say: "No MS next cycle; Bengaluru or Chennai both work. In five years I want detection and AI red-teaming for retail."

Follow-ups: Expect "What was your exact contribution vs team's?", "How did you validate?", "What would you do differently?" — answer with test/number/lesson, not philosophy.

5. Revision Table — Memorize in 15 Minutes

6. Mistakes That Fail This Round

1. Vagueness — the #1 killer. "We improved security / handled scale." HM hears zero. Fix: S+T in 30s, then numbers. Every answer ends with count/%/date.
2. No outcome / no learning. Stopping at Action. Fix: always close "Result was X; what I'd do differently is Y." They score R, not effort.
3. Blaming / trash-talking. "My teammate was lazy / manager was clueless." At Walmart (Respect value) you fail instantly. Fix: "We had different constraints; I brought data; relationship stayed strong."
4. Generic Why-Walmart. "Big brand, stable, good pay, want to learn." Fix: scale (cart/inventory at Fortune-1) + mission (save families money → invisible security) + specific (GT India blog, SOC stack, AI search). Name one real artifact you read.
5. "We" everywhere. "We fixed..." Who did what? Fix: "I proposed / I implemented / team reviewed." Claim credit without hogging.
6. Fake weakness or no failure. "I'm a perfectionist" or "No failures." Fix: real bug (transaction leak), owned rollback, systemic prevention.
7. Rambling >3 min / 10s one-liners. Both fail. Fix: 90-120s STAR, then stop. Let them probe.
8. No questions / bad questions. "No questions" = no curiosity. Salary/PPO to HM = mercenary. Fix: ask §3.12 — SOC stack + findings→prod + conversion win.

Night-before: ☐ 6 STARs <2 min ☐ Intro <90s ☐ Why Walmart/security ☐ Weakness+fix ☐ MS/relocate ☐ 2 questions ☐ sophic.dev + GitHub open ☐ timeline drill (project → date + 2 numbers) ☐ screen hygiene (notifications off, notes off-screen).

Be specific, honest; tie every number to a customer.