The Card Company | Software Engineer - Backend (SDE 1) | Interview Experience | On-Site

the card company logo
the card company
Software Engineer - Backend (SDE 1)Ongoing
November 11, 202517 reads

Summary

I interviewed for a Software Engineer - Backend (SDE 1) role at The Card Company, undergoing two rounds that covered Java fundamentals, DSA, and complex System Design scenarios. I am currently awaiting the outcome of my application.

Full Experience

I recently had my interview experience at The Card Company, formerly known as FYP, for a Software Engineer - Backend (SDE 1) position. The process involved two distinct rounds, each lasting approximately an hour.

Round 1 – Java + Data Structures & Algorithms

This round began with a rapid-fire series of Java-based questions. The interviewer probed my understanding of core Java and Spring Boot concepts. We discussed topics such as:

  • How to handle exceptions globally in a Spring Boot application.
  • The possibility of skipping a finally block and returning directly from a try block.
  • An explanation of Java Streams and their utility.
  • The differences and appropriate use cases for @Service, @Controller, and @Component annotations in Spring.
  • A comparison between ArrayList and LinkedList, highlighting their underlying data structures and performance characteristics.
  • What database indexing is and how it fundamentally works to improve query performance.

Following these conceptual questions, I was presented with one Data Structures and Algorithms problem: First Unique Character in a String. I had to solve this problem, which typically involves using a hash map to track character frequencies.

Round 2 – System Design

The second round was focused entirely on System Design. It started with a High-Level Design discussion for a Notification System. Based on this, the interviewer asked several follow-up questions:

  • How I would ensure that each notification is sent exactly once to each user, a common challenge in distributed systems.
  • Which design pattern I would consider applying in this particular notification system scenario to achieve robustness and scalability.
  • Strategies for handling time-based or scheduled notifications effectively.

After the notification system discussion, a new scenario was introduced: an Order Service interacting with three other microservices – Payments, Inventory, and Receipt Generation. The core problem was to describe how I would handle situations where the payment fails. This included explaining how to manage partial updates, address money deductions, and implement rollback scenarios to maintain data consistency across all involved microservices, likely touching upon concepts like distributed transactions or sagas.

I am currently awaiting the verdict on my interview performance.

Interview Questions (11)

Q1
Global Exception Handling in Spring Boot
Other

How do you handle exceptions globally in a Spring Boot application?

Q2
Skipping Finally Block and Returning from Try
Other

Can we skip finally block and return from the try block?

Q3
What are Java Streams?
Other

What is Java Streams.

Q4
Spring Annotations: @Service, @Controller, @Component
Other

Difference between @Service, @Controller, and @Component annotations?

Q5
ArrayList vs LinkedList
Data Structures & Algorithms

Difference between ArrayList and LinkedList?

Q6
Database Indexing
Other

What is indexing in databases, and how does it work?

Q7
First Unique Character in a String
Data Structures & AlgorithmsEasy

Given a string s, find the first non-repeating character in it and return its index. If it does not exist, return -1.

Q8
Exactly-Once Notification Delivery
System Design

How would you ensure that each notification is sent exactly once to each user in a notification system?

Q9
Design Pattern for Notification System
System Design

Considering the notification system scenario, which design pattern would you apply?

Q10
Handling Scheduled Notifications
System Design

How would you handle time based or scheduled notifications?

Q11
Microservice Transaction Rollback for Order Service
System Design

You have an Order Service that interacts with three microservices - Payments, Inventory, and Receipt Generation. If the payment fails, how would you handle partial updates, money deduction, and rollback scenarios to maintain consistency?

Discussion (0)

Share your thoughts and ask questions

Join the Discussion

Sign in with Google to share your thoughts and ask questions

No comments yet

Be the first to share your thoughts and start the discussion!