"Build emerging and novel projects with secure coding. Secure the digital world through both defense and offense."
Hi, I'm Sagar Biswas. I'm a Computer Science & Engineering student at AIUB (Bangladesh), expected to graduate in 2028. I've been building software and breaking into cybersecurity since before I knew what a "career path" even meant — and this document is the roadmap I'm following to turn that energy into something real.
This isn't a polished corporate strategy. It's my honest plan — what I'm studying, what I'm learning after graduation, and why I made every choice along the way. I wrote this for myself first, but I'm sharing it publicly because maybe it helps someone else figure out their own path too.
- What This Document Is
- Where I Am Right Now
- What I'm Building Toward
- Why Software Engineering
- Why Cybersecurity
- Why AI
- My Final Academic Plan
- Post-Graduation Roadmap
- Target Profile by 2030
- Principles I Build By
- Find Me
This is my personal career roadmap — a living document that lays out my academic decisions, my post-graduation learning plan, and the reasoning behind every choice. I update it as my thinking evolves.
Who is this for?
- For me — so I don't lose focus. When things get overwhelming (and they will), I come back here and remember what I'm building toward.
- For recruiters and employers — so you can see how I think, not just what I've built. The projects on my GitHub show what I can do; this document shows where I'm going and why.
- For other students — especially those in Bangladesh or similar situations, trying to figure out what to study and what to learn on their own. If any of this helps you plan your own path, that's a win.
I'm not starting from zero. Here's where I stand as of mid-2026:
What I've already built:
- 90+ repositories on GitHub — from SaaS applications and AI-powered tools to e-commerce platforms, security scanners, and educational notebooks
- A full security assessment of a production platform (ReserveX — 15 findings, 2 critical, chain analysis included)
- Open-source learning resources used by other students (Python, Bash, JavaScript, React, PHP, NestJS, C/C++, Git, Cybersecurity notebooks)
- AI-powered applications, web vulnerability scanners, URL shorteners, voice assistants, and more
- A community (AIUB CyberSecurity & Programming Society) where I share projects, notebooks, and security research
What I already know (not exhaustive, just the highlights):
| Area | Technologies & Topics |
|---|---|
| Languages | C, C++, Python, JavaScript, PHP, Bash, Arduino |
| Frontend | HTML, CSS, React, Next.js |
| Backend | NestJS, PHP (MVC), REST APIs |
| Databases | MySQL, PostgreSQL, MongoDB |
| DevOps | Docker, CI/CD, Linux, Git |
| Web Security | OWASP Top 10, XSS, SQLi, CSRF, SSRF, Burp Suite, OWASP ZAP |
| AI Security | OWASP LLM Top 10, Prompt Injection, Jailbreaking |
| Networking | DNS, TCP/IP, HTTP, Wireshark, Nmap |
| Auth & Sessions | JWT, Cookies, Sessions, OAuth patterns |
| Other | Social Engineering, Threat Modeling, Technical Writing |
I'm not listing these to show off. I'm listing them because they explain the choices below. When you already have hands-on experience building full-stack apps and breaking web applications, you make very different academic decisions than someone starting from scratch.
By 2030, I want to be a Senior Software Engineer / Backend Engineer who can:
- Design and build scalable, production-grade systems from the ground up
- Integrate AI into real products (not just play with APIs)
- Think like an attacker when writing code — because I am one (ethically)
- Work with cloud infrastructure, not just write code that runs on someone else's setup
- Contribute meaningfully to the security of whatever system I touch
That's the north star. Every decision in this document points toward it.
After completing my undergrad, my plan is to eventually settle in a first-world country — but I'm also open to remote work and local opportunities in Bangladesh. The goal is to build skills that are valuable everywhere, not just in one market.
Let me be direct: I chose Software Engineering as my primary focus because it's where the demand is, and it's where I'm strongest.
I've been building projects since before I entered university — web apps, tools, full-stack systems. I know from experience that I enjoy the craft of building software: designing systems, writing clean code, shipping features, debugging production issues. It's not just a career choice; it's what I actually do in my free time.
But I'm also being strategic. When I look at the global job market through 2030 and beyond, software engineering consistently tops the list for:
- Job demand — every industry needs engineers who can build and maintain software
- Salary potential — especially for backend and infrastructure roles
- Remote work opportunities — the most location-independent career I can pursue
- Startup potential — I can build my own products, not just work for others
- AI resilience — engineers who understand architecture and design (not just syntax) are harder for AI to replace
That last point matters a lot to me. I'm not worried about AI replacing developers who design systems, make trade-offs, and own production reliability. I'm more worried about developers who only write boilerplate CRUD code. That's exactly why my coursework focuses on architecture, design patterns, and quality engineering — not just "more coding."
This one's personal.
Cybersecurity has been my dream since childhood. Long before I wrote my first line of code, I was fascinated by how systems get broken — and how they get defended. That curiosity never went away; it just got sharper.
Today, I study both sides:
- Offensive — I practice penetration testing, web exploitation (XSS, SQLi, CSRF, SSRF), network reconnaissance, and social engineering. I've done real security assessments on production platforms.
- Defensive — I study secure coding practices, threat modeling, application security, and security architecture. When I build software, I think about how an attacker would try to break it.
I don't plan to become a full-time pentester or security analyst. Instead, I want to be an engineer who thinks like a hacker — someone who builds secure systems by default because they understand the attacker's mindset. That combination (builder + breaker) is rare and extremely valuable.
This is also why I'm pursuing CCNA — most software engineers don't bother with networking certifications, but networking is the blood of cybersecurity. You can't secure what you don't understand. Understanding routing, switching, TCP/IP, and network architecture at a deep level makes me a better security thinker and a better engineer.
I'll be honest: I'm not naturally drawn to the math-heavy, research side of AI. I'm not trying to publish papers or train foundation models from scratch.
But here's what I believe — in this era, AI is not an option; it's an answer. Every product I build in 2028, 2030, and beyond will involve AI in some form. If I can't integrate LLMs, build RAG pipelines, architect AI agents, and evaluate model outputs, I'll be building with one hand tied behind my back.
So my approach to AI is practical:
- Learn how to use AI APIs, vector databases, and retrieval systems
- Learn how to build AI-powered products and applications
- Learn how to evaluate and secure AI systems (which connects back to my security background)
- Skip the heavy research track that requires advanced math I don't enjoy
Build AI products, not become an AI researcher. That's the line.
I've already started down this path — I've built AI-powered tools (chat assistants, voice assistants, AI-augmented security scanners) and I've studied AI security in depth (OWASP LLM Top 10, prompt injection, jailbreaking). The academic Machine Learning course fills in the theoretical foundation I'm missing without going overboard.
Here's what I'm taking for the rest of my undergraduate degree and why each course matters for my roadmap.
What it covers: System design principles, scalable software architecture, common design patterns (Factory, Observer, Strategy, etc.), architectural styles (microservices, event-driven, layered).
Why I'm taking it: This is arguably the most important course on my list. Knowing how to code is table stakes — knowing how to design systems is what separates mid-level engineers from senior ones. System design interviews at top companies test exactly this knowledge. And frankly, this is the kind of thinking that's hardest for AI to automate. An LLM can write a function, but it can't make the trade-off between consistency and availability in a distributed system the way a human architect can.
How it connects: Directly feeds into Phase 5 (Advanced Engineering) of my post-graduation plan, and it's foundational for the "System Design Expertise" in my 2030 target profile.
What it covers: Advanced full-stack development, modern web frameworks, SaaS application architecture, API design, real-time features.
Why I'm taking it: I've already built web applications — a lot of them. But there's a difference between building something that works and building something that's production-grade. This course pushes me into advanced patterns: authentication flows, payment integrations, real-time communication, and the architectural decisions behind SaaS platforms. Every startup idea I have depends on these skills.
How it connects: Strengthens my immediate earning potential (freelance and startup opportunities), and deepens the full-stack foundation that everything else builds on.
What it covers: Testing methodologies (unit, integration, e2e), CI/CD pipelines, test automation, quality metrics, code review practices, production monitoring.
Why I'm taking it: Most students skip this or treat it as boring. I don't. Here's why — every production system I've worked on has had bugs that proper testing would have caught. CI/CD isn't just a buzzword; it's the backbone of how professional teams ship code. Understanding quality engineering makes me the kind of developer that teams trust with production deployments. That trust is career currency.
How it connects: Essential for the "Production-ready software" mindset I need across all five phases of my post-graduation plan. Also directly relevant to security — you can't verify that a fix actually works without good tests.
What it covers: Core ML concepts — supervised/unsupervised learning, classification, regression, clustering, model evaluation, feature engineering. Practical implementation using Python libraries.
Why I'm taking it: I don't need to be an ML researcher, but I do need AI literacy. When I'm building AI-powered products after graduation (Phase 3), I need to understand what's happening under the hood — not just call an API and hope for the best. This course gives me the foundational vocabulary and intuition to evaluate models, understand trade-offs, and have meaningful conversations with ML engineers. It's the minimum viable AI knowledge for a product-focused engineer.
How it connects: Directly prepares me for Phase 3 (AI Engineering), where I'll focus on LLMs, RAG, vector databases, and AI agents.
What it covers: Query optimization, indexing strategies, transaction management, database replication, sharding, NoSQL patterns, performance tuning.
Why I'm taking it: Every application I build hits a database. If I can't design efficient schemas, optimize slow queries, and make informed decisions about database architecture, I'm bottlenecked before I even start. This is one of those "invisible" skills that separates good backend engineers from great ones. Recruiters might not ask about it directly, but the moment you're debugging a production query that takes 30 seconds instead of 30 milliseconds, this knowledge pays for itself.
How it connects: Core to my backend engineering identity. Feeds directly into Phase 5 (Advanced Engineering) and is essential for the "Advanced Database Knowledge" in my 2030 target profile.
After I graduate in 2028, the real work begins. Here's my five-phase self-study and certification plan. The phases are roughly sequential, but in practice they'll overlap — I'll keep building projects throughout.
What I'll learn:
- AWS — compute, storage, networking, serverless, IAM
- Docker — containerization, multi-stage builds, Docker Compose
- Kubernetes — orchestration, deployments, scaling, service mesh basics
- Terraform — infrastructure as code, provisioning, state management
- CI/CD — GitHub Actions, automated testing pipelines, deployment strategies
Target certification: AWS Certified Solutions Architect — Associate
Why this comes first: Because the gap between "I can build an app on my laptop" and "I can deploy and operate it in production" is massive. Cloud and infrastructure skills are what make a developer employable at scale. I want to be the engineer who doesn't just write the code — I understand where it runs, how it scales, and why it costs what it costs.
How I'll learn: Hands-on projects. I'll take my existing applications and deploy them properly — containerized, orchestrated, with CI/CD pipelines and infrastructure defined in code. No tutorials without real output.
Target certification: Cisco Certified Network Associate (CCNA)
What I'll learn:
- Routing and switching fundamentals
- TCP/IP deep dive
- Network troubleshooting and diagnostics
- Subnetting, VLANs, ACLs
- Network architecture and design
Why this exists in my plan: I said it earlier — networking is the blood of cybersecurity. Most software engineers have a surface-level understanding of networking ("it works over HTTP, right?"). I want to go deeper. Understanding how packets actually move through a network, how routing decisions are made, and how network segmentation works makes me a fundamentally better security thinker and a more capable infrastructure engineer.
How I'll learn: Cisco's official curriculum + lab simulations (Packet Tracer, GNS3). I'll combine this with real network analysis using Wireshark and Nmap, which I already use in my security work.
What I'll focus on:
- LLM APIs — OpenAI, Anthropic, Groq, local models
- RAG (Retrieval-Augmented Generation) — building systems that combine LLMs with domain-specific data
- Vector databases — Pinecone, Weaviate, pgvector
- AI agents — autonomous workflows, tool use, multi-step reasoning
- AI application architecture — how to structure production AI systems
- Model evaluation — benchmarking, testing, safety assessment
Why this matters:
My goal is to build AI products, not become an AI researcher.
I've already built AI-powered tools — chat assistants, voice assistants, security scanners with AI triage. Phase 3 is about going from "I can use an API" to "I can architect a production AI system." The market demand for engineers who can build reliable, scalable AI applications (not just prototype demos) is going to be enormous through 2030.
How I'll learn: By building. Every concept gets a project. RAG system for my cybersecurity notebooks. AI agents for security assessment automation. Production-grade AI features integrated into my SaaS projects.
What I'll learn:
- OWASP Top 10 — deep mastery, not just awareness (I already have a strong foundation)
- Secure coding practices — language-specific security patterns, input validation, output encoding
- Threat modeling — STRIDE, attack trees, security architecture review
- Application Security (AppSec) — SAST, DAST, dependency scanning, security in CI/CD
- Web security testing — advanced penetration testing, API security, authentication bypasses
Optional certifications:
- eLearnSecurity Junior Penetration Tester (eJPT)
- CompTIA Security+
Why this is Phase 4, not Phase 1: Because I've been doing security informally since the beginning — it's woven into everything I build. This phase is about formalizing that knowledge, filling gaps, and getting certified. By this point, I'll have cloud infrastructure knowledge (Phase 1), networking depth (Phase 2), and AI literacy (Phase 3) — which means my security thinking will be holistic, not just "check for XSS."
How I'll learn: Platforms like PortSwigger Web Security Academy, TryHackMe, and Hack The Box for hands-on practice. Real security assessments (with permission). Building security tools and contributing to open-source security projects.
What I'll master:
- Distributed systems — consistency models, consensus algorithms, partition tolerance
- Microservices — service boundaries, inter-service communication, data ownership
- Event-driven architecture — message brokers, event sourcing, CQRS
- Message queues — Kafka, RabbitMQ, SQS — when to use what
- Caching — Redis, CDN strategies, cache invalidation patterns
- Observability — logging, metrics, tracing, alerting (the "three pillars")
- Performance engineering — profiling, load testing, optimization at scale
Recommended reading: Designing Data-Intensive Applications by Martin Kleppmann — widely considered the bible of modern backend engineering.
Why this is the final phase: Because these topics only make sense when you already have real-world experience. You can't truly understand distributed systems trade-offs until you've deployed to the cloud, dealt with network partitions, and debugged production incidents. This phase is about going from "senior engineer" to "staff-level thinking."
How I'll learn: Deep reading (DDIA, system design case studies), building increasingly complex distributed systems, and learning from production experience at whatever company I'm working at by then.
Senior Software Engineer / Backend Engineer
By 2030, this is the profile I'm working toward — and I believe it offers the strongest combination of job demand, salary potential, remote work flexibility, startup opportunity, and long-term relevance.
| Competency | Depth |
|---|---|
| System Design | Can design scalable, distributed systems from scratch |
| Backend Engineering | Deep expertise in APIs, databases, server architecture |
| Cloud & DevOps | AWS-certified, comfortable with containers, IaC, CI/CD |
| AI Product Engineering | Can architect and ship production AI features |
| Security Awareness | Thinks like an attacker, builds like a defender |
| Networking | CCNA-level understanding of infrastructure |
This isn't about collecting certifications or checking boxes. It's about becoming the kind of engineer who can look at a complex problem — a failing system, a new product idea, a security incident — and know what to do.
These aren't corporate values I memorized. They're things I've learned the hard way by building 90+ projects:
-
Security is not an afterthought. I write secure code from the first commit, not as a patch before release. If you understand how attackers think, you build differently.
-
Build things that work, not things that impress. A deployed product with 100 users teaches you more than a perfect prototype that never ships.
-
Learn by building, not by watching. Every concept in my roadmap gets a real project. No tutorial hell. No passive consumption.
-
Understand the full stack. Even as a backend-focused engineer, I want to know what's happening from the browser to the database to the network packet. Gaps in understanding become gaps in security.
-
Share what you learn. I've written 20+ educational notebooks, run a community group, and publish security research publicly. Teaching forces you to actually understand what you think you know.
| Platform | Link |
|---|---|
| Portfolio | sagarbiswas-multihat.github.io |
| GitHub | SagarBiswas-MultiHAT |
| sagarbiswas-multihat | |
| YouTube | Sagar-MultiHAT |
| Community | AIUB CyberSecurity & Programming Society |
| eng.sagarbiswas.aiub@gmail.com |
This document is a living roadmap. I update it as I grow, learn, and recalibrate. If you're a student figuring out your own path — take what's useful, ignore what's not, and build your own plan. The best roadmap is one you actually follow.
Last updated: June 2026