Tekion SDE-1 Backend Interview Experience : Complete DSA, Java, Concurrency & System Design Breakdown

Published : 26 May 2026

253 Views

#interview-experience

I recently interviewed for an SDE-1 Backend Engineer role at Tekion and honestly, the process felt much more engineering-focused than a typical coding-heavy interview loop. Before attending the interviews, I assumed most rounds would revolve around solving DSA problems quickly. But after going through the complete process, I realized Tekion evaluates candidates much more deeply. The interviewers were constantly trying to understand:

how I think through problems
how I explain trade-offs
how comfortable I am with backend engineering concepts
whether I can design scalable systems
and how I behave under pressure situations

The process lasted around one to two weeks and consisted of four rounds. Even though I was eventually rejected, the experience itself taught me a lot about how strong backend-focused product companies evaluate engineers today. Many discussions felt closer to real engineering conversations than traditional interview-style question-answer sessions.

Interview Process Overview

Round	Focus Area
Round 1	Online Assessment (3 DSA Problems)
Round 2	Bar Raiser – Problem Solving + Logical Thinking
Round 3	Java + Mockito + Elevator System Design
Round 4	Java Concurrency + Behavioral Discussion

The overall difficulty level was medium, but the follow-up discussions made several rounds significantly deeper than expected.

Round 1 : Online Assessment (DSA Coding Round)

The interview process started with an online assessment containing three coding problems. What I liked about this round was that all three questions tested completely different concepts. Instead of repeatedly asking array problems, the assessment covered:

dynamic programming
mathematical sequence optimization
greedy problem-solving

The round mainly evaluated: coding fluency, optimization thinking, problem decomposition and handling edge cases.

I managed to solve all three questions, although one of them definitely consumed more time than expected.

Problem 1 – Minimum Cost Path in a Grid

The first question was a classic dynamic programming problem.

We were given a grid containing costs and obstacles and the goal was: Find the minimum cost path from the top-left cell to the bottom-right cell while avoiding blocked cells. At first glance, the problem looked like a standard grid traversal question, but obstacle handling made the transitions more interesting.

For example:

Grid:


1 3 1
1 X 1
4 2 1

Here:

X represents blocked cells
movement is allowed only right or down

The challenge is finding the path with minimum total cost while avoiding invalid paths.

My Thought Process

I immediately identified this as a dynamic programming problem because:

every cell depends on previous computed states
overlapping subproblems exist naturally

I created a DP table where dp[i][j] stores the minimum cost required to reach that cell The biggest challenge was carefully handling:

blocked cells
unreachable states
initialization of first row/column

Instead of directly filling the DP table, I first marked invalid states using a very large number (INF) so they would never be selected as part of the minimum path. That simplified the transition logic significantly.


//My Java Solution

class Solution {

    public int minCostPath(int[][] grid) {
        int m = grid.length;
        int n = grid[0].length;
        // If source or destination is blocked
        if (grid[0][0] == -1 || grid[m - 1][n - 1] == -1) {
            return -1;
        }
  
        int INF = (int) 1e9;
        int[][] dp = new int[m][n];
        // Initialize all cells as unreachable
        for (int i = 0; i < m; i++) {
            Arrays.fill(dp[i], INF);
        }
        dp[0][0] = grid[0][0];
        // Fill first column
        for (int i = 1; i < m; i++) {
            if (grid[i][0] != -1 &&
                dp[i - 1][0] != INF) {
                dp[i][0] =
                    dp[i - 1][0] + grid[i][0];
            }
        }

        // Fill first row
        for (int j = 1; j < n; j++) {
            if (grid[0][j] != -1 &&
                dp[0][j - 1] != INF) {
                dp[0][j] =
                    dp[0][j - 1] + grid[0][j];
            }
        }

        // Fill remaining cells
        for (int i = 1; i < m; i++) {
            for (int j = 1; j < n; j++) {
                // Skip blocked cells
                if (grid[i][j] == -1) {
                    continue;
                }
                int top = dp[i - 1][j];
                int left = dp[i][j - 1];
                int minPrev = Math.min(top, left);
                if (minPrev != INF) {
                    dp[i][j] =
                        grid[i][j] + minPrev;
                }
            }
        }
        return dp[m - 1][n - 1] == INF
                ? -1
                : dp[m - 1][n - 1];
    }
}

Problem 2 – Length of Longest Arithmetic Progression

The second question required a completely different style of thinking. This was not about traversal or recursion. Instead, it focused on mathematical relationships between numbers.

The task was Find the length of the longest arithmetic progression present inside an array

An arithmetic subsequence means:

consecutive chosen elements have the same difference
elements do NOT need to be contiguous
original ordering must remain preserved

Example:


Input:
[1, 7, 10, 13, 14, 19]

Output:
4

Explanation:


[1, 7, 13, 19]
Difference = 6

My Approach

The brute-force solution becomes extremely inefficient because there can be many possible subsequences. I identified this problem as a dynamic programming problem because brute force would require checking too many possible subsequences, which becomes inefficient very quickly. Instead of generating all subsequences, I used:

dynamic programming
hash maps

to efficiently track arithmetic relationships between elements. The core idea was dp[i][diff] stores the length of the longest arithmetic subsequence ending at index i with common difference diff. For every pair of indices (j, i) where j < i, I calculated:

diff = nums[i] - nums[j]

If an arithmetic subsequence with the same difference already existed ending at index j, I extended that subsequence by including nums[i]. Otherwise, I started a new subsequence of length 2.

The interesting part of this problem was recognizing the hidden state relationship between:

current index
common difference
previously computed subsequences

rather than simply writing nested loops.

The interviewer seemed more interested in optimization thinking, DP state modeling and explanation clarity than just coding syntax itself.


//My Java Solution
class Solution {

    public int longestArithSeqLength(int[] nums) {
        int n = nums.length;
        HashMap<Integer, Integer>[] dp = new HashMap[n];

        for (int i = 0; i < n; i++) {
            dp[i] = new HashMap<>();
        }
        int max = 2;
        for (int i = 1; i < n; i++) {
            for (int j = 0; j < i; j++) {
                int diff = nums[i] - nums[j];
                int length = dp[j].getOrDefault(diff, 1) + 1;
                dp[i].put(diff, length);
                max = Math.max(max, length);
            }
        }
        return max;
    }
}

Problem 3 – Minimum Number of Stops to Reach Target

Out of all three coding questions, this one honestly required the most thinking.

The problem involved:

reaching a target location
minimizing the number of stops
deciding optimally where to stop

This was primarily a greedy optimization problem.

Example:


Target = 100
Start Fuel = 10
Stations:
[10,60]
[20,30]
[30,30]
[60,40]

The challenge is determining:

which stations should be used
and when refueling decisions should happen
to minimize total stops.

Initially, I explored multiple approaches, including DP-style thinking, but eventually realized a greedy strategy using a max heap works much better.

The idea is:

keep moving forward
whenever fuel becomes insufficient, use the largest available fuel station seen so far

I managed to solve the problem, but afterward I personally felt the implementation could have been cleaner and slightly better optimized in terms of space complexity.

One thing I learned from this round was: Interviewers appreciate self-awareness Even after solving the problem, discussing:

optimization opportunities
trade-offs
limitations creates a stronger impression.


// Optimal Java Solution
class Solution {

    public int minRefuelStops(int target,
                              int startFuel,
                              int[][] stations) {

        PriorityQueue<Integer> pq =
                new PriorityQueue<>(Collections.reverseOrder());

        int fuel = startFuel;
        int stops = 0;
        int index = 0;
        while (fuel < target) {

            while (index < stations.length &&
                   stations[index][0] <= fuel) {
                pq.offer(stations[index][1]);
                index++;
            }

            if (pq.isEmpty()) {
                return -1;
            }
            fuel += pq.poll();
            stops++;
        }
        return stops;
    }
}

Round 2 : Bar Raiser Round

The second round was conducted by a Bar Raiser and felt very different from the online assessment. This round focused much more on:

analytical reasoning
structured thinking
communication clarity

instead of pure implementation speed. The interviewer continuously asked follow-up questions to understand how I reason through problems.

Problem 1 – 8 Ball Weighing Puzzle

This was the famous puzzle where:

one ball is heavier
only three balance operations are allowed

The interviewer was not interested in memorized answers. He mainly evaluated:

divide-and-conquer reasoning
elimination strategies
communication clarity

I explained how splitting balls into equal groups systematically reduces uncertainty after every weighing operation. The discussion gradually became more about logical reasoning than the puzzle itself.

Problem 2 – Product of Array Except Self

The second question was a classic optimization problem. For every index in the array: Return the product of all remaining elements except the current one without using division.

Example:


Input:
[1,2,3,4]

Output:
[24,12,8,6]

The interviewer specifically focused on optimization, avoiding redundant calculations and space complexity.

My Approach

I used prefix products and suffix products. The intuition was simple For every position:

multiply product before it with product after it

This avoids division completely while maintaining O(N) complexity.

//My Java Solution
class Solution {

    public int[] productExceptSelf(int[] nums) {
        int n = nums.length;
        int[] result = new int[n];
        result[0] = 1;
        for (int i = 1; i < n; i++) {
            result[i] = result[i - 1] * nums[i - 1];
        }

        int suffix = 1;
        for (int i = n - 1; i >= 0; i--) {
            result[i] *= suffix;
            suffix *= nums[i];
        }
        return result;
    }
}

The interviewer appreciated both the optimization and dry-run explanation.

Round 3 – Java, Mockito & Elevator System Design

This round honestly felt the closest to a real backend engineering discussion. The interviewer spent significant time discussing:

previous projects
scalability decisions
architecture trade-offs
modular design

instead of rapid-fire theoretical questions.

Java & Mockito Discussion

The Java discussion focused heavily on practical engineering usage. We discussed:

dependency injection
mocking frameworks
test-driven development
service isolation during testing

The interviewer asked several practical questions around Mockito and how mocking helps isolate dependencies during unit tests. This discussion felt much deeper than basic what is Mockito? questions.

Elevator System Design

The major design problem in this round was Design a Simple Elevator System

Initially, the question sounded straightforward. But once real-world constraints were added, the complexity increased significantly.

The interviewer wanted discussion around:

scheduling efficiency
handling multiple elevators
request prioritization
modular class structure
scalability

I identified the core entities Elevator, Request, Floor, ElevatorController and Scheduler. Then we discussed:

request allocation
direction handling
minimizing waiting time
handling simultaneous requests

The interviewer seemed more interested in:

structured thinking
extensibility
trade-off reasoning

than perfect UML diagrams. This round genuinely felt like a real backend engineering design conversation.

Round 4 – Java Concurrency & Behavioral Round

The final round combined backend technical depth with behavioral evaluation. This round focused heavily on Java concurrency concepts.

Java Concurrency Discussion

The interviewer asked practical questions around:

threads
synchronization
race conditions
deadlocks
thread safety

Instead of textbook definitions, the interviewer expected:

production examples
debugging strategies
practical understanding

For deadlocks, we discussed:

lock ordering
timeout-based locking
concurrent collections
synchronized blocks

This round clearly showed how important concurrency knowledge has become for backend engineering interviews today.

Behavioral Questions

The hiring manager also asked questions such as:

Tell me about a disagreement with your team
How do you handle deadlines under pressure?
How do you maintain code quality while moving fast?

The interviewer mainly evaluated ownership, communication, maturity and decision-making ability.

The conversation felt fairly natural instead of robotic HR-style questioning.

Final Result – Rejected

Unfortunately, I was rejected after the final round. Based on the feedback, it appeared that while my technical performance was decent, the hiring team felt there was room for improvement in:

handling pressure situations
project ownership maturity
prioritization during uncertainty

Initially, the rejection felt disappointing because technically most rounds had gone reasonably well. But afterward, I realized the process itself highlighted several important areas I genuinely needed to improve. And honestly, that made the experience valuable.

What I Learned From Tekion’s Interview Process

One thing this interview made very clear is: Backend interviews are no longer only about solving coding questions Companies increasingly expect engineers to understand: