₹8 LPA to ₹55 LPA in 4 Months (No BS Breakdown) ft. Dhairyasheel
Harkirat Singh · 33:27 · 2026-04-16
What This Is Actually About
Dhairyasheel (24) graduated in 2023 with an 8 LPA service-based consulting job in Pune, spent 2 years in a toxic environment working on legacy Java/VM setups, then quit everything to join Harkirat's Super 30 cohort. Within 4 months of joining Cal.com as an intern (60,000/year (roughly 55 LPA). The video is a breakdown of exactly what he did differently to make this jump possible, with specific focus on the Cal.com hiring process, interview strategy, and the mindset required to convert internship to full-time at a high-growth remote startup.
tldr.md
8 Lpa To 55 Lpa In 4 Months No Bs Breakdown Ft Dhairyasheel
Dhairyasheel quit his 8 LPA job entirely before joining Cal.com as an intern. Friends told him to keep his old job as a fallback, use referrals, or hedge his bets. He rejected all of it. His logic: if he kept the safety net and failed, he would always wonder if he didn't give 100%. By burning the bridge, he eliminated the psychological option to retreat. This was a calculated decision based on hating his previous daily work environment (remote desktop lag, boring billing software, toxic pressure).
What this means for developers: Risk appetite varies by person and background, but keeping a "fallback" often becomes a ceiling. The mindset shift was treating the 4-month internship as the only option—working 12+ hour days, sometimes skipping sleep, to maximize conversion probability.
Open Source as the Only Credential
Cal.com's hiring process for interns is deliberately simple: contribute to their open source repository, email the head of engineering (Keith) with your contributions, and get an interview slot. No referrals needed, no complex application portals. Dhairyasheel had contributed to Cal.com's repo before applying. He also had GSOC (Google Summer of Code) experience with Rocket.Chat. These two credentials—visible, public code—were more valuable than his 2 years at a service company.
Critical detail: Cal.com prefers backend/API contributions over UI-only PRs. Dhairyasheel specifically mentioned that other candidates had more PRs but they were UI-heavy; his were distributed across backend, APIs, and architecture, which made him stand out.
Interview Preparation as a Product Demo
For the 30-minute Cal.com interview, Dhairyasheel prepared like he was pitching a product:
The interview ended in 20 minutes with an on-spot offer. His preparation signaled that he could ship production code immediately, not just answer algorithmic questions.
Developer takeaway: Treat interviews as demo days, not Q&A sessions. Deployed code + visual architecture > resume bullet points.
Converting Internship to Full-Time at Cal.com
Cal.com is known for hiring interns and not converting them. The previous Super 30 batch had a near-100% conversion rate, which was unusual. Dhairyasheel's approach during the 4-month internship:
Free work beyond assigned duties: Interns are technically hired to review community PRs. He did that, then asked the Product Engineer (Karina) for additional issues he could own. Took on testing for fast-moving features when the main developers couldn't test thoroughly.
Visibility through shoutouts: The company has a "Gratitude" channel for recognizing good work. Dhairyasheel received 3-5 shoutouts during his internship and DMs from senior developers and leadership saying "you're doing great work."
100% availability: He worked from waking up to sleeping, with only food/walking breaks. Not because of pressure, but because he treated this as his only shot.
The Reality of "AI Slop" in Production Code
Cal.com provides Devin and Cursor access to engineers. Dhairyasheel estimates 80-90% of his code is now AI-generated, with implementation taking 40-50% of the time and testing taking the rest. However, he identified clear patterns that separate good AI-assisted PRs from "AI slop":
Red flags (immediately visible to reviewers):
AI creates duplicate functions instead of reusing existing ones
AI implements all 3 possible solutions when only 1 is needed (user commits all 3)
No proof attached: no screenshots, no videos, no performance metrics for backend/database changes
Green flag: AI is fine to use, but you must test manually, attach proof of testing, and ensure the code follows existing patterns. Reviewers can spot "vibe coding" instantly.
The Path from SD1 to SD3: No Courses, Only Production Experience
When asked how to grow from junior to senior (SD1 → SD2 → SD3), both Dhairyasheel and Harkirat agreed: there are no courses for this. The only path is experiencing real production issues over time:
Database sharding when queries slow down
Cloud infrastructure failures at scale
ISP-related issues
Server outages under real user load
30-day release cycles with production fixes
These are not theoretical. Cal.com is a full-stack product with 30-day release cycles and real users hitting real scale issues. Two years at Cal.com equals SD2 in most other companies because you're shipping to production, fixing live issues, and touching all layers of the stack.
Harkirat's specific advice: Working at Cal.com specifically accelerates this because it's a small team with systems going to many users. You see issues daily that would take 5 years to encounter at Google. After 2 years at Cal.com, you can likely command senior roles at Amazon or other big tech companies.
Side Bets vs. Deep Work
Harkirat's closing advice to Dhairyasheel: now that he has achieved the initial goal (55 LPA at 24), he should treat that as his "last achievement." The next phase should be about "side bets"—spending the other 8 hours of the day on technically stimulating work beyond the day job. Examples: Upwork contracts, Toptal, Twitter/X freelance, or building something own. Not for money necessarily, but to accelerate learning 3x by exposing the brain to different problems at different companies simultaneously.
Key insight: 8 hours at one company has diminishing returns. The last 2 hours of a 10-hour day are less productive than the first 2 hours at a completely different technical context.
If You Remember Nothing Else
Burn the boats: Keeping a "safe" job while trying to convert an internship gives you an excuse to not give 100%. Dhairyasheel quit his 8 LPA job completely before starting the Cal.com internship.
Open source is the resume: Cal.com hired him because he had contributed to their public repo. No referrals, no connections—just code they could read.
Demo, don't describe: In interviews, he showed live deployed apps with architecture diagrams. The interview ended in 20 minutes with an immediate offer.
AI slop is visible: Using AI is fine, but reviewers instantly spot when you blindly commit AI output—duplicate functions, missing tests, no proof. Always test manually and attach screenshots/metrics.
SD3 has no course: You cannot study to become senior. You have to ship, break things in production, fix scale issues, and repeat. Small teams with real user load accelerate this faster than big tech.
Watch Out For
"Just contribute to open source" oversimplification: Dhairyasheel mentions that when Cal.com announces hiring, there's a sudden burst of PRs that fizzle after 1-3 weeks. Long-term, consistent contribution over months is what gets noticed, not a flurry of activity when news breaks.
Survivorship bias on risk-taking: Harkirat explicitly notes he would NOT have taken the same risks at 24—he would have kept the 8 LPA job and moonlighted. Risk appetite depends on background and obligations. Dhairyasheel's no-backup strategy worked, but it could have failed.
AI training data contamination: Harkirat notes that AI models have likely trained on Cal.com's open source codebase, which means they can generate plausible-looking Cal.com code that is actually wrong. This makes "AI slop" harder to detect for that specific codebase.
Missing counterfactual: The video doesn't address how many Super 30 cohort members attempted this path and failed. The sample size is small, and the 100% conversion rate mentioned for Dhairyasheel's batch may not be representative.
