Reflections

Thank You - My Mentors, Guides, Teachers, Parents & Everyone

Nikesh — Sun, 26 Oct 2025 08:15:30 GMT

I've been writing these blogs for a while now, documenting projects, struggles, lessons, and the messy process of learning. But I realized I haven't written the most important one yet—the one where I acknowledge that none of this happened alone. So this is that post. A big thank you to everyone who made this journey possible.

To my parents, who let me try things even when they didn't fully understand why. When I told you I wanted to join Scaler alongside IB, you could have said it was too much. When I wanted to attend Master's Union bootcamps, you could have questioned if it was worth it. When I asked to go to Dubai for GITEX, you could have said focus on your studies instead. But you didn't. You trusted that I knew what I was learning from, even when the path didn't look traditional. You gave me the freedom to explore, to fail, to try again. That freedom is the foundation everything else is built on. Thank you for believing in my curiosity even when it led to late nights, stress, and unconventional choices. Thank you for supporting dreams that don't fit neatly into checkboxes on application forms.

To my teachers at school, especially those who saw that learning happens outside the classroom too. Thank you for understanding when I was exhausted from balancing too many things. Thank you for not making me choose between IB and everything else I was trying to do. Thank you for asking questions that pushed my thinking, for giving feedback that made my work better, for treating me like someone capable of handling challenges rather than protecting me from them. You taught me that education isn't just about grades—it's about developing the ability to think critically, question assumptions, and keep learning long after school ends.

To the team at Scaler, thank you for taking a chance on a 17-year-old who wanted to learn software engineering while still in school. Thank you for not watering down the curriculum or making it easier because I was young. Thank you for treating me like a serious learner who could handle rigorous content if I was willing to put in the work. The late nights debugging code, the frustration of not understanding concepts immediately, the satisfaction of finally solving problems—all of that taught me more than just programming. It taught me how to think like an engineer, how to break down complex problems, how to persist when things don't make sense. That's a skill set I'll carry forever.

To everyone at Master's Union, thank you for creating bootcamps that weren't just theoretical business lessons but actual hands-on experiences. Thank you for the ApniDukaan challenge that forced me to understand e-commerce by doing it, mistakes and all. Thank you for the pitch competitions that taught me how to articulate ideas under pressure. Thank you for creating an environment where it was okay to try, fail, learn, and try again. The back-to-back competition wins felt good, but what mattered more was learning that business isn't something you study—it's something you do. You gave me the space to do it badly at first and get better through iteration.

To my manager and the entire team at CuriousRubik, thank you for hiring an intern who had no idea what a Business Analyst actually did. Thank you for letting me sit in client meetings even when I was obviously lost. Thank you for patiently explaining concepts I should have known but didn't. Thank you for treating my mistakes as learning opportunities rather than failures. Thank you for showing me what it looks like to translate business problems into technical solutions, to bridge the gap between what clients need and what developers build. Every time I misunderstood a requirement, you helped me see what I'd missed. Every time I asked a basic question, you answered it without making me feel stupid. That patience and guidance shaped how I think about work, collaboration, and learning.

To the developers at UnyKloud, thank you for welcoming a junior intern who was still figuring out how React actually worked. Thank you for reviewing my code and pointing out issues in ways that helped me learn, not just fixing things for me. Thank you for explaining why certain approaches were better than others, for showing me what good code structure looks like, for teaching me that performance and user experience matter as much as functionality. Thank you for letting me struggle with problems before stepping in to help—that struggle is where real learning happened. Watching you work taught me what it means to think like a developer, to anticipate problems before they happen, to write code that other people can actually understand and maintain.

To my senior teammates on the machine learning research project, thank you for letting me contribute even though I was clearly the least experienced person on the team. Thank you for explaining concepts multiple times when I didn't get them the first time. Thank you for treating my questions seriously instead of dismissing them as too basic. Thank you for showing me what real research looks like—the iterations, the failed experiments, the slow process of figuring things out. I'm still learning, still catching up to your level of understanding, but you've made that gap feel like something I can close with time and effort rather than something insurmountable.

To the MUN community and my fellow delegates, thank you for creating spaces where teenagers can engage with complex global issues and practice diplomacy. Thank you to the senior delegates who gave me advice after I froze at my first conference, who told me that everyone messes up and what matters is showing up again. Thank you for the debates that pushed my thinking, the resolutions we drafted together, the late-night committee sessions where we actually worked through difficult problems. Those experiences taught me how to listen to perspectives different from mine, how to build consensus, how to argue for positions I might not personally agree with. That's training for engaging with the world as it actually is, not as we wish it were.

To my friends who've supported this chaotic journey, thank you for understanding when I couldn't hang out because I had deadlines. Thank you for listening to me talk about projects you probably found boring. Thank you for celebrating the wins and commiserating over the failures. Thank you for keeping me grounded when I got too stressed about everything I was trying to do. Having people who know me as just Nikesh—not as achievements or projects, just as a person—has been more important than I realized.

To everyone who's engaged with my content—watched a YouTube video, listened to a podcast episode, read a blog post—thank you for giving my learning documentation your time and attention. Thank you especially to those who commented, who shared what helped them, who asked questions that made me think harder. Knowing that documenting my messy learning process might help even one other person makes the vulnerability of creating in public feel worthwhile. You've taught me that sharing what you don't know yet is more valuable than pretending expertise you don't have.

To the founders I met at GITEX who took time to talk to a random student who couldn't offer them anything professionally, thank you. You didn't have to stop and explain your businesses to someone who was just curious. You didn't have to share the hard parts, the failures, the pivots that didn't work. But you did. Those conversations gave me a realistic picture of what building companies actually looks like, beyond the polished success stories. That honesty was generous and genuinely helpful.

To my extended family who've supported and encouraged me even when they weren't sure what exactly I was doing, thank you. Thank you for asking questions about my projects even when the answers were technical and confusing. Thank you for celebrating the small wins—getting into programs, finishing projects, learning new skills. Thank you for believing that unconventional paths can lead somewhere meaningful, even when the destination isn't clear yet.

I also want to acknowledge the privilege of having these opportunities in the first place. I'm fortunate to have parents who can support my education, access to programs like Scaler and Master's Union, the ability to take internships that might be unpaid or low-paid, the resources to attend conferences in other countries. Not everyone has these opportunities, and I don't take that for granted. The fact that I can explore different interests, try things and fail, learn from experiences beyond my classroom—that's a privilege. I'm aware of it, grateful for it, and I hope to use what I'm learning to eventually create opportunities for others too.

To everyone who saw potential in me before I saw it in myself, thank you. To everyone who pointed out my gaps in knowledge without making me feel inadequate, thank you. To everyone who pushed me to try harder without making me feel like my best wasn't enough, thank you. To everyone who shared their own struggles and failures so I'd know mine were normal, thank you. To everyone who answered my questions patiently even when they were basic, thank you. To everyone who gave feedback that was critical but constructive, thank you. To everyone who believed I could figure things out even when I wasn't sure, thank you.

I'm 17, still learning, still making mistakes, still figuring out what I want to do with all this knowledge I'm accumulating. I don't know where this path leads exactly. But I know I'm not walking it alone. Every project I've worked on, every skill I've developed, every lesson I've learned—none of it happened in isolation. It happened because people gave their time, knowledge, patience, and support to someone who was just trying to learn.

So thank you. For everything. For believing in curiosity. For supporting exploration. For teaching me that learning is a lifelong process and that it's okay to not have everything figured out at 17. For showing me what's possible when you're willing to try, fail, learn, and try again.

I hope to pay it forward someday. To be the person who gives someone else a chance. To share knowledge patiently with someone who's still learning. To create opportunities for others the way opportunities have been created for me. To be generous with time and guidance the way so many people have been generous with me.

But for now, all I can say is: Thank you. This journey is just beginning, and I'm grateful to everyone who's been part of it so far.

Connect: www.creativenikesh.com | nikeshcreative@gmail.com

Because nothing we accomplish is truly individual—it's built on the foundation of everyone who believed in us along the way.

What a Tech Conference in Dubai Taught Me About How Much I Don't Know

Nikesh — Sun, 26 Oct 2025 08:06:35 GMT

The convention center was massive.

Like, actually massive. GITEX Global 2024 in Dubai—one of the world's largest tech conferences. Thousands of exhibitors. Hundreds of thousands of attendees. Startups from everywhere pitching everything. I'd convinced my parents this trip was educational. "It's a tech conference. I'll learn about AI, startups, innovation. It'll be valuable for my future." That was true. But it wasn't the whole truth.

The whole truth: I wanted to see if the things I was learning—coding, business, entrepreneurship—actually mattered in the real world. I wanted to see what adults building real companies looked like. I wanted to know if I was remotely on the right track.

I got answers. Just not the ones I expected.

Day One: Feeling Very Small

The first booth I walked into was showing some AI-powered enterprise solution for supply chain optimization.

The founder was explaining their technology to a group of serious-looking people in suits. I caught maybe 30% of what he was saying.

"...blockchain integration for immutable record-keeping..."

"...predictive algorithms reducing inventory overhead by 23%..."

"...enterprise deployment across 47 countries..."

Everyone was nodding like this made perfect sense.

I stood there thinking: I'm in way over my head. Then I walked through startup alley. Hundreds of early-stage companies with booths, eager founders ready to pitch anyone who stopped. Most weren't the AI-blockchain-enterprise complexity I'd just encountered. They were solving specific problems:

A platform connecting freelance delivery drivers in emerging markets.

An app helping small restaurants manage inventory without expensive software.

A tool for construction companies to track materials and prevent waste.

These made sense to me. I could see the problems. I could imagine using the solutions.

And suddenly: I didn't feel quite so lost.

The Founder Who Actually Talked to Me

His name was Arjun. Indian startup. Building something in the fintech space—helping small businesses access credit. I stopped at his booth. Read the poster. He could tell I was young, probably a student, definitely not an investor or potential client.

He talked to me anyway.

"What are you working on?" he asked.

"I'm still a student. IB. But I've been learning to code, did some internships, built a small e-commerce project..."

"What did you learn from the e-commerce thing?"

Not "how much revenue did you make" or "how many users did you get."

What did you learn.

We talked for twenty minutes. He told me about starting his company three years ago. The mistakes he made. The pivots he had to do. How the first version of his product was completely wrong.

"Everyone here," he gestured around the conference, "we all started not knowing what we were doing. The difference is, we kept going anyway."

That conversation was worth the entire flight to Dubai.

The Panel I Barely Understood

I attended a panel on "Scaling AI Products in Emerging Markets."

Five founders/executives on stage. All brilliant. All accomplished.

They talked about:

Infrastructure challenges in developing markets
Data collection in low-connectivity environments
Balancing innovation with regulatory compliance
Unit economics at scale
Building teams across geographies

I understood the words. I didn't understand the depth.

These weren't theoretical problems from a business class case study. These were real challenges these people faced building actual companies.

And the solutions weren't clean. They were messy, context-dependent, "we tried three things that didn't work before finding something that kind of works."

This was what real entrepreneurship looked like. Not the polished success stories. The complicated middle where nothing is clear.

The Startups That Made Me Realize I'm Not Ready

I saw startups with:

Teams of 50+ people
Offices in multiple countries
Millions in funding
Products used by thousands of companies
Complex technology I didn't fully understand
Business models that took me several minutes to grasp

And I thought: I'm nowhere near ready to build something like this.

Then I'd see:

Teams of 2-3 people
Working out of apartments
Bootstrapped or minimal funding
Solving one specific problem well
Technology I could mostly understand
Business models that made immediate sense

And I'd think: Maybe I could try something like this. Not now. But eventually.

Both reactions were useful.

The Pattern I Started Noticing

After two days walking around, talking to founders when they'd talk to me, watching pitches, attending panels—I noticed something.

The most impressive founders weren't the ones with the most complex technology.

They were the ones who could explain their solution clearly.

Who knew exactly what problem they were solving and for whom.

Who had tried, failed, adjusted, tried again.

Who were honest about what they didn't know yet.

The complexity came from solving real problems, not from trying to sound impressive.

This felt important. I wasn't sure why yet.

What I Learned About AI (The Hype versus The Reality)

AI was everywhere at this conference. Every booth mentioned it. Every pitch included it.

"AI-powered" "Machine learning-driven"
"Intelligent algorithms"

Some were legitimate. Using AI to actually solve problems in clever ways.

Many were... questionable. AI seemed to mean "we have a basic algorithm that does simple pattern matching."

One founder was honest with me: "Everyone says AI because investors like it. We're doing basic data analysis, but if we call it AI, people pay attention."

This taught me: buzzwords matter less than substance. Real solutions show themselves through clarity, not jargon.

Also: I'm learning machine learning at the right time. Not too early (when I'd be lost in theory), not too late (after the hype has died). Right in the middle where I can learn to actually apply it, not just talk about it.

The Networking Part (Which I Was Terrible At)

Everyone was networking. Exchanging cards. Scheduling meetings. Making connections.

I had... none of that.

I'm 17. I don't have a company. I don't have a card. I'm not fundraising or hiring or looking for partnerships.

I'm just a student trying to learn.

A few times, people asked: "What do you do?"

"I'm a student. Learning about tech and business. Here to see how real companies work."

Most people smiled politely and moved on. They were busy. I wasn't useful to them professionally.

A few stayed and talked anyway. Those conversations were the best ones. They weren't networking. They were just generous with their time.

I learned: networking isn't just about exchanging value. Sometimes it's just about curiosity and generosity.

The NorthStar Event

Part of GITEX included NorthStar—a section focused on startups, innovation, and the entrepreneurial ecosystem.

Pitch competitions. Workshops. Investor meetings.

I watched startups pitch. Five minutes to convince a panel of investors why their idea deserved funding.

Some pitches were smooth, polished, confident. Some were nervous, stumbling, but honest.

The best ones weren't the most polished. They were the ones that made you immediately understand the problem and believe the solution could work.

Watching this taught me more about business communication than any class ever did.

You have to know your problem deeply.
You have to articulate it simply.
You have to show why you're the right person to solve it.

And you have to do all of that in minutes, under pressure, while people judge you.

I wasn't ready to do that. But I understood what I needed to learn to eventually do it.

The Moment of Doubt

Third day. Evening. Exhausted from walking around all day. I was sitting in the food court, surrounded by founders, investors, executives, all doing real business.

And I thought: What am I even doing here? I'm not building a company. I don't have a groundbreaking idea. I'm just a student who's curious. Everyone here is actually doing something. I'm just... learning. Then I remembered Arjun's comment: "We all started not knowing what we were doing." Everyone at this conference was once where I am now. Not knowing. Just learning. Just curious. The difference: they kept going. They started something even when they weren't ready. They learned by doing. I couldn't start a serious company at 17. But I could keep learning. Keep building small things. Keep preparing. This trip wasn't about launching something today. It was about understanding what I needed to learn to launch something eventually.

What I Realized About Scale

I'd been thinking about entrepreneurship in terms of building one thing that works. This conference showed me: successful companies are really about scaling something that works. Anyone can build a prototype. Some people can get their first few customers. The hard part is going from 10 customers to 100 to 1,000 to 10,000.

That requires:

Operations at scale
Team building and management
Financial systems that work at volume
Technology that doesn't break under load
Business models that still make sense when bigger

I understood none of this deeply. But I saw it was the real challenge. Building something people want is step one. Scaling it is the actual work.

The Technologies I Saw (And Didn't Understand)

Blockchain for supply chain (still confused how this works practically) Edge computing for IoT devices (vaguely understand the concept, not the implementation)

Quantum computing applications (completely lost)

Advanced robotics for manufacturing (impressive, no idea how it actually works)

Synthetic biology startups (didn't even know this was a thing)

The range of technology being built was overwhelming. I understood maybe 40% of it.

But here's what I did understand: the technology alone doesn't matter.

What matters: does it solve a real problem? Will people pay for it? Can you build a sustainable business around it?

Those questions applied to everything, whether I understood the tech or not.

The Gap Between My Skills and Reality

I left Dubai understanding my gaps more clearly:

What I know:
Basic coding, web development fundamentals, some business theory, how to learn quickly.

What I don't know yet:
How to build products at scale. How to lead teams. How to navigate regulations. How to raise funding. How to make complex business decisions with incomplete information.

What I thought before the trip:
Maybe I'm close to ready to start something.

What I know after the trip:
I'm not close. But I'm on the right path. Learning the right things. Building the right foundation.

I need a few more years. More experience. More projects. More failures. More learning.

And that's okay.

The Question I'm Left With

If I were to start something today, what would it be?

I don't have an answer yet. But GITEX changed how I think about the question.

Before: What's a cool idea I could build?

After: What real problem do I understand deeply enough to solve? Who would pay for that solution? How would I actually reach them?

Those are harder questions. Better questions.

I don't have answers. But I'm starting to understand what I need to observe, learn, and experience to eventually find answers.

What Dubai Actually Taught Me

Not "here's how to start a company."

Not "here's the cutting-edge technology you need to know."

What it actually taught me:

Real entrepreneurship is messy.
The success stories are clean. The actual work is complicated, full of uncertainty, rarely goes according to plan.

You don't need to understand everything.
You need to understand your problem deeply and your solution well enough. Everything else, you figure out as you go.

Starting before you're ready is normal.
Nobody feels ready. The ones who succeed are the ones who start anyway and learn fast.

Scale is the real challenge.
Building a prototype is step one. Building a business is the actual work.

Clarity matters more than complexity.
The best founders could explain their business simply. Jargon and buzzwords weren't impressive. Clear thinking was.

Being young and learning is an advantage.
I don't have to have it figured out. I have time to observe, learn, build skills, try small things, fail safely.

Was It Worth It?

The flight. The cost. The time away from IB work.

Was it worth it?

Yes. But not for the reasons I expected.

I didn't leave with a startup idea. I didn't make useful connections. I didn't learn specific skills.

I left understanding what I don't know. Understanding what real entrepreneurship looks like. Understanding that I'm not ready yet, but I could be eventually.

That clarity was worth the trip.

I'm back in Hyderabad now. Back to IB work. Back to internships. Back to normal life.

But something shifted. I saw what's possible. I saw what it actually takes. I saw where I might fit eventually.

And I know I'm not ready yet. I've got years of learning ahead.

But for the first time, I can see the path. It's not clear. It's not certain. But it exists.

And that's enough to keep going.

If you ever get a chance to attend a major tech conference—go.

Not to network (though you might). Not to learn specific skills (though you will). But to see the real world of building things. To understand the gap between where you are and where you want to be. To get clarity on what you actually need to learn.

That perspective is invaluable.

Learning Out Loud: Why I Started Documenting Everything

Nikesh — Sun, 26 Oct 2025 07:54:50 GMT

I uploaded my first YouTube video at midnight. Not because midnight was strategic or optimal. Because I'd been staring at the "Publish" button for two hours. The video was rough. Audio wasn't great. I stumbled over words. The editing was basic. But it was real. It showed what I was actually working on, the problems I was trying to solve, the things I was learning. I finally clicked "Publish" and immediately wanted to unpublish it. Too late. It was out there.

Me, learning in public. Permanently.

Why This Felt Terrifying

Putting your work online when you're still figuring things out feels like: Walking into a room of experts and saying "I'm just starting, watch me make mistakes." Documenting your confusion and calling it content. Admitting you don't know things, on the record, searchable forever. Everyone tells you to "build your personal brand" and "create content." What they don't mention: it requires being vulnerable in ways that feel uncomfortable at 17.

The Three Things I'm Creating (And Why Each One Scares Me Differently)

YouTube Channel: Creative Nikesh

Videos about projects I'm building, concepts I'm learning, my experiences in internships and competitions. What scares me: Video is permanent. Everyone can see exactly how I explain things, how I present myself, how I stumble over technical concepts I'm still learning. You can't hide behind text. Your face is there. Your voice is there. Your uncertainty is visible.

Podcast: Neural Nexus

Episodes exploring AI, technology, business, healthcare innovations, space exploration, politics—topics I'm curious about but definitely not expert in. What scares me: I'm 17, talking about complex topics to an audience that might include actual experts. What if I get something fundamentally wrong? What if someone who actually knows this field listens and thinks I'm oversimplifying or misunderstanding?

Blog: Substack

Writing about programming concepts, business lessons, my learning journey. What scares me (less): Text is easier. I can edit twenty times before publishing. But it's still public, still permanent, still me claiming to understand things I'm actively learning.

The Voice in My Head

"Who are you to create content about this? You're still learning."

"People will think you're trying to be an expert when you're clearly not."

"What if you explain something wrong and someone corrects you publicly?"

"Your videos aren't as polished as other creators."

"Your podcast isn't as professional as the ones you listen to."

"Your blog posts are just documenting your confusion. Why would anyone read that?"

This voice is loud. It's there every time I sit down to create something.

I'm learning to create anyway.

What Changed: One Comment

Three weeks after starting my YouTube channel, someone commented on a video where I explained a coding concept I'd just learned: "Thank you for this. I've been stuck on this for days and your explanation finally made it click. The way you explained it—like you just figured it out yourself—helped me understand better than textbook explanations."

That comment made me realize something: The fact that I just learned this isn't a weakness. It's why my explanation is helpful. I remember what was confusing. I remember what questions I had. I remember what finally made it clear. Experts forget what it's like to not know. They skip steps that seem obvious to them but aren't obvious to beginners. I'm still close enough to confusion to explain things in a way that makes sense to other confused people.

The Neural Nexus Experiment

Starting a podcast felt ambitious. Maybe too ambitious. I'm not a journalist. I'm not a researcher. I'm not an expert in AI, healthcare, space technology, or politics. I'm a curious teenager who reads a lot and wants to understand how the world works. But that curiosity drives the podcast. Each episode, I research a topic deeply—not to become an expert, but to understand it well enough to explain it clearly to someone else.

Recent episodes:

AI in healthcare: How machine learning is changing diagnosis
The business of space exploration
Digital diplomacy and cyber governance
Breakthroughs in renewable energy

Do I know everything about these topics? No. Do I research them thoroughly, connect ideas across fields, and try to explain them accessibly? Yes.

Is that enough to justify creating content about them? I'm deciding it is.

What Creating Content Actually Teaches You

1. Teaching forces deeper understanding

When you have to explain something, you can't hide behind vague comprehension.

I've rewritten blog posts three times because I realized while writing that I didn't actually understand the concept as well as I thought.

I've re-recorded video sections because explaining out loud revealed gaps in my logic.

Creating content is a test of understanding. If you can't explain it clearly, you don't understand it well enough yet.

2. You learn what resonates

Some videos I think will be great get minimal views. Others I almost didn't publish end up helping people.

You can't predict what will be useful to others. You just have to create consistently and see what connects.

3. Documentation helps you track your own growth

I can go back and watch videos from six months ago. I see how my thinking has evolved, what I understand better now, what I was confused about then.

It's like leaving breadcrumbs for my future self. This is where I was. This is what I was learning. This is how far I've come.

4. Vulnerability builds connection

The videos where I'm most honest about struggling—those get the best responses.

People don't connect with perfection. They connect with "I'm figuring this out too, let's learn together."

The Technical Side (Which I'm Still Learning)

Video creation:

Recording: Still figuring out good lighting and audio
Editing: Learning DaVinci Resolve, very slowly
Thumbnails: Mine are... functional. Not great. Working on it.
Consistency: Trying to post regularly while managing IB and internships

Podcast production:

Recording setup: Decent microphone, quiet room (when my family cooperates)
Editing audio: Removing umms, awkward pauses, background noise
Scripting versus improvising: Finding the balance between prepared and natural
Episode length: Still figuring out optimal length

Blog writing:

Structure: How to organize thoughts clearly
Voice: Writing like I talk versus writing formally
Frequency: Balancing depth versus posting regularly
Topics: What's actually useful versus what I just find interesting

All of this is work. On top of IB. On top of internships. On top of projects.

Some weeks I don't post anything because I'm drowning in actual work.

That's okay. This isn't my job. It's documentation of my learning journey.

What I'm Not Trying to Be

Not trying to be: An influencer with thousands of subscribers who makes money from content.
Actually trying to be: Someone documenting their learning journey authentically, in case it helps other people learning similar things.
Not trying to be: The expert 17-year-old who has everything figured out.
Actually trying to be: The honest 17-year-old who's willing to show the messy process of figuring things out.
Not trying to be: The person with perfect, polished content.
Actually trying to be: The person with real, useful content, even if it's imperfect. The Comments That Make It Worth It

Beyond that first comment, others that have stuck with me:

"I'm also learning to code and feeling overwhelmed. Your videos show it's normal to struggle. That helps."

"Your podcast episode on AI in healthcare made me think about my own field differently. Thank you."

"Just found your blog. Finally, someone explaining business concepts without assuming I already know everything."

These aren't thousands of views or viral moments. They're individual people saying: "This helped me."

That's enough reason to keep creating.

What My Schedule Actually Looks Like

Monday-Friday:

School: 8am-3pm
Homework/IB work: 3pm-6pm
Internship work: 6pm-9pm (some days)
Content creation: Whenever I can squeeze it in

Weekends:

Catch up on IB work I didn't finish during the week
Work on bigger projects
Record videos, edit podcasts, write blog posts
Sometimes: Just rest because I'm exhausted

Creating content consistently while managing everything else isn't sustainable long-term. I don't know how full-time creators do this daily. But for now, documenting my journey feels important enough to make time for it, even when that time is scarce.

The Criticism I Prepare For (But Hasn't Come Yet)

I expect someone will eventually say:

"You're 17. Why are you creating content like you're qualified to teach this?"

My answer ready: I'm not teaching as an expert. I'm sharing as a learner. There's a difference.

"Your content isn't as good as [established creator]."

My answer: Of course not. They've been doing this for years. I've been doing this for months. I'm learning.

"You're just documenting your homework."

My answer: Kind of, yeah. And if documenting my homework helps someone else understand their homework better, that's valuable.

The criticism will probably come eventually. When it does, I'll deal with it. For now, the encouraging comments outnumber the critical ones, and I'm grateful for that.

Why I Think Other Students Should Do This

If you're learning something—coding, business, science, art, anything—consider documenting it publicly. Not because you'll become famous or make money.

But because:

It forces clarity. You can't document vague understanding. You have to make sense of things.
It creates accountability. When you say publicly "I'm learning X," you're more likely to actually learn it.
It helps others. Someone is one step behind you, confused about exactly what confused you last week. Your documentation helps them.
It tracks your progress. Future you will appreciate seeing where you started.
It builds communication skills. Explaining complex ideas clearly is valuable regardless of your field.

What I'm Still Figuring Out

How much to share: Some projects I work on, I'm not sure if I should document publicly. Internship work has confidentiality considerations. Personal struggles feel too vulnerable sometimes.
Quality versus consistency: Is it better to post consistently even if quality suffers, or post rarely but make everything polished? Still figuring out that balance.
Audience versus authenticity: Should I create what I think people want, or document what I'm genuinely interested in? Right now, doing the second. Hope that's right.
Time management: How do I sustain this long-term without burning out? Don't have an answer yet.

The Real Reason I Do This

Yes, it helps others learn. Yes, it forces me to understand things deeply. Yes, it builds skills. But the real reason?

I'm figuring out who I am and what I care about by doing this publicly. Every video, podcast episode, blog post is me thinking through:

What interests me?
What do I understand about this?
How does this connect to other things I'm learning?
What questions do I still have?

This isn't just content creation. It's thinking out loud. Documented.

And somehow, that process—learning out loud, making it public, being vulnerable about not knowing everything—feels like the most honest way to move through this phase of my life.

If You're Considering Creating Content

Start before you're ready.

Document what you're learning right now, not what you'll learn eventually. Be honest about what you don't know. Your first work will be rough. That's fine. Everyone's first work is rough. Someone, somewhere, is one step behind you. Your imperfect documentation will help them more than perfect silence. And five years from now, you'll look back at what you created and see how far you've come.

That future perspective is worth the current vulnerability.

My content:

17 and Crystal Clear: Why My Career Path & Choices Makes Sense to Me.

Nikesh — Sun, 26 Oct 2025 07:42:30 GMT

Everyone asks: "What do you want to study?" I tell them: "The intersection of technology and business—building and scaling products."

They usually look confused. Then they ask: So... engineering?. "Not exactly. Not traditional engineering."

So business then? Also not exactly.

And then comes the look. The one that says: "Why are you making this complicated? Just pick one."

Here's the thing

I figured this out between 8th to 10th grade. Not the confused, scattered kind of figuring out. The clear kind.

I know I want to build companies that use technology to solve real problems. That means understanding how to build products (the technical side) AND how to bring them to market, scale them, and create sustainable businesses (the business side). I'm not interested in being just an engineer who codes what someone else designs. I'm not interested in being just a business person who doesn't understand how the products actually work. I want both. I need both.

That's why I chose Business Management, Computer Science, Global Politics, and Math for IB. Not because I couldn't decide. Because I deliberately wanted that combination.

But explaining this to people? Exhausting

Few Say: "You should focus. You're spreading yourself thin."

Relatives: "Engineering is a safe career. Why complicate it?"

Friends: "Just do CS if you like tech. Why do you need business subjects?"

Everyone wants me to fit into a box: Engineer. Entrepreneur. Business Student. I don't fit neatly. That's not because I'm confused. It's because the boxes are wrong.

Why I don't want traditional engineering

The traditional engineering path:

Four years learning theory
Get placed in a company
Spend years coding features someone else decided to build
Maybe lead a team eventually
Retire after 25-30 years

That path has worked for millions of people. It's stable, it's respectable, it's safe.

It's also not what I want. I don't want to spend my career building someone else's vision. I want to build my own. I don't want to only understand the technical side while someone else makes all the strategic decisions. I don't want to be hired to execute. I want to be the person deciding what to execute. That requires a different skill set than traditional engineering programs teach.

What I actually want

To start a company that builds technology products that solve real problems. Not "start a company" in the vague Instagram entrepreneur way. Specifically: identify problems people actually have, build technical solutions, understand the market, create a sustainable business model, scale it.

That means I need to:

Build: Understand software development, system design, product architecture
Strategize: Know how businesses work, market dynamics, competitive positioning
Execute: Understand operations, team building, resource allocation
Navigate: Understand policy, regulations, global market contexts

One subject doesn't cover all of this. One degree doesn't prepare you for this. So I'm building the foundation across multiple domains. Deliberately.

Why my subject combination makes sense

Computer Science: The technical foundation. How do you actually build products? How do systems work? What's possible and what's not?
Business Management: How do companies operate? What makes businesses succeed or fail? How do you create value and capture it?
Global Politics: How do regulations, policies, and global dynamics affect business decisions? What contexts do companies operate within?
Mathematics: The underlying logic. Optimization, modeling, data analysis. The language that connects everything.

This isn't scattered. This is strategic. I'm not learning these subjects in isolation. I'm learning how they inform each other.

The gap in traditional engineering education

Traditional engineering programs teach you to build things. They're good at that.

What they don't teach:

Is this the right thing to build?
Will people actually use this?
How do you get it to market?
What's the business model?
How do you scale it?
What are the regulatory implications?

You graduate knowing how to code but not how to build a company.

Then you either:

Join a company and build what they tell you to build
Try to start your own company and realize you're missing half the skills you need

I'm trying to avoid that gap. Build the full picture from the start.

The programs I'm looking for

Not traditional engineering. Those focus 90% on technical skills.

Not traditional business. Those assume you'll hire technical people and manage them.

I'm looking for programs that:

Teach both technical fundamentals AND business thinking
Focus on building products, not just engineering systems
Emphasize entrepreneurship, not just employment
Connect technology to market realities
Prepare you to start things, not just join things

These programs exist. They're just newer. Less traditional. Harder to explain to relatives who expect you to say "IIT" or "engineering college."

What people get wrong about my path

"You're trying to do too much."
No. I'm trying to do one specific thing—build companies—which requires multiple skill sets.

"You should specialize."
In what? Engineering? Then I won't understand the business side. Business? Then I won't understand what's technically possible. The intersection IS the specialization.

"You're not focused."
I'm extremely focused. I'm focused on building sustainable tech businesses. That focus requires breadth, not depth in one area.

"Entrepreneurship is risky. Get a degree first."
I'm not dropping out tomorrow to start a company. I'm building skills now so when I do start something, I'm not starting from zero.

The confidence I have (and where it comes from)

I'm confident in this path because I've tested it. ApniDukaan taught me: I can build a functional product, but that's only 20% of creating a successful business. The other 80%—marketing, operations, customer service, pricing strategy—that's all business skills. My CuriousRubik internship taught me: understanding the business problem is as important as writing good code. Maybe more important. My UnyKloud internship taught me: technical skills matter, but knowing what to build and why matters more. Scaler taught me: I can learn to code. But coding alone doesn't create value. Products do. Businesses do. Every experience has confirmed: the intersection is where I need to be.

The questions I can answer

What do you want to do?
Build technology products that solve real problems and scale them into sustainable businesses.

What skills do you need?
Technical skills to build, business skills to scale, strategic thinking to make good decisions, global awareness to navigate complex environments.

Why not just do engineering?
Because engineering programs teach you to be hired, not to hire. I want to be the person building the company, not just the person writing the code.

Why not just do business?
Because business programs assume you'll manage technical people. I want to be technical enough to make good technical decisions myself.

What's your five-year plan?
Learn these skills deeply. Work on real projects. Start building things. Launch something. Probably fail. Learn from that. Try again.

The pressure I don't feel

Following the traditional path.

Picking one lane and staying in it forever.

Convincing everyone that my path makes sense to them.

Having every detail figured out.

The pressure I do feel

Finding programs that actually prepare you for this intersection.

Explaining to university admissions why my diverse subject combination isn't "scattered."

Proving to people that this isn't just theoretical—I'm actually building things, not just talking about it.

Making sure I'm building real skills, not just collecting experiences for a resume.

What I'm doing right now

Building technical skills through Scaler and my internships.

Understanding business through real projects like ApniDukaan and my business analyst work.

Developing strategic thinking through my IB subjects and research projects.

Connecting with people who've built companies—learning from their journeys.

Applying to programs that bridge technology and business, not traditional engineering schools.

To anyone who thinks they need to pick one thing

Maybe you do. Maybe deep specialization is your path.

But maybe you're interested in the intersection of multiple fields. Maybe the problems you care about require different types of knowledge.

That's valid too.

You don't have to fit into traditional categories. You don't have to choose between technical and business, between building and scaling, between coding and strategizing.

The intersection is a real place. It's where a lot of interesting work happens.

It's harder to explain at 17. But that doesn't make it wrong.

Where I am

Clear on what I want: Build technology companies.

Clear on what I need: Technical skills AND business thinking.

Clear on why traditional paths don't fit: They optimize for employment, not entrepreneurship.

Still figuring out: Which specific programs will best prepare me for this.

Still defending: Why this path makes sense to people who expect me to just pick "engineering" or "business."

But I'm not confused. I'm just on a path that doesn't have an obvious label yet.

And I'm okay with that. Because the path makes sense to me.

That's what matters.

The Art of Asking for Help: Lessons from My Internships

Nikesh — Sun, 26 Oct 2025 07:26:28 GMT

I spent four hours trying to fix a bug I could have solved in ten minutes.

Four. Hours.

My manager walked by my desk three times during those four hours. Each time, I tilted my screen slightly, pretending to be making progress. Didn't want him to think I couldn't handle the task. Didn't want to admit I was stuck.

By the time I finally gave up and asked for help, he looked at my code for about thirty seconds. "Oh, you're missing this one line here. Common mistake." He added it. The code worked immediately. I'd wasted four hours because I was too proud to ask a simple question.

The Permission I Didn't Know I Needed

Here's what nobody tells you about internships: everyone expects you to ask questions. Except you, apparently, who thinks you're supposed to magically know everything. During my first week at CuriousRubik, I was drowning. Acronyms I didn't recognize, tools I'd never used, processes nobody had explained. I was frantically Googling everything while pretending I understood. Then I attended a team meeting where a senior developer asked: "Wait, what does BRD stand for again?"

A senior developer. Someone who'd been there for years. Asking a basic question. Nobody laughed. Someone just said "Business Requirements Document" and the meeting continued.

That moment changed something for me. If people who actually know what they're doing can ask simple questions, maybe I can too? The permission I needed wasn't from my manager. It was from myself.

The Questions I Was Too Embarrassed to Ask

Week 2 at CuriousRubik:

"Could you send me the MIRO link?" I had no idea what MIRO was. Everyone else was using it like it was obvious. I Googled it—okay, it's a digital whiteboard tool. But which project's board? Where do I find our team's workspace? How do I even get access? I spent 20 minutes searching, clicking around, getting nowhere. I should have just asked: "Sorry, I've never used MIRO. Could you show me how to access our project board?" Instead, I said: "Sure!" and then frantically tried to figure it out alone. Eventually, I had to ask anyway. My manager probably wondered why I'd wasted half an hour on something that took two minutes to explain.

Month 1 at UnyKloud:

Senior developer: "Just use the staging environment for testing." Me: "Okay." (What's a staging environment? Is that different from production? Where do I find it? How do I access it?) I spent an hour testing on my local machine instead, which wasn't what they meant. When they checked my work, they were confused why I hadn't tested properly. If I'd just asked: "Could you show me how to access the staging environment?" this would have been solved in two minutes.

The Stupid Question That Wasn't Stupid

During a client call at CuriousRubik, they were discussing the client's inventory system. They kept mentioning "SKUs" and everyone was nodding along.

I had no idea what a SKU was. I should have asked right then. Instead, I jotted it down, planning to Google it later. But the conversation kept moving, and references to SKUs kept coming up, and I was getting more lost by the minute. Finally, I worked up the courage: "Sorry, could you clarify what you mean by SKU? I want to make sure I'm understanding correctly." The client didn't even blink. "Stock Keeping Unit—it's basically a unique ID for each product in our inventory."

"Got it, thank you." After the call, my manager told me: "Good question. Always better to ask for clarification during the meeting than to make assumptions and document the wrong requirements." What felt like admitting ignorance was actually doing my job properly.

When Asking Feels Like Failing

The hardest questions to ask aren't the technical ones. They're the ones that feel like they expose how much you don't belong.

"Could you explain that again?"
Translation in my head: "I'm too slow to understand things the first time."

"I'm not sure I understand what you want me to do."
Translation: "I'm incompetent at basic comprehension."

"How long should this task take?"
Translation: "I have no idea what I'm doing and can't even estimate my own work."

These questions feel like admissions of inadequacy. Asking them feels like highlighting your weaknesses to people who are evaluating you. But here's what I've slowly learned: not asking these questions is way worse. When you pretend to understand and then do the wrong thing, you've wasted time—yours and everyone else's. When you ask for clarity upfront, you get it right the first time. Managers would rather answer ten clarifying questions than deal with work that has to be completely redone.

The Different Types of Help (And When to Ask)

I used to think there was only one kind of asking for help: "I don't know how to do this, please help." There are actually different levels:

1. "Can you point me in the right direction?"
You're willing to do the research, you just need to know where to start.

2. "I've tried X and Y, but I'm stuck on Z."
You've made an effort, you can show your work, you need help with a specific blocker.

3. "I don't understand this concept at all."
You need someone to teach you the fundamentals before you can even attempt the task.

4. "This is urgent and I'm completely stuck."
You need immediate help because a deadline is approaching or something is broken.

I've learned that #2 is usually the sweet spot. Show that you've tried, explain where you're stuck, ask for specific guidance. But sometimes you need #3, and that's okay too. Better to admit "I don't know this" early than to fake it and fail later.

What Good Help Actually Looks Like

Bad way I used to ask for help:

"Hey, my code isn't working." (No context, no explanation of what I tried, no specific error message, just vague "it's broken.")

Better way I'm learning:

"Hey, I'm getting this error: [specific error message]. I'm trying to fetch data from the API and display it, but the component is rendering before the data loads. I've tried adding a loading state, but I'm not sure I'm implementing it correctly. Could you take a look at lines 23-35?" Specific problem. What I'm trying to do. What I've already tried. Where exactly I'm stuck. This makes it way easier for someone to help me. They don't have to debug my entire file or guess what I'm trying to accomplish.

The Questions I Should Have Asked Earlier

Looking back at my internships, here are questions I eventually asked but should have asked way sooner:

"What should I do when I'm stuck?"
Should I try for 30 minutes then ask? An hour? Is there someone specific I should ask first?

"How do I know if I'm on the right track?"
Should I check in after I make the outline? After I build the first version? Or just at the end?

"What does good work look like for this task?"
Can you show me an example of a similar project done well?

"What are the most common mistakes people make on this type of task?"
This one is gold. Helps you avoid obvious pitfalls.

These meta-questions about how to work effectively are just as important as technical questions. Maybe more important.

When Someone Says "Figure It Out Yourself"

This happened once. I asked my senior developer a question, and he said: "Try to figure it out yourself first. You'll learn more that way." I felt dismissed. Like I'd bothered him with something too basic. But I tried. Spent an hour working through it. Got about 70% of the way there. Asked again, showing what I'd figured out and where I was still stuck.

This time, he was happy to help. Explained the remaining 30%, and because I'd struggled with it myself, I actually understood and remembered his explanation. He wasn't being dismissive the first time. He was teaching me how to learn.

There's a difference between:

"Try for 20 minutes, then ask if you're still stuck"
"Figure it out completely on your own no matter how long it takes"

Most people mean the first one. I was hearing the second one.

The Questions That Actually Impressed People

Weirdly, some of my questions made me look better, not worse:

"What's the business goal behind this feature?"
Shows you're thinking beyond just coding—you want to understand why it matters.

"How will users actually interact with this?"
Shows you're thinking about user experience, not just functionality.

"What happens if [edge case scenario]?"
Shows you're thinking ahead about potential problems.

"I've researched two approaches—what are the tradeoffs?"
Shows you've done your homework and want to make an informed decision.

These aren't "I don't know" questions. They're "I want to do this well" questions.

That distinction matters.

What I'm Still Bad At

Knowing when I've tried long enough:
Sometimes I give up too quickly. Sometimes I waste hours on something I should have asked about immediately. Still figuring out that balance.

Asking in real-time versus after the meeting:
I'm getting better at asking questions during meetings instead of pretending to understand. But I still default to "I'll figure it out later" more than I should.

Admitting when I've made a mistake:
"Hey, I think I misunderstood the requirements and built the wrong thing" is still really hard for me to say. Getting better though.

Following up when I'm still confused:
Sometimes someone explains something and I'm still not clear, but I don't want to ask them to explain again. Working on: "Thanks, that helps. Could you clarify one more thing..."

What Asking for Help Actually Shows

I used to think asking for help showed:

I'm not smart enough to figure things out
I'm slower than everyone else
I don't deserve to be here

Now I'm starting to understand it actually shows:

I care about doing the work correctly
I'm willing to admit what I don't know
I'm focused on learning, not on protecting my ego
I value other people's time (asking early rather than redoing work later)

The managers and senior developers who've been most helpful? They don't think less of me for asking questions.

They think less of the people who don't ask, make mistakes, and waste everyone's time fixing them later.

What I'd Tell My Week-One Self

Just ask.

That bug you'll spend four hours on? Ask after thirty minutes. That acronym you don't know? Ask immediately. That task where you're not sure what "good" looks like? Ask before you start.

The embarrassment you feel asking is temporary and minor. The embarrassment of doing everything wrong because you didn't ask is way worse. Nobody expects you to know everything. Everyone expects you to ask when you don't. That's not a weakness. That's literally how you learn.

Writing a Book About Money When You Don't Have Any

Nikesh — Sun, 26 Oct 2025 07:14:57 GMT

"So you wrote a book on financial literacy?" Yeah. How much money have you made? Um... I'm 14. I wrote Wealth Warriors: Gen Z Guide to Conquering Finances in Grade 10 as part of my Personal Project. It's on Amazon. Real book, people have actually bought it. And yes, the irony is thick: a teenager with no real income, no investments, no financial independence, writing a guide about money management.

Let me explain how this happened—and what it taught me about learning by teaching.

The Question That Started Everything

My Personal Project required picking something to learn deeply and create something from it. Most of my classmates were doing art projects, building models, composing music. I kept thinking about a conversation I'd had with my parents about money. They were discussing investments, retirement planning, terms like "mutual funds" and "compound interest."

I understood maybe 30% of what they were saying. And I realized: I'm supposed to be an adult in a few years. How do I know nothing about managing money? So my Personal Project question became: Can I learn enough about financial literacy to teach it to others my age? The teaching part was important. I wasn't trying to become a financial expert. I was trying to understand enough to explain it clearly to people who knew as little as I did.

Research Felt Like Learning a New Language

I started reading. Books on personal finance. Articles about investing. Videos on budgeting and saving. At first, everything was overwhelming. Every resource assumed you already understood basic concepts. They'd casually mention "diversification" or "asset allocation" or "liquidity" without explaining what those meant.

I'd have to stop every two paragraphs to Google terms. Then Google the explanation because that had terms I didn't know either. My process journal from that time is full of confused notes:

"What's the difference between stocks and bonds? Why would you buy either?"
"How do mutual funds actually work? Who manages them? How do you know if they're good?"
"Why do people say credit cards are bad but also that you need to build credit?"

Nothing made intuitive sense at first. Finance has this whole vocabulary that feels deliberately complicated.

The Outline That Kept Growing

I started with a simple outline:

Why Gen Z needs financial literacy
Basics of saving and budgeting
Understanding credit
Introduction to investing
Future planning

Simple, right? Maybe 50 pages. Then I started researching each section and realized how much there was to cover.

Budgeting alone could be a whole book. The 50-30-20 rule, zero-based budgeting, envelope method, digital tools, tracking expenses, setting realistic goals, adjusting for irregular income...

Investing was even worse. Stocks, bonds, mutual funds, index funds, ETFs, risk tolerance, time horizons, diversification, rebalancing, tax implications, retirement accounts...

Every topic branched into five more topics. My outline grew. 50 pages became 80. Then 100. Then 150. At some point, I had to make peace with the fact that I couldn't cover everything. I was writing for beginners, by a beginner. The goal wasn't comprehensiveness—it was accessibility. I cut ruthlessly. Focused on what Gen Z specifically needed to know now, not what financial experts think is important.

Writing About Things I Was Still Learning

Here's the weird part: I was writing chapters about concepts I'd just learned myself. I'd spend a week researching compound interest, making sense of the formulas, understanding the implications. Then I'd write a chapter explaining it as simply as possible. Sometimes while writing, I'd realize I didn't understand something as well as I thought. I'd have to go back, research more, revise.

The process journal requirement turned out to be incredibly valuable. I'd write daily reflections:

"Today I learned about the difference between active and passive investing. I thought I understood it, but when I tried to explain it in writing, I realized I was confused about who actually picks the stocks in an index fund."
"Rewrote the credit score section three times. The first version was too technical. The second was too simplified and missed important details. Third attempt: trying to find the balance."

Writing forces clarity. You can't hide behind vague understanding when you have to explain something in concrete terms.

The Sections I Had No Business Writing

Chapter on Retirement Planning: I'm 15, writing about retirement planning. I don't even know what career I'll have. But I researched 401(k)s, IRAs, compound growth over decades. Made spreadsheets showing how starting early matters.

Did I understand this deeply? Not really. Did I learn a lot writing it? Absolutely.

Chapter on Investing in the Stock Market: I'd never bought a stock. Still haven't. I was explaining how to research companies, read financial statements, understand market trends.

I felt like a fraud writing some of this. Who was I to give advice?

But then I'd remind myself: I'm not claiming expertise. I'm sharing what I learned. That's different.

What My Teachers Asked That I Couldn't Answer

During my Personal Project presentation, my supervisor asked questions I hadn't considered:

"What about investing in international markets?"
I don't know. I only researched Indian markets because that felt overwhelming enough.

"How do Gen Z readers in different economic situations apply this advice?"
Good question. Most of my research was middle-class focused. I hadn't thought deeply about how advice changes if you're financially struggling or if you're wealthy.

"What about cryptocurrency?"
Um... I read about it, but I don't understand it well enough to recommend anything. So I left it out?

These questions revealed the limits of my understanding. I wasn't writing a comprehensive financial textbook. I was writing what one curious teenager managed to learn in a few months.

And that's okay. That was the project.

The Editing Process Was Humbling

I thought writing the first draft was the hard part. Then I started editing.

Reading my own writing weeks later, I found:

Paragraphs that explained things in the most confusing way possible
Sections where I clearly didn't understand the concept as well as I thought
Advice that sounded confident but was actually oversimplified
Contradictions between chapters because I'd learned something new while writing later sections

I rewrote probably 40% of the book.

Then my mentor read it and pointed out more issues:

"This section on credit cards makes it sound like they're always bad. But if used responsibly, they're useful tools."
"You explain compound interest mathematically but don't show real examples that Gen Z can relate to."
"This advice about investing is technically correct but unrealistic for most teenagers. What can they actually do right now?"

Each round of feedback made the book better. Also made me realize how much I still didn't know.

What Teaching Taught Me

The irony: I learned more about finance by trying to teach it than I would have just studying it for myself.

When you have to explain something simply, you must understand it deeply. You can't hide behind jargon or vague understanding. If you can't explain it to someone who knows nothing, you don't really get it yourself.

Writing is thinking. I thought I understood budgeting until I tried to write a clear, practical guide to it. Writing revealed gaps in my knowledge I didn't know existed.

Teaching creates accountability. If someone reads my book and follows the advice, it better be good advice. That responsibility made me research more carefully than if I was just learning for myself.

The best way to learn is to commit to teaching it. This principle has carried over to everything else. My blog, my YouTube videos, even explaining concepts to classmates—teaching forces you to clarify your own understanding.

The Parts I'm Proud Of

The tone. I didn't write like a financial advisor talking down to young people. I wrote like a peer who just figured something out and wanted to share it. That authenticity—including admitting what I didn't know—made it more relatable than textbook-style guides.

The Gen Z specificity. Most financial books are written for people with steady incomes, mortgages, families. I focused on challenges Gen Z actually faces: student debt, gig economy, unclear career paths, economic uncertainty.

The process journal. Documenting my learning journey—the confusion, the breakthroughs, the mistakes—made the project about learning, not just producing a book. That's what my supervisor valued most.

The Parts I'd Change Now

If I wrote this book today, I'd:

Be more honest about what I don't know. I tried to sound authoritative in some sections where I should've said "this is complex and I'm still learning, but here's what I understand so far."

Include more diverse perspectives. My research was limited to resources I could access. Real financial experts, people from different economic backgrounds, international perspectives—all missing.

Make it more actionable. Some chapters explain concepts well but don't give clear "here's what to do today" steps for teenagers.

Address economic inequality more directly. Financial literacy is important, but systemic issues matter too. The book focuses too much on individual responsibility without acknowledging structural barriers.

These aren't failures exactly. They're limitations of a 15-year-old's understanding. But they're worth acknowledging.

What This Experience Actually Taught Me

You don't need to be an expert to learn in public. I wasn't pretending to be a financial expert. I was documenting what a curious student could learn. That's valuable in its own way.

Teaching is a forcing function for learning. When you commit to teaching something, you push yourself to understand it more deeply than you would otherwise. This principle has shaped how I approach learning everything now.

Imperfect knowledge shared is better than perfect knowledge kept to yourself. Yes, my book has limitations. But some people have told me it helped them start thinking about money differently. That wouldn't have happened if I'd waited until I was a financial expert to write it.

Process matters more than product. The book itself is nice. But what really mattered was the learning process—the research, the struggle to understand, the iterative improvement. That's what the Personal Project was actually about.

To Anyone Thinking About Creating Something

Don't wait until you're an expert. Create from whatever level you're at right now. Document your learning. Share your confusion along with your breakthroughs. People relate to the messy journey more than polished expertise. You'll feel like a fraud sometimes. That's normal. As long as you're honest about your limitations and don't pretend to know more than you do, you're not actually being fraudulent. The best time to teach something is right after you've learned it. You still remember what was confusing. Experts forget what it's like to be a beginner.

Am I qualified to have written a book about money at 15? Probably not. Did writing it teach me more than any finance class could have? Absolutely. Would I do it again? Yes. Maybe with a disclaimer on every page: "Written by a teenager still figuring this out. Read critically."

That disclaimer might have actually made it better.

What Winning Competitions Taught Me About Losing

Nikesh — Sun, 26 Oct 2025 07:04:08 GMT

Master's Union Next-Gen Summer Skills Competition: 1st Place
Master's Union Winter Entrepreneurship Bootcamp: Winner (Back-to-Back)
Model United Nations: 3x Outstanding Delegate, Best Journalist Award

On paper, these look impressive. When people hear about them, they say: "Wow, you must be really good at this."

Here's what those bullet points don't show: the projects that failed completely, the pitches that fell flat, the conferences where I embarrassed myself, and the weeks of work that led nowhere. This isn't a post about winning. It's about everything that happened before, after, and between the wins—the parts that actually taught me something.

The Pitch That Won (After Three That Didn't)

BioPod—our AI-powered indoor farming solution—won at Master's Union's Winter Bootcamp. The judges loved it. The presentation was smooth. We answered questions confidently. What nobody saw: the three ideas we pitched before BioPod that went absolutely nowhere.

Idea 1: A marketplace for local artisans. Judges' feedback: "Too broad, not scalable, saturated market."

Idea 2: A platform connecting students with mentors. Feedback: "Unclear revenue model, how is this different from LinkedIn?"

Idea 3: An app for managing household chores. Feedback: "Solving a problem nobody is paying to solve."

Each rejection stung. After the third one, I genuinely questioned whether I was capable of thinking through business ideas properly. My teammates were frustrated too. We'd spent hours on each pitch, only to be told it wasn't good enough.

BioPod was our fourth attempt. And honestly? It wasn't necessarily a better idea than the others. It was a better pitch. We'd learned from three failures what judges were actually looking for: clear problem statement, defensible solution, realistic business model, demonstration of market understanding. The win didn't come from being brilliant. It came from failing three times and paying attention to why.

The MUN Conference Where I Froze

People see "3x Outstanding Delegate" and assume I'm naturally good at public speaking and debate. Let me tell you about the MUN conference in 10th grade where I completely froze.

I was representing a country in the United Nations Security Council. Big committee, experienced delegates, intense debate about international intervention. I'd prepared for weeks—research notes, position papers, opening speech memorized. My turn to speak came. I stood up, walked to the podium, looked at 60 people staring at me.

My mind went blank. Not "I forgot a few lines" blank. Completely, utterly blank. I couldn't remember my country's position. Couldn't remember my opening line. Stood there in silence for what felt like an eternity (probably 15 seconds) before mumbling something incoherent and sitting down.

I wanted to disappear. The rest of that conference, I barely spoke. I was too embarrassed. Convinced everyone thought I was incompetent. After it ended, one of the senior delegates—someone who'd won multiple awards—pulled me aside. "First time freezing up?" I nodded.

"Happened to me too. Still happens sometimes. The difference is, next time you'll know that feeling, and you'll push through it anyway." He was right. The next MUN, I felt that panic rising when I stood to speak. But I knew what it was. I pushed through. My speech wasn't amazing, but I finished it.

That's what those Outstanding Delegate awards don't show: the conferences where I was terrible, the moments I wanted to quit, the slow process of getting comfortable being uncomfortable.

The ApniDukaan Detail They Don't Ask About

"Won 1st place for ApniDukaan e-commerce project." True. But here's what I don't usually mention: I won not because ApniDukaan made the most money (it didn't), had the best design (it didn't), or was the most innovative (definitely wasn't).

I won because during the presentation, I was honest about what went wrong. While other students showed polished success metrics, I showed my failed marketing campaigns. My supplier issues. My customer complaints. My wrong assumptions about pricing. One judge asked: "If you could start over, what would you do differently?" I had a whole list ready. Because I'd messed up enough times to know exactly what I'd change. Another student—who'd made more revenue than me—got asked the same question. They confidently said they wouldn't change anything. The judges looked skeptical. After the results were announced, that same judge told me: "We're not looking for perfection. We're looking for learning. You clearly learned from your mistakes."

That's when I realized: the value wasn't in winning. It was in being honest about the messy process that got me there.

What the Awards Don't Teach You

They don't teach you resilience. Failing does. Losing a competition, then deciding to try again—that builds resilience. The trophy at the end is just a nice bonus.
They don't teach you critical thinking. Getting harsh feedback that forces you to completely rethink your approach—that teaches critical thinking. The award just confirms you eventually figured it out.
They don't teach you collaboration. Working with teammates when your idea gets rejected and everyone's frustrated—that teaches collaboration. Winning together is just the celebration of figuring out how to work through hard moments.
They don't validate your worth. This is the big one. I thought winning would make me feel competent, validated, like I'd proven something. It feels good for maybe a week. Then you're back to working on the next thing, feeling uncertain again.

Your worth isn't in the wins. It's in showing up, trying things, learning from what doesn't work.

The Losses That Mattered More

The business pitch that bombed: We pitched Lego Homes at one bootcamp before winning with it at another. The first time? We got destroyed in Q&A. Judges pointed out flaws we hadn't considered. We felt defensive and defeated.

But we listened. Rewrote everything. Addressed their concerns. The second pitch—the winning one—was built on the foundation of that first failure.

The MUN conference with no awards: I worked harder preparing for that conference than any other. I was so sure I'd win something. I didn't even get a special mention.

Sitting in the closing ceremony watching others get recognized hurt. But it made me analyze: what did they do that I didn't? How were their arguments structured? How did they build alliances?

Those observations made me better at the next conference. That award wouldn't have happened without this loss.

The essay competitions I entered and heard nothing back from: Not even feedback. Just silence. Those taught me that sometimes your work just isn't chosen, and you have to be okay with that. Not everything you create will be recognized, and that's fine. You keep creating anyway.

What I'm Trying to Remember

When I look at my "achievements," I'm trying to remember: These represent maybe 10% success, 90% stumbling around figuring things out. The wins came after multiple losses. They're the visible part of a much messier process. The recognition is temporary. The learning from failures lasts longer. I'm not "good at this." I've just failed at it enough times to occasionally get it right.

The competitions I didn't win taught me more than the ones I did.

To Anyone Who Keeps Losing

If you're entering competitions, pitching ideas, trying things and not winning—this is normal. This is most of the experience for most people. The winners you see? They're not winning everything. You're just not seeing all their losses. I have a folder on my laptop called "Failed Projects." It has way more files than my "Successful Projects" folder. That ratio is normal.

Keep trying. Not because you'll definitely win eventually (maybe you will, maybe you won't), but because the trying itself teaches you things you can't learn any other way. And if you do win something? Enjoy it. Take the photo. Update your resume. Feel proud for a moment. Then remember: this doesn't define you. The willingness to try again after failing—that defines you more than any trophy ever will.

The Intersection of Everything: Why I Study Business, Politics, Computer Science, AND Math

Nikesh — Sun, 26 Oct 2025 06:46:20 GMT

"Why are you taking so many different subjects?"

I get this question a lot. Usually followed by: "Wouldn't it be better to focus on one thing?" My IB subjects—Business Management, Global Politics, Computer Science, Mathematics—seem scattered to people. Like I couldn't make up my mind about what I wanted to study, so I just picked everything. But here's what I've realized over the past two years: the most interesting problems don't live in just one subject. They live in the spaces between them.

The Question That Started This

Last year, during my ApniDukaan e-commerce project, I was trying to figure out pricing strategy. Simple question: how much should I charge for products? Business Management taught me about profit margins, competitive pricing, and value-based pricing. Useful frameworks.

But then I started thinking about the actual customers. Who were they? Why would they buy from an unknown store run by a teenager? What political and economic factors influenced their purchasing power? Global Politics kicked in. I started considering: What's the economic situation in India right now? How do global supply chains affect local prices? What role does consumer trust play in e-commerce in developing markets?

Then the technical side: How do I build dynamic pricing into my system? What algorithms make sense? How do I collect and analyze customer data ethically? Computer Science and Math entered the conversation. No single subject could answer my question. I needed all of them talking to each other.

That's when I understood: these subjects aren't separate. They're different lenses for looking at the same complex world.

How Computer Science Changed How I Think About Politics

Here's something weird: learning to code made me better at analyzing political systems. In Computer Science, you learn to think in systems and feedback loops. If this happens, then that happens. What are the inputs? What are the outputs? Where are the bottlenecks? When I started applying this thinking to Global Politics, everything became clearer.

Take my research on Hyderabad's lake pollution and urban development policies. I wasn't just analyzing "government bad, corporations bad, environment suffering." I was mapping it like a system:

Input: Urban development demand, political pressure for growth
Process: Policy creation (or lack thereof), enforcement gaps, stakeholder conflicts
Output: Environmental degradation, public health issues
Feedback loops: Where does pressure come from? Who benefits? What incentives exist?

Thinking like a programmer—breaking down complex problems into logical components—made political analysis less overwhelming. I could identify where the system was breaking. Not just point at problems, but understand the mechanisms creating them.

How Global Politics Made Me a Better Business Student

Business Management class teaches you about markets, competition, operations. All useful. But Global Politics taught me: nothing happens in a vacuum. When we studied trade policies and international relations, I started seeing how global dynamics shape business decisions. A company doesn't just "expand internationally." They're navigating trade agreements, cultural differences, regulatory environments, political risks.

During my CuriousRubik internship, we had a client who wanted to expand their business to Southeast Asian markets. My Business Management knowledge said: "Analyze market size, competition, entry strategies."

My Global Politics knowledge added: "What are the regulatory environments in these countries? How stable are their governments? What are the cultural attitudes toward foreign businesses? How do regional trade agreements affect operations?"

These questions made my analysis actually useful instead of generic textbook responses.Business strategy without understanding political and cultural context is just theory. Global Politics gave me the context that Business Management sometimes skips over.

Math: The Language Everything Else Speaks

I used to think Math was separate from my other subjects. It felt pure, abstract, disconnected from messy human problems. Then I started working on my machine learning research project—building a predictive retail price optimization system. Suddenly, Math wasn't abstract anymore. It was the foundation everything else was built on.

The algorithms I was coding? Mathematical functions.
The business problem I was trying to solve? Optimizing a mathematical equation under constraints.
The political-economic context of retail pricing? Expressed through data that needed mathematical analysis to make sense of.

Linear regression, decision trees —these aren't just Math concepts. They're tools for solving real business problems, analyzing political trends, building functional code. Math became the language that let my other subjects talk to each other. Without it, I could have business ideas and political understanding and technical knowledge, but I couldn't connect them rigorously.

The Conversations Between Subjects

Here's what happens when you study multiple disciplines simultaneously: they start having conversations with each other in your head.

During Business Management class: "This marketing strategy makes sense theoretically, but how would you actually implement it technically? What does the code look like? And would this work in markets with different political structures?"
During Global Politics research: "This policy sounds good, but what are the economic incentives for stakeholders? Can we mathematically model the outcomes? How would you build a system to track implementation?"
During Computer Science: "This algorithm is efficient, but what business problem does it solve? Could this technology be misused politically? What ethical frameworks apply here?"
During Math: "This is beautiful abstractly, but where does this apply in real systems? How do businesses use this? How do governments model policy outcomes with this?"

I'm not saying I have answers to all these questions. Most of the time, I don't. But I'm learning to ask them. And the asking itself makes my understanding deeper.

What This Looks Like in Practice

Let me give you a concrete example: my machine learning research project on retail price optimization.

The Business Question: How should retailers set prices to maximize profit while staying competitive?
The Computer Science Component: Building a system that uses regression models (Decision Tree, Linear Regression) and clustering (K-Means) to predict optimal pricing.
The Math Foundation: Understanding the algorithms, evaluation metrics (RMSE, R²), statistical significance, feature importance.
The Political-Economic Context: Why does this matter? How do pricing strategies affect consumers differently across economic classes? What are the ethical implications of dynamic pricing? How do market structures and regulations constrain pricing decisions?

If I only knew Business Management, I could talk about pricing strategy theoretically but couldn't build anything. If I only knew Computer Science, I could build the system but wouldn't understand the business problem or ethical implications. If I only knew Math, I'd understand the algorithms but miss why they matter in the real world.

I needed all of it. Not just knowing each subject separately, but understanding how they connect.

The Questions I'm Asking Now

This interdisciplinary thinking has changed what questions interest me:

Not: "What's the best algorithm for this problem?" But: "What business problem am I solving, and is technology actually the right solution? What are the broader implications?"
Not: "What's the optimal business strategy?" But: "How does political context shape what's actually possible? How would you technically implement this? What does the data say?"
Not: "What's the mathematical model?" But: "What real-world system am I trying to understand? How accurate does this need to be for the business decision? What am I missing?" These richer questions lead to more interesting answers. They also reveal how much I still don't understand.

Why This Matters for What I Want to Study

People ask what I want to study at university. Engineering? Business? Something else? Honestly? I want both. Not because I can't decide, but because I think they need each other.

Engineering gives you the tools to build solutions. Business ensures those solutions actually reach people and create value. Politics and Math provide the context and language to think rigorously about what you're building and why it matters. I want to learn in environments where it's normal to ask questions that span disciplines. Where you can talk about technical implementation and business strategy and ethical implications in the same conversation. Because the real problems I care about—making technology accessible, building sustainable businesses, creating systems that work for people—don't fit neatly into one academic department.

What I'm Still Figuring Out

I don't have this all worked out. Most days, I feel like I'm barely keeping up with each individual subject, let alone synthesizing them brilliantly. Sometimes I wonder if I'm spreading myself too thin. Should I just focus on becoming really good at one thing instead of being mediocre at several? But then I work on a project that needs multiple perspectives, and I'm grateful I at least have basic literacy across these different domains. Even if I'm not expert-level at any of them.

I'm also still learning how to actually integrate these subjects, not just study them in parallel. Knowing Computer Science AND Business Management doesn't automatically mean you can build a good tech business. The synthesis is its own skill that I'm still developing.

The Messiness Is the Point

Here's what I've realized: real problems are messy and interdisciplinary. They don't arrive with labels saying "this is a Computer Science problem" or "this is a Business problem." A challenge like climate change? That's science, politics, economics, engineering, social behavior, international relations, data analysis. All of it. Simultaneously. A question like how to make technology accessible in developing markets? That's understanding technical constraints, business models, cultural contexts, political structures, economic realities.

The world doesn't organize itself by academic department. Why should my learning? Maybe I am taking "too many" subjects. Maybe I'm not going as deep into each one as I could if I specialized. But I'm learning to think across boundaries. To see connections others might miss. To ask questions that combine technical feasibility with business viability with ethical considerations. That feels more valuable than being expert in one narrow domain while missing how everything connects.

What This Looks Like Moving Forward

I don't know exactly where this interdisciplinary approach will lead me. I'm 17, still figuring out so much. But I know I want to keep learning at the intersections. Keep asking questions that don't fit neatly into one subject. Keep building things that require multiple types of knowledge. Because the most interesting problems—the ones worth solving—live in the messy spaces between disciplines.

And if I'm going to work on problems that matter, I need to be comfortable in that messiness.

Do you study multiple different subjects? How do they connect for you? I'm curious how others think about the intersections between what they're learning.

Why I'm Learning to Code at 17 (And Why It's Harder Than I Expected)

Nikesh — Sun, 26 Oct 2025 06:33:22 GMT

Let me tell you about the least glamorous part of learning to code: the hours you spend completely stuck. Not stuck in a productive "I'm working through this" way. Stuck in a "I've tried everything I can think of and nothing makes sense" way. Initially, I spent two hours debugging an error message: TypeError: Cannot read property 'map' of undefined. Two hours. For what should have been a basic feature—displaying a list on a webpage.

This is what learning to code actually looks like. And nobody really tells you this before you start.

Why I Didn't Wait for University

People ask me this a lot. Why not just relax during IB and learn programming properly at university with structured courses and professors?

The honest answer: I was too curious to wait.

I kept using apps every day—Instagram, Google Maps, online stores—and wondering: how do these actually work? What does that code look like? Could I build something like this? IB Computer Science taught me basics, but it felt theoretical. We solved textbook problems, not real ones. I wanted to build things people could actually use. So I joined Scaler, a rigorous software engineering program. I thought: "Great, now I'll learn to code properly." What I actually learned: I knew way less than I thought I did.

The Concepts That Broke My Brain

Arrays: Made sense. A list of items you can access by position. Fine.

Linked Lists: Completely lost me. The concept sounded simple—each item points to the next one. But implementing it? Writing code to reverse a linked list? I stared at that problem for an entire Sunday. I looked at solutions online afterward, and they made sense when I read them. "Obviously you need three pointers—previous, current, and next." But I never would have figured that out alone.

Time Complexity: In school, we wrote code that worked. Nobody mentioned whether it was efficient. "Why does it matter if something takes 0.01 seconds versus 0.001 seconds?" I thought. Then we ran my simple loop on a list of 1 million numbers. It took forever. Someone else's binary search found the answer instantly. That's when I realized: writing code that works isn't the same as writing good code.

Debugging: The Part Nobody Warns You About

Here's what shocked me: you spend more time fixing code than writing it.

I'd write perfectly logical code (or so I thought). Run it. Error. Fix it. Run it again. Different error. Fix that. Run it. Now it gives the wrong answer. Spend another hour figuring out why. During my internship at UnyKloud, I built a simple form—users enter data, click submit, it saves to the database. Should've taken an hour, maybe two.

I spent three hours debugging why the submit button didn't work. The problem? I wrote onClick={handleSubmit()} instead of onClick={handleSubmit}. One set of parentheses. Three hours to find it. When I finally figured it out, I didn't feel smart. I felt exhausted.

Watching Senior Developers Make It Look Easy

At my internship, I work with developers who've been coding for years. A feature that takes me a full day, they complete in two hours.

I once showed a senior developer a component I'd spent a week building. I was proud—it worked, it was organized. He looked at it for thirty seconds: "This will cause performance issues with lots of data. You're making too many API calls. Also, extract this repeated code into a reusable component." He rewrote it in twenty minutes. His version was cleaner, faster, half as much code. I felt impressed and slightly defeated at the same time."Everyone's code looks like this at first," he told me. "You learn by doing it wrong, getting feedback, doing it better next time."

What I Still Don't Understand

Let me be honest about the gaps:

Closures in JavaScript: I've read explanations multiple times. I get it for five minutes, then it slips away.
System Design at Scale: How do you build something that handles millions of users? I understand the theory. I have no intuition for what actually works.
When to Use Which Data Structure: In assignments, they tell you: "use a hash map." In real projects? You have to figure it out yourself. Still learning.
Asynchronous Programming: I can follow examples with promises and async/await. Truly understanding what's happening underneath? Still working on that.

The Impostor Syndrome Is Constant

There's this feeling that everyone else gets it faster than you do. On Scaler forums, people ask sophisticated questions about optimization and edge cases. Meanwhile, I'm Googling "how to reverse a string in JavaScript" for the third time. At my internship, developers casually reference concepts I've never heard of. I nod along, then frantically Google them later. I mentioned this to a senior developer once. He said: "I've been coding for eight years. I still Google basic syntax. The difference is, I don't let it stop me from trying." That helped. Not completely—I still feel like I'm faking it most days—but enough to keep going.

The Small Wins

Despite the frustration, there are moments that make it worth it. When I finally solved that recursion problem at 2 AM. Not because someone showed me—I worked through it myself. When the code ran correctly, I literally jumped out of my chair. When a feature I built at my internship worked on the first try. That almost never happens. I kept testing it, expecting bugs, but it just... worked. When a user said the UI component I built was "intuitive and easy to use." They had no idea how many hours I'd spent on it. To them, it just worked. That felt incredible. These moments are rare. But they're why I keep going.

What I've Actually Learned (Beyond Code)

Problem-Solving Persistence: You can't give up when you're stuck on a bug. You have to keep trying different approaches. This has carried over to IB work—I'm more willing to push through difficult problems.
Breaking Down Complexity: Code forces you to think step-by-step. You need specific, logical steps, not vague ideas. This helps in Math and even Global Politics essays.
Humility: Error messages don't care about your ego. Code either works or it doesn't. I'm much more comfortable now saying "I don't know" and asking for help.
Appreciation for Digital Products: I can't use any app without thinking about how it was built. That smooth animation? Someone spent hours on it. That instant search? Complex optimization underneath. I have so much more respect for developers now. Why I Don't Regret Starting Early

Would university have been easier? Yes. Structured courses, clear explanations, classmates at the same level, time to focus. But starting at 17 has given me realistic expectations. I know how hard this is. When I get to university, I won't think I'll "learn to code in three months." I'll know confusion is normal. That debugging is most of the work. That feeling lost doesn't mean you're not cut out for this. Plus, I've built real things—applications people actually use. That context matters.

If You're Thinking About Learning to Code

A few things I wish I'd known:

It's harder than you think. Way harder. You'll spend hours on simple problems. That's normal.
You'll feel stupid regularly. Get comfortable with it. It means you're learning something challenging.
Tutorials make it look too easy. They edit out the debugging, the confusion, the time reading documentation. Your journey will be messier.
You don't need to understand everything immediately. Some concepts I've learned three or four times before they clicked.
Build things, even if they're terrible. My first projects were embarrassingly bad. But building teaches you more than tutorials ever will.

Still Learning

I've been coding seriously for about a year and a half. I'm not a software engineer. I'm not close. I'm a student learning to code while managing IB. Some days I feel like I'm progressing. Other days I feel like I understand less than last week. I still get stuck on problems experienced developers would solve in minutes. I still Google basic syntax. I still confuse concepts I thought I'd mastered.

But I can build things now that I couldn't a year ago. I can read code and roughly understand it. I can work through problems, even if it takes longer than it should. That error message at the start? I eventually fixed it. The problem: I was trying to map over data before it loaded from the API. Once I added a loading state, everything worked.

Took me three hours total. A senior developer probably would've spotted it in three minutes. But I figured it out. And next time, I'll know what to look for. That's progress. Slow, frustrating, humbling progress. But progress.

From Classroom Theory to Client Calls: What My CuriousRubik Internship Taught Me About Business

Nikesh — Sun, 26 Oct 2025 05:36:50 GMT

I was sitting in my first real client meeting, trying to look like I belonged there. My notebook was open, pen ready, professional expression on my face. Inside? I was terrified.

The client—a small business owner looking to build a custom inventory management system—was explaining his problems. His current system was slow, his team was frustrated, and orders were getting mixed up. He was talking fast, using industry terms I'd never heard before, occasionally referencing "the old system" that I knew nothing about.

My manager was asking questions, taking notes, nodding thoughtfully. The senior solution designer was sketching something on his iPad. And I was sitting there thinking: "I have no idea what's happening. What am I supposed to be doing right now?"

Welcome to my internship at CuriousRubik, where I learned that real business is nothing like IB Business Management class.

How I Got Here (Mostly Luck and Timing)

Let me be honest about how this internship happened: I got lucky.

I'd been looking for opportunities to see how tech companies actually operate. I'd done some coding through Scaler, built ApniDukaan, learned the theory in Business Management class. But I wanted to understand the middle ground—how do you translate business problems into technical solutions? How do companies actually decide what to build? I found CuriousRubik through a connection. They were a tech consultancy working with various businesses to build custom software solutions. When I reached out, they were looking for a Business Analyst intern—someone who could help bridge the gap between clients and developers.

The job description intimidated me. "Experience with requirements gathering," "knowledge of agile methodologies," "familiarity with wireframing tools." I had maybe 30% of what they were asking for. But I applied anyway, was honest in the interview about what I didn't know, and somehow they said yes. Looking back, I think they appreciated that I admitted my gaps rather than pretending to know everything. My first day, I was given access to their project management tools, introduced to the team, and immediately put on three active client projects.

I had no idea what I was doing.

The Gap Between Theory and Reality

In IB Business Management, I'd learned about stakeholder analysis, market research, operations management. We'd done case studies about companies making strategic decisions. I'd written essays about competitive advantage and organizational structure. But sitting in that first client meeting, I realized: none of that prepared me for this.

In class, case studies are clean. The information is presented clearly. The problem is defined. You analyze it, write your answer, get your grade. In the real meeting, the client wasn't presenting a clear problem. He was venting. He was jumping between three different issues—inventory tracking, team communication, and customer notifications. He'd start explaining one thing, then remember something else, then go off on a tangent about his supplier.

My manager had to gently guide the conversation back, ask clarifying questions, dig deeper into what the real issue was. I was scribbling notes frantically, trying to keep up, but mostly feeling lost.

After the meeting, my manager asked me: "So what do you think the core problem is?" I looked at my notes—five pages of scattered information. I had no idea how to synthesize it into one clear problem statement. "Um... they need a better system?" I offered weakly. He smiled. Not unkindly, but in a way that said, "You're going to need to be more specific than that."

Learning to Listen (Which Is Harder Than It Sounds)

The first skill I had to develop wasn't technical—it was learning how to actually listen. In my second week, I was sitting in on a call with a client who ran a small e-commerce business. She was explaining how her team processed orders, and I was nodding along, thinking I understood. Afterwards, my manager asked me to draft the document based on that call. I spent three hours writing what I thought was a comprehensive document outlining what they needed.

When I showed it to him, he read through it quietly, then looked up. "This is what they said they wanted. But is it what they actually need?" I stared at him, confused. "Isn't that... the same thing?"

He pulled up the recording of the call and pointed to a specific moment. The client had mentioned, almost as an aside, that her team was manually checking every order for errors because they didn't trust the automated system."Why don't they trust it?" he asked me. I didn't know. I hadn't thought to ask.

That's when I learned: clients don't always know how to articulate their real problems. They tell you symptoms—"the system is slow," "my team is frustrated"—but not the root cause. Your job is to dig deeper, ask follow-up questions, and figure out what's actually broken. I started practicing this. In the next few meetings, I forced myself to ask more questions, even when I felt dumb for not understanding something obvious:

"Can you walk me through exactly how you do this now?" "What happens when this goes wrong?" "Why do you think this is happening?" Sometimes the seniors would look at me like, "We were about to ask that," but other times my questions led somewhere useful. More often, I was just trying to catch up to what everyone else already understood.

The Art of Translation

Here's what I didn't understand about being a Business Analyst: you're essentially a translator.

The client speaks in business terms—revenue, customer satisfaction, operational efficiency.

The developers speak in technical terms—APIs, database schemas, frontend frameworks.

Your job is to stand in the middle and make sure both sides understand each other. I was terrible at this initially. A client would say, "We need the system to be more intuitive," and I'd write that down verbatim in the requirements document. The developer would read it and ask, "What does 'intuitive' mean specifically? What should the interface do?"

I didn't know. I hadn't asked.

I learned to translate vague requirements into specific ones:

"More intuitive" became "Users should be able to complete the checkout process in under four clicks"
"Better reporting" became "Weekly automated reports showing sales by category, sent via email"
"Faster system" became "Page load time under 2 seconds"

But this took time to learn. I'd go back to clients multiple times asking for clarification, feeling embarrassed that I didn't get it the first time. My manager kept reminding me: "It's better to ask now than to build the wrong thing." Still, I felt like I was bothering people with basic questions.

The MIRO Flows and Prototypes I Didn't Know How to Create

After a few weeks of sitting in meetings and writing BRDs, my manager asked me to create a MIRO flow for a new project.

I nodded confidently. Internally, I panicked. What's a MIRO flow? I Googled it quickly. MIRO is a digital whiteboard tool. A "flow" is basically a visual representation of how users will move through a system. Okay, that makes sense conceptually.

Creating one? Completely different story. I spent four hours making my first MIRO flow. It was a mess—boxes everywhere, arrows going in illogical directions, trying to map out every possible scenario. I showed it to my manager the next day, already knowing it wasn't right.

He looked at it for about thirty seconds. "This is too complicated. What's the simplest path a user would take?" I hadn't thought about the simplest path. I'd tried to map everything at once.

He walked me through it: start with the main user journey. Just the basics. Then add edge cases later. Think about what the user wants to accomplish, not every possible thing they could do. We redid it together. His version was clean, logical, easy to understand. Mine had been a visual representation of my confused brain.

I got better at this over time. I learned that good flows aren't about being comprehensive—they're about being clear. But every new project still takes me multiple attempts before I create something that actually helps the developers understand what to build.

Testing As a "User Persona"

One of my roles was to test features before they went to the client. I was supposed to step into different "user personas"—act like I was the sales manager, or the warehouse operator, or the customer—and see if the system made sense from their perspective.

This sounds straightforward. It wasn't.

I'm 17. I've never managed a warehouse. I've never run a sales team. How am I supposed to know if this interface makes sense for them? I remember testing an inventory management feature and thinking, "This seems fine." But I had no real context for whether it actually solved the problem. I was just clicking buttons and making sure they worked technically. My manager noticed I wasn't catching issues. "You're testing like a developer," he said. "Test like a user who has five other things to worry about and just wants to get this task done quickly." That perspective shift helped. I started thinking: if I were overwhelmed and busy, would I figure out how to use this? If I'd never seen software like this before, would it make sense? I started catching issues: buttons that were technically functional but placed in illogical spots. Features that worked but required too many steps. Labels that made sense to us but would confuse the actual users.

But I still felt like I was guessing half the time. I didn't have the real-world experience to know what users actually needed. I was extrapolating from my limited understanding.

The Coordination Dance With Developers

Here's something I underestimated: developers are incredibly smart, but they're not mind readers. I'd write a requirement like "The system should send a notification when inventory is low," and think I'd been perfectly clear. The developer would implement it, and then I'd see it in action and realize: oh, they're sending a notification every single time someone opens the inventory page if something is low. That's not what I meant. I meant a daily summary notification. But I hadn't specified that. I'd assumed it was obvious.

I learned to be painfully specific:

When should the notification be sent? (Daily at 9 AM)
Who should receive it? (Warehouse manager only)
What should it include? (List of items below threshold, with current quantities)
What should the threshold be? (Client to define)

Even then, I'd miss things. There was always some edge case I hadn't thought of.

The developers were patient with me, mostly. Sometimes I could tell they were frustrated when I'd come back with changes to requirements they'd already built. I felt guilty every time, but I also didn't know what I didn't know until I saw it actually working. I learned to involve developers earlier in the process, showing them my requirements documents before marking them final. They'd point out ambiguities or technical impossibilities that I hadn't considered. This saved time, even though it meant admitting I needed help before claiming something was "done."

What IB Business Management Didn't Teach Me

I'm grateful for what I'm learning in Business Management class. The concepts—understanding stakeholders, analyzing markets, thinking about organizational structure—are genuinely useful.

But there's so much it doesn't cover:

The emotional labor of managing client expectations: Sometimes clients want something that's technically impossible or would cost way more than they can afford. Having those conversations—being honest but not discouraging—is a skill I'm still developing. In class, we analyze case studies from an objective distance. In real life, you're telling someone who's excited about their business idea that their vision isn't feasible, and watching their face fall.
The messiness of real projects: In class, projects have clear phases and timelines. In reality, clients change their minds halfway through. Requirements evolve. What you thought was a three-week project becomes two months. You have to adapt constantly.
The importance of relationships: The theory teaches you about formal organizational structures and communication channels. But in practice, having a good relationship with the developers means they'll give you honest feedback when your requirements don't make sense. Having trust with clients means they'll be honest about their budget constraints. These relationship skills aren't in the textbook.
How many things can go wrong simultaneously: We had a project where the client was late providing information, the developer assigned to it got sick, and the tool we were using for prototyping had a technical glitch. All in the same week. Your case studies don't prepare you for juggling multiple problems while still moving forward.
What I'm Still Really Bad At

Let me be clear about what I haven't figured out:

Estimating time: When my manager asks "How long will it take you to create that requirements document?" I genuinely don't know. Sometimes it takes two hours. Sometimes it takes eight. I'm getting better at building in buffer time, but I still underestimate more often than not.
Knowing when to escalate issues: Sometimes I spend hours trying to solve a problem that my manager could have answered in five minutes. Other times I ask questions too early, when I should have tried figuring it out myself first. I haven't found the right balance.
Reading between the lines: Senior team members can listen to a client call and immediately identify what's not being said—the concerns they're hesitant to voice, the budget they haven't mentioned, the timeline pressure they're under. I'm not there yet. I hear the words, but I miss the subtext.
Technical depth: I can translate between business and technical language at a basic level, but when conversations get deeply technical, I'm lost. I nod along like I understand, then Google terms afterwards. I'm learning, but there's a huge gap between my current knowledge and where I need to be.
Why I'm Grateful For This Opportunity

I'm aware that getting this internship at 17 is not normal. Most students my age aren't sitting in client meetings or working on real business projects. I don't say this to brag—I say it because I'm genuinely grateful, and I don't take it for granted.

CuriousRubik didn't have to hire a student with minimal experience. They could have brought on someone with actual business analysis experience who wouldn't need constant guidance. But they took a chance on someone willing to learn. And more importantly, they created an environment where it was okay to not know things, to ask questions, to make mistakes.

My manager never made me feel stupid for misunderstanding something. The senior solution designers patiently explained concepts I should have known. The developers tolerated my vague requirements and helped me improve them. This kind of environment—where learning is expected and supported—is rare. I know this because I've heard stories from friends who had internships where they were treated like they should already know everything.

What This Experience Changed

Before this internship, I thought understanding business meant knowing theory—market segmentation, financial ratios, organizational structures. Now I understand that real business is about people. It's about understanding what clients actually need (even when they can't articulate it), coordinating with team members who have different priorities, managing expectations when things don't go as planned.

The theory is useful—it gives you frameworks to think through problems. But the practice is where you actually learn how things work. I'm more comfortable with ambiguity now. In school, there's usually a right answer. In business, there are just different approaches with different trade-offs. You make the best decision you can with incomplete information, and then adjust when you learn more.

I'm also more aware of how much I don't know. Before, I thought I understood how businesses worked. Now I realize I'm just beginning to scratch the surface. Every project shows me new layers of complexity I hadn't considered.

And weirdly, that feels good. Not knowing everything used to scare me. Now it feels like proof that I'm learning something real.

To Anyone Considering an Internship While Still in School

If you're thinking about doing an internship while juggling IB or other studies, here's what I'd say:

Expect to feel lost. You'll be in meetings where you don't understand half of what's being discussed. That's normal. Don't fake understanding—ask questions and take notes.
Your age is both an advantage and a disadvantage. Disadvantage: you lack experience and context that others have. Advantage: people expect you to ask basic questions and be learning. Use that. Ask everything. Nobody expects you to already know it all.
The work will take longer than you think. What takes a senior team member an hour might take you four hours. That's okay. You're learning while doing it. Build extra time into your estimates, and be honest with your supervisors about your pace.
You'll make mistakes. I've made so many. The key is learning from them and not making the same mistake twice. (I've definitely made some mistakes more than twice, to be honest, but I'm working on it.)
Balance is hard. I won't pretend it's easy to do an internship alongside IB. There are weeks when I'm overwhelmed. But for me, the learning is worth the stress. You have to decide if that trade-off works for you.

Still Learning

I'm still at CuriousRubik, still learning, still making mistakes. Just last week, I sent a client presentation with the wrong data in it because I'd pulled from an old version of the file. Embarrassing, but fixable.My manager keeps telling me: "You're not supposed to be good at this yet. You're supposed to be learning."

That's the mindset I'm trying to embrace. I'm not here to prove I already know everything. I'm here to figure out what I don't know and get better at it. Every client meeting teaches me something new about how to listen. Every requirements document I create is slightly less terrible than the last one. Every mistake shows me what to watch out for next time. I don't know if I want to be a Business Analyst long-term. I'm still figuring out if I'm more drawn to the technical side (building things) or the business side (understanding what to build). Maybe both, somehow.

But I know that this experience—being uncomfortable, being challenged, being in rooms where I'm the least experienced person—is teaching me things that will be useful regardless of what I end up doing.And that first client meeting where I felt completely lost? I'm still sitting in meetings where I feel that way sometimes. But now I know it's part of the process, not a sign that I don't belong there.

If you've had internship experiences—especially ones where you felt in over your head—I'd love to hear about them. How did you handle it? What did you learn ?