The FAQ

Over the last few years, I've been sharing what I'm building, learning, and breaking on the internet. Whether it's coding, AI, jobs, automation, or just life in general, one thing stayed constant: people kept asking the same questions.

Rather than typing the same answers repeatedly, I decided to write them down once. This blog is a collection of my experiences, opinions, mistakes, and things that have worked for me so far.

None of this is universal advice. It's simply what I've learned while trying things, failing at some of them, and sticking with others.

Use the bottom table of content to easily navigate through your problem.

How to Choose My Field in CSE?

If you're trying to choose a field in CSE, my advice is simple:

Stop trying to find your passion before you start.

Most people sit for months thinking:

• Should I do AI?
• Should I do Web Development?
• Should I do Cyber Security?
• Should I do DSA?
• Should I do App Development?

The problem is that you cannot realistically decide without trying them.

When I was in 11th and 12th grade, I already knew I wanted to pursue engineering. Since I was going to spend a huge part of my life working in this field, I didn't want to blindly pick something and regret it later.

So I spent months trying different things.

The first thing I tried was Java and DSA through YouTube tutorials.

Bad decision.

Java felt too difficult as a first language and I absolutely hated DSA at the time. I became frustrated and stopped coding completely for a while.

Later I came back and tried something different.

I got interested in electronics, drones, Arduino, microcontrollers, and embedded programming. I learned some C and spent time exploring that world. If resources weren't a limitation back then, I honestly think I might have ended up in embedded systems engineering.

But hardware requires money, devices, and experimentation. At that stage I didn't have enough resources, so I moved on.

Then I tried Android development with Java and Kotlin.

I watched tutorials, built a chat application, built a video calling application, and spent a couple of months learning the ecosystem.

Again, I didn't enjoy it enough to stay with it long term.

After that I tried AI and Machine Learning.

That lasted around two weeks.

At the time my mathematics fundamentals were weak. Concepts like calculus, differentiation, and integration were going completely over my head. Instead of forcing myself through something I wasn't ready for, I decided to move on.

Eventually I discovered web development.

Interestingly, I didn't even start with React or modern frameworks.

I started with Blogger.

Google's Blogger platform used XML templates, so I spent time modifying themes, creating websites, and experimenting with layouts. I even built an early portfolio that way.

That was the first time something clicked.

I enjoyed building things.

I enjoyed designing things.

I enjoyed seeing instant results.

And most importantly, I could keep doing it for hours without feeling forced.

That's how I ended up choosing web development.

Not because someone told me it had the highest salary.

Not because it was trending.

Not because I was passionate from day one.

I chose it because after trying multiple fields, it was the one I naturally kept returning to.

If you want a practical framework, here's what I would do:

1. Pick a field.
2. Spend 15 days to 2 months exploring it.
3. Watch tutorials.
4. Read documentation.
5. Build at least one small project.
6. See whether you enjoy the process.

Don't judge a field after watching three YouTube videos.

Judge it after building something.

That's when the real experience starts.

A lot of people think passion comes first and work comes later.

In reality, it's usually the opposite.

You get exposure first.

Then you develop competence.

Then you start enjoying it.

Then interest grows.

You don't discover passion instantly.

You discover it through repetition.

So don't overthink your choice too much in the beginning.

Try things.

Build things.

Quit what you genuinely dislike.

Double down on what keeps pulling you back.

That's usually your answer.

How to Learn to Code?

Most people make learning to code unnecessarily complicated.

They spend weeks choosing the perfect language, the perfect course, the perfect roadmap, and the perfect YouTube playlist before writing even a single useful line of code.

My approach is much simpler.

First, understand what you're actually trying to build.

For example, when I wanted to learn Go, I didn't start by memorizing every feature of the language. I started with a goal.

I wanted to build a CLI application.

So I went to ChatGPT and asked:

• I want to build a CLI in Go.
• What topics do I need to learn?
• Create a roadmap for me.

It gave me a list of concepts like:

• Variables
• Functions
• Structs
• Interfaces
• Packages
• Error handling
• Goroutines
• Concurrency
• Standard library usage

This is what I call knowing the unknowns.

Most beginners fail because they don't even know what they don't know.

Once I had the roadmap, learning became much easier because now I had a target.

After that, I started reading documentation, watching videos when needed, searching Google, asking AI to explain concepts, and experimenting on my own.

The important part comes after this.

You need to build.

A lot.

The more you build, the more you understand why things work the way they do.

Programming is one of those skills where understanding comes from implementation, not consumption.

You can watch 50 videos about APIs.

The moment you build one yourself, you'll learn more than those 50 videos combined.

Another thing I strongly recommend is reading source code.

Most people completely ignore this.

If you're learning a language, find good open-source projects built with it.

Read the code.

See how folders are structured.

See how features are implemented.

See how experienced developers solve problems.

You don't need to understand everything.

Even learning one new thing every day compounds over time.

Nowadays, AI makes this even easier.

You can paste an open-source repository into Cursor or VS Code and ask questions like:

• How is authentication implemented?
• How does this feature work?
• Why is this pattern used?

Treat it like having a senior developer sitting next to you.

One thing I would avoid as a beginner is letting AI write everything for you.

When I was learning Go, I intentionally wrote most things myself.

I used AI to explain concepts, not generate entire features.

The reason is simple.

If AI writes everything, you never build the muscle required to solve problems on your own.

Later, when something breaks, you won't know where to start.

My general rule is:

• Use AI heavily for learning.
• Use AI lightly for coding while you're still learning.
• Use AI aggressively only after you understand what it's doing.

The goal isn't to write code.

The goal is to understand code.

Writing comes naturally after that.

Learning to code is not about finishing a course.

It's about repeatedly going through a cycle:

• Learn a concept.
• Build something with it.
• Break it.
• Fix it.
• Repeat.

Do that long enough and coding stops feeling like something you're learning and starts feeling like something you do every day.

How to Escape Tutorial Hell?

If you're stuck in tutorial hell, the solution is not another tutorial.

Most people already know enough to build something.

The problem is that they keep consuming and never creating.

You watch a React tutorial.

Then another React tutorial.

Then a "React in 2026" tutorial.

Then a "React Project Tutorial."

Then an AI-generated React course.

Six months later, you've watched hundreds of hours of content and still can't build a simple project without following along.

That's tutorial hell.

And nowadays there is an even worse version of it: AI hell.

Instead of copying from a YouTube video, people copy from ChatGPT or Cursor. The result is the same. The code works, but they have no idea why.

I already made an entire video on this topic if you want the full breakdown: How to escape tutorial hell

My approach is very simple.

Stop learning passively.

Start building actively.

Learning is supposed to be uncomfortable.

You are supposed to get stuck.

You are supposed to spend time debugging.

You are supposed to hit problems that make you question whether you're smart enough.

That's normal.

The people who improve are not the ones who avoid struggle.

They're the ones who struggle repeatedly until the struggle becomes familiar.

Whenever you're building something and get stuck, don't instantly ask AI for the solution.

Instead:

• Understand the problem.
• Think about possible solutions.
• Spend at least 30 minutes trying.
• Test your assumptions.
• Break things.
• Fix things.

Only after that should you ask AI for help.

And even then, don't ask:

"Give me the code."

Ask:

• "Is my approach correct?"
• "What am I missing?"
• "Why is this failing?"
• "What trade-offs exist here?"

Use AI as a reviewer, not as a replacement for thinking.

The biggest mistake beginners make is solving problems too quickly.

That sounds counterintuitive, but it's true.

When you suffer through a problem for an hour and finally solve it yourself, that lesson sticks.

When AI gives you the answer in 10 seconds, you usually forget it by tomorrow.

A practical exercise I recommend is:

• Watch a tutorial once.
• Close the tutorial.
• Rebuild the same project from memory.

You'll immediately discover what you actually learned versus what you only watched.

That's where real learning starts.

The goal is not to finish tutorials.

The goal is to become independent.

If every problem requires a tutorial, you're still learning tutorials.

If every problem requires your own thinking first, you're learning engineering.

And that's how you eventually escape tutorial hell.

DSA vs Development?

This is probably one of the most common questions I get.

The first thing I want to make clear is that people spend way too much time arguing about DSA vs Development and way too little time getting good at either of them.

Most beginners haven't become good at one thing yet but are already debating which one is more important.

My advice is simple:

• If you have enough time, do both.
• If you don't have enough time, prioritize development first.

Now before the LeetCode warriors attack me, let me explain.

Personally, I never enjoyed DSA.

In fact, if you've read the section on choosing a field, you'll know that DSA was one of the first things I tried and one of the first things I quit.

I spent most of my time building products, websites, tools, automations, and learning development.

Because of that, most of my interview preparation happened indirectly through building things rather than solving hundreds of algorithm questions.

Interestingly, only a small number of interviews I've personally given asked me DSA-heavy questions. Most of them were closer to real engineering problems, debugging problems, implementation questions, or logic-based questions.

In one interview I got a nested array problem.

In another, I got a graph-related question.

I was able to solve them not because I had grinded LeetCode for months, but because I had encountered similar patterns while building projects.

That said, don't take my experience as a universal rule.

Many companies still use DSA as a filtering mechanism.

Nobody is paying you to reverse a linked list in your daily job.

But companies use DSA because it helps them filter candidates at scale.

That's the reality.

So if your target companies ask DSA, then do DSA.

Don't let people on the internet convince you otherwise.

My personal recommendation looks something like this:

• 60-70% Development
• 20-30% DSA
• Remaining time on system design, communication, networking, and everything else

The reason I prioritize development is simple.

Development is what you'll actually spend most of your career doing.

You'll be:

• Reading code
• Writing code
• Debugging code
• Designing features
• Talking to users
• Understanding business requirements
• Maintaining systems

That's where your salary comes from.

DSA helps you get through some interviews.

Development helps you survive after getting hired.

Another thing people ask me is:

AI can solve DSA now. Why should I learn it?

The same reason you should still learn development even though AI can write code.

Understanding matters.

AI can generate solutions.

AI cannot automatically give you intuition.

If you don't understand what the generated solution is doing, you're depending on luck.

The same applies to development.

AI is useful.

But AI still struggles with ambiguous requirements, messy codebases, business trade-offs, and large real-world systems.

Those are the exact areas where engineers create value.

So stop treating DSA and Development like opposing teams.

They're not enemies.

They're just tools.

If you have enough time, do both.

If you don't, become exceptionally good at development first and add DSA gradually.

Being average at both is usually worse than being genuinely strong at one.

How Much Vibe Coding Should I Do as a Beginner?

Very little.

At least in the beginning.

I know that's not the popular answer right now.

Everyone is posting screenshots of Cursor, Claude or Codex generating entire applications, agents shipping products overnight, and AI writing thousands of lines of code in a few minutes.

That's cool.

The problem is that beginners look at this and think they should start there.

I disagree.

AI is an accelerator, not a replacement.

Think of it like this:

• If you can walk, AI is a bicycle.
• If you can ride a bicycle, AI is a motorcycle.
• If you can ride a motorcycle, AI is a helicopter.

AI amplifies what you already have.

If your fundamentals are weak, AI will amplify weak fundamentals.

If your understanding is strong, AI will make you significantly faster.

Garbage in becomes garbage out, just at a much larger scale.

As a beginner, your goal should not be generating code.

Your goal should be understanding code.

That's why I recommend:

• Read every line AI generates.
• Understand the flow.
• Modify things manually.
• Debug issues yourself.
• Trace how data moves through the system.
• Try to predict what the code is doing before running it.

Most importantly, don't become dependent on it.

A simple test I use is this:

Imagine tomorrow all frontier models disappear.

Could you still build the thing?

Maybe slower.

Maybe with more Googling.

Maybe with more documentation reading.

But could you still do it?

If the answer is no, then you're relying on AI too much.

When you're learning a language or framework, try writing things yourself first.

Struggle with the syntax.

Struggle with the bugs.

Struggle with the implementation.

That's where the learning happens.

Once you understand how things work, then start introducing AI into your workflow.

For example:

• Let AI generate boilerplate.
• Let AI explain errors.
• Let AI review your code.
• Let AI suggest improvements.
• Let AI help with documentation.

But don't let AI replace the thinking process.

One mistake I see a lot is people building projects entirely through prompts.

The project works.

The GitHub repo looks impressive.

But if I ask them:

• Why did you choose this architecture?
• How does authentication work?
• Why is this database schema designed this way?
• What happens when this API fails?

They have no answers.

That's the danger.

Generated code comes with generated consequences.

Sooner or later you'll have to maintain it, debug it, extend it, and explain it.

And AI won't always be there to save you.

So my recommendation is simple:

• Learn fundamentals first.
• Use AI for learning.
• Use AI for assistance.
• Use AI for acceleration.

But don't use AI as a substitute for understanding.

The fastest way to become a good engineer is still the same as it has always been:

Think first.

Code second.

Ask AI third.

How Much AI Do I Use?

A lot.

Probably more than most developers.

But not in the way people think.

Most people start with AI and then think.

I do the opposite.

I think first and then use AI.

Whenever I get a feature request or a problem statement, I don't immediately open Cursor and start prompting.

The first thing I do is understand the problem.

I usually create a rough PRD (Product Requirements Document) or at least think through the feature properly.

Questions I ask myself are:

• What exactly am I building?
• Why am I building it?
• What existing code will this affect?
• What edge cases exist?
• What happens if this fails?
• Should this feature even exist?
• How will users interact with it?
• What is the lifecycle of this feature?

Only after I have a reasonably clear picture do I start writing code.

In many cases, I even think about the test cases before implementation.

Once I know what needs to be built, AI becomes extremely useful.

At that point, AI is no longer making decisions.

It's helping me execute decisions I've already made.

The reason I work this way is simple.

AI is very good at generating code.

AI is not very good at understanding your business context.

For example, AI might generate a perfectly valid implementation but:

• Export unnecessary fields
• Create incorrect types
• Miss edge cases
• Ignore business constraints
• Introduce subtle bugs

I've seen situations where a field should clearly be a number, but AI generates it as unknown.

I've seen situations where AI invents properties that don't exist.

I've seen situations where AI changes behavior without understanding why the original behavior existed.

None of these are huge problems if you're reviewing the code.

They become massive problems if you're blindly accepting everything.

That's why I treat AI like a junior engineer.

I let it write code.

Then I review everything.

I verify assumptions.

I check types.

I look for weird edge cases.

I make sure the implementation actually matches the requirement.

Only then does the code get merged.

The biggest difference between beginners and experienced developers using AI is not the prompting.

It's the review process.

Experienced developers know when AI is wrong.

Beginners often don't.

That's why I don't recommend copying code blindly.

Use AI aggressively if you want.

Just make sure your understanding grows faster than your dependency.

If you're interested in my broader thoughts on AI, software engineering, and jobs, I already wrote a detailed article on it: Ai software engineering and job

My current workflow can be summarized in one sentence:

• Human decides.
• AI assists.
• Human reviews.
• Human ships.

That's where I think AI provides the most value today.

How Do I Learn Nowadays?

The way I learn today is completely different from how I learned when I started.

In the beginning, I relied heavily on tutorials, courses, playlists, and structured learning.

Nowadays, I rarely buy courses.

Most of my learning comes from documentation, experimentation, reading source code, and simply being curious enough to go down random rabbit holes.

A lot of my learning starts with a question.

For example:

• How does this system work?
• Why did this company build it this way?
• Why did this outage happen?
• What trade-offs are they making?
• How would I build something similar?

Once I have a question, I start digging.

I read documentation. I read open-source repositories. I read engineering blogs. I read postmortems. I experiment with things myself.

And then I try building something related to it.

One thing I do a lot nowadays is use AI to accelerate understanding rather than replace it.

For example, if I want to understand how tensors work, I might use Hermes to generate explanations, summaries, diagrams, or even visual walkthroughs that help me build intuition faster.

But the actual learning still happens when I spend time thinking about it.

I also spend a lot of time reading how real companies operate.

Whenever a company like Discord, Cloudflare, Stripe, Vercel, or someone else publishes an outage report or engineering article, I read it.

Not because I need it immediately.

But because every postmortem teaches you something.

You learn:

• System design
• Reliability
• Scaling
• Trade-offs
• Incident response
• Engineering culture

And those lessons are usually more practical than another course module.

Another thing that helps is that I'm chronically online.

I consume a ridiculous amount of:

• Tweets
• GitHub repositories
• Engineering blogs
• Hacker News discussions
• Research papers
• Product launches

Whenever I find something interesting, I bookmark it.

Then on weekends, I go through those bookmarks and see what is actually worth learning.

Over time, I've shifted from structured learning to curiosity-driven learning.

Most of my learning process today looks like:

• Find something interesting.
• Break it apart.
• Figure out how it works.
• Build something related.
• Repeat.

Some people call it unstructured.

I call it "fuck around and find out."

Because honestly, that's what it is.

You try things.

Most of them don't matter.

A few of them completely change how you think.

And those few are worth everything else.

The biggest mistake I see people making is waiting until they feel "ready" to learn something.

You don't need permission.

You don't need a course.

You don't need a roadmap for everything.

Sometimes the fastest way to learn is:

• Open the docs.
• Open the code.
• Start clicking things.
• Break things.
• Figure out why they broke.

That process has taught me more than most courses ever did.

How Do I Get to Know a Lot of New Things Early?

The truth is, I don't actually discover everything early.

A lot of times I'm late by a few weeks, sometimes even a month.

The difference is that when I discover something useful, I try it immediately.

Most people discover things and bookmark them.

I discover things and use them.

That's the real advantage.

A huge reason I get exposed to new things is because I'm online a lot.

I spend time reading:

• Engineering blogs
• GitHub repositories
• Hacker News
• Research papers
• Twitter/X
• Developer communities

Whenever I'm interested in a topic, I start aggressively searching around it.

For example, if I'm learning React, I won't just search:

• React

I'll search things like:

• React internals
• React optimization patterns
• React testing
• React performance
• React AI tools
• React MCP
• React architecture

Then while reading about one thing, I discover three more things.

One search leads to another.

One keyword leads to another.

One blog leads to another.

And eventually I end up in a completely different rabbit hole.

That's usually how I discover new tools.

For example, I discovered Playwright this way.

I wasn't actively searching for Playwright.

I was solving a different problem, stumbled across it, tried it, and realized it could make parts of my workflow significantly easier.

The same thing happens with many tools.

You discover them while chasing a problem, not while chasing the tool itself.

Another thing I do often is use AI for research.

If I'm interested in a topic, I'll ask ChatGPT, Claude, or Perplexity to give me:

• Recent developments
• Related technologies
• Important keywords
• Alternative approaches
• Interesting projects

Not because I blindly trust the output, but because it helps me discover areas I didn't know existed.

Then I go read the original sources myself.

The biggest thing, though, is curiosity.

Whenever I see something interesting, I ask:

• How does this work?
• Why was this built?
• Can I use this?
• Can I build something with this?

Most people stop at the first question.

I keep going until I've either used it or broken it.

And that's probably the biggest reason I keep learning new things.

Not because I have some secret source of information.

Not because I'm smarter.

Just because whenever I discover something interesting, I actually spend time playing with it.

The internet is already showing everyone the same information.

The difference is that most people consume it.

Very few people experiment with it.

That's usually where the learning happens.

How I'm Using Hermes Agent Nowadays?

I already wrote an entire blog on Hermes, so if you want the technical details and architecture, read this first: How i automated everything using ai

The current version is much more advanced than what I originally wrote about.

At this point, Hermes is less of a chatbot and more of an operating system for my life.

One of the first things it does every day is generate my gym workout.

Earlier it used to wait for inputs like sleep duration and mood. Over time I removed a lot of that friction.

Now when I send my sleep data, it automatically adjusts training volume.

If I've slept badly, it reduces workout intensity.

If everything looks normal, it keeps the workout as planned.

The goal is simple: fewer decisions, more execution.

Another thing it does is generate a morning brief.

Every day it goes through tools like:

• WhatsApp
• Teams
• Outlook
• Linear

And creates a summary of:

• What I need to do
• Important reminders
• Pending tasks
• Things I shouldn't forget

This saves me from manually opening ten different applications every morning.

I also use it heavily with Obsidian.

Whenever I find interesting blogs, articles, research papers, or resources, I clip them into my inbox using the Obsidian Web Clipper.

Later I can tell Hermes to process them.

It will:

• Read them
• Generate summaries
• Extract learning points
• Create notes
• Update indexes
• Store everything properly

Over time this has become my second brain.

Instead of remembering everything myself, I focus on learning and let the system handle storage and retrieval.

Another thing I added is context preservation for work.

A lot of times you stop working on a task and continue it the next day.

The problem is that ticketing systems usually show the task, but not your thought process.

So I started feeding Hermes context about:

• What I'm working on
• Why I'm working on it
• Current blockers
• Next steps

Now when I return to a task, it can remind me where I left off instead of forcing me to reconstruct everything from scratch.

I also track personal metrics through it.

Every night it collects information related to:

• Sleep
• Gym
• Calories
• General habits

Then it generates reviews and trends over time.

This helps me spot patterns that would otherwise be invisible.

Another fun thing is computer automation.

I have workflows where Hermes can interact with my machine and perform repetitive actions for me.

For example:

• Gathering information
• Running workflows
• Performing repetitive office tasks

If something is repetitive enough, I usually try automating it.

One of my favorite tiny automations is a punch-in workflow.

Whenever I punch in for work, I can trigger a command and Hermes automatically creates reminders before my punch-out time.

It's a tiny automation, but it removes yet another thing I don't have to remember.

The interesting part is that Hermes keeps changing.

Some automations get removed.

Some get rewritten.

Some turn out to be useless.

Some become daily necessities.

My goal isn't to automate everything.

My goal is to automate the things that create unnecessary friction.

If an automation saves me five seconds but requires ten minutes of maintenance every week, I remove it.

If an automation consistently saves mental energy, I keep it.

That's basically how I think about Hermes today.

It's not a project anymore.

It's an evolving system that helps me reduce friction, preserve context, learn faster, and spend more time thinking about important things instead of repetitive ones.

How to Prepare for Interviews?

My interview preparation is probably very different from what most people expect.

I don't spend months preparing specifically for interviews.

Most of my preparation happens while building projects, reading documentation, fixing bugs, shipping features, and working on real problems.

Because if you think about it, interviews are usually testing one of two things:

• Can you solve problems?
• Can you communicate how you solve problems?

Building things helps with both.

A lot of people separate "interview preparation" from "actual engineering."

I never really did that.

Whenever I build a project, I naturally run into:

• Bugs
• Edge cases
• Performance issues
• Architecture decisions
• Trade-offs

Those same things show up in interviews.

So every project becomes preparation.

Now, does that mean you should completely ignore DSA?

No.

My personal experience was that only a few interviews asked me DSA-heavy questions. Most questions were either logic-based, implementation-based, debugging-focused, or related to things I had already encountered while building projects.

But your experience may be completely different.

If your target companies ask DSA, then prepare DSA.

It's that simple.

Don't blindly follow somebody else's path.

Follow the path required by your target companies.

Apart from coding rounds, there is another part that most people underestimate:

Communication.

I've seen technically strong people fail interviews because they couldn't explain their work properly.

When somebody asks:

• Tell me about yourself.
• Tell me about your project.
• Why did you build this?
• Why did you choose this architecture?
• What trade-offs did you consider?

You shouldn't be giving one-line answers.

You should be telling a story.

Whenever I talk about my projects, I focus heavily on:

• The problem
• The constraints
• The decisions
• The trade-offs
• The mistakes
• The lessons

Because that's what actually demonstrates engineering maturity.

Anyone can show a GitHub repository.

Very few people can explain why it was built that way.

One thing I always recommend is this:

If somebody asks about your best project, you should be able to talk about it for 30 minutes without running out of things to say.

Not because you're memorizing answers.

Because you genuinely understand what you built.

You should know:

• Why you chose the database
• Why you chose the framework
• Why you rejected alternatives
• What failed
• What worked
• What you would improve

The deeper your understanding, the easier interviews become.

Another thing I focus on is first-principles thinking.

When I'm asked a question I don't know, I don't panic.

I start reasoning through it.

Interviewers often care more about how you think than whether you immediately know the answer.

A candidate who thinks clearly out loud is usually much easier to trust than a candidate who stays silent and hopes for the answer to magically appear.

If I had to summarize my interview preparation process, it would look like this:

• Build projects.
• Read documentation.
• Solve real problems
• Learn enough DSA for your target companies.
• Practice communicating clearly.
• Understand your projects deeply.
• Explain trade-offs instead of memorizing answers.

Most interviews are not won by the smartest person in the room.

They're won by the person who can combine technical depth with clear communication.

And communication is something most developers neglect until it's too late.

How to Get a Job?

The traditional answer is simple:

• Apply to jobs.
• Get interviews.
• Clear interviews.
• Get hired.

Everyone already knows that.

So instead, let me tell you what actually worked for me.

The biggest thing is proof of work.

You need enough proof that when somebody visits your profile, portfolio, GitHub, or social media, they can immediately understand what you're good at.

When people looked at my profile, it was obvious that I was a frontend-heavy developer who spent a lot of time building products.

That clarity matters.

Most people have random projects scattered everywhere.

A little bit of AI. A little bit of Blockchain. A little bit of Cyber Security. A little bit of Web Development. A little bit of Mobile Development.

The result is that nobody knows what they're actually good at.

Try to become known for something.

Another thing that helped me a lot was building actual projects instead of clone projects.

The internet is already full of:

• Netflix clones
• Amazon clones
• Airbnb clones
• Twitter clones

Nobody cares about another clone.

Build something useful. Build something weird. Build something that solves a real problem. Build something that people can actually use.

Even if only ten people use it, that's infinitely more interesting than another tutorial project.

Internships also matter a lot.

If you're still in college, get internships as early as possible.

Even if the pay isn't amazing.

Even if the company isn't famous.

The experience compounds.

The mistakes compound.

The learning compounds.

And every internship makes the next opportunity easier.

Networking is another thing people underestimate.

When I say networking, I don't mean spamming people with:

• Hi sir.
• Can you refer me?
• Please help me.

I mean genuinely talking to people.

Ask questions.

Discuss ideas.

Share what you're building.

Help other people.

Be active in communities.

Go to events.

The best opportunities I've seen rarely came from cold applications alone.

They came from people already knowing who you are.

The final thing is social proof.

Post what you're learning.

Post what you're building.

Post your failures.

Post your experiments.

Post your observations.

Not because you're trying to become an influencer.

Because visibility creates opportunities.

A founder might see your work.

A recruiter might see your work.

Another developer might see your work.

Someone might refer you.

Someone might offer freelance work.

Someone might offer an internship.

You never know which arrow will hit the target.

That's why I share things publicly.

Not because every post goes viral.

But because every post is another opportunity surface.

If I were starting from zero today, my plan would be:

• Build a lot of projects.
• Deploy everything.
• Get internships.
• Network with people.
• Document what I'm learning.
• Create visible proof of work.
• Become known for one thing.

The job is usually a byproduct of all those things.

Most people chase the job directly.

I prefer chasing the skills, proof, and visibility that make the job almost inevitable.

How to Get a Remote Job?

Honestly, getting a remote job is not very different from getting a normal job.

Most people think there is some secret remote-job strategy.

There isn't.

The same fundamentals still apply:

• Build skills.
• Build proof of work.
• Build a strong portfolio.
• Build a strong online presence.
• Network with people.
• Get good at interviews.

The only real difference is where you apply.

Instead of targeting companies hiring for office roles, you deliberately target companies that are remote-first or remote-friendly.

That's it.

The mistake I see many people make is that they want a remote job before they become valuable enough to work remotely.

Remote jobs usually come with more trust and less supervision.

Nobody is sitting next to you.

Nobody is constantly checking whether you're working.

Nobody is reminding you every hour.

You need to be capable of managing yourself.

Another thing that helps is having public proof of work.

When a company is hiring remotely, they can't easily evaluate you in person.

So they look at signals:

• Portfolio
• GitHub
• Blog posts
• Social media
• Open-source contributions
• Previous work

The easier it is for somebody to verify your skills online, the easier it becomes to trust you remotely.

One thing I would strongly recommend is not becoming obsessed with remote jobs.

A lot of students treat remote jobs as the goal.

Remote is just a work arrangement.

The real goal should be becoming good enough that companies want to hire you regardless of location.

Once you become valuable, location becomes a much smaller problem.

My process would still be exactly the same:

• Build a lot of proof of work.
• Get internships.
• Improve communication.
• Build visible projects.
• Network with people.
• Share your work publicly.

The only difference is that when opportunities appear, I would choose to apply for remote positions instead of office positions.

That's really all there is to it.

Why I Chose an Offline Job Over a Remote Job?

This surprises a lot of people because I spent the last couple of years working remotely.

Most people assume that once you get a remote job, that's the final goal.

For me, it wasn't.

I chose an offline job because I wanted a different environment and a different set of experiences.

I had already seen what remote work looked like.

I had already built systems around it.

I had already spent years sitting in my room working through screens.

At some point, I felt like I was optimizing too much for comfort.

And comfort is great until it starts limiting your growth.

Since I'm still fairly young and can relocate easily, I thought this was probably the best time to experiment.

If I don't try it now, it becomes harder later.

One of the biggest reasons was exposure.

When you're working offline, you're constantly surrounded by people who are solving similar problems.

You overhear conversations.

You discuss architecture.

You walk up to someone and ask a question.

You get feedback instantly.

You learn things that would never appear in a Slack message or a meeting recording.

That kind of environment is difficult to replicate remotely.

Another reason was mentorship.

Good mentorship can happen remotely.

But in-person mentorship feels different.

There is a lot of learning that happens naturally when you're physically around experienced people.

Not because they're teaching you directly, but because you're observing how they think, communicate, prioritize, and make decisions.

I wanted more of that.

I also wanted a stronger separation between work and life.

One thing I struggled with during remote work was overworking.

When your office and your bedroom are the same place, work starts leaking into everything.

It's very easy to tell yourself:

• I'll just finish one more thing.
• I'll just check one more message.
• I'll just fix one more bug.

And suddenly it's midnight.

An office naturally creates boundaries.

You go there.

You work.

You leave.

And then life continues.

That structure was something I wanted to experience again.

Another factor was simply life itself.

I wanted to move to a new city.

Meet new people.

Travel a little.

Go outside more often.

Build a different lifestyle.

Remote work is amazing, but I didn't want my entire twenties to happen inside a room.

That doesn't mean remote work is bad.

Far from it.

I would happily work remotely again in the future.

In fact, there's a good chance I eventually will.

This wasn't a decision against remote work.

It was a decision for growth.

At this stage of my life, I felt the experiences I would gain from an offline environment were more valuable than the comfort I had already optimized for.

So the question wasn't:

• Which is better?

The question was:

• Which is better for me right now?

And right now, the answer was offline.

Your answer might be completely different.

That's okay.

There isn't a universally correct choice.

There is only the choice that aligns best with your current goals, stage of life, and what you're trying to optimize for.

How to Grow on Twitter/X?

I've already made a video on this topic, so if you want the detailed breakdown, watch that first: How to grow on twitter.

The biggest mistake people make on Twitter is trying to grow.

That sounds weird, but hear me out.

Most people open Twitter and immediately start thinking:

• What will go viral?
• What should I post?
• How do I get followers?
• How do I get impressions?

The result is that they end up sounding exactly like everyone else.

Instead, focus on becoming worth following.

Growth becomes much easier after that.

For me, Twitter was never about becoming an influencer.

It was about documenting what I was learning, building, breaking, and figuring out.

That's still what I recommend.

A simple framework is:

• Learn something.
• Build something.
• Observe something.
• Share it.

Repeat forever.

That's it.

Most people think they don't have anything worth posting.

In reality, they just aren't paying attention.

You can post about:

• Things you're learning
• Problems you're solving
• Bugs you fixed
• Books you're reading
• Systems you're building
• Mistakes you made
• Opinions you've formed

You don't need to be an expert.

You just need to be one step ahead of somebody.

Another thing that matters is consistency.

Not because the algorithm rewards consistency.

Because consistency creates more opportunities.

One post can fail.

Ten posts can fail.

A hundred posts can fail.

But if you keep showing up, eventually people start recognizing you.

And recognition compounds.

Authenticity also matters a lot.

People can immediately tell when you're pretending to be somebody else.

Don't try to copy another creator's personality.

Don't try to force controversial opinions for engagement.

Don't try to sound smarter than you actually are.

Just write the way you think.

Another thing that helped me was having niche clarity.

When somebody lands on your profile, they should immediately understand what you're about.

For me, people usually associate me with:

• Building things
• Development
• Systems
• Automation
• Learning in public

That clarity makes growth easier because people know why they should follow you.

Do that for long enough and growth becomes a byproduct instead of the goal.

How Do I Manage My Time?

Watch this How do i manage my time for more detailed answer.

I don't think I'm exceptionally good at time management.

What I think I'm reasonably good at is prioritization.

Because most people don't actually have a time problem.

They have a priority problem.

Everyone gets the same 24 hours.

The difference is what gets placed inside those hours.

A lot of people try to optimize calendars, productivity apps, and fancy workflows before figuring out what actually matters.

I do the opposite.

The first thing I try to figure out is:

• What are the highest-impact things right now?
• What absolutely needs to get done?
• What can wait?
• What can be ignored?

Once those answers become clear, scheduling becomes much easier.

Another thing I've learned is that energy management is often more important than time management.

There are days where I can do eight hours of high-quality work.

There are days where I can't do two.

Pretending both days are the same is a mistake.

That's why I try to align important work with periods where my energy is highest.

Not every task deserves the same version of me.

A difficult engineering problem deserves a high-energy brain.

Replying to messages doesn't.

I also try to reduce unnecessary distractions.

Not because I have insane discipline.

But because willpower is unreliable.

If something constantly interrupts your attention, eventually it wins.

So instead of trying to resist distractions forever, I prefer removing them wherever possible.

Another thing that helped me a lot was building systems instead of relying on motivation.

Motivation is useful.

But motivation is also temporary.

Some days you'll feel motivated.

Most days you won't.

Systems continue working even when motivation disappears.

That's one of the reasons I built Hermes in the first place.

A lot of repetitive decisions and reminders are handled automatically so I can spend more mental energy on actual work.

I also try to schedule intentionally rather than reactively.

A reactive schedule looks like:

• Wake up.
• Check notifications.
• Reply to things.
• Attend random meetings.
• End the day wondering what happened.

An intentional schedule starts with deciding what matters before the day starts.

That doesn't mean planning every minute.

In fact, I think that's a mistake.

I prefer keeping enough flexibility to handle unexpected work.

Because unexpected things always happen.

Tasks take longer.

New priorities appear.

Bugs show up.

Life happens.

If your schedule breaks the moment something changes, it wasn't a very good schedule.

How to Survive College My Way?

If I had to start college again today, I would do a lot of things differently.

The biggest one?

I would spend far less time worrying about the perfect roadmap and far more time experimenting.

Most students enter college and immediately start asking:

• Which language should I learn?
• Which field should I choose?
• Which roadmap should I follow?
• Which company should I target?

The problem is that most of them haven't tried enough things to answer those questions yet.

So if I were in my first year again, I would spend most of it experimenting.

I would try:

• Web development
• Mobile development
• AI
• Open source
• SaaS
• Startups
• Design
• Content creation

Basically anything that looked remotely interesting.

Not because I want to master all of them.

Because I want enough exposure to figure out what I actually enjoy.

The first year would mostly be "fuck around and find out."

I would also focus heavily on networking.

Not the LinkedIn influencer version of networking.

Actual networking. Making friends. Joining communities. Attending events. Talking to seniors.

Talking to people building interesting things.

Most opportunities in college come through people.

Not through job portals.

Another thing I would do is avoid locking myself into one identity too early.

A lot of people decide:

• I am an AI engineer.
• I am a Web 3 developer.
• I am a cybersecurity guy.

Within the first few months of college.

I think that's too early.

Experiment first.

Commit later.

Once I find something I genuinely enjoy, that's when I would go deep.

That's essentially what happened with me and web development.

After trying multiple things, I eventually found something I could spend hours doing without getting bored.

Then I went all in.

From second year onward, most of my effort would go into becoming genuinely good at one thing.

Not ten things.

One thing.

Depth creates opportunities.

Another thing I would prioritize is building.

Lots of building. Projects. Startups. SaaS products. Tools. Experiments. Anything.

College is probably one of the few periods in life where you can afford to take weird bets with relatively low risk.

Use that advantage. Build random things. Launch random things. Most will fail.

A few will teach you more than an entire semester.

Internships would also be a major focus.

The earlier you start getting real-world experience, the better.

Even if the pay isn't amazing.

Even if the company isn't famous.

The learning compounds quickly.

One thing I would actively avoid is comparison.

College is full of people comparing:

• Packages
• Internships
• Followers
• Projects
• Skills

It's endless.

And honestly, it's a waste of energy.

There will always be someone ahead of you.

There will always be someone behind you.

The comparison never ends.

I'd rather spend that energy improving myself.

I would also be careful about the people I spend time with.

Good friends can accelerate your growth.

Bad friends can destroy years of progress without you even realizing it.

The people around you influence:

• Your standards
• Your habits
• Your ambitions
• Your mindset

Choose carefully.

And finally, I would make sure college isn't only about career growth.

A lot of people optimize so hard for success that they forget to enjoy the experience.

Go to events. Travel occasionally. Make memories. Meet people. Have fun.

Because one day you'll graduate and realize nobody remembers your CGPA as much as you thought they would.

How I Fix My Life When Everything Is Going Wrong?

First of all, whenever everything feels like it's going wrong, I stop trying to fix everything at once.

That's usually the biggest mistake.

People panic.

They try to fix their career, fitness, relationships, finances, habits, sleep schedule, and mental state all in the same week.

That rarely works.

Instead, I start by figuring out where I currently am.

I call this Point A.

Then I figure out where I want to be.

That's Point B.

Most people spend all their time thinking about Point B.

Very few people honestly evaluate Point A.

So I sit down and ask myself:

• What's actually broken?
• What is causing the most damage right now?
• What is still working?
• What needs immediate attention?
• What can wait?

Once I have clarity, I stop focusing on the entire mountain and focus on the next step.

For example, if my health is terrible, my sleep is terrible, my work is suffering, and my routine is broken, then trying to solve everything simultaneously is a recipe for failure.

Instead, I ask:

• What is the highest leverage thing I can fix first?

Sometimes that's sleep.

Sometimes that's fitness.

Sometimes that's work.

Sometimes that's simply reducing chaos.

After identifying the gap between Point A and Point B, I create a system.

Not motivation. Not inspiration.

A system.

Because motivation disappears very quickly.

Systems survive bad days.

A system could be as simple as:

• Sleep at a fixed time.
• Wake up at a fixed time.
• Go for a walk daily.
• Finish one important task.
• Repeat.

Nothing fancy.

Nothing life-changing.

Just consistent actions.

Then I follow the system religiously.

Not perfectly.

Just consistently.

There is already a full video where I talk about this in more detail: How do i fix my life?

If I had to summarize my approach in one sentence, it would be:

Accept where you are, define where you want to go, build a system that gets you there, and follow it long enough for the results to catch up.

What screenshot tool and Screen recording tool I use?

I use CleanShot X for screenshots and Screen Studio for screen recordings.

While these both apps are paid the free alternatives are also good.

• Cleanshot Alternative: ScreenShot Studio or Better Shot

• For ScreenStudio Alternative: Cap, or OpenScreen

Why I Wrote This Blog

Over the time, I've noticed that most people ask me the same questions.

• How do I learn to code?
• How do I get an internship?
• How do I get a job?
• How do I choose a field?
• How much AI should I use?
• How do I survive college?

And honestly, that's completely fair.

Everyone starts somewhere.

The problem is that after answering the same questions hundreds of times, I realized I was spending more time repeating myself than sharing new things I was learning.

That's one of the reasons this blog exists.

Instead of answering the same question individually every week, I can simply point people here.

Will this answer every question?

No.

Because everyone's situation is different.

I don't know your background. I don't know your financial situation. I don't know your family responsibilities. I don't know your strengths and weaknesses.

And because of that, there is no advice that works perfectly for everyone.

Everything in this blog is based on my experience.

Some things may work for you.

Some things may not.

Take what is useful and ignore the rest.

Another reason I started documenting more publicly is that I genuinely enjoy sharing what I'm learning.

I would rather write it down once than repeat it a hundred times.

That's also why I'm gradually moving away from a lot of one-on-one (topmate) guidance.

Not because I don't want to help people.

But because the same conversations keep happening again and again.

A lot of the questions eventually loop back to the same fundamentals:

• Build things.
• Learn consistently.
• Create proof of work.
• Stay curious.
• Be patient.

There are no secret shortcuts hiding behind a paid call.

Most of the answers are already available publicly.

The hard part is actually executing them.

This blog will continue to grow over time.

Whenever I notice a new question being asked repeatedly, I'll probably add it here.

That way both of us save time.

You get a better answer.

And I get to spend more time building, learning, and sharing new things.

If you've made it this far, thanks for reading.

How to find blogs, research paper's to read?

Not sure how many people love or hate ai. but AI is really good at finding things off the internet and summarizing them.

To find good blogs, research papers, if you are starting with the same, go to ChatGPT/Claude/DeepSeek/GLM and write this prompt:

Hey, I work in [YOUR DOMAIN (eg backend, infra, frontend)]. Find me a couple of top-tier timeless blogs, and research papers I should read.

Yep, it is that simple to do.

Now, what about reading daily new blogs?

There are a few sources and one Google search to do it.

• Daily.dev
• Hacker News

And then other underrated ways to read blogs are simply looking for companies and their blogs, just search [Company] tech blogs.

eg Netflix tech blog, Hotstar tech blog.