Life, lately.

Earlier this year, I went through the interview process for a Front End Engineer role with J.P. Morgan's Personal Investing team in London. I got fairly deep into the process before being turned down, and the experience taught me something I hadn't fully appreciated before: the gap between knowing how to build something and building it fluently while someone watches you think.

The format. After an initial recruiter screening, the process moved to a first-round interview covering my background, motivation for the role, core frontend fundamentals, accessibility, and topics like stakeholder management and CI/CD. That went well, and I progressed to a pair-programming round — around 90 minutes, working through live coding tasks in JavaScript and React with two engineers.

Where it went sideways. The pair-programming round was the deciding stage. I was slower than the interview expected me to be, needed some guidance to get unstuck, and didn't fully finish the styling on one of the tasks — the interviewers had to step in a few times. Looking back, the feedback was really about coding fluency and pace under live pressure, not about whether I understood the underlying concepts.

The outcome. I was rejected after the pair-programming round, before reaching the final behavioral/team-fit interview that had already been scheduled.

What I took from it. This one stuck with me more than most rejections, because it wasn't a knowledge gap — it was a performance-under-pressure gap. I know how to solve these problems when I have time to think. I'm working on closing the gap between that and solving them fluently, out loud, on a clock, while being watched.

Earlier this year, I went through an interview process with IBM for a senior consulting/engineering role in Hyderabad. Unlike a few other processes I've written about here, this one went the full distance — all the way to a written offer.

The format. The process started with a technical interview and discussion round. After that, I moved into the selection stage, which involved providing compensation documentation, a background verification process, and ongoing conversations with HR about the role and package.

What stood out. Compared to the more code-heavy, live-pressure rounds I'd been through elsewhere, this process leaned more on discussion — my experience, my approach to problems, and how I'd fit into the team and the work. The documentation and verification stages took real time, more administrative patience than technical prep.

The outcome. The process concluded with a formal written offer — a meaningful step up from my compensation at the time, and validation that the work I'd been doing was landing the way I hoped it would with people evaluating it from the outside.

What I took from it. Reaching an actual offer, after a run of rounds that didn't convert elsewhere, was a good reset. It's easy to let a string of rejections shape how you see your own level — this was a useful reminder that interview outcomes are noisy, and one "no" (or four) doesn't define where you actually stand.

I recently went through the interview process for a Senior Software Engineer (Frontend) role at Microsoft. It didn't end in an offer, but it was one of the more structured processes I've been through, and I wanted to write down what I took from it.

The format. The process started with a HackerRank assessment covering DSA and React fundamentals, followed by a live-coding technical phone screen, and then a final loop of three interviews — two technical rounds and one "as appropriate" round with a senior interviewer, all scheduled on the same day.

What it actually tested. The technical rounds leaned heavily on live coding combined with how I reasoned through the problem out loud — not just arriving at a working solution. The final round felt less about a specific technical challenge and more about how I think and communicate under pressure.

My honest self-assessment. Looking back, my first technical round felt strong. My second had a weaker behavioral moment I could have handled better. The final round went well — I walked out feeling genuinely good about it.

The outcome. About six days after my final interview, the decision came back as a rejection. It stung in the moment, but going through a process at that bar sharpened how I think about interviews — and about my own gaps — more than an easier process would have.

What I'd do differently. Two things, specifically: sharpen my DSA fundamentals so live coding feels less effortful under time pressure, and prepare more deliberately for behavioral rounds — having sharper, more structured stories ready instead of thinking through them in the moment.

Late last year, a recruiter reached out about a Senior Software Engineer (Frontend) opportunity at PayPal. I said yes, and what followed was a process that moved quickly at first, then slowed into something more deliberate.

The format. After the initial recruiter conversation, I completed a HackerRank assessment within the requested window, covering practical frontend questions — all test cases passed. From there, the process moved to a DSA interview, followed by a frontend-focused system design round.

What the system design round actually tested. This was the most interesting part of the process for me. It wasn't about frontend implementation details at all — the conversation covered modularity, scalability, fault tolerance, load balancing, caching, and horizontal scaling. It was a genuine systems-thinking conversation, closer to backend/infrastructure reasoning than day-to-day frontend work, and it pushed me to think about frontend architecture at a scale I don't always get to operate at.

The outcome. After the system design round, I had a recruiter follow-up call, and the process ultimately didn't result in an offer.

What I took from it. This process was a good reminder that "senior frontend" interviews increasingly expect you to reason like a systems engineer, not just a UI engineer — trade-offs, failure modes, and scale considerations, even when the day-to-day role is frontend-focused. It's pushed me to deliberately study system design concepts I wouldn't naturally reach for in frontend work.