Three Lead Platform Engineer interviews. Six weeks. Same rejection, almost word for word: “strong operations background, but we’re looking for someone who’s built the paved road, not just maintained it.”
If you’ve been a senior engineer in Indian tech for 10+ years and you’re trying to break into Lead or Staff roles in 2026, you’ve probably heard a version of this too. The market has shifted. Fifteen years of experience, by itself, is not the differentiator it was five years ago. What hiring managers want to see — before they’ll even open the technical round — is evidence. A real portfolio project for Lead Platform Engineer candidates — a public artifact that proves you can design, build, and ship platform-grade infrastructure end to end.
So two weeks ago, I built one. A public, fully reproducible, AI inference platform on AWS EKS — Mistral 7B serving on a Karpenter-provisioned GPU through KServe and vLLM, all as Terraform code. This is the honest 2026 guide to building a portfolio project for Lead Platform Engineer interviews — written in real time, from inside the same problem many of you are navigating right now.
If you’re navigating the same transition, the rest of this post is my working-through of what I think actually moves the needle, where my own bets are placed, and what the next 90 days will tell me about whether this strategy works. It’s the article I wish someone had written for me at the start of these two weeks.
WHAT THIS PORTFOLIO PROJECT FOR LEAD PLATFORM ENGINEER GUIDE COVERS
- Why most portfolio advice fails for seniors — the hiring-manager signals that matter at 10+ years vs the ones that matter at 2 years
- The project I built and why I bet on AI/ML infrastructure — the market research behind choosing where to invest 30 hours
- The three nights of 2 AM debugging — the real stories that are becoming my Lead interview material
- The honest cost and return — exact hours, exact AWS spend, what I’m actually measuring over the next 90 days
- The 5-step framework — if you want to build your own, this is the sequence that works
About 15 minutes end-to-end. If you’re pressed for time, read sections 2 and 4 — the hiring-manager signals and the three nights of debugging carry most of the practical value.
1. The 2 AM Thought Every Senior SRE Has Had
It’s 2 AM. The baby is asleep in the next room. The villa we bought with a 2027 possession date needs its next EMI in eleven days. Three Lead Platform Engineer interviews rejected in the last six weeks, two of them before the technical round even started. The feedback was always some version of the same sentence.
If you’ve lived this scene, you know the specific texture of it. The spreadsheet open on one monitor with the comp band you need to reach. The LinkedIn job tab open on the other. The quiet, nagging suspicion that the problem isn’t the market — it’s that you’ve been doing the same shape of work for too long and nobody can tell what you’d ship if given the chance.
Fifteen years in Indian tech. Lead Platform Engineer on paper, managing large-scale EKS and ECS Fargate platforms at a Fortune 500 client. HashiCorp Terraform certified. The résumé reads clean. And yet — the market is telling me the résumé isn’t the problem. The proof is the problem.
That’s the gap I decided to close over the last two weeks. Not by applying harder. By building something public that answers the hiring manager’s unasked question before they even ask it.
2. Why Most Portfolio Advice Fails Senior Engineers
Here’s the uncomfortable truth about most portfolio advice floating around LinkedIn and YouTube in 2026: it’s optimized for juniors trying to land their first job, not seniors trying to break into Lead. The right portfolio project for Lead Platform Engineer candidates — the kind that actually converts into interview callbacks at your target compensation band — looks nothing like the tutorial-follow projects that worked at year three.
“Deploy a three-tier app to Kubernetes!” “Build a CI/CD pipeline with GitHub Actions!” “Set up monitoring with Prometheus!” These projects demonstrate you can follow a tutorial. They do not demonstrate you can be a Lead. A hiring manager scanning for a Lead-level IC is looking for completely different signals.
I spent two days before touching any code reading Lead Platform Engineer and Senior SRE job descriptions from Flipkart, Swiggy, Razorpay, Walmart Global Tech, GCCs in Hyderabad and Bangalore, and product companies in the ₹60L+ compensation band. The pattern underneath the job descriptions was consistent:
Signal 1: Evidence of debugging in production conditions
Not “I built the happy path and it worked.” Proof that you’ve hit real production problems, diagnosed them under pressure, and documented the fix in a way the next engineer can learn from. This is the single strongest signal hiring managers look for in a senior candidate’s public work.
Signal 2: Architecture decisions with explicit trade-offs
Not “I used Karpenter.” Why Karpenter over Cluster Autoscaler. What you gave up. When you’d choose the other. The ability to defend a design decision with the same clarity as making it — that’s the Lead-vs-Senior line in interviews.
Signal 3: Cost awareness and FinOps thinking
Senior engineers burn money. Leads optimize it. Can you talk about spot vs on-demand pricing, scale-to-zero economics, cost per inference request? Can you justify an infrastructure choice in rupees per month? Most senior engineers can’t — and the ones who can get Lead offers.
Signal 4: Reproducibility — everything as code
Not a tutorial-follow with manual AWS console clicks you can’t rebuild. If a hiring manager clones your repo on Monday, they should have your exact setup running inside two hours. Terraform modules, phased deploy, documented teardown. This is what “paved road” means in practice.
Signal 5: Documentation that reads like you’d write it at work
A JOURNAL.md with real debugging stories dated and timestamped. A DEPLOY.md that actually works. A README that doesn’t exaggerate. Hiring managers can smell a project that was documented after the fact for the portfolio — and they can smell one that was documented in real time while the engineer was actually figuring it out. Only the second type carries signal.
The default advice fails on all five. A tutorial-follow project — the kind that works for a junior career — checks none of these boxes at the senior level. That’s why it doesn’t convert. If you’re thinking about building a portfolio project for Lead Platform Engineer interviews, the five signals above are what you’re building for. From day one, I decided the debugging was going to be the portfolio project, not the finished infrastructure.
3. The Portfolio Project I Built for Lead Platform Engineer Interviews — and Why I Bet on AI Infrastructure
The portfolio project: paved-road-ai-eks — a public reference architecture for serving open-source LLMs on EKS with GPU autoscaling. Fully reproducible via Terraform. Mistral 7B served on a Karpenter-provisioned NVIDIA T4 GPU through KServe and vLLM. OpenAI-compatible API, Prometheus and Grafana observability including GPU metrics via NVIDIA’s DCGM exporter, scale-to-zero economics.
If that stack reads like noise, the deeper technical deep-dive is in the repo README. This post isn’t about the architecture. It’s about why I bet on this specific project out of a hundred possible options, because that bet is the single highest-leverage decision in the whole exercise.
Why AI/ML infrastructure, specifically
Because that’s where the market pays premium right now, and I’m willing to say it out loud. If you’re picking a portfolio project for Lead Platform Engineer interviews in 2026, the market segment you choose matters at least as much as the quality of your execution. The pattern across those Lead-level job descriptions I spent two days reading was overwhelming:
- Roles that mentioned “AI/ML infrastructure,” “GPU workloads,” “model serving,” or “LLM operations” paid 30-50% more than equivalent Lead SRE roles without that specialization
- They were easier to interview for, not harder, because most senior SREs haven’t built this kind of thing yet. The applicant pool is smaller
- The technical content overlaps 70% with what you already know as a Kubernetes practitioner — EKS, Terraform, Karpenter, Helm, Prometheus. The remaining 30% (KServe, vLLM, GPU tuning, NVIDIA device plugins) is learnable in two weeks of focused work
So the economic calculus was simple: maximum portfolio differentiation for the smallest learning investment, in the segment of the market with the fastest-growing demand. If you’re thinking about building your own paved road and you need a decision framework for what to build, that’s the one I’d use.
What the stack actually is, in one paragraph: a Terraform-managed EKS 1.35 cluster with Karpenter 1.6.0 handling GPU node autoscaling to zero when idle, KServe + Knative Serving providing an OpenAI-compatible model-serving layer, vLLM as the inference engine running Mistral 7B on a g4dn.xlarge T4 GPU, NVIDIA device plugin and DCGM exporter for GPU observability, and Prometheus + Grafana for metrics. Everything in a public GitHub repo with every commit visible. First inference happened on 2026-10-15 at 7:56 PM IST after about 30 hours of work spread across two weeks.
None of that is interesting, by itself, as a Lead interview story. The debugging is.
4. The Three Nights of Debugging That Became the Portfolio
Here’s the shift I want you to internalize if you take nothing else from this post: when you build a portfolio project for Lead Platform Engineer interviews, the debugging IS the portfolio project. The green checkmarks at the end are not the signal. Any junior engineer with a copy of the tutorial can produce the green checkmarks. The signal is the walk — the specific scars, the specific decisions, the specific stories you can defend in a Lead interview.
Here are four of them, pulled from the JOURNAL.md in the repo, where I logged every one in real time with timestamps and commit references. Each one maps directly to the kind of answer that signals “this candidate has been in production” vs “this candidate watched a YouTube tutorial.”
The GPU Nodes That Launched But Never Joined
Karpenter is running. Terraform apply is clean. I submit a Mistral deployment. Karpenter sees the pending GPU pod, requests a g4dn.xlarge spot instance from AWS, and the EC2 instance launches successfully. The console output shows kubelet starting, the NVIDIA driver loading, every bootstrap step succeeding. But kubectl get nodes never shows the node joining the cluster. No error anywhere obvious. The instance is just sitting there at $0.1578/hour doing nothing while I debug.
Four hours in, I find it. EKS replaced the old aws-auth ConfigMap flow with the access-entries API, and Karpenter’s node IAM role wasn’t in the authorized principals list for the cluster. EKS was silently refusing the kubelet’s join request. No log entry on the EKS side. No event in Karpenter. Just a GPU EC2 instance quietly running, costing money, going nowhere.
The Container That Kept Getting Killed Mid-Load
Vedika is crying in the next room. I’m watching my Mistral pod go through its fourth CrashLoopBackOff of the night. Every attempt looks the same: vLLM starts downloading the 15 GB model from Hugging Face, gets to about 60% loaded, and then — gone. Container killed. Pod restarted. Loop forever.
I spend an hour chasing memory limits before realising it isn’t a memory problem. KServe is injecting a default readinessProbe with a 30-second window into every InferenceService Deployment that doesn’t specify one. Mistral 7B takes 5-10 minutes to load on a T4. The probe is firing, marking the pod unhealthy, and killing the container long before the model finishes loading.
Fix: explicitly omit readinessProbe and livenessProbe from the InferenceService spec, keep only a startupProbe with a 15-minute window. Three lines of YAML. The lesson is bigger — default Kubernetes probe timings assume stateless web services that boot in seconds, and they’re actively harmful for LLM inference containers that take minutes.
startupProbe window and no readiness or liveness probes during initial boot — otherwise the operator reconciles its defaults back in and kills your pod mid-load.” That’s a technical-leadership answer.
The 16 GB GPU That Couldn’t Fit a 7 Billion Parameter Model
Mistral 7B weights in float16 are 13.5 GB. A T4 has 16 GB of VRAM. That should be comfortable, right?
Not even close. The model loads fine. Then vLLM crashes: “ValueError: No available memory for the cache blocks. Try increasing gpu_memory_utilization when initializing the engine.”
The math, once I sit down with it: at vLLM’s default --gpu-memory-utilization=0.9, vLLM caps itself at 14.4 GB total. Subtract 13.5 GB for weights and about 500 MB for CUDA runtime overhead, and that leaves roughly 400 MB for KV cache. Not enough to serve a single token of context.
Fix: bump to --gpu-memory-utilization=0.95 AND cap --max-model-len=4096 instead of the default 8192. Combined, that yields about 800 MB of KV cache headroom. Enough to serve real workloads.
Never Trust “Auto” on a New Model Family
Container starts. Model weights download fine. Container crashes with “TypeError: expected str, bytes or os.PathLike object, not NoneType” deep inside Hugging Face’s tokenizer loading code. The traceback is three hundred lines of Python internals and makes no immediate sense.
What’s happening: vLLM’s default --tokenizer-mode=auto tries the fast tokenizer first, falls back to the slow SentencePiece one when the fast path misbehaves, and the slow loader expected a vocab_file path that wasn’t set. The fix is explicit --tokenizer-mode mistral, which bypasses the Hugging Face fallback chain entirely and uses Mistral’s native tokenizer path.
This is the scar that generalizes the most. The lesson: never trust “auto” settings in inference engines on newer models. Pick the explicit mode that matches your model family, even when auto should work. It’s the kind of specific, defendable production wisdom that reads differently in a design conversation than tutorial knowledge.
--tokenizer-mode mistral explicit, every time. The failure mode when you leave it on auto is a cryptic NoneType error deep in HF internals that costs an hour to diagnose. That’s the kind of thing you only know after you’ve been there.” That’s a battle-scar answer.
5. The Honest Cost and the Honest Return
If you’re weighing whether to build your own portfolio project for Lead Platform Engineer interviews, the question that matters is not “will it work?” — it’s “what will it cost me, and what’s the realistic return?” I promised honest numbers at the top. Here they are, without rounding.
What it cost me
| Cost | Actual | Notes |
|---|---|---|
| Time | ~30 focused hours | Three overnight debugging sessions (Oct 12-13, 13-14, 14-15), one successful deploy session (Oct 15), one re-deploy for proof capture (Oct 16). Not sustainable at this pace. |
| AWS spend | ~₹2,000 total | Across all deploy/destroy cycles. Scale-to-zero via Karpenter kept idle cost near zero. I tore down the cluster every single night. |
| Energy | Significant | 2 AM debugging sessions with an infant daughter and a working day the next morning. If I were doing this again I’d spread it over four weeks instead of two. |
| Opportunity cost | Two weekends | Blog posts I didn’t write. Family time I didn’t have. These are real costs that career advice usually doesn’t name. |
What it got me — so far
Here’s where I have to be transparent. I don’t have interview-conversion data yet. The repo went public on 15 October. This post is being written on 16 October. Any hiring-manager impact is weeks away from being measurable.
What I can measure after one week:
- Technical confidence shift — real. I now have end-to-end working knowledge of a stack (KServe, vLLM, Karpenter GPU, DCGM) that was abstract to me two weeks ago. In a Lead interview that goes technical, this is now ground I can defend.
- Résumé artifact — real. “Built public reference architecture for AI inference on EKS, serving Mistral 7B on Karpenter-provisioned GPUs via KServe + vLLM” is a line that did not exist on my résumé two weeks ago.
- GitHub profile signal — real. Hiring managers who click through now see a repo with 40+ commits, a detailed JOURNAL.md, Terraform modules, and evidence of real debugging. Different signal from an empty profile.
- Interview conversion rate — TBD. I’ll update this post with real numbers 90 days from today.
6. The 5-Step Framework for Building a Portfolio Project for Lead Platform Engineer Roles
If you’re a senior engineer thinking about building a portfolio project for Lead Platform Engineer or Staff SRE interviews in 2026, here’s the framework I wish someone had handed me at the start of these two weeks.
Step 1: Pick a project in a segment where the market pays premium
In 2026 that’s AI/ML infrastructure, FinOps, platform engineering, or developer experience. Research actual Lead-level job descriptions in your target compensation band and reverse-engineer what they test for. Avoid “generic Kubernetes tutorial clone #4,712.” The market segment you choose is at least half the eventual return.
Step 2: Make it reproducible via infrastructure as code
Not a tutorial-follow with manual console clicks. If a hiring manager can’t clone your repo and have it running inside two hours, it doesn’t count as a portfolio project — it counts as a demo video. Terraform modules, phased deploy, documented teardown. The code is the real artifact.
Step 3: Document the failures, not just the successes
A clean README with “it works!” screenshots is worth less than a JOURNAL.md with 20 real debugging stories. The failures prove you’ve been there. The successes prove nothing — anyone can copy-paste a working config. If I had to choose between polishing the architecture and polishing the journal, I’d polish the journal every time.
Step 4: Keep the repo public and the commit history visible
Every commit is a timestamped proof of progress. Hiring managers do click through. Don’t force-push, don’t rebase history, don’t delete the embarrassing early commits where you learned what Karpenter was. The messy history is the credibility.
Step 5: Write about it in your own voice
Not a dev.to technical reference. A post that connects the technical work to your career narrative — the kind you’re reading right now. The technical post is for GitHub. The career-angled post is what drives hiring managers from your blog to the repo. If I had written only the technical version and skipped this one, 70% of the eventual return would be gone.
Three questions to be honest with yourself about
- Do you have 4-6 weeks of runway where you can commit focused evening hours without wrecking your family or current job?
- Are you willing to accept short-term stress and lower output in exchange for a step-change in trajectory?
- Is your current situation actually bad enough to warrant the disruption — or are you catastrophizing based on Blind posts?
If you can say yes on all three, start this quarter. If you can say no on any — especially the third — the honest answer is sometimes to stay in your current role, do the preparatory work of specialization first, and revisit the portfolio-project decision in 12 months from a stronger position. Not every quarter is the right one to make this bet.
A Word Directly to You
If you’re 10+ years into Indian tech and the Lead role has been just out of reach for the last two interview cycles, I want you to hear this specifically. The feedback you’re getting is not about your technical ability. It’s almost always about the evidence gap — the hiring manager can’t see what you’d ship when given room to lead, because nothing you’ve shipped publicly tells them.
That gap is closable in 4-6 weeks of deliberate work. A well-chosen portfolio project for Lead Platform Engineer interviews — picked in a segment the market is paying premium for, built in public, with failures documented as carefully as the successes, written up in your own voice connecting the technical work to your career narrative — is the artifact that does the talking for the next 90 days.
I’m testing this strategy in my own career, right now, in real time. I’ll be back in 90 days with honest numbers — including if it didn’t work. If you’re scoping your own portfolio project for Lead Platform Engineer interviews and want a second opinion, DM me on LinkedIn. I’ll help you narrow it down to something that actually ships inside a month, instead of becoming the project you’ve been “working on” for six.
Rooting for all of you.
— Arvind
Quick Reference — The Senior Portfolio Project Playbook
The Sharp Claim
The right portfolio project for Lead Platform Engineer interviews is not the one that got you your first junior job. Different signals, different artifact, different build strategy.
What Lead Hiring Managers Actually Look For in a Portfolio Project for Lead Platform Engineer Roles
- Evidence of debugging in production conditions
- Architecture decisions with explicit trade-offs
- Cost awareness and FinOps thinking
- Everything as code — reproducible via git clone
- Documentation written in real time, not after the fact
The Market Bet for 2026
If you’re picking a portfolio project for Lead Platform Engineer roles, AI/ML infrastructure pays 30-50% more than equivalent Lead SRE roles without that specialization. 70% skill overlap with what you already know as a Kubernetes practitioner. Smallest learning investment for the largest market differentiation.
The 5-Step Framework
- Pick a project in a premium-paying market segment
- Make it reproducible via infrastructure as code
- Document the failures, not just the successes
- Keep the repo public with the full commit history
- Write about it in your own voice, career-angled
The Honest Cost
~30 focused hours over 2 weeks. ~₹2,000 AWS spend. Significant energy drain if compressed. Spread over 4 weeks if you can. 90-day interview-conversion update coming January 2027.