The Setup That Felt Right

When Myntra reached out for a Senior Frontend Engineer position, I was genuinely excited. This is one of India’s largest fashion e-commerce platforms — millions of users, complex catalog management, real-time inventory, mobile-first design challenges. The kind of frontend problems I love solving.

I researched their tech stack (React, Node.js, microservices), read about their mobile app performance optimizations, studied their user interface patterns. I was ready to discuss component architecture, state management at scale, performance optimization for large product catalogs.

I prepared for the wrong interview.

Round 1: The False Comfort

The first round was an online assessment. Standard stuff for a frontend role:

• JavaScript fundamentals and ES6 features
• React concepts: hooks, component lifecycle, state management
• Problem-solving questions (not heavily algorithmic, more logic-based)
• Some CSS and responsive design questions

I felt comfortable. These were the tools I use daily. The problems were practical, relevant to actual frontend development work. I submitted the assessment feeling pretty good about my chances.

Two days later: “Congratulations! You’ve cleared the first round. Please come to our office for the next round.”

Perfect. I assumed round two would dive deeper into React architecture, maybe discuss some system design, possibly pair programming on a real frontend challenge.

I was so wrong.

Round 2: The Office Visit That Wasn’t What I Expected

Walking into Myntra’s Bangalore office, I felt that familiar pre-interview energy. The office looked great — modern, buzzing with activity, engineers everywhere. This felt like a place where I could do good work.

The interviewer introduced himself — let’s call him Raj, a senior software engineer who’d been at Myntra for three years. We exchanged pleasantries about the company, the role, my background.

Then he said something that should have been a red flag: “Great. So today we’re going to focus on your problem-solving skills and algorithmic thinking.”

Algorithmic thinking? For a senior frontend role?

Before I could process this fully, he handed me a pen and a blank sheet of paper.

“Here are two problems I’d like you to solve. Take your time, explain your approach, and write the code.”

Problem 1: Non-Overlapping Intervals

The Problem: Given a collection of intervals, find the minimum number of intervals you need to remove to make the rest of the intervals non-overlapping.

Example: [[1,2], [2,3], [3,4], [1,3]] → Remove [1,3] → Answer: 1

I stared at the problem for a moment. This felt familiar — I’d definitely seen similar problems before, probably on LeetCode during my earlier job search phases.

My approach (brute force): “Okay, so I need to find overlapping intervals and remove the minimum number. One approach would be to sort the intervals by start time, then iterate through and count overlaps…”

I started writing code on paper:

function eraseOverlapIntervals(intervals) {
    if (intervals.length <= 1) return 0;
    
    // Sort by start time
    intervals.sort((a, b) => a[0] - b[0]);
    
    let removed = 0;
    let prevEnd = intervals[0][1];
    
    for (let i = 1; i < intervals.length; i++) {
        if (intervals[i][0] < prevEnd) {
            // Overlap found, need to remove one
            removed++;
            // Keep the one with earlier end time
            prevEnd = Math.min(prevEnd, intervals[i][1]);
        } else {
            prevEnd = intervals[i][1];
        }
    }
    
    return removed;
}

As I’m writing this out by hand, I’m already doubting myself. Is this optimal? I think it works, but the logic feels shaky when I try to trace through examples.

“Okay, that’s one approach. What’s the time complexity?”

“O(n log n) for the sorting, plus O(n) for the iteration, so O(n log n) overall.”

“Right. Can you think of a more optimal solution?”

I stared at the paper. More optimal than O(n log n)? I don’t think you can do better than the sorting step…

“I’m not sure we can do better than O(n log n) because we need to sort the intervals…”

“Hmm, what if you sort by end time instead of start time? Would that change your approach?”

Now I’m second-guessing everything. Maybe my solution was wrong to begin with?

I tried to think through it again, but writing code on paper without being able to run it, trace through examples easily, or refactor quickly was genuinely difficult. My brain felt sluggish.

Problem 2: Kth Largest Element

The Problem: Find the kth largest element in an unsorted array.

Example: [3,2,1,5,6,4], k=2 → Answer: 5

This one I definitely knew. Classic problem.

My brute force approach: “Simple approach would be to sort the array and return the element at index length-k.”

function findKthLargest(nums, k) {
    nums.sort((a, b) => b - a); // Sort descending
    return nums[k - 1];
}

“Time complexity O(n log n). But you probably want a more optimal solution?”

“Yes, can you think of something better?”

I knew the answer theoretically: quickselect algorithm, average O(n) time complexity. But implementing quickselect from scratch on paper? That felt daunting.

“There’s the quickselect approach, which is like quicksort but only recurse on one side. Average case O(n), worst case O(n²)…”

“Can you implement it?”

I started writing the quickselect code, but halfway through, I was making mistakes. Partitioning logic, handling edge cases, getting the indices right — all of this was challenging to do cleanly on paper without the ability to test and iterate.

function findKthLargest(nums, k) {
    // Convert k to 0-indexed from the end
    return quickSelect(nums, 0, nums.length - 1, nums.length - k);
}

function quickSelect(nums, left, right, targetIndex) {
    if (left === right) return nums[left];
    
    // Choose pivot and partition
    let pivotIndex = partition(nums, left, right);
    
    if (pivotIndex === targetIndex) {
        return nums[pivotIndex];
    } else if (pivotIndex < targetIndex) {
        return quickSelect(nums, pivotIndex + 1, right, targetIndex);
    } else {
        return quickSelect(nums, left, pivotIndex - 1, targetIndex);
    }
}

function partition(nums, left, right) {
    // Implementation details...
    // I was getting confused here
}

I could see I was making errors in the partition function, getting confused about the indexing, and running out of mental bandwidth to debug on paper.

“I think my partition logic might have bugs. In a real coding environment, I’d test this step by step, but on paper it’s harder to trace through…”

The Moment I Knew I Was Done

Twenty minutes into the second problem, I could see the interviewer’s expression. Not hostile, but not encouraging either. That look that says, “This isn’t going where we hoped.”

“Alright, I think that’s enough for today. Do you have any questions for me?”

I asked a few questions about the role, the team, the technology stack. But I already knew how this was going to end.

“We’ll get back to you with feedback soon.”

As I packed up my notebook and walked out, he added almost casually: “The feedback isn’t positive, so we won’t be moving forward.”

Just like that. No sugar-coating, no “we’ll be in touch,” no constructive feedback about what went wrong or what I could improve.

The walk to the parking lot was brutal.

What Bothered Me Most

Here’s what frustrated me about this experience:

The Role Mismatch: I applied for Senior Frontend Engineer. I expected questions about:

• React architecture and component design
• State management strategies (Redux, Context, Zustand)
• Performance optimization for large applications
• CSS-in-JS vs traditional CSS approaches
• Testing strategies for frontend applications
• Accessibility and responsive design
• Bundle optimization and code splitting

Instead, I got pure algorithmic problems that could have been given to any software engineer regardless of specialization.

The Medium Mismatch: Writing code on paper in 2024 feels archaic. I haven’t written significant code by hand since college. Modern development involves:

• IDE assistance for syntax and autocompletion
• Ability to run and test code iteratively
• Debuggers to step through logic
• Stack Overflow and documentation for reference

Removing all these tools doesn’t test my ability to be a productive frontend engineer — it tests my ability to memorize algorithms and write bug-free code in an artificial environment.

The Skills Mismatch: The algorithmic problems they gave me have no bearing on my day-to-day work as a frontend engineer. When was the last time I needed to implement quickselect in a React application?

Meanwhile, I can:

• Design and implement complex React component hierarchies
• Optimize bundle sizes and implement code splitting
• Handle complex state management across large applications
• Debug performance issues and memory leaks
• Implement responsive designs that work across devices
• Write accessible components that work with screen readers
• Handle API integration and error states gracefully

But none of that mattered because I couldn’t optimize interval-removal algorithms on paper.

The Broader Industry Problem

This experience highlighted something that frustrates many frontend developers: the disconnect between what companies say they want and how they actually interview.

Job Description Reality:

• “Build responsive, accessible user interfaces”
• “Optimize React applications for performance”
• “Collaborate with designers to implement pixel-perfect designs”
• “Integrate with APIs and handle complex data flows”

Interview Reality:

• “Implement quickselect from memory”
• “Optimize this graph traversal algorithm”
• “Solve this dynamic programming problem”

Don’t get me wrong — algorithmic thinking is valuable. Problem-solving skills matter. But the degree to which some companies weight pure DSA ability over role-relevant skills seems misaligned.

For Fellow Frontend Developers

If you’re facing similar experiences:

It’s not just you. Many frontend developers struggle with the algorithm-heavy interview process, especially when it feels disconnected from the actual role.

Prepare anyway. Whether we like it or not, DSA interviews are common. Treat them as a necessary skill for job hunting, even if not for the job itself.

Find the right companies. Some companies do interview in ways that match the actual work. They exist, and they’re worth seeking out.

Don’t let rejections define your worth. Your ability to implement quickselect on paper doesn’t determine your value as a frontend engineer.

The industry is slowly evolving toward more relevant interview processes, but change is gradual. In the meantime, we adapt.

What’s been your experience with role/interview mismatches? I’d love to hear about it in the comments.

Written by Anil Peddireddy