Fresher Interview Questions That Actually Get Asked

Sure, I'd love to introduce myself.

I recently completed my B.Tech in Computer Science from IIIT Hyderabad with a CGPA of 8.2. During my time there, I developed a strong interest in backend development — I find something deeply satisfying about building systems that handle real traffic and need to be reliable.

The project I'm most proud of is a collaborative study-notes platform I built during my third year. I used React on the frontend, Node.js with Express on the backend, and MongoDB for storage. What made it more than just a course project was that 500+ students on campus actually used it during exam season. I handled issues like concurrent editing, image optimization for slow networks, and even added a real-time notification system using Socket.io. That experience of building something that people relied on daily taught me more than any classroom.

I'm particularly excited about this opportunity at Razorpay because your engineering blog on building resilient payment systems resonated with exactly the kind of challenges I want to work on. I want to start my career at a place where I'm building real infrastructure that millions of people depend on, and I'm ready to learn fast.

I can't speak to what other candidates bring, but I can tell you three things about me that I think make me a strong fit for this role.

First, I don't just write code that works — I write code that's maintainable. During my internship at a startup, I refactored their invoice generation module. The previous version had zero tests and was a 600-line function. I broke it into clean, tested modules with 90% coverage. My mentor told me it was the first piece of intern code he'd ever merged without requesting changes.

Second, I learn fast under pressure. When the startup needed a payment gateway integration and no one on the team had done one, I volunteered, read the Razorpay docs cover to cover in one evening, and had a working prototype in 3 days. It went live the following week.

Third, I'm genuinely excited about this specific role — not just getting a job. I've read your engineering blog, I've tried your product, and the challenge of building scalable APIs for [specific product area] is exactly where I want to spend my first few years growing as an engineer.

My biggest strength is that I'm a methodical debugger. When something breaks, I don't panic or start making random changes. I trace the problem systematically — logs first, then reproduce it, then isolate the component. During my internship, I found a bug that had been open for 2 months. Three other developers had looked at it. I traced it to a race condition in the caching layer by writing a small test script that simulated concurrent requests. Fixed it in a day.

My honest weakness is public speaking and presenting technical work. I'm much more comfortable writing code than explaining it to non-technical stakeholders. I've been actively working on this — I started a habit of writing short technical blog posts on Hashnode (I've published 8 so far), and I volunteered to present my final year project to the department rather than just submitting a report. It's getting better, but it's still an area I'm consciously working on.

I first got interested in Computer Science during 11th grade when I built a small expense tracker in Python for my family. It was basic — just a command-line script that read from a CSV file — but the feeling of solving a real problem with code was addictive. I spent the next two months going down the rabbit hole of building small tools: a quiz app, a basic website, a weather widget.

In college, that interest deepened significantly. I started competitive programming in my second year, which taught me how to think about efficiency and edge cases. But what really solidified my direction was my third-year course on databases and distributed systems — understanding how companies like Flipkart handle millions of concurrent users made me realize I wanted to build backend infrastructure, not just write code that works on my laptop.

Today, I'm most excited about the intersection of reliability engineering and product development — building systems that are fast, handle failure gracefully, and directly impact user experience. That's why I'm drawn to a product engineering role rather than pure R&D.

In the first year or two, my goal is simple: become a reliable, independent contributor. I want to get to the point where I can own a feature end-to-end — from design to deployment — without needing constant guidance. I know there's a gap between college knowledge and production-grade engineering, and I'm excited to close that gap quickly.

By year 3, I'd love to start taking on technical leadership responsibilities — maybe owning a small module or service, doing code reviews, and helping onboard newer engineers. I've found that teaching something is the fastest way to truly master it.

In 5 years, I see myself as a senior engineer or tech lead — someone who's trusted to make architectural decisions and mentor a team. I'm especially interested in how your company is expanding into [specific area], and I'd love to be part of building that as it grows.

I've done some research on Glassdoor and AmbitionBox, and I understand that for a fresher SDE role in Bangalore, the typical CTC range is around 5 to 8 LPA depending on the company and specific role. I'd be comfortable within that range.

But honestly, at this stage of my career, the compensation matters less to me than the quality of the engineering challenges I'll be working on, the caliber of the team I'll learn from, and the growth trajectory. If the role offers strong mentorship and the chance to work on real-scale systems, that's worth more to me than a slightly higher number. I'm confident the compensation will be fair.

During my third year, I built an automated attendance system for our department using face recognition. The idea was simple — a camera at the classroom door would identify students and mark attendance automatically. But the implementation was much harder than I expected.

The biggest challenge was accuracy in real-world conditions. The model I trained worked great in my room with good lighting, but in the classroom — where the lighting changed every hour, students wore masks, and the camera angle was fixed — accuracy dropped from 95% to about 60%. That was unusable.

I spent two weeks researching and tried three approaches. First, I augmented my training data with varied lighting conditions and partial face occlusions. Second, I switched from a basic CNN to a pre-trained FaceNet model with transfer learning. Third, I added a confidence threshold — if the model was less than 85% sure, it would flag the student for manual verification rather than marking a wrong attendance.

The final system achieved 92% accuracy in classroom conditions, and our department actually piloted it for one semester with 4 classes. It processed 120 students per day and reduced the faculty's attendance-marking time from 10 minutes to 30 seconds. I wrote it up as my final year project and scored the highest grade in my batch.

Three reasons, honestly. First, I'm a daily user of your product. I've been using [product] since my second year for [specific use case], and I've watched it evolve from [old feature] to [new feature]. As an engineer, I find it exciting to work on something I actually use and care about as a customer.

Second, I read your engineering blog — specifically the post about how you handle real-time data processing at scale. The approach of using [specific technology] for [specific use case] was fascinating, and that's exactly the kind of systems-level challenge I want to work on early in my career.

Third, I've noticed you're expanding into [specific area/market]. Being part of a team that's building something new from the ground up, rather than just maintaining existing systems, is the kind of opportunity where I think a motivated fresher can add the most value and learn the fastest.

Absolutely. [Company] is a [B2B/B2C] platform that helps [customers] with [core value proposition]. You were founded in [year] by [founders] and have raised [funding amount] to date. Your core product serves [target market] and you've grown to [user count/revenue milestone].

What caught my attention specifically was your recent launch of [specific feature/product]. I read the announcement on your blog and it mentioned how you're using [specific technology] to handle [specific challenge] — that's directly related to what I've been learning in my [course/project].

I also noticed your engineering team contributes to open-source — I saw [specific repository or contribution] on GitHub, which told me the engineering culture here values quality and community, not just shipping fast.

During our college hackathon, my team had 24 hours to build a working prototype of a food delivery app for campus. By hour 8, we realized our original plan — building a full React frontend with a Node backend — was too ambitious for the remaining time.

Instead of panicking, I suggested we pivot to a simpler approach: a clean HTML/CSS frontend with a Firebase backend. I broke the remaining work into 4 independent tasks, assigned each team member one, and we checked in every 2 hours. I took on the hardest piece — the real-time order tracking — because I was the most comfortable with Firebase's real-time database.

We submitted our prototype with 30 minutes to spare. It wasn't as polished as some entries, but it was fully functional — you could browse menus, place orders, and track them live. We placed second out of 20 teams. The key lesson: when time is short, cut scope, not quality.

During my final year project, I was in a 4-person team building a plagiarism detection tool. Early on, we hit a conflict — two teammates wanted to use a pre-built API, and I and the fourth member wanted to build the detection algorithm from scratch because we'd learn more and it would be a stronger project for interviews.

Rather than arguing, I proposed a compromise: we'd build the core algorithm ourselves but use a pre-built API for text preprocessing (tokenization, stop-word removal). This way, we'd have meaningful technical work to discuss while saving time on the commodity parts.

I took on the algorithm implementation — a cosine similarity engine that compared TF-IDF vectors across documents. My teammate handled the database and file upload system. The other two built the frontend and integrated the preprocessing API.

We shipped on time, the tool could compare 50 documents in under 3 seconds, and our professor awarded us the highest grade. But the part I'm most proud of is how we resolved that early disagreement without anyone feeling steamrolled — and we're still friends.

My biggest achievement was building and deploying an open-source Chrome extension that now has 1,200 active users. It's called "Focus Mode" — it blocks distracting tabs during study hours and tracks your deep-focus time with a simple dashboard.

I built it during my second year because I was struggling with my own productivity. The initial version took two weekends. But what I'm most proud of is what happened after — I published it on the Chrome Web Store, set up a GitHub repo, and started getting feature requests from actual users. I learned about semantic versioning, automated testing with CI, handling bug reports from strangers, and writing documentation that people could actually follow.

It taught me that building software isn't just about writing code — it's about solving a real problem for real people and maintaining it responsibly. That experience influenced my decision to pursue product engineering rather than pure research.

You're right to ask — my CGPA of 6.8 doesn't fully represent my ability, and I want to be transparent about it. In my first two years, I was taking courses I didn't find meaningful — a lot of pure theory and subjects that didn't connect to real engineering problems. I was doing the bare minimum to pass and spending most of my time on things that excited me more — online courses, building side projects, and competitive programming.

The turning point was my third year when I took Operating Systems and Distributed Computing. Those courses finally clicked — I understood WHY the theory mattered. My grades in those subjects were 8.5 and 9.0 respectively. From that point on, I was a different student.

More importantly, during those "low CGPA" years, I wasn't sitting idle. I built 3 deployed projects, completed two internships (one at a startup where I contributed production code), won a hackathon, and contributed to 2 open-source projects. I believe my portfolio demonstrates engineering ability more accurately than my GPA does.