Interview Prep Sheet

My name is Umar, and I'm a second-year Computer Science student at NED University of Engineering and Technology, Karachi. I'm currently in my fourth semester, majoring in Computer Science and Information Technology.

On the technical side, I work as a junior MERN stack developer with a backend focus. I've built and shipped full-stack projects including a notes application, an AI-integrated chat application, a hospital management system, and I'm actively developing a group expense manager. I've solved over 145 problems on LeetCode, which has sharpened my problem-solving and algorithmic thinking.

Beyond coding, I'm deeply interested in Artificial Intelligence and Data Science — that's the long-term direction I'm building toward. I believe combining solid software engineering foundations with AI expertise is where I want to be in five years.

This role genuinely excites me because it sits at the intersection of technical development and real-world application — which is exactly where I want to grow. I'm not just looking for a position; I'm looking for an environment where I can contribute meaningfully while also learning from experienced professionals.

Given my background in full-stack web development and my interest in backend systems, this opportunity allows me to apply my current skills while pushing me toward the next level. I also see it as a step in the direction of my long-term goal of working in AI and Data Science — understanding how software systems work at scale is a foundation I need to build.

Based on my research, your company is known for [insert: company's core product/service] and has built a reputation for [insert: key strength — innovation, reliability, community, etc.]. What stood out to me was your focus on [specific mission or value], which resonates strongly with my own principles around building meaningful technology.

I also noticed [a recent achievement, product, or news item], which tells me the company is growing and forward-thinking. That's the kind of environment I want to be part of at this stage of my career.

While building ChatZee, my MERN-based AI chatbot, I ran into a challenge where the backend was intermittently dropping responses from the AI API under concurrent requests. The app would work fine in isolation but break unpredictably in real usage — which is the worst kind of bug.

Rather than guessing, I isolated the problem systematically — logged every request cycle, identified that async handlers weren't resolving in the right order, and restructured the middleware chain. It took time, but fixing it properly rather than patching around it made the app stable. The lesson: don't paper over bugs. Understand them, then fix the root.

I've developed a fairly structured approach to this. When a deadline is approaching, the first thing I do is break the task into smaller, ordered chunks — what's blocking everything else, what can be done in parallel, and what can be cut if needed.

I also manage my energy intentionally. I structure my study and work schedule around my most productive hours, using a "weekdays maintain, weekends grow" model where weekdays handle essential tasks and weekends are reserved for deeper, more demanding work. This prevents burnout while keeping momentum. When things get genuinely overwhelming, I pause, reset, and come back with fresh eyes rather than pushing through and making poor decisions under stress.

My technical stack includes JavaScript, Node.js, Express.js, MongoDB, React, and Tailwind CSS — the full MERN stack. I have hands-on experience with REST API development, JWT-based authentication, database schema design, and Mongoose ODM.

Beyond the stack, I've worked with PostgreSQL and the pg library for a PERN stack project, so I'm comfortable with both SQL and NoSQL paradigms. I also have solid fundamentals — data structures and algorithms (145+ LeetCode problems), Git version control, and basic system design thinking. Soft-skill-wise, I communicate clearly, document my code, and prefer planning before implementation, which reduces errors and rework.

One project I'm particularly proud of is ChatZee, an AI-integrated MERN chat application I built. The challenge was connecting a frontend interface to an AI API in a way that felt seamless and responsive — not just a basic chatbox.

I designed and built the backend with Express, handled API communication with the AI service, managed session state, and built the React frontend with a clean UI using Tailwind CSS. The project taught me how to handle asynchronous operations at scale, manage API rate limits gracefully, and structure a backend for extensibility. It's shipped and working — and it directly informed the architectural decisions I'm making in my current project, a bill splitter and group expense manager.

I use a structured weekly framework. Weekdays are for maintaining progress — university coursework, small coding tasks, revision, and LeetCode. Weekends are for deeper work — building projects, learning new technologies, or tackling harder problems that need uninterrupted focus.

Within a day, I anchor my schedule around fixed commitments (prayer times, classes) and build work blocks around them. I also use a planning-first approach for every project: I map out the full roadmap before writing a single line of code. This prevents mid-project confusion and keeps me from wasting time on implementation decisions that should've been resolved in design.

During the development of StickyBits, I collaborated with a friend who was helping with the frontend UI while I handled the backend. Even in a small two-person setup, coordination mattered — we had to agree on API contracts, data shapes, and which features to cut from the first version to hit a workable MVP.

My role was backend and architecture — I set up the Express server, MongoDB schema, and auth flow, then clearly documented the endpoints so my collaborator could build the frontend against them without constant back-and-forth. It reinforced how much clear communication and shared documentation matter even in small teams.

I genuinely welcome it — and I mean that practically, not just as an interview answer. When I get feedback on my code or my work, my first instinct is to understand the reasoning behind the critique before reacting. Sometimes the feedback points to something I missed; sometimes it reveals a gap in my knowledge that I didn't know existed.

For example, when I've had code reviewed and been told my approach was suboptimal, I go back, research the better pattern, and reimplement. The goal isn't to defend what I did — it's to improve. Ego is expensive in software development.

During one of my projects, I had planned to use a specific library for state management in React. Midway through, I found that the library had compatibility issues with the version of React I was using, and switching versions would break other dependencies.

Rather than forcing it, I pivoted to a simpler, native solution using React's built-in Context API, which actually turned out to be lighter and more maintainable for the project's scale. That experience reinforced something I believe strongly: attachment to tools over outcomes is a trap. The goal is always the working product, not the original plan.

Strengths: I'm a strong problem-solver — 145+ LeetCode problems have built real algorithmic instincts in me. I'm also a planning-first thinker; I rarely jump into code without a clear mental model of the system, which reduces wasted effort. And I'm genuinely self-driven — most of what I know technically, I taught myself outside of class.

Area for improvement: I sometimes over-engineer solutions early on, spending too much time on architecture before validating whether the approach works. I'm actively working on this by building MVPs first and iterating — my current bill splitter project follows that model deliberately.

I follow a combination of curated sources and active practice. For news and trends, I keep track of developments through developer communities, tech blogs, and YouTube channels focused on software engineering and AI. For staying sharp technically, I work on LeetCode problems consistently and build personal projects that force me to use new tools.

I'm currently paying close attention to the AI/ML space — specifically how large language models are being integrated into applications and what Python-based ML tooling is emerging. That's the field I'm building toward, so I treat staying informed as part of the work, not an optional extra.

When explaining the backend architecture of ChatZee to a friend who wanted to understand how it worked but had no technical background, I had to translate concepts like API calls, async requests, and server responses into something intuitive.

I used a restaurant analogy: the frontend is the customer, the backend is the kitchen, the AI API is a specialist chef we call in for specific dishes, and the server is the waiter managing orders. Once that model clicked, they understood why response delays happened and why error handling mattered. Abstraction over jargon — that's my default when communicating technical complexity.

What excites me most is the opportunity to work on real systems that have real users — not academic exercises. The chance to contribute to [specific responsibility from job description] is directly relevant to what I'm building toward as a developer.

I'm particularly drawn to roles that involve backend logic, system design, or data — those are the areas where I feel most at home and where I believe I can add immediate value while growing at the same time.

I start by making sure I actually understand their approach before disagreeing — sometimes what looks like a wrong decision has context I'm missing. If after understanding it I still disagree, I raise it directly but constructively: "I see where you're coming from, but here's a concern I have and an alternative I think might work better."

If we can't reach agreement, I defer to whoever has more context or authority on that decision — and I commit fully to the agreed approach. Disagreeing respectfully and then executing well is more valuable than being right and creating friction.

While building ChatZee, there was a point where the project could've gone in two very different directions — a simple chatbot or a more robust, session-aware AI application. No one was telling me which to build; I had to make the call myself.

I chose the more ambitious route, planned the architecture end-to-end before writing code, and executed it phase by phase. When I hit blockers — like API rate limiting or async bugs — I resolved them without abandoning the original vision. The app shipped working and stable. Leadership for me is about taking ownership of outcomes, not just tasks.

Three things set me apart. First, I'm not just a student who knows theory — I've shipped real projects. StickyBits, ChatZee, and an actively growing bill splitter application. I build things that work.

Second, I'm a problem-first thinker. I don't reach for tools or code until I understand the problem clearly. That means less rework and more intentional solutions. And third, I'm genuinely invested in growing — not just in this role, but as an engineer. I'm building toward AI and Data Science, which means I bring curiosity and long-term motivation that goes beyond collecting a paycheck. You'd be hiring someone who will still be learning aggressively three years from now.

In five years, I see myself working as an AI or Data Science engineer — someone who can build intelligent systems, not just integrate APIs. The path I'm on right now — MERN stack development, strong fundamentals, algorithm practice — is the foundation. The next layer is Python, machine learning, and applied AI engineering.

This role is part of that journey. The experience of working in a professional environment, shipping real products, and collaborating with senior engineers will accelerate my growth in ways that university alone can't provide. I'm not in a hurry — I want to do each phase well — but the direction is clear.

Yes — I have a few.

1. What does the day-to-day look like for someone in this role in the first month? I want to understand how I'd be expected to contribute from the start.

2. What does growth look like here — are there opportunities to take on more technical responsibility over time?

3. What's the biggest challenge the team is currently working through? I like to know what I might actually be walking into.

4. What do people who succeed in this role have in common?