Volvo Cars Full Stack Developer Interview Experience (Selected)

Rajesh Suryawanshi

Published : 22 May 2026

17 Views

#interview

#interview-experience

#interview-preparation

#technical-interview

#interview-questions

3 Rounds of SQL, Java, Web Fundamentals, Project Discussions and Real Engineering Conversations

Recently, I went through the interview process for the Full Stack Developer role at Volvo Cars and I thought it would be useful to share the complete experience because the interview process felt very different from the typical solve hard DSA problems for hours kind of interviews many of us usually prepare for.

What I personally liked about the process was that the interviewers were more focused on understanding how well I actually knew software engineering fundamentals instead of trying to make the interview unnecessarily difficult. The discussions revolved around SQL, Java, JavaScript, TypeScript, debugging thought process, project understanding and how I work in real development environments.

The complete process had three rounds conducted remotely over roughly one to two weeks and thankfully, I was able to clear all the rounds and receive the offer.

One thing I realized after this interview is that many companies are slowly moving away from purely competitive-programming-based hiring. Instead, they want engineers who can genuinely understand systems, write maintainable code, communicate clearly and solve practical problems in production environments. So in this article, I’ll share:

the complete interview flow,
the questions I was asked,
what the interviewers seemed to evaluate,
mistakes candidates usually make,
and how I think one should prepare for similar full stack interviews.

Initial Thoughts Before the Interview

Before the interview started, I honestly expected at least one hardcore DSA round because that has become almost standard across product companies. I revised arrays, trees, graphs, DP and all the usual topics expecting multiple coding rounds. But the actual process turned out to be much more focused on fundamentals and practical engineering discussions.

That does not mean the interview was easy. In fact, interviews based on fundamentals can sometimes feel harder because you cannot rely on memorized patterns. If someone asks:

how Java Garbage Collection actually works,
why HashMap behaves differently from LinkedHashMap,
how the JavaScript event loop works internally,
or how recursive CTEs behave in SQL,

you need real understanding rather than memorized interview answers. That was probably the biggest learning from this experience.

Round 1: Online Assessment

The first round was an Online Assessment consisting of MCQs divided into three sections: Programming Language, Web Fundamentals and Database/DBMS concepts. Each section had around twelve questions.

Initially, when I heard MCQ round, I assumed it would be simple. But once the test started, I realized the questions were designed to check conceptual understanding very carefully.

The programming section mostly focused on language fundamentals, syntax behavior, object-oriented concepts and implementation understanding. The web fundamentals section covered browser-related concepts, JavaScript behavior, asynchronous execution, frontend basics and API-related understanding. The database section focused heavily on SQL concepts, joins, normalization, indexing and DBMS fundamentals.

What made this round tricky was that there was no room for partial correctness. Either you clearly understood the concept or you lost the mark immediately. I remember some questions being deceptively simple. They looked easy at first glance, but the options were intentionally confusing to test whether you actually understood the behavior internally.

That is something many candidates underestimate. A lot of people prepare only by watching interview-crack videos or memorizing shortcuts. But in rounds like this, shallow preparation becomes very visible.

Several engineers who shared their experiences with Volvo interviews online also mentioned that the company places strong emphasis on software fundamentals and practical technical understanding rather than only competitive coding.

Waiting Period After the Assessment

After the assessment, there was a short waiting period before the next round got scheduled. Honestly, during this phase, I kept overthinking every question I attempted in the MCQ round. I think most candidates do this after interviews. You start remembering the questions you were unsure about and assume the worst.

But one thing I’ve learned from interviews over time is that companies do not always expect perfection. Sometimes they are evaluating overall understanding, confidence and consistency more than absolute scores.

A few days later, I received the invitation for the technical discussion round.

Round 2: Technical Interview

This was the main technical round and probably the most important part of the entire process. The interview started with introductions and discussion around my current role, daily responsibilities and projects I had worked on. The interviewers were friendly, but they were clearly trying to understand whether I genuinely understood the systems I had mentioned on my resume.

One thing I noticed throughout the conversation was that the interviewers kept asking follow-up questions continuously. They were not satisfied with textbook answers. They wanted practical understanding. The round mainly covered:

SQL,
Java,
JavaScript,
TypeScript,
and web fundamentals.
SQL Questions and Discussion

The SQL section was much deeper than I expected. One of the first questions was writing a query to find the third-highest salary without using LIMIT.

This is a very common interview question, but what I realized during the discussion is that interviewers care less about memorized queries and more about understanding different approaches. I explained multiple solutions including: subqueries, dense ranking and window functions.

The interviewer seemed more interested in understanding whether I knew:

handling duplicates,
optimization trade-offs,
and query readability.

Then we discussed the difference between: SELF JOIN, CROSS JOIN and NATURAL JOIN.

Again, the discussion was very practical. Instead of only defining them, I explained:

where SELF JOIN is useful,
why CROSS JOIN can explode result size,
and why NATURAL JOIN can sometimes become risky in production systems because it automatically matches columns.

The interviewer then moved toward CTEs and hierarchical queries. This part was actually interesting because we discussed how recursive CTEs are useful for:

employee-manager hierarchies,
category trees,
and nested organizational structures.

I could feel that the interviewer was evaluating whether I had practical SQL exposure rather than only academic knowledge. Other SQL questions included:

finding employees who joined in the last six months,
and identifying departments with more than ten employees.

These questions were straightforward logically, but the interviewer was watching:

query structure,
aggregation handling,
date filtering,
and clarity of explanation.

One important thing I noticed during this interview is that SQL still matters a lot in backend and full stack interviews. Many candidates focus entirely on DSA and neglect SQL preparation, which becomes a huge weakness later.

Java Questions

The Java section was focused heavily on object-oriented programming, collections, runtime behavior and memory management.

One of the first questions was: abstract class vs interface.

Instead of giving textbook definitions, I tried explaining with practical examples:

when abstract classes make sense,
when interfaces provide better flexibility,
and how Java interfaces evolved after default methods were introduced.

The interviewer seemed to appreciate practical reasoning more than memorized points.

Next came: HashMap vs LinkedHashMap.

We discussed: insertion order, hashing, performance and internal implementation behavior.

Then the interviewer asked about Java Reflection API.

This was slightly advanced compared to the earlier questions. I explained how reflection allows runtime inspection and dynamic behavior and I mentioned practical use cases such as: dependency injection frameworks, annotations and dynamic class loading.

After that, we had a discussion around Garbage Collection. This was less about definitions and more about internal understanding.

The interviewer wanted to know whether I actually understood: heap memory, object lifecycle, generations and why memory leaks can still happen even with automatic garbage collection.

Then came one of the classic Java questions: difference between ==, .equals() and .hashCode().

What I’ve noticed in interviews is that even simple-looking Java questions can become difficult because interviewers keep digging deeper into implementation behavior.

JavaScript and TypeScript Questions

The JavaScript section was one of the most discussion-heavy parts of the interview.

One question involved race conditions with Promises. We discussed asynchronous behavior, execution order and handling multiple concurrent requests safely.

Then we moved into: var, let and const.

This question sounds basic, but interviewers often use it to explore: scope, hoisting, temporal dead zone and immutability behavior.

I was also asked a few output prediction questions involving asynchronous execution. These questions are difficult if someone only memorizes syntax without understanding: closures, Promise execution, event queues and runtime behavior.

The event loop discussion went quite deep. We talked about: call stack, task queue, microtasks, macrotasks and Promise prioritization.

The final frontend-related topic involved: any, unknown and never in TypeScript. I explained why unknown is safer than any and how never represents unreachable states or impossible values.

One thing I genuinely appreciated in this round was that the discussion felt very engineering-oriented rather than puzzle-oriented. The interviewers were trying to understand: How well does this person actually understand software development? That made the conversation much more natural.

Round 3: Final Discussion Round

The third round was conducted by two interviewers and was more conversational compared to the technical round. The discussion revolved around: my daily workflow, coding practices, software design thinking, debugging approach, collaboration and project experience.

This round honestly felt more like a real engineering conversation than an interview. The interviewers asked:

how I approach code reviews,
how I handle production issues,
how I debug failures,
and how I structure development tasks.

Then we discussed my past projects in detail. This is one area where I think many candidates struggle. People often add technologies and projects to resumes but cannot explain:

architecture decisions,
scalability considerations,
trade-offs,
or implementation details deeply.

The interviewers kept asking follow-up questions around:

why certain approaches were chosen,
what challenges occurred,
and how problems were solved.

This round made me realize something important: companies are increasingly evaluating whether candidates can work effectively inside real engineering teams, not just whether they can solve interview problems.

What I Think Helped Me During the Process

Looking back, I think a few things genuinely helped me.

The first was strong fundamentals. Instead of preparing only interview patterns, I spent time understanding: Java internals, SQL behavior, JavaScript execution and practical software engineering concepts.
Second, I tried keeping my explanations conversational rather than robotic. Interviewers usually know when answers are memorized. Practical explanations with examples feel much more natural.
Third, I knew my projects deeply. That helped a lot during project discussions because I could explain: design decisions, optimizations, architecture and technical trade-offs confidently.

My Advice for Candidates Preparing for Similar Interviews

If you are preparing for Full Stack Developer interviews at companies like Volvo Cars, I would strongly recommend focusing on engineering fundamentals rather than only grinding DSA endlessly.

SQL preparation is extremely important. You should be comfortable with: joins, subqueries, window functions, CTEs, aggregations and practical query-writing.
For Java, focus heavily on: OOP concepts, collections, memory management, multithreading basics, and runtime behavior.
For frontend preparation, understand: asynchronous JavaScript, event loop, Promises, closures, browser behavior and TypeScript fundamentals.
Most importantly, understand your own projects deeply. Many interviews are won or lost during project discussions.

Overall, the Volvo Cars interview experience felt practical, balanced and engineering-focused. What I appreciated most was that the interviewers were trying to evaluate whether I could function effectively as a software engineer in real-world environments rather than simply testing how many competitive programming tricks I had memorized. The process focused on:

fundamentals,
communication,
practical thinking,
debugging mindset
and project understanding.

For me personally, this interview reinforced an important lesson: Strong engineering fundamentals and clear understanding of real software development concepts are still incredibly valuable, even in a world where many candidates focus only on solving coding problems endlessly.