My Vegapay Backend Engineer (SDE 2) Interview Experience (Rejected)

Lana Rose

Published : 22 May 2026

23 Views

#interview-experience

#interview-preparation

#technical-interview

#experienced-candidate-interview

#interview-questions

Interview Focused on Problem Solving, Low Level Design, Scalability and Real System Thinking.

Recently, I interviewed for the Backend Engineer (SDE 2) role at Vegapay and honestly, this was one of the most technically demanding backend interview processes I have faced in a while. The process was not extremely long in terms of rounds, but the depth of technical expectations made it genuinely challenging. Unlike interviews where companies mainly focus on solving random DSA problems, this process tested a combination of coding ability, backend engineering fundamentals, scalability thinking and system design maturity.

The complete process consisted of two remote rounds conducted over roughly one to two weeks. Even though I eventually got rejected, I still feel the experience was extremely valuable because it exposed several important gaps in my Low Level Design preparation and highlighted the kind of thinking strong product companies now expect from backend engineers.

One thing I appreciated throughout the process was that the interviewers were technically strong but supportive. The rounds were definitely difficult, but the interviewers were not trying to create unnecessary pressure. Instead, they seemed genuinely interested in understanding how I think, how I reason through problems and whether I can design scalable backend systems under realistic constraints.

What became very clear during this process is that companies like Vegapay expect backend engineers to think much beyond writing APIs or solving coding questions. They are looking for engineers who understand scalability, reliability, architecture trade-offs, distributed systems and production-grade backend design. Several publicly shared Vegapay interview experiences also mention that the company places strong emphasis on design-oriented backend thinking rather than only traditional DSA rounds.

Before the Interview: What I Expected vs What Actually Happened

Before the interview started, I prepared mainly around:

medium-level DSA problems,
backend fundamentals,
Java concepts,
system design basics,
and common coding patterns.

Since the role was Backend Engineer (SDE 2), I expected a combination of coding and some high-level design discussions. But I underestimated how deeply the interview process would focus on system-level reasoning and Low Level Design thinking.

One important realization I had after the process is that backend interviews today are changing rapidly. Earlier, many companies mainly evaluated coding ability and maybe some database concepts. But now, especially in product-based startups and fintech companies, backend interviews increasingly focus on:

scalability,
distributed systems,
concurrency,
backend workflows,
API contracts,
reliability,
and production-grade architecture thinking.

This trend is becoming especially visible across fintech engineering interviews where companies prioritize correctness, scalability, resilience and high-throughput backend systems. Discussions across backend engineering communities also show that payment and fintech companies increasingly evaluate candidates on architecture maturity and defensive engineering thinking. That became extremely obvious during the Vegapay process.

Round 1: Coding + Problem Solving Discussion

The first round started in a fairly relaxed way. The interviewer began with introductions and asked about my day-to-day responsibilities, current projects, backend exposure and the overall scope of work I handle in my current role.

What I liked was that the interviewer was genuinely interested in understanding practical engineering exposure before jumping into coding questions. We discussed:

backend services,
APIs,
scaling considerations,
debugging,
and project ownership.

After the introductory discussion, the interviewer moved toward the coding problem:

Validate Parentheses String with Wildcards.

At first glance, the problem looked familiar because I had solved the simpler version earlier where only standard parentheses balancing logic is involved. I explained the straightforward stack-based solution for the easier variant and walked the interviewer through my thought process carefully. But then the wildcard constraint completely changed the nature of the problem.

The interviewer wanted me not only to solve the simpler version but also to extend the logic properly for wildcard handling. That required significantly more reasoning because the wildcard character could behave as:

opening bracket,
closing bracket,
or empty string.

The challenge became even harder because I was not allowed to use a code editor or execute the code. Everything had to be written directly inside Google Docs without compilation, autocomplete, syntax highlighting or runtime validation.

Honestly, that changed the difficulty level significantly. Writing code inside an actual IDE allows small mistakes to get caught quickly. But writing logic directly into a plain document forces you to think much more carefully about: edge cases, syntax, variable flow and correctness.

Initially, I struggled to arrive at a complete solution for the wildcard handling part. There were moments where I genuinely felt stuck because multiple edge cases started appearing while reasoning through different scenarios. But one thing I appreciated was that the interviewer remained patient throughout the discussion. Instead of interrupting aggressively or rushing me, he allowed me time to think through the problem calmly. That support helped a lot psychologically.

Eventually, I managed to reason through the problem and arrive at a correct approach. The discussion became less about memorized coding patterns and more about logical reasoning, edge-case handling and problem-solving mindset. That is something many candidates underestimate in backend interviews.

Often, interviewers are not just checking whether you already know the exact problem. They are evaluating:

how you behave under uncertainty,
how you approach complexity,
how you communicate reasoning,
and whether you can recover when stuck.

By the end of the round, I felt the discussion was challenging but positive overall and thankfully, I was able to clear it.

Questions Asked in Round 1

Validate Parentheses String with Wildcards
Discussion around extending simpler solutions
Edge-case handling
Logical reasoning without code execution
Day-to-day backend responsibilities
Project and system discussions

What Made the First Round Difficult

Looking back now, the hardest part of Round 1 was not actually the coding problem itself. The real challenge was:

writing code without execution,
reasoning under pressure,
handling edge cases live,
and maintaining structured communication while thinking.

Many candidates prepare by solving problems inside IDEs with compiler support, but interviews like this expose whether you truly understand the logic deeply enough to reason without execution support.

Another important observation was that the interviewer continuously focused on thought process rather than rushing toward the final answer. This is something I’ve increasingly noticed in strong backend interviews. Companies are less interested in memorized patterns and more interested in how engineers think when facing uncertainty.

Round 2: Low Level Design (LLD) Interview

The second round was where the interview became significantly more difficult. This round started with introductions and soon after that, the interviewer presented a Low Level Design problem involving a VOIP calling platform.

The task was to design a backend system with features such as:

VOIP calling between users,
call routing,
call forwarding,
and per-second billing.

At first, the problem sounded manageable because I had prepared some High Level Design concepts earlier. But very quickly, the discussion started becoming much deeper and much more implementation-oriented than I expected.

The interviewer also provided non-functional requirements including:

50 million daily active users,
2 million peak concurrent users,
latency below 100 milliseconds,
high scalability,
high availability,
and SaaS-level reliability.

The moment those constraints entered the discussion, I realized this was not going to remain a simple architecture conversation. This was a real backend systems design interview.

Where I Struggled During the Design Round

To be completely honest, this round exposed one of my biggest preparation gaps: Low Level Design.

I was relatively comfortable discussing High Level Design concepts such as:

load balancers,
microservices,
caching,
distributed systems,
and scaling strategies.

But the interviewer wanted much more detailed backend reasoning. He expected discussions around:

object interactions,
service boundaries,
workflows,
backend contracts,
concurrency,
billing flow,
call session lifecycle,
and component-level implementation details.

That is where I struggled. I could explain the broader architecture, but breaking it down into a proper Low Level Design became difficult because I had not practiced enough real LLD scenarios earlier.

Another thing that added to the difficulty was the use of Excalidraw during the interview. I had almost no prior experience using Excalidraw for live design discussions.

That may sound like a small issue, but during system design interviews, unfamiliarity with whiteboarding tools can genuinely affect performance because:

organizing diagrams becomes slower,
modifying flows becomes awkward,
and expressing ideas visually takes more effort.

Instead of focusing entirely on the design itself, part of my attention kept going toward managing the interface and structuring diagrams properly. That created additional friction during the discussion.

As the interview progressed, I realized the interviewer was evaluating:

backend architecture maturity,
system modeling ability,
scalability understanding,
real-time system workflows,
and implementation-level thinking.

Unfortunately, I was not able to structure the Low Level Design discussion effectively enough.

The Most Important Learning From This Interview

This interview taught me something extremely important about backend engineering interviews today. For SDE 2 and mid-level backend roles, companies increasingly expect candidates to possess:

coding ability,
system design understanding,
and Low Level Design maturity simultaneously.

Being good at DSA alone is no longer enough. Especially in fintech and backend-heavy companies, interviewers increasingly evaluate:

scalability,
backend workflows,
concurrency,
fault tolerance,
API contracts,
data consistency,
and reliability under heavy load.

This trend is visible across many backend interview experiences shared online where companies focus heavily on design-oriented engineering rather than only competitive programming.

The interview also made me realize that many candidates prepare High Level Design superficially without practicing actual Low Level Design deeply enough.

There is a huge difference between saying: Use microservices and Kafka versus actually designing:

service interactions,
entities,
workflows,
retry behavior,
billing logic,
concurrency handling,
and communication patterns.

That difference became painfully obvious during this round.

Topics Discussed in Round 2

VOIP calling platform design
Call routing
Call forwarding
Per-second billing
Scalability for 50M DAU
Handling 2M concurrent users
Latency optimization
SaaS architecture
Availability and reliability
Backend workflows
Low Level Design concepts
Excalidraw-based system design discussion

What I Would Prepare Differently Now

After this interview, I completely changed how I approach backend interview preparation. Earlier, most of my preparation focused on: DSA, frameworks, APIs and basic system design concepts. But now I realize backend interviews require much deeper engineering preparation.

If I were preparing again for similar interviews, I would spend significantly more time on:

Low Level Design,
backend workflows,
concurrency handling,
distributed systems,
real-time systems,
event-driven architecture,
and fintech-related backend design patterns.

I would also practice designing systems visually using tools like: Excalidraw, Draw.io or Miro.

Because during live design interviews, comfort with the whiteboarding tool itself matters much more than people realize.

My Advice for Backend Engineers Preparing for Similar Interviews

If you are targeting backend or SDE 2 roles at companies like Vegapay, do not focus only on LeetCode. Coding rounds are important, but increasingly, the real filtering happens during system design and Low Level Design discussions.

Strong preparation should include:

medium-level DSA patterns,
backend architecture fundamentals,
API design,
concurrency concepts,
caching,
database design,
distributed systems,
and detailed LLD practice.

Most importantly, practice explaining your thought process clearly. Many interviewers evaluate:

how structured your thinking is,
how calmly you handle uncertainty,
and whether you can reason through trade-offs logically.

And one more important thing: practice system design discussions on whiteboarding tools. That sounds minor initially, but it genuinely affects interview performance during live collaborative design rounds.

Final Thoughts

Overall, even though I received a rejection, I genuinely consider the Vegapay Backend Engineer interview experience extremely valuable. The process was technically challenging, realistic and heavily focused on practical backend engineering rather than artificial puzzle-solving. What I appreciated most was that the interviewers consistently evaluated:

reasoning ability,
backend fundamentals,
scalability thinking,
design maturity,
and engineering depth.

For me personally, this interview reinforced one very important reality about modern backend engineering interviews: Strong coding ability might help you enter the conversation, but real backend engineering maturity is often what determines whether you clear the final rounds.