# Priyam's Blog — Engineering, Architecture & Web Dev — Full Content Index for LLMs > Technical deep dives, architectural insights, and modern fullstack engineering practices by Gyanranjan Priyam. Covering Next.js, React, Web Security, System Design, and Performance Optimization. > Author: Gyanranjan Priyam (https://www.priyam.tech | @gr_priyam) > Generated from: https://blogs.priyam.tech > Total Articles: 7 --- ## Article 1: My Role in HackVerse '26: Organising, Managing & Building the Hackathon - **URL**: https://blogs.priyam.tech/my-role-in-hackverse-26-organising-managing-and-building-the-hackathon/ - **Author**: Gyanranjan Priyam - **Published**: 2026-10-02 - **Updated**: 2026-10-02 - **Category**: Engineering - **Reading Time**: 5 min read - **Tags**: HackVerse, Hackathon, CodeBreakers, Leadership, Event Management, Web Development, Teamwork, Organising - **Summary**: A behind-the-scenes look at my journey as Organising Team Coordinator, Management Team member, and Development Head while planning, building, and managing HackVerse '26. ### Content: ## More Than Just a Hackathon Organising a hackathon looks exciting from the outside. You see the problem statements, registrations, projects, presentations, prizes, and the final celebration. But behind all of that is a completely different story. **HackVerse '26**, organised by **CodeBreakers, GCE Kalahandi**, was one of the biggest events I have been involved in. My role was not limited to a single responsibility. I worked across **event coordination, management, and technical development**, which gave me the opportunity to experience what it actually takes to build and run a large-scale student hackathon. I was part of the **Organising Team as a Coordinator**, worked closely with the **Management Team**, and also served as the **Development Head**. 🔗 **Official HackVerse '26 Website:** [https://hackverse.codebreakersgcek.tech/](https://hackverse.codebreakersgcek.tech/) This is the story of what happened behind the scenes. --- ## My Three Core Responsibilities My involvement in HackVerse '26 can broadly be divided into three areas. ### 1. Organising Team Coordinator As an organising team coordinator, my responsibility was to make sure different teams stayed aligned and that planned activities actually moved forward. This involved: - Coordinating between different organising teams. - Following up on assigned responsibilities and deadlines. - Helping resolve issues during registrations and evaluation rounds. - Communicating important updates to participants and team members. - Supporting the planning and execution of different event activities. - Making sure information reached the right people at the right time. A lot of this work happened quietly in the background. There were countless small decisions, follow-ups, corrections, and last-minute changes that were necessary to keep everything running. --- ### 2. Management Team Along with coordination, I was also involved with the **management side of HackVerse '26**. This meant looking at the event from a broader perspective rather than focusing only on individual tasks. We had to think about things such as: - Registration management - Participant communication - Team and volunteer coordination - Scheduling - Evaluation rounds - Jury coordination - Documentation - Event logistics - Problem statement management - Handling unexpected situations One important lesson I learned was that event management is mostly about **anticipating problems before they become visible problems**. A schedule may look perfect on paper, but once hundreds of participants, organisers, mentors, and jurors are involved, things rarely go exactly according to plan. --- ### 3. Development Head: Building the Technical Backbone The third and probably the most technically demanding part of my role was serving as the **Development Head**. HackVerse needed more than a landing page. We had to build and maintain the technical infrastructure that supported the entire event workflow. This included working on: - Hackathon website - Registration workflows - Problem statement management - Participant and team data - Forms and submissions - Payment-related workflows - Communication-related systems - Evaluation processes - Administrative interfaces - Deployment and production fixes The development work required constant coordination with the organising and management teams because the requirements were continuously changing. A small change in the event process could result in a change in the application. That meant development was not simply: **"Build the website → Deploy → Done."** It was more like: **Requirement → Development → Testing → Feedback → Change → Deployment → Monitoring → Fix** and sometimes the entire cycle happened within a few hours. --- ## Building While Managing One of the most challenging parts of HackVerse '26 was balancing **technical development with event management**. There were times when I was working on a production issue while also coordinating an organising task. At other times, a change in the event process required an immediate change in the website. This taught me an important lesson: > **Technology for an event is not built in isolation. It has to evolve with the people and processes using it.** The development team had to stay closely connected with the people handling registrations, communications, evaluations, and management. That coordination was just as important as writing the code itself. --- ## Managing the Online Screening & Evaluation The evaluation rounds were another major responsibility. We had to coordinate: - Team schedules - Evaluation slots - Jury members - Meeting links - Participant communication - Presentation timings - Prototype demonstrations - Attendance and tracking - Rescheduling requests With multiple teams participating, even a small scheduling issue could affect several other teams. We therefore had to maintain a structured process while still being flexible enough to handle genuine problems. This was one of the areas where I learned the importance of **clear communication and contingency planning**. --- ## The Technical Challenges Like every real project, HackVerse did not run without technical problems. We faced issues related to: - Production deployments - Domain configuration - Payment gateway integration - Database migration - Form workflows - Authentication - Changing requirements - Data consistency - Last-minute updates - Production bugs One of the major technical decisions during the project was moving our backend data infrastructure from **Neon PostgreSQL to Supabase**, particularly because of the need for realtime capabilities and better integration with the event workflow. Working through these problems was valuable because the consequences were real. A bug in a personal project is one thing. A bug in a system being used by hackathon participants is completely different. It taught me to think more carefully about **testing, monitoring, rollback strategies, and production reliability**. --- ## Working With the Team HackVerse was never an individual effort. Even though I had responsibilities across organising, management, and development, the event depended on collaboration between many people. There were organisers handling communication, registration, design, sponsorship, logistics, participant support, evaluation, and technical operations. My role often required connecting these different areas. A requirement from the management team could become a development task. A development limitation could affect event planning. A scheduling change could require a communication update. That constant interaction gave me a much better understanding of **cross-functional teamwork**. --- ## What I Learned From HackVerse '26 The biggest takeaway from HackVerse was that organising a large event is very different from participating in one. As a participant, you mostly see the final experience. As an organiser, you see everything behind it. I learned how important it is to: - Communicate clearly. - Document important decisions. - Keep responsibilities clearly assigned. - Build systems that can handle change. - Have backup plans. - Test before going live. - Stay calm when things go wrong. - Trust the team and delegate effectively. Most importantly, I learned that **leadership is not about doing everything yourself**. It is about making sure the right people have the right information, resources, and direction to do their work effectively. --- ## From Code to Coordination HackVerse '26 gave me an opportunity to combine two areas that I enjoy: **Technology and Leadership.** As Development Head, I worked with code, architecture, databases, deployments, and production systems. As an Organising Team Coordinator and part of the Management Team, I worked with people, planning, communication, coordination, and decision-making. Bringing these two sides together was probably the most valuable part of the entire experience. --- ## Looking Back HackVerse '26 was not just another event on my calendar. It was a real-world experience in **building, managing, coordinating, troubleshooting, and leading**. There were long working sessions, unexpected problems, last-minute changes, technical bugs, scheduling challenges, and plenty of discussions. But there were also moments where we saw everything come together. From building the technical infrastructure to coordinating teams and helping execute the event, every responsibility added something to my experience. I am proud to have been part of the team behind **HackVerse '26**, and even more grateful for everything the process taught me. You can explore the complete event, problem statements, registration workflow, and other information on the **[official HackVerse '26 website](https://hackverse.codebreakersgcek.tech/)**. **The hackathon may be about building projects, but organising one teaches you how to build people, processes, and systems too.** --- ## Article 2: Securing 1st Position in SIH Internal Round & The Journey to Choosing SIH26102 and SIH26097 - **URL**: https://blogs.priyam.tech/securing-1st-position-in-sih-internal-round-and-our-problem-statement-journey/ - **Author**: Gyanranjan Priyam - **Published**: 2026-09-08 - **Updated**: 2026-09-08 - **Category**: Engineering - **Reading Time**: 4 min read - **Tags**: Smart India Hackathon, SIH, Hackathon, Problem Statement, Leadership, Teamwork, Web Development, Engineering - **Summary**: From standing 1st in our college's Smart India Hackathon internal round to the intense brainstorming sessions that led us to select problem statements SIH26102 and SIH26097 — here is our complete hackathon journey. ### Content: ## The Milestone: 1st Position in the Internal Screening Round Participating in the **Smart India Hackathon (SIH)** is one of the most exciting and demanding experiences for any engineering student in India. Before getting the chance to represent our institution at the national level, we had to clear the first big hurdle: the **College Internal Hackathon Screening Round**. Our team spent days refining our presentation, understanding the core requirements, and preparing a rock-solid technical blueprint. When the results were officially announced, we were thrilled to have **secured the 1st position** among all the competing teams in our college! Winning the internal round validated our preparation and gave our team immense confidence, but we knew that the real challenge had only just begun. --- ## The Biggest Hurdle: Selecting the Perfect Problem Statement Once the internal round was cleared, our biggest struggle began: **choosing the right Problem Statements (PS)** from hundreds of problem statements released by various government ministries and departments. Selecting a problem statement isn't just about picking what looks interesting—it requires balancing several critical factors: - **Technical Feasibility & Scope**: Ensuring the problem is challenging enough to stand out while being achievable within hackathon deadlines. - **Societal & Industry Impact**: Addressing a real-world bottleneck where technology creates a measurable, positive impact. - **Team Strengths Alignment**: Leveraging our combined expertise in full-stack web engineering, scalable databases, APIs, and modern system architectures. - **Clear Evaluation Criteria**: Identifying problems with well-defined deliverables that jury panels can rigorously evaluate. --- ## The Final Decisions: SIH26102 and SIH26097 After multiple rounds of team discussions, debate sessions, and architectural feasibility checks, we narrowed down our focus and finalized two standout problem statements that tackle critical national challenges: ### 1. SIH26102: AI-Powered Anomaly & Fraud Detection for MPLAD Scheme - **Official Statement**: *Development of an AI-powered system to detect anomalies, fraud, and inefficiencies in MPLAD Scheme implementation regd.* - **The Core Problem**: The Members of Parliament Local Area Development Scheme (MPLADS) handles substantial public funds distributed across thousands of local infrastructure projects. Tracking fund utilization, identifying duplicate projects, catching fraudulent contractors, and eliminating bureaucratic delays across districts is historically difficult with manual oversight. - **Our Solution & Technical Approach**: - **Machine Learning Anomaly Detection**: Implementing unsupervised clustering and anomaly detection models to identify abnormal fund expenditures, project completion delays, and inflated cost estimates. - **Cross-District Duplicate Detection**: Natural Language Processing (NLP) to detect overlapping project proposals submitted across adjacent jurisdictions. - **Transparent Analytical Dashboard**: Building a clean, real-time analytics portal with geospatial project mapping and automated risk scores for auditing authorities. ### 2. SIH26097: AI-Driven Multilingual Voice Assistant for PM-AJAY - **Official Statement**: *AI-Driven voice Assistant for livelihood Mapping and NSQF-Aligned Skilling Recommendations for SC Communities under GIA component of PM-AJAY.* - **The Core Problem**: Under the Grants-in-Aid (GIA) component of the Pradhan Mantri Anusuchit Jaati Abhyuday Yojana (PM-AJAY), connecting beneficiaries from Scheduled Caste (SC) communities with skill development programs is hindered by digital illiteracy, language barriers, and complex application portals. - **Our Solution & Technical Approach**: - **Multilingual Conversational AI**: Integrating high-accuracy Automatic Speech Recognition (ASR) and Text-to-Speech (TTS) models supporting regional Indian languages and local dialects. - **Livelihood & Skills Mapping**: An intelligent recommendation engine that analyzes existing skills, educational backgrounds, and local market demands to recommend NSQF-aligned (National Skills Qualifications Framework) training programs. - **Accessible & Low-Bandwidth Interface**: Creating an intuitive voice-first interface that functions reliably on basic smartphones with voice prompts and automated enrollment assistance. --- ## Team Brainstorming & Architecture Blueprint With both problem statements selected, we immediately jumped into planning and architecting the solutions: - **System Architecture**: Mapping out data models, database schemas, and microservice/monolithic service boundaries. - **UI/UX Wireframing**: Creating clean, distraction-free mockups to guarantee exceptional usability during evaluation. - **Milestone Tracking**: Dividing responsibilities across frontend, backend, API integrations, and documentation. --- ## Next Steps on the Road to the Grand Finale With our problem statements locked in and foundational architecture designed, our roadmap for the upcoming weeks includes: - **Developing the Core MVP**: Building out the functional prototypes for both selected problem statements. - **Conducting Rigorous Testing**: Stress-testing edge cases, data validation, and security layers. - **Iterating with Mentor Feedback**: Gathering continuous feedback from faculty guides and industry mentors to polish our submissions. Stay tuned for more updates as we continue building and progressing through our Smart India Hackathon journey! --- ## Article 3: Successfully Completing My GeeksforGeeks Campus Mantri Journey: Months of Growth and Leadership - **URL**: https://blogs.priyam.tech/successfully-completing-my-geeksforgeeks-campus-mantri-journey-months-of-growth-and-leadership/ - **Author**: Gyanranjan Priyam - **Published**: 2026-06-02 - **Updated**: 2026-06-02 - **Category**: Career & Journey - **Reading Time**: 3 min read - **Tags**: GeeksforGeeks, Campus Mantri, Student Ambassador, Leadership, Community Building, Career Growth, Learning Journey, Campus Leadership, Professional Development, Networking, Technology Community, Achievement - **Summary**: I am thrilled to share the successful completion of my one-year journey as a GeeksforGeeks Campus Mantri. This experience provided me with invaluable opportunities to develop leadership skills, build a strong professional network, organize impactful initiatives, and contribute to one of India's largest tech communities. ### Content: ## A Memorable Milestone in My Professional Journey I am delighted to share that I have successfully completed my tenure as a **GeeksforGeeks Campus Mantri** and have been awarded a **Certificate of Completion** in recognition of my contributions throughout the program. This achievement marks the culmination of an enriching one-year journey filled with learning, leadership, collaboration, and personal growth. Being a Campus Mantri was more than just a role; it was an opportunity to represent a renowned technical community and create a positive impact among students. --- ## My Experience as a Campus Mantri Throughout this journey, I actively worked towards: - Promoting technical learning and awareness among students. - Connecting peers with valuable resources offered by GeeksforGeeks. - Building and engaging a community of learners and aspiring developers. - Enhancing communication, leadership, and organizational skills. - Collaborating with fellow Campus Mantris from different institutions. Each initiative and interaction helped me grow both professionally and personally while strengthening my confidence as a community leader. --- ## Key Learnings from the Program The Campus Mantri Program taught me several important lessons that will continue to benefit me throughout my career: - **Leadership and Responsibility**: Taking ownership of activities and representing a large community taught me how to lead effectively and manage responsibilities with professionalism. - **Communication and Networking**: Regular interactions with students, mentors, and professionals improved my communication skills and expanded my professional network. - **Consistency and Commitment**: Balancing academic responsibilities with program activities reinforced the importance of discipline, consistency, and time management. - **Community Building**: One of the most rewarding aspects of this journey was helping students discover learning opportunities and fostering a culture of continuous growth. --- ## A Heartfelt Thank You I would like to express my sincere gratitude to the entire GeeksforGeeks team for providing such an incredible platform for students to learn, grow, and lead. Special thanks to **Mr. Sandeep Jain**, Founder and CEO of **GeeksforGeeks**, for building a community that empowers millions of learners and aspiring developers. I am also thankful to the program coordinators, mentors, and fellow Campus Mantris whose support and collaboration made this journey truly memorable. --- ![Successfully Completing My GeeksforGeeks Campus Mantri Journey: Months of Growth and Leadership](https://assets.priyam.tech/blog-content/7mgE9vIfISqVCBaypiR2xYBs5tMBE57n-1780426025757-8oo41ownjdq.png) ## Looking Ahead While my tenure as a Campus Mantri has come to an end, the lessons, experiences, and connections gained during this journey will continue to inspire me. I look forward to applying these learnings in future opportunities, contributing to the technology community, and continuing my journey of lifelong learning. This certificate is not just a recognition of past efforts but also a motivation to keep striving for excellence in everything I do. Thank you, GeeksforGeeks, for being a significant part of my growth journey. --- --- ## Article 4: The Tools I Actually Use to Build Production-Level Websites - **URL**: https://blogs.priyam.tech/the-tools-i-actually-use-to-build-production-level-websites/ - **Author**: Gyanranjan Priyam - **Published**: 2026-04-01 - **Updated**: 2026-04-01 - **Category**: Engineering - **Reading Time**: 5 min read - **Tags**: WEB DEVELOPMENT, FULL STACK DEVELOPMENT, PRODUCTION LEVEL WEBSITES, MODERN TECH STACK, GITHUB COPILOT - **Summary**: A practical, experience-driven breakdown of the tools I rely on to build real-world websites that don’t break in production—and why simplicity beats trends every time. ### Content: ## The Phase Where Everything Feels Important There was a time when I thought being a good developer meant knowing more tools—every new framework felt like an upgrade, and every trending library felt like something I should learn, so I kept switching stacks trying to stay “relevant,” and it felt like progress; but when I actually tried to build something real—something that had to handle users, errors, and edge cases—I ran into an uncomfortable truth: I wasn’t struggling because I lacked tools, I was struggling because I didn’t understand the ones I was using deeply enough, and that’s when I stopped chasing and started simplifying. --- ## What “Production-Level” Actually Means Before tools, it’s important to define this properly. A production-level website is not just something that works. It should: - Handle failures without crashing - Load fast enough that users don’t leave - Be readable and maintainable after months - Work across devices and browsers Most tutorials don’t teach this part. But this is the part that matters. --- ## The Stack I Keep Coming Back To Over time, I ended up with a small, consistent set of tools. Not because they’re perfect, but because they reduce friction. | Layer | Tools I Use | Why I Use Them | | :--- | :--- | :--- | | Frontend | React, Next.js, Tailwind CSS | Fast development, structure, consistency | | Backend | Node.js, Express / Next API | Simple, predictable, easy to debug | | Database | PostgreSQL / MongoDB | Flexible depending on project | | Auth | Clerk / Firebase Auth | Avoid security headaches | | Deployment | Vercel, Railway, Render | Minimal setup, fast shipping | | Dev Tools | VS Code, GitHub, Postman | Essential workflow support | This is not a “perfect stack.” It’s a *stable* one. --- ## Frontend: Where Simplicity Wins I use React with Next.js for most projects, not because they’re trendy but because they remove unnecessary decisions—you don’t spend time setting up routing or worrying too much about structure since it’s already there, and that mental space matters more than people realize; for styling, I use Tailwind CSS, and while I used to care about writing “clean CSS” with strict naming conventions and file structures, I’ve found that simplifying those choices lets me focus more on actually building things that work. Now I care about: - building faster - staying consistent - avoiding context switching Tailwind is not the prettiest solution, but it’s efficient. And in production work, efficiency matters more than elegance. --- ## Backend: Keep It Boring This is something I learned the hard way: a complicated backend might feel impressive at first, but it almost always becomes a problem later. I stick with: - Node.js - Express or Next.js API routes That’s it. Because when something breaks in production, you don’t want clever code. You want understandable code. For databases, I don’t overthink it: - PostgreSQL for structured data - MongoDB for flexible schemas No strong opinions. Just practical choices. --- ## Authentication: Not Worth Reinventing I used to build authentication systems myself. It looked simple at first. Then came: - session handling - token expiration - security concerns - unexpected edge cases Now I use services like Clerk or Firebase Auth. It saves time, reduces risk, and removes a whole category of problems I don’t need to solve anymore. --- ## Deployment: It Should Feel Invisible There was a time when deploying felt like a separate skill, but now it shouldn’t—I use Vercel for most projects, where you push code and it just goes live, and that’s it. If deployment requires too many manual steps, it slows everything down, and in real projects, speed of iteration matters, which is why for backend services I stick to platforms like Railway or Render—same idea, minimal setup, and predictable behavior. --- ## The Tools That Quietly Matter Some tools don’t get much attention, but they make a huge difference: - VS Code – where everything happens - GitHub – tracks your decisions, not just code - Postman / Thunder Client – test before things break - Chrome DevTools – find problems faster These are not “exciting,” but they are essential. --- ## Using AI Without Losing Control I do use tools like GitHub Copilot and ChatGPT. They help with: - writing repetitive code - debugging hints - quick explanations But there’s a line. If you stop understanding your own code, it shows—and in production, that becomes a problem very quickly; AI should support your thinking, not replace it. --- ## What Actually Matters in the End At some point, I realized something simple: production-level development is not about tools—it’s about responsibility. It’s about writing code that: - doesn’t break easily - can be understood later - handles real users, not just ideal cases The tools help, but they’re not the reason things work—the reason things work is because you’ve reduced complexity where it doesn’t belong. --- ## Final Thought I stopped asking, “**What’s the best tool right now?**” and started asking, “**What will still work when this project grows?**" That shift changed everything, because in the end building for production isn’t about showing what you know; it’s about building something that keeps working even when you’re not there to fix it. --- ## Article 5: When Code Meets Curriculum: The Unspoken Grind of Being a Student and a Developer - **URL**: https://blogs.priyam.tech/when-code-meets-curriculum-the-unspoken-grind-of-being-a-student-and-a-developer/ - **Author**: Gyanranjan Priyam - **Published**: 2026-03-22 - **Updated**: 2026-03-22 - **Category**: Career & Journey - **Reading Time**: 8 min read - **Tags**: Student Life, Developer, Non-CSE, College, Coding, Personal Essay, Career, Learning, Problem Solving, Campus - **Summary**: Assignments on one tab, a half-broken project on the other. Attendance shortages, mid-sem panic, and a side project that refuses to compile. If you are a student who also builds things — especially from a non-CSE branch — you already know this life. This is the honest, unfiltered story of what it actually feels like to carry both worlds at once, and why that struggle quietly makes you better than you realise. ### Content: ## Two Worlds, One Person There is a very specific kind of exhaustion that only a student-developer knows. It is not just the exhaustion of late-night debugging sessions or the panic of a submission deadline approaching fast. It is the exhaustion of living two parallel lives at the same time — one inside a classroom, and one inside a code editor. On one side, there are assignments with strict word counts, lab reports that need to be handwritten, attendance registers that do not care whether you were up until 3 AM fixing a broken API call. On the other side, there is a project that is half-built, a GitHub repo with too many uncommitted changes, and a learning curve that never really flattens out. Most people around you see only one of these worlds. Your professors see a student who sometimes looks distracted. Your developer peers see someone who codes. Very few people see both — and even fewer understand what it costs to maintain them simultaneously. --- ## The Academic Calendar Does Not Care About Your Side Project The academic year has its own rhythm, and it is relentless. Assignments pile up from the very first week. Attendance registers fill with absences on the days you stayed in to push a feature or debug something that had been bothering you for hours. Internal assessments sneak up before you have had time to open the syllabus properly. And then there is the mid-semester examination — that peculiar academic invention designed to arrive precisely when you have just found your stride in a project. You are finally making progress on something real, something you built from scratch, and the calendar pulls you back into memorising theory that feels miles away from anything you actually do. The end-semester examination is its own category of pressure entirely. Weeks of syllabus compressed into days of revision. The code gets closed. The projects get paused. You switch modes entirely and try to convince yourself that you still remember what you studied in Unit One back in August. Every student knows this pressure. But when you are also a developer, the cost is doubled. Because while you are sitting in an exam hall writing about topics that may or may not matter to your future, your mind is already thinking about the bug you left unresolved, the feature that is almost done, the deployment that needs to happen. --- ## Being Non-CSE Changes Everything Now here is where it gets genuinely interesting — and genuinely harder. Spare a thought for the student-developer who does not belong to a Computer Science or CSE specialisation branch. CSE students have it difficult too, no question. But they have something that non-CSE developers do not: a curriculum that at least partially rhymes with what they are building. They have lab sessions that touch on relevant concepts. They have classmates who understand what a merge conflict is. They have professors who might, occasionally, appreciate what they are working on outside of class. The Electrical Engineering student who codes. The Mechanical undergraduate maintaining a web app. The Civil branch student who taught themselves backend development because it genuinely excited them. These people are building in the dark. No structured pathway. No supportive peer group that relates to both sides of their life. No professor who nods approvingly when you mention you spent the weekend working on a REST API. Instead, they sit in lectures about subjects that feel entirely disconnected from the things they are passionate about, take notes they will need to reproduce in exams, and then go back to their rooms and open their laptops and build things that nobody in their academic circle fully understands. There is a particular kind of loneliness in that. And also, if you pay close enough attention, a particular kind of strength. The real challenge is not the code, and it is not the exam. It is carrying both at once — without dropping either — and doing it without a roadmap. --- ## The Problems You Face Become the Products You Build Something remarkable happens to student-developers who are pushed to figure things out on their own. Because the system does not hand them solutions, they are forced to become problem-solvers in the truest sense. Not problem-solvers who follow a textbook method, but problem-solvers who look at an actual friction point in their daily life and think: I could fix this. The attendance tracker that alerts you when you are getting close to the shortage threshold — built by a student who had already crossed it once and never wanted to again. The assignment deadline reminder app that sends a notification three days before, one day before, and the morning of — built by someone who submitted something late and decided it would never happen again. The CGPA calculator that tells you exactly what you need to score in your finals to hit the number you are aiming for — built at 1 AM by someone who needed the answer immediately and did not want to do the math by hand. These are not impressive portfolio projects by the standards of the tech industry. But they are real. They solve actual problems. They were built under real constraints — limited time, limited energy, a full academic schedule sitting on top of the development work. And they work. That is what separates the student-developer from someone who just learns coding in isolation. The problems are real. The motivation is personal. The feedback loop is immediate. If something breaks, you feel it. If something works, you feel that too. --- ## The Things Nobody Tells You Going In - You will miss deadlines sometimes — academic ones because of your project, or project ones because of your academics. That is not failure. That is the reality of managing two demanding things at once. The skill is in learning which one needs you more on any given day. - Being from a non-CSE branch does not put you behind. In many ways, it puts you ahead. You learned to code because you wanted to, not because your curriculum required it. That kind of motivation is difficult to manufacture and impossible to fake. - The loneliness of building something that your classmates do not fully understand is temporary. The internet is full of people who get exactly what you are doing. Communities exist. You just have to find them and show up. - Impostor syndrome is louder when you are surrounded by people who share neither your academic world nor your developer world. Remember: you exist in both. That is not a weakness. That is a genuinely rare combination. - The projects you build to solve your own problems are often better than the ones you build trying to impress someone. Build for yourself first. The portfolio will follow. - Time management for a student-developer is not a productivity hack. It is survival. Learn it early, iterate on it constantly, and do not feel bad when a system stops working — just build a new one. - Showing up consistently, even on the days when neither the code nor the coursework is going well, is what separates people who eventually get somewhere from those who do not. --- ## What This Life Quietly Builds in You The grind of being a student-developer — especially a non-CSE one — is not glamorous. It does not always look impressive from the outside. There are no highlight reels of sitting in an exam hall wishing you were debugging instead, or closing your laptop at midnight because the assignment is due tomorrow and the project will have to wait. But here is what that grind quietly builds, almost without you noticing: resilience, adaptability, and an instinct for problem-solving that is grounded in reality rather than theory. You learn to ship things under pressure because your entire college life is pressure. You learn to keep going when something is not working because stopping is not really an option. You learn to context-switch — from engineering principles to software architecture, from exam revision to code review — in ways that most people never have to. And perhaps most importantly, you learn that the constraints are not the enemy. The constraints are the curriculum. Every limitation you work around teaches you something that no tutorial ever will. --- ## To the Student Who Has a Browser Tab Open Right Now If you are reading this with one tab open for your assignment and another open for Stack Overflow — this is for you. If you have missed a lecture because you were too deep in a bug to notice the time — this is for you. If someone has ever asked why you are learning to code when your branch has nothing to do with software — this is definitely for you. What you are doing is harder than it looks. Carrying two worlds without a map, without guaranteed support, without the comfort of fitting neatly into either category — that takes something. And you are doing it anyway. The pain is real. The exhaustion is real. But so is the instinct that got you here — the one that said I want to build something, and did not wait for permission from the curriculum. Keep going. The people who build their way out of problems are exactly the kind of people the world needs more of. And you are already one of them. --- ## Article 6: My Journey to Becoming a GFG Campus Mantri: Doubts, a Shaky Interview, and an Unexpected Yes - **URL**: https://blogs.priyam.tech/my-journey-to-becoming-a-gfg-campus-mantri-doubts-a-shaky-interview-and-an-unexpected-yes/ - **Author**: Gyanranjan Priyam - **Published**: 2026-03-10 - **Updated**: 2026-03-10 - **Category**: Career & Journey - **Reading Time**: 5 min read - **Tags**: Personal, GFG, Career, Learning, Campus, GeeksforGeeks - **Summary**: I applied on a whim, waited four months, stumbled through a telephonic interview, and fully convinced myself I had not made it. Then the welcome email arrived. This is the honest, unfiltered story of how I became a GFG Campus Mantri—and what the whole experience quietly taught me about showing up even when you are not sure you are ready. ### Content: ## The Application I Almost Did Not Submit It was November. I was sitting in my hostel room, scrolling through some tech community pages when I came across the GFG Campus Mantri program. I had heard the name before in passing but never really looked into what it actually involved. I read through the description. Campus representative. Help students access learning resources. Organize technical events. Connect peers with opportunities. Something about it felt right. Not in a grand, life-changing way — more like a quiet instinct that said this is worth trying. So I filled out the application, submitted it, and then almost immediately started wondering if I was even qualified enough to have applied in the first place. That self-doubt after submitting an application is something I think a lot of people feel but rarely talk about. You put yourself forward for something and the moment you hit submit, your brain starts listing all the reasons it probably will not work out. --- ## Ten to Fifteen Days of Silence Days passed. Then more weeks. No email, no update, nothing. At some point I genuinely forgot I had applied. Life moved on — college assignments, club activities, learning new things. The GFG application faded to the back of my mind. And then, out of nowhere, an email landed in my inbox. I had been selected as the GFG Campus Mantri. I re-read it twice. I sat with it for a moment. Then the nerves showed up immediately, as if they had been waiting just offscreen this whole time. --- ## The Email That Changed Everything A few days later — I think it was a Monday — I opened my inbox to a welcome letter from GeeksforGeeks. I had been selected as a Campus Mantri. I read it once. Then again. Then I put my phone down and just sat there for a second. The feeling was not immediate celebration. It was more like the slow unwinding of something I had been holding tightly without realizing it. Relief first. Then disbelief. Then this quiet, spreading happiness that kept growing the more it sank in. I texted my friend immediately. Their reply was something like "I told you." And honestly, they had. --- ## What Being a Campus Mantri Actually Means to Me Once the initial excitement settled, I started thinking more seriously about what this role actually meant. It is not just a title. It comes with real things to do — organizing events, sharing learning paths, being a visible and approachable point of contact for students who are trying to figure out where to start with tech. And the reason that matters to me personally is straightforward: I was that confused student not too long ago. I was the kid from Electrical Engineering who wandered into a coding club induction session and did not fully understand what he was walking into. Nobody handed me a roadmap. I figured things out slowly, by reading docs, breaking projects, and asking questions. If I can be the person who shortens that learning curve for even a few students — who says here is a resource, here is where to start, here is why it is worth continuing even when it feels hard — then this role has real meaning. --- ## Things I Carried Away From This Experience Not everything you learn comes from a course or a tutorial. Some of it comes from just going through a process and paying attention to what it shows you about yourself. - Apply anyway, even when you are not sure you are ready. The worst that happens is you do not get it and you try again. The best is you get an email that makes you stop and sit quietly for a moment. - Stumbling in an interview is not the same as failing it. I stumbled. I still got selected. What you say matters, but how honestly you say it might matter more. - Talking to someone you trust before something stressful is not weakness. It is just smart. My friend did not prepare me. They reminded me of what I had already done. - The wait can be the hardest part. Four months is a long time to hold onto something uncertain. Learning to keep moving forward while something is unresolved is its own kind of skill. - Confidence is not the absence of doubt. It is continuing even with the doubt sitting right there next to you. --- ## To Anyone Reading This Who Is Thinking About Applying If you are sitting on an application right now — for the Campus Mantri program, or anything else — and wondering if you are qualified enough or experienced enough or ready enough, I just want to say: probably just apply. You are not going to feel perfectly ready. The interview might not go the way you rehearsed it. You might hang up the call convinced it did not work. And then a few days later, an email might show up that changes the whole story. Or it might not. But at least you will have tried. And trying, even imperfectly, is what gets you somewhere. --- ## What Comes Next I am genuinely excited about this. Not in an overwhelming way, but in the steady way that comes when something aligns with what you actually care about. There are students at my college who are smart, curious, and just looking for a starting point. I want to be part of creating those starting points — through events, conversations, shared resources, or just being someone who is openly figuring things out and willing to talk about it. This whole journey — from that November application to the welcome email — has been one of the more unexpected and meaningful things that has happened to me in college. And I think it is really just beginning. --- ## Article 7: From Electrical Engineering to Web Development: My Unexpected Journey into Coding - **URL**: https://blogs.priyam.tech/from-electrical-engineering-to-web-development-my-unexpected-journey-into-coding/ - **Author**: Gyanranjan Priyam - **Published**: 2026-02-22 - **Updated**: 2026-02-22 - **Category**: Career & Journey - **Reading Time**: 7 min read - **Tags**: Personal, Web Development, React, Career, Learning - **Summary**: If someone had asked me during my first year of college whether I would ever lead the technical team of a coding club, I would have laughed. This is the story of how curiosity slowly turned into passion. ### Content: ## Introduction If someone had asked me during my first year of college whether I would ever lead the technical team of a coding club, I would have laughed and said no. I am an Electrical Engineering student, and when I entered college, coding was not even on my radar. I had no real idea what software development meant, how websites were built, or what developers actually did. But college has a funny way of changing people. Sometimes all it takes is one small exposure, one event, or one conversation to shift your direction completely. This blog is about how that shift happened for me and how curiosity slowly turned into passion. --- ## First Year: A Student Without Direction in Coding When I joined college as a first year Electrical Engineering student, my focus was simple. Attend classes, adjust to hostel life, make friends, and understand how college works. Coding felt like something only Computer Science students did. I believed it was too late for me to even think about entering that world. During our induction program, the college introduced us to different student clubs. There were clubs for robotics, photography, music, literature, and of course, coding. At that time, I did not have any clear interests, so I decided to explore everything. I joined almost every club just to see what each one offered. One of those clubs was our college coding club, Codebreakers. At that moment, joining it felt like just another item on the list. I did not know it would end up changing my college life. --- ## The Day That Sparked My Curiosity When I attended my first session with Codebreakers, everything felt new and exciting. Seniors were talking about different domains like web development, app development, open source, UI/UX, and competitive programming. It was the first time I realized that coding is not just about writing difficult programs. It is about building things. Real things. Websites, apps, tools, and ideas that people actually use. That session planted a small seed of curiosity in my mind. I returned to my hostel room that day thinking about what I had heard. For the first time, I wanted to try building something myself. --- ## Starting With the Basics: HTML, CSS, and JavaScript Luckily, I had a tiny advantage. During my +2, I had learned the basics of HTML. It was very basic knowledge, but it gave me the confidence to start somewhere. That night, I opened my laptop and decided to build a simple webpage. Nothing fancy. Just text, colors, and a few buttons. But the feeling of creating something that worked in a browser was amazing. From there, I started learning: - HTML to structure pages - CSS to style them - JavaScript to add interactivity I began building small projects: - Personal profile pages - Simple landing pages - Small interactive web elements Every small project made me more curious. I wanted to know how real websites worked. Slowly, my interest in development started growing. --- ## Learning Without Courses One thing about my journey is that I did not follow traditional learning paths. I did not enroll in paid courses or follow long playlists. Instead, I focused mainly on documentation. Yes, official documentation. Whenever I picked a new technology, I would go straight to the official website and read the docs. At first, it felt difficult. Documentation can look scary when you are a beginner. But over time, I realized that docs are the most reliable and up to date learning resource. My learning process became simple: - Pick a tech stack - Read the official documentation - Try building something with it - Learn by doing And whenever I got stuck or faced errors, I followed a simple habit. I copied the error and searched for solutions. Often, I would ask ChatGPT to explain the error, understand the problem, and then try to fix the code myself. This helped me understand the logic behind mistakes instead of just copying solutions. This approach is often called learning by building, and it worked perfectly for me. --- ## Discovering React: A Turning Point After building several small websites using HTML, CSS, and JavaScript, I started hearing a lot about React. Many developers in the club were talking about it, and I kept seeing it mentioned in developer discussions. So I decided to explore it. Learning React felt like a big step forward. At first, concepts like components, props, and state felt confusing. But once things started making sense, everything clicked. React changed how I thought about development: - I understood how modern web apps are structured - I learned how to break big problems into small components - I started writing cleaner and reusable code Working with React gave me confidence. For the first time, I felt like I truly understood the basics of development. --- ## From Member to Leader As months passed, I kept building projects and staying active in the coding club. I participated in discussions, helped juniors when I could, and kept improving my skills. Without realizing it, coding had become a major part of my daily routine. What started as curiosity turned into passion. Eventually, I got the opportunity to lead the technical team of Codebreakers. Becoming the Technical Lead of the college coding club was something I never imagined when I first walked into that induction program. Along with this, I also became the Campus Mantri of GeeksforGeeks for my college, Government College of Engineering, Kalahandi. This role gave me the chance to connect students with learning resources, organize technical events, and help more students start their journey in tech. Now, I help: - Organize technical sessions - Guide juniors starting their coding journey - Share resources and learning paths - Encourage students from non-CS branches to start coding Because I know exactly how it feels to start from zero. --- ## Lessons From My Journey - You do not need to be from Computer Science to start coding. I come from Electrical Engineering, and many amazing developers come from non-CS backgrounds. - Start small. Your first webpage does not need to be perfect. Just start building. - Documentation is powerful. Learning how to read docs is a superpower for developers. - Errors are part of learning. Every error is a lesson in disguise. - Curiosity can change your path. All it takes is one step to discover a new passion. --- ## Where I Am Now Today, I am still learning, still building, and still exploring. Development is a field where learning never stops. Every new project teaches something new. And it all started with a single club session during the college induction program. If you are someone who feels late, confused, or unsure about starting coding, I hope my story gives you confidence. You do not need a perfect beginning. You just need the courage to take the first step. --- ## Final Thoughts My journey into development was unexpected, unplanned, and completely self driven. From knowing nothing about coding to leading the technical team of a coding club and becoming the Campus Mantri of GeeksforGeeks, the journey has been exciting and full of learning. And this is just the beginning. ---