Meta description: A software engineer's honest career journey in India — from college at AKTU to working at an AI startup. Real lessons, mistakes, and practical tips for freshers starting out.
Two years ago, I was a final-year IT student at Dr. A.P.J. Abdul Kalam Technical University with zero industry experience, a GitHub with three half-finished projects, and a browser history full of "how to get a software engineering job in India" searches.
Today, I'm a Member of Technical Staff at TestMu AI — an AI-powered testing startup in Noida — and I recently shipped my first open-source npm package, webguardx, which crossed 50 stars in its first week.
This isn't a motivational post. It's the unfiltered version of what my software engineer career journey in India actually looked like — the internships, the rejections, the skills I had to teach myself, and the things nobody told me in college.
If you're a fresher trying to figure out your path, keep reading. I wish someone had written this for me.
Where I Started — and What College Actually Prepared Me For
I did my Bachelor's in Information Technology from AKTU. If you've been through a tier-2 engineering college in India, you know the drill — heavy on theory, light on industry-relevant skills, and a curriculum that moves at a pace that feels disconnected from what companies actually want.
What college did give me: a foundation in data structures, some exposure to web development through side projects, and — honestly — the pressure of placement season which forced me to actually start coding seriously.
What it didn't give me: version control habits, how real team workflows operate, what production code actually looks like, or how to communicate technical decisions to non-technical people.
That gap? I had to fill it myself. And that's exactly what these two years have been about.
My First Internship: FlexEHR and What Working Remotely Taught Me
In December 2023, I joined FlexEHR Healthcare Solutions as an SDE intern. It was remote, based out of Bengaluru, and it was my first real exposure to a professional codebase.
The first week was humbling. Real code doesn't look like the tutorial projects you build in college. There are files everywhere, naming conventions you haven't seen before, legacy decisions baked into the architecture, and a pace that doesn't slow down for you to catch up.
A few things that hit me immediately:
GitLab was not GitHub. I had used GitHub casually for personal projects but hadn't worked with proper branching strategies, pull requests, or merge request reviews. My first week was partly just learning how the team moved code around.
Nobody has time to explain everything. In college, someone is always available to answer your question. In a startup, people are heads-down on deliverables. I learned to read documentation carefully, trace code myself before asking, and ask specific questions rather than broad ones.
The healthcare domain had real constraints. Building UI components for a healthcare platform isn't the same as building a generic web app. Accessibility wasn't a nice-to-have — it was a requirement. Compliance mattered. That context shaped how I thought about writing clean, careful code.
I stayed for six months. By the time I left, I had gone from barely understanding the codebase to confidently shipping frontend features independently.
GeeksforGeeks Internship: The DSA Grind That Changed Everything
Before FlexEHR, I had a six-month stint at GeeksforGeeks as a Problem Solver intern. This is where my relationship with Data Structures and Algorithms went from "I barely pass this in exams" to "I actually enjoy this."
I spent most of 2022 grinding problems. Not for placement prep — well, partly for placement prep — but because I started genuinely understanding why certain approaches were more efficient than others. That shift from memorising solutions to understanding patterns was one of the most important things that happened to my engineering brain.
If you're a fresher struggling with DSA, here's what actually helped me:
- Stop solving random problems. Pick one topic (arrays, trees, graphs) and exhaust it before moving on.
- Understand the "why" before the "how." Before coding a solution, explain to yourself why this approach makes sense.
- Revisit problems you got wrong. Not to copy the solution — to understand what your thinking missed.
- Write it out. Typing code in an IDE is different from writing logic on paper. Both are useful muscles.
DSA didn't just help me in interviews. It changed how I reason through problems in production code, which I didn't expect but am genuinely grateful for.
Getting My First Full-Time Job at Typof
In July 2024, I joined Typof as a Frontend Developer. Typof is a commerce platform and my role was building and maintaining frontend interfaces using React.js, Node.js, and Material UI.
Getting this job wasn't magic. It was the result of two internships on my resume, a portfolio with real projects, and being able to talk confidently in the interview about problems I had actually solved — not hypothetical ones.
What I learned at Typof was a different kind of lesson: scale matters. At FlexEHR I was working on a small team. At Typof, the frontend served thousands of merchants. The decisions I made about component architecture, performance, and reusability had real downstream effects.
I also learned what burnout looks like. The pace was fast, the expectations were high, and there were weeks where I was shipping features faster than I was fully understanding them. I got better at speaking up, slowing down when something needed to be done properly, and communicating timelines honestly.
Eight months later, the next opportunity arrived.
The Skills Gap Nobody Talks About
Here's something I think the Indian tech education system consistently underestimates: the gap between writing code and being an engineer.
Writing code is the smallest part of the job. The bigger parts are:
- Reading and understanding other people's code, which is often messy and underdocumented
- Communicating decisions — why you built something a certain way, what trade-offs you made
- Estimating work honestly — not optimistically, which is the natural instinct
- Writing documentation and tests, which nobody teaches you to love but everyone needs you to do
- Debugging production issues under pressure, which is a completely different skill from solving algorithm problems
I had to learn all of this on the job. Some of it through mistakes, some through watching senior engineers work, and some through actively building habits like writing comments for future-me and always asking "what breaks if this fails?"
If you're still in college: start building these habits now. They will differentiate you more than knowing the latest framework.
How I Landed at an AI Startup (and What That Actually Means Day-to-Day)
In February 2025, I joined TestMu AI as Member of Technical Staff.
TestMu AI is focused on AI-powered testing — which meant the intersection of my frontend/backend experience and the AI exposure I had gained earlier through Outlier, where I spent time training large language models in coding best practices.
People romanticize working at an AI startup. The reality is more grounded — and more interesting for it. We're building real infrastructure, solving real engineering problems, and the "AI" part means we're constantly thinking about how to make testing smarter, faster, and more reliable.
What's different about working here compared to my earlier roles:
- Ownership is higher. At a startup, you're not just a contributor to a large system. Your decisions have visible impact quickly.
- The learning curve is steeper. You're expected to move across the stack — TypeScript, Python, Node.js — and pick up new domains fast.
- The pace tests your fundamentals. When things move fast, shortcuts hurt you. The engineers who thrive here are the ones who built strong fundamentals early and don't cut corners when it matters.
Building webguardx — My First Open Source Project
Alongside my work at TestMu AI, I built and launched webguardx — an open-source npm package for full-page web auditing using Playwright.
The idea came from a problem I kept seeing across every project I worked on: web apps break in ways that users notice before developers do. Broken links, accessibility failures, silent JavaScript errors, poor performance — these things accumulate and nobody catches them systematically.
So I built webguardx to do exactly that. Accessibility checks, HTTP status codes, broken links, console errors, performance and SEO via Lighthouse, SQL injection tests, session invalidation checks — all from a single config file with three commands.
Building in public taught me things working in private never could:
- People will use your code in ways you didn't design for. This is humbling and motivating at the same time.
- Documentation is a first-class feature. A tool nobody can set up is a tool nobody uses.
- Community feedback is the fastest way to improve. The security audit checks in the latest version came directly from user requests.
The webguardx launch post on LinkedIn got more traction than anything I had posted before. Building something real and sharing it openly is the single best portfolio move I have made in my career.
5 Honest Lessons from 2 Years in the Industry
After two years of internships, full-time roles, a startup, and an open-source project, here's what I genuinely believe:
1. Your first job matters less than what you do in it.
Prestige of the company fades quickly. What stays is the quality of the work you do, the habits you build, and the problems you own. I've learned more from a mid-size startup than I would have coasting at a large company.
2. Communication is a technical skill.
The engineers who grow fastest aren't always the best coders — they're the ones who can clearly explain what they built, why it works, and what can go wrong. Practice this like you practice DSA.
3. Side projects are the best interview prep.
Not because of resume points, but because they force you to own the full problem. No one tells you what to build, how to architect it, or when to stop. That autonomy builds a kind of engineering judgment that tutorial projects never develop.
4. Learn the problem domain, not just the tech stack.
At FlexEHR I learned about healthcare compliance. At Typof I learned about e-commerce infrastructure. At TestMu AI I'm learning about software quality at scale. The engineers who understand the domain they're building for write better software.
5. Your career is not a straight line.
Two internships, a full-time role, a startup, an open-source project, and now content creation. None of it was planned. Every step opened a door I didn't know existed. Stay curious and stay willing to bet on yourself.
What I'd Tell My Fresher Self
If I could send one message back to myself in final year:
Start building things people can use. Not tutorial clones — real things that solve real problems, even small ones. Put them on GitHub. Write about how you built them. The compounding effect of this habit over two years is greater than any certification or course.
Everything else follows from that.
Key Takeaways
- College gives you a foundation, but the industry gap is real — plan to fill it yourself
- Internships are worth more than their stipend — treat every one as a learning sprint
- DSA matters, but communication, documentation, and ownership matter just as much
- Open source is the most underrated career accelerator for developers in India
- Your software engineer career journey in India is not a template — it's yours to build
What's Next for Me
I'm currently focused on three things: shipping more features for TestMu AI, growing webguardx into a widely-used tool in the developer community, and sharing everything I'm learning through writing and video content about tech, AI, and travel.
If you're a fresher or early-career engineer finding your footing — I hope this was useful. The path is messier than anyone's LinkedIn makes it look, and that's exactly what makes it worth it.
Follow me on LinkedIn for weekly posts on software engineering, open-source, and the developer life: linkedin.com/in/ritikpal
Check out webguardx on npm and GitHub — contributions and feedback are always welcome.
Subscribe to this blog to get notified when I publish the next post — coming soon: "How I learned TypeScript from scratch while working full-time."
If this post helped you, share it with a fellow developer who's just starting out. It means more than you know.
Top comments (0)