My Rupeek SDE 3 Round 1 Interview Experience
Recently, I appeared for the Round 1 technical interview for an SDE 3 role at Rupeek and I thought it would be useful to share the experience in detail because the round was much more practical and discussion-oriented than I expected.
The interview mainly focused on problem-solving, optimization thinking, edge cases and how confidently I could explain my reasoning while coding in Java. The interviewer was not just checking whether I could solve the problem. He was continuously evaluating how I approached the solution, how I handled mistakes and whether I could optimize the code step by step.
The complete round felt closer to a real engineering discussion rather than a competitive programming session.
Two coding questions were discussed during the interview:
- Coin Change Problem
- Trapping Rain Water Problem
Both are popular DSA questions, but in an interview environment, the challenge is not only writing code. The real challenge is explaining the logic clearly while maintaining confidence under pressure.
Problem 1 : Coin Change
The first question was based on Dynamic Programming.
You are given an integer array of coins representing coins of different denominations and an integer amount representing a total amount of money. Return the fewest number of coins needed to make up that amount. If that amount of money cannot be made up by any combination of the coins, return -1.
You may assume that you have an infinite number of each kind of coin.
Example 1
Input: coins = [1,2,5], amount = 11
Output: 3
Explanation:
11 = 5 + 5 + 1
Example 2
Input: coins = [2], amount = 3
Output: -1
Example 3
Input: coins = [1], amount = 0
Output: 0
My Initial Thought Process
I started with recursion. The basic idea was: For every coin, we have two choices:
- Take the current coin
- Skip the current coin
If we take the coin, the remaining amount reduces. If we skip it, we move to the next coin.
That recursive breakdown naturally leads toward Dynamic Programming because many states start repeating.
My Java Solution
class Main {
static int max = Integer.MAX_VALUE;
static int getMinCoins(int[] arr, int p, int target) {
if (target == 0) {
return 0;
}
if (p < 0) {
return max;
}
if (arr[p] > target) {
return getMinCoins(arr, p - 1, target);
}
int take = getMinCoins(arr, p, target - arr[p]);
if (take != max) {
take = take + 1;
}
int notTake = getMinCoins(arr, p - 1, target);
return Math.min(take, notTake);
}
public static void main(String[] args) {
int[] coins = {1, 2, 5};
int amount = 11;
int result = getMinCoins(coins, coins.length - 1, amount);
System.out.println(result == max ? -1 : result);
}
}
During the interview, one interesting debugging moment happened while solving the problem.
The code was compiling fine, but the output suddenly started showing a very large negative number. Initially, I was confused because the recursive logic looked correct.
After tracing the execution carefully, I realized the issue was caused by integer overflow.
I had directly written:
int take = 1 + getMinCoins(arr, p, target - arr[p]);
For invalid states, the recursive function was returning Integer.MAX_VALUE. So in some cases the calculation became:
1 + Integer.MAX_VALUE
Since Java integers overflow after exceeding their range, the value rotated into a huge negative number, which completely broke the minimum comparison logic. The fix was actually simple. I forgot to add a validation check before incrementing:
int take = getMinCoins(arr, p, target - arr[p]);
if (take != max) {
take = take + 1;
}
Once I added that condition, the solution worked correctly.
The interviewer then asked me to explain why the negative number was appearing, which turned into a discussion around integer overflow, sentinel values and handling invalid states safely.
For me, that was one of the most valuable parts of the interview because it reminded me that senior-level interviews are not just about solving problems. They are also about debugging calmly, identifying root causes logically and explaining technical issues clearly under pressure.
Senior-level interviews are not about writing flawless code instantly. They are more about how you react when something goes wrong. Do you panic? Or do you debug calmly and fix the issue logically? That matters a lot.
Moving Toward Memoization
The interviewer then asked: What is the time complexity of your recursive solution?
The recursive approach was exponential because the same subproblems were getting solved repeatedly. That naturally led to memoization. So I optimized the recursive solution using a DP table.
Memoization Java Solution
import java.util.Arrays;
class Main {
static int INF = Integer.MAX_VALUE;
static int getMinCoins(int[] arr, int p, int target, int[][] dp) {
if (target == 0) {
return 0;
}
if (p < 0) {
return INF;
}
if (dp[p][target] != -1) {
return dp[p][target];
}
int notTake = getMinCoins(arr, p - 1, target, dp);
int take = INF;
if (arr[p] <= target) {
int subResult =
getMinCoins(arr, p, target - arr[p], dp);
if (subResult != INF) {
take = 1 + subResult;
}
}
dp[p][target] = Math.min(take, notTake);
return dp[p][amount];
}
public static void main(String[] args) {
int[] coins = {1, 2, 5};
int amount = 11;
int[][] dp =
new int[coins.length][amount + 1];
for (int[] row : dp) {
Arrays.fill(row, -1);
}
int result =
getMinCoins(
coins,
coins.length - 1,
amount,
dp
);
System.out.println(result == INF ? -1 : result);
}
}
Follow-Up Questions Asked by the Interviewer
After solving the problem, the interviewer started asking conceptual questions.
One thing I noticed during the interview was that solving the problem was only the beginning. Most of the discussion happened after the solution.
Some important follow-up questions were:
Why does greedy fail here?
The interviewer gave this example:
coins = [1,3,4]
amount = 6
Greedy picks:
- 4 + 1 + 1
which uses 3 coins. But the optimal answer is:
- 3 + 3
which uses only 2 coins. That is why Dynamic Programming is required.
What is the space complexity?
For memoization: O(n * amount)
Where:
- n = number of coins
- amount = target amount
Can this be solved using Bottom-Up DP?
Yes. The interviewer expected discussion around tabulation as well.
Problem 2 : Trapping Rain Water
After Dynamic Programming, the interviewer moved to an array-based problem. This was the classic Trapping Rain Water problem.
Given n non-negative integers representing an elevation map where the width of each bar is 1, compute how much water it can trap after raining.
// Example 1
Input:
height = [0,1,0,2,1,0,1,3,2,1,2,1]
- Output: 6
// Example 2
Input:
height = [4,2,0,3,2,5]
- Output: 9
My Approach During the Interview
Before coding, I explained the intuition. The amount of water trapped at any index depends on:
-
min(leftMax, rightMax) - currentHeight
-
Because water can only stay if both sides have taller boundaries.
-
The smaller boundary limits the water level.
Java Solution Using Prefix Maximum Arrays
class Main {
public static void main(String[] args) {
int[] height = {4, 2, 0, 3, 2, 5};
int n = height.length;
int[] leftMax = new int[n];
int[] rightMax = new int[n];
leftMax[0] = height[0];
for (int i = 1; i < n; i++) {
leftMax[i] = Math.max(leftMax[i - 1], height[i]);
}
rightMax[n - 1] = height[n - 1];
for (int i = n - 2; i >= 0; i--) {
rightMax[i] = Math.max(rightMax[i + 1], height[i]);
}
int water = 0;
for (int i = 1; i < n - 1; i++) {
int currentWaterLevel = Math.min(leftMax[i], rightMax[i]);
water += currentWaterLevel - height[i];
}
System.out.println(water);
}
}
Optimization Discussion
Once the solution was completed, the interviewer asked:
Can you optimize the space complexity?
That led to discussion around the two-pointer approach. The optimized solution reduces extra space complexity from: O(n) to O(1)
This was one pattern throughout the interview. The interviewer constantly pushed the discussion beyond the first working solution.
What I Learned From This Round
One thing became very clear after this interview. For SDE 3 interviews, companies are not only testing coding ability. They are evaluating engineering maturity. The interviewer was paying attention to:
- How clearly I explained the logic
- Whether I could discuss trade-offs
- How I handled debugging
- Whether I understood optimization deeply
- How comfortable I was discussing edge cases
The coding questions themselves were standard. The real challenge was the discussion around them.
Final Thoughts
Overall, the Round 1 interview at Rupeek was a really good learning experience. It reminded me that interview preparation should not only focus on solving problems silently. Real interviews require:
- communication
- reasoning
- debugging
- optimization thinking
- and confidence while explaining ideas.
If you are preparing for senior backend or SDE interviews, one thing I would strongly recommend is this: Do not just practice writing solutions. Practice explaining them aloud. Because in real interviews, your thought process matters just as much as your final code.
