My First Interview in 3 Years — Senior Software Engineer (Frontend) at Headout

⚠️ Note: These aren’t the exact interview questions. They’re paraphrased versions that capture the type and difficulty, out of respect for the company’s hiring process.

Verdict: Rejected. But honestly? One of the best interview experiences I’ve ever had.

Before we begin… a tiny confession

You know that feeling when you’ve been at the same company for so long that your IDE shortcuts feel like an extension of your nervous system?

Your teammates know your coffee order.

The most “interview-like” thing you’ve done in three years is explaining your tech stack to a new joiner.

Yeah. That was me.

I spent three beautiful years at Tessell — shipping features, breaking production (occasionally 🙃), fixing production (always), and getting really, really comfortable.

And comfort, my friend, is a sneaky little thing. One day you’re “settled.” The next, you realize the last time you opened LeetCode was when JavaScript itself was younger.

So when I finally decided to dip my toes back into the interview pool, I wasn’t just nervous.

I was terrified.

The kind of terrified where you keep refreshing the recruiter’s email at 2 AM.

The kind where you rehearse “Tell me about yourself” in the shower like it’s a TED Talk.

The kind where you ask yourself, “Do I even remember how to write a for loop without auto-complete?”

Spoiler: I do. But the brain does dramatic things when it’s panicking.

And out of all places I could’ve picked for my comeback round… I chose Headout. Senior Software Engineer — Web (Frontend). No pressure.

A little about me

I’m a frontend engineer who has spent the last few years deep in React land — building dashboards, design systems, and the occasional component that technically worked but no one (including me) fully understood why.

Tessell was my home for 3 years. I got to work on genuinely hard problems, ship at startup pace, and grow from “I think I know JavaScript” to “I’m pretty sure I know JavaScript… most days.”

Frontend has always been my thing — that sweet spot where logic meets pixels, where a misplaced display: flex can ruin your afternoon, and where every small interaction can change how a user feels.

But after 3 years, I knew it was time to test the waters. To see where I stood. To find out if my skills had grown — or if I was just very good at one specific codebase.

Enter: Headout.

How it began

Honestly, I didn’t expect a callback so quickly.

I applied, half-expected the silence that usually follows job applications, and a few days later — my phone rang.

An unknown number.

I almost let it go to voicemail (because who actually answers unknown numbers in 2025?). But something told me to pick up.

It was the recruiter from Headout.

After 3 years of being in a “safe” cocoon, hearing a recruiter’s voice on the other end felt like a plot twist I wasn’t quite ready for.

My brain went into instant “act normal, act normal, ACT NORMAL” mode. I think I said “yeah, sure, that sounds great” about fourteen times in two minutes. Smooth.

But once I hung up, took a deep breath, and let it sink in — the wheels started turning.

The process had three rounds. And what surprised me from day one was how human it all felt. No copy-pasted templates. No vague timelines. No ghosting. Just clear, respectful, well-communicated steps.

Let me walk you through each round 👇

🚀 Round 1 — The Recruiter Screen

If you’re reading this thinking, “Oh, recruiter rounds are easy. They just ask about CTC and notice period and we move on” — please sit down. I have news.

This round was nothing like that.

I walked in expecting a friendly, surface-level chat about compensation and timelines. What I got instead was a deeply thoughtful, almost philosophical conversation about my career, my motivations, and frankly, the kind of person I am.

The recruiter started gently — introductions, my background, my time at Tessell. And then, slowly, the questions started getting sharper.

Not aggressive. Not unfair. Just… genuinely probing.

The kind of questions that make you pause mid-sentence and actually think before answering.

Here’s a flavor of what I was asked:

• “Why are you leaving Tessell? If your career is going so well there, why move now?”
• “Is money the only motive behind this switch?”
• “What does Headout mean to you?”
• “What do you think you’ll gain at Headout — apart from money?”
• “How can Headout help you grow technically?”
• “Why Headout, specifically? Out of all the companies you could’ve applied to?”

Now reading this list, you might think, “These are standard questions, what’s the big deal?”

The big deal is — when you’re asked these in sequence, by someone who is genuinely listening and follow-up questioning every answer, you have nowhere to hide.

There’s no surface-level reply that survives.

The “I’m looking for new challenges” answer? Doesn’t fly. The “I want to work on impactful problems” answer? She’d ask, “Like what specifically? And why can’t you do that at Tessell?”

It was the kind of conversation that gently held a mirror up to me and asked, “Okay, but do you actually know what you want?”

And honestly? I had to be brutally honest with myself in real time. Because the moment you try to BS, the moment you give a rehearsed LinkedIn-flavored answer — it shows.

Recruiters who care about culture fit can smell scripted answers from a mile away.

I’ll be transparent — I fumbled on a couple of these. Especially the “what does Headout mean to you” one, because I hadn’t framed my own answer beyond “they build cool stuff in travel/experiences.”

I had to think out loud, and I appreciated that she gave me the space to do that instead of rushing me.

My lesson from this round:

If you ever think “recruiter rounds don’t matter,” let me gently slap that thought out of you. This round sets the tone for everything that follows.

The recruiter isn’t just qualifying you — they’re trying to understand whether you genuinely want to be here, or whether you’re just shopping around.

So before you walk into any recruiter screen, ask yourself:

• Why this company, specifically?
• What does growth look like for you — beyond title and salary?
• What would make you stay somewhere for 3+ years again?

If you can’t answer these for yourself, the recruiter will find out very quickly. And so will you.

By the end of the call, I felt drained but oddly grateful. The recruiter was warm, professional, and made the whole thing feel like a real human conversation — but one with substance. The kind that leaves you thinking long after you hang up.

I walked away from that call about 30% less terrified for the next rounds. Maybe 40%.

(The other 60% was still very, very terrified. Let’s be real.)

💻 Round 2 — Frontend Machine Coding

This is the round where I officially remembered I was an engineer.

Focus areas:

• Vanilla JavaScript
• Plain CSS
• HTML

No React. No Tailwind. No “let me just npm install my way out of this.”

Just you, the browser, and your relationship with document.querySelector.

Get Yashpreet Bathla’s stories in your inbox

Join Medium for free to get updates from this writer.

Remember me for faster sign in

The kind of round where you suddenly realize how much modern frameworks have been carrying you.

We love you, React. We owe you everything. But also — you’ve made us soft.

The problems revolved around:

• Infinite scroll / pagination
• Virtualized lists with 10,000+ items

Now, the interesting part wasn’t just writing the code. The interviewer wanted me to explore multiple approaches:

• Intersection Observer API — the modern, elegant, “look at me being a 2024 developer” approach.
• Scroll position + screen height calculations — the classic, slightly chaotic, “I was here before Intersection Observer was cool” approach.

We talked about trade-offs. When does each shine? What’s the performance hit? What happens when you have 10k DOM nodes vs. 10k virtualized nodes?

How do you keep scroll position stable when items load?

How do you handle edge cases like fast scrolling or sudden window resizes?

This round wasn’t just “can you code it?” It was “do you understand why you’re coding it this way?”

Honestly, I enjoyed this round the most. There’s something liberating about going back to fundamentals. No frameworks to hide behind. Just JavaScript doing JavaScript things.

Pro tip from the trenches: practice without frameworks before frontend interviews. Yes, it feels like writing letters with a quill in 2025, but it forces you to actually understand the DOM, the event loop, and how the browser really works.

And interviewers love that.

🧠 Round 3 — System Design + Frontend Architecture

Ah yes. The final boss.

This round was a glorious 1.5 hours long, and by minute 47, I’m pretty sure my brain started making the dial-up internet noise.

The question? On paper, it sounded innocent:

“Design a Toast component as an NPM package.”

I almost laughed.

A toast? I’ve built toasts. Toasts are easy. Toasts are like — position: fixed; bottom: 20px; show; setTimeout; hide. Done.

Reader, I was wrong.

Once you peel back the layers of “design it as a package,” the floor opens up beneath your feet. Suddenly, you’re not just building a component — you’re building a product that other engineers will install, configure, customize, debug, and possibly curse at on a Friday night.

The expectations were genuinely high:

• ✅ Strictly typed code (TypeScript, and not the “any everywhere” kind)
• ✅ High-level design — architecture, public API, extensibility
• ✅ How will external apps consume it? — peer dependencies, tree-shaking, bundle size
• ✅ Performance considerations — re-renders, animation jank, queue management
• ✅ Folder structure — yes, folder structure was discussed in detail
• ✅ Unit testing strategy — what do you test, how, with what tools?

We went deep into things like:

• How do you expose the component API without forcing a provider?
• How do you handle multiple toasts? A queue? A stack? FIFO? LIFO?
• How do you make it themeable without bloating the bundle?
• What if someone wants to render a custom component inside the toast?
• How do you handle SSR? (Because of course, SSR.)
• What about accessibility? ARIA roles, keyboard dismissal, screen reader announcements?

I tried my best. I really did. I got through most of it.

But somewhere along the way, I could feel the gap between “I can build this” and “I can design this at a senior bar.”

And that’s exactly where I think I fell short. The bar was high — and honestly, deservedly so for a senior role.

I walked out of this round mentally cooked. Like, brain-needs-a-pillow cooked.

The rejection (and why it didn’t sting)

A few days later, the email came.

Now, I’ve been rejected before. Most of us have. And usually it goes like:

“Thank you for your time. We’ve decided to move forward with other candidates. We wish you the best in your future endeavours.”

Translation: We have no idea who you are. Goodbye.

But Headout? They did something different.

They sent actual, detailed, specific feedback.

What I did well. Where I could improve. What I should focus on if I wanted to try again in the future.

It felt like reading a thoughtful code review, not a corporate brush-off.

For a candidate, this is gold. Most companies treat rejection feedback like state secrets. Headout treated it like a gift — and that completely changed how I felt about the whole process.

I closed my laptop, sat back, and instead of spiraling into “I’m not good enough” mode, I just… nodded.

Because now I knew exactly where I stood and what to work on.

More companies need to do this.

Seriously. Rejection is part of every engineer’s journey, but how you reject someone says everything about your culture.

My biggest learnings 📚

If I had to distill this whole experience into things I’d tell my past, pre-interview self:

1. Frontend system design is a skill in itself.

It’s not just “draw a few boxes and arrows.” You need to think about APIs, performance, packaging, accessibility, edge cases, and developer experience. Practice it. Out loud. With diagrams. With a rubber duck if needed.

2. TypeScript fundamentals matter more than you think.

Not just “I use it daily.” I mean really understanding generics, conditional types, utility types, and how to design type-safe APIs that don’t make consumers cry.

3. Get comfortable without frameworks.

If you can build infinite scroll, modals, dropdowns, and toasts in vanilla JS — React will feel like a vacation.

4. The interview is not just an exam — it’s a conversation.

The best moments in my rounds were when I stopped trying to “perform” and just started thinking out loud.

5. Rejection is not failure. It’s signal.

Every “no” tells you exactly where to grow next. Especially when companies care enough to spell it out for you.

Closing thoughts

A huge shoutout to the entire Headout recruitment team. From the very first phone call to the final rejection note, every step was professional, respectful, and — dare I say — kind.

Experiences like these leave a positive impression even when the outcome doesn’t go your way.

I came in scared. I came in rusty. I came in unsure if I still had what it takes after 3 cozy years at one place.

I left with clarity, learning, and a list of things to work on.

That’s a win in my book — outcome or not.

To anyone else out there sitting on the edge of “Should I start interviewing again?” — yes. You should. The water’s cold at first, but you’ll figure out how to swim. The first one is the scariest. After that, it’s just reps.

If you’re preparing for frontend interviews, I’d also recommend checking out uisheet.com — they have a really solid collection of frontend interview questions and patterns that closely mirror what you’ll actually face in real interviews.

Now if you’ll excuse me, I have a date with the TypeScript handbook and a Toast component that haunts my dreams.

Onwards. 🚀

If this helped you in any way — or if you’re prepping for a similar interview — feel free to reach out. We’re all just figuring it out one round at a time. ✨

Liked this? A few claps 👏 would make my day. Follow for more honest interview write-ups and frontend deep dives.