Optimus Solutions SDE Intern Interview Experience — OOPS, SQL, DSA, Projects | Not Selected

I Didn't Get Selected at Optimus Solutions. Here's the Full Interview Experience.

Girls-Only Hiring Drive | Noida

• Company: Optimus Solutions
• Role: SDE Intern
• Drive: Girls-Only Drive
• Location: Noida
• Mode: In-person
• Shortlist: 16 girls out of 207 girls
• Duration: ~40-45 minutes
• Result: Not Selected

207 gave the OA. 16 got shortlisted. I was one of the 16.

I still didn't get selected.

I almost didn't write this, because rejection posts feel weird to publish. But the interview experiences that helped me most were never the polished ones. They were the honest ones, where someone said what was actually asked and where they messed up. So here's mine, mistakes and all.

Also, this is a note to future me. One day I want to look back and see exactly where I started.

16 out of 207

That shortlist message? Best feeling. I won't pretend otherwise.

Then reality landed: this was my first proper in-person interview, and it was outside Jaipur. New city, new office, new everything.

I was excited. I was also very nervous, and the nervous part definitely showed up. There were things I knew, really knew, and the moment someone said "explain it" or "write the code, right now," my brain handed me a silly mistake instead.

Spoiler: that became the theme of the day.

40 minutes, one pattern

The interview ran about 40-45 minutes and covered OOPS, DBMS, SQL, DSA, my resume, my projects, and one situational question.

What I didn't see coming was the pattern. Nothing stopped at the first answer. It kept going like this:

Concept -> Follow-up -> Example -> Code -> Another follow-up

A definition only got me through the first step. After that, he was testing whether I actually understood.

OOPS: I knew it. My hands didn't.

We started with the four pillars: encapsulation, abstraction, inheritance, polymorphism. Then he wanted real understanding and real code.

And here's the line I'll remember from this whole experience:

Knowing something while studying and explaining it in an interview are two completely different skills.

I knew operator overloading. I had studied it. But when he asked me to explain it, the words wouldn't line up. That one stung, because it wasn't a topic I'd skipped. It was right there in my head and just wouldn't come out clearly.

Then he asked for code, and I couldn't write these correctly:

• Function overriding
• Virtual function
• Abstract keyword / abstraction-based implementation

None of these were new. I'd read them, understood them, nodded along in my notes. But writing them live, with someone watching, was a whole different game.

Friend function came up too: what it is, why it exists, how it accesses a class's members. He wanted the why, not a textbook line.

And the virtual function moment sums up my day:

"I know this, but I couldn't show it under pressure."

Looking back, my studying was too comfortable. I read and recognized things. I didn't do enough active recall or handwritten coding.

DBMS: ACID, but make it a scenario

The big topic was ACID properties: atomicity, consistency, isolation, durability.

But he didn't ask "what is ACID?" and move on. He gave me imaginary situations and asked, "okay, what happens here?" So I had to apply it, not recite it.

I actually liked this. It showed me DBMS has to be prepared through real scenarios. A definition alone doesn't survive one.

SQL: 2 out of 5

He gave me 5 SQL questions. I solved 2.

No excuses. I know SQL syntax, but solving queries quickly in front of someone is its own skill, and I clearly haven't trained it enough. Understanding something and feeling good about it is not the same as solving it live.

DSA: same problems, different game

Here's what we covered:

1. N-Queens. Approach and implementation. Recursion, backtracking, reasoning about constraints.

2. Two Sum with hashing. Picking the right data structure.

3. 3Sum. Sorting, two pointers, duplicate handling, complexity.

4. Modified 3Sum: find and count the triplets. My favorite follow-up. He took a problem I knew and changed one requirement. That's the moment you realize you can't just memorize the standard solution. You have to understand why it works, because the question can change anytime.

My biggest mistake of the whole interview

This one wasn't about forgetting syntax. It was about how I approached every single DSA question.

In all of them, I jumped straight to the optimal solution. I thought that was the smart move. Why waste time on brute force when I already know the best approach?

But that's not what he wanted. He wanted to see me start with brute force and climb to the optimal approach: here's the simple idea, here's why it's slow, here's what I can improve, and here's how I get there.

I only realized this when I got my feedback. It pointed out exactly this.

Jumping to the answer shows what I remember. Walking from brute to optimal shows how I think. And thinking is what an interviewer is actually hiring.

The one where I felt like myself

There was one situational UI question, and I answered it quite well.

After a lot of definitions and syntax, here was a question about how I'd think through a UI/product situation and what I'd do. Nothing to recall. Just reasoning. For those few minutes I felt completely in my element.

It reminded me that interviews aren't only about memorizing CS concepts. Problem-solving and reasoning matter a lot too.

He opened my project on his phone

Both projects on my resume were deployed.

And the interviewer opened them on his phone. Live. In the interview.

He didn't say "tell me about your project" and lean back. He looked at what I'd actually built and asked about whatever he saw:

• Features and how they work
• Implementation
• Technologies used, and why those ones
• How the parts connect
• What exactly my contribution was
• The technical decisions I made

The lesson is simple:

If a project is on your resume, be ready to defend every part of it.

Especially if it's deployed. Someone can literally pick up a phone and start asking.

"Maybe this worked out."

That's what I thought walking out.

Forty-plus minutes, projects discussed, DSA problems worked through, a lot of the technical discussion handled, and a few moments where I felt genuinely confident.

Then I found out I wasn't selected. And later I learned that nobody from my college was selected in this drive either.

That was a little heavy. I'd put in the effort, I travelled for it, and I really believed I had a chance.

But this isn't just a rejection story

Look at what it actually was: my first proper in-person interview, and my first interview outside Jaipur.

I made silly mistakes. I froze on things I know. I couldn't explain operator overloading. I couldn't write overriding, virtual functions, or abstract implementations. I solved 2/5 SQL questions. And in DSA, I skipped the thinking and jumped straight to optimal answers.

That's a long list. But it's also a clear list. I don't have to guess where I'm weak anymore, and that's worth a lot.

What I'm taking home

1. Don't jump to the optimal solution. Show the journey. Start with brute force, say why it's slow, then improve it step by step. They want to see how you think, not only what you remember. This was my biggest mistake.

2. Knowing ≠ being able to explain. Study a topic ten times, and you can still freeze if you've never said it out loud or written the code from scratch.

3. Write the fundamentals by hand. OOPS, inheritance, overloading, overriding, virtual functions, abstract classes, friend functions. On paper, in the editor, without notes.

4. SQL needs real reps. Understanding isn't enough. I need to get faster at solving queries.

5. Learn the pattern, not the solution. Requirements can change mid-interview. I want to understand a solution well enough to bend it.

6. Your projects will be questioned. Especially deployed ones. Don't list something just because it looks good. Be ready to explain it end to end.

Final thoughts

I didn't get selected at Optimus Solutions, and yes, I was disappointed.

But I came back with something I didn't have before: a clear picture of what to work on. This interview showed me gaps I'd never have found studying alone. Maybe that's exactly what I needed.

First in-person interview. First interview outside Jaipur. Nerves, silly mistakes, some things I nailed, some I couldn't answer, and some I knew but couldn't show.

That's the real story, and I'm okay sharing it.

I’m still learning, still improving, still showing up.

And I'm really hoping that before the end of 2026, I get to write an interview experience that ends with "SELECTED."

Until then, back to prep.