My Google L4 Phone Screen Interview Experience (Hyderabad) — Frontend, JavaScript

TL;DR

7 YOE frontend dev. Prepared 1 month (~60 LC Easy/Medium). Got the classic “Logger Rate Limiter” problem. Solved with a hashmap and finished on time. Verdict: No hire. HR feedback: solution wasn’t optimal (no further detail). Biggest takeaway: don’t just code a working solution—be explicit about assumptions, edge cases, and optimality.

Note: The interview happened in Oct 2024 — I’m publishing this later from my notes.

Background

This phone screen happened in Oct 2024 — I’m publishing it now from my notes, in case it helps someone preparing with a similar profile.

I interviewed for a Google L4 role for the Hyderabad location.

Experience: 7 years (frontend-strong)
Preferred language: JavaScript
Interview type: Phone screen (DSA)
Interview date: 31/10/2024, 3 PM IST
Preparation time: 1 month

Scheduling and preparation window

In the initial HR call, I negotiated 1 month of preparation time. I had basic DSA knowledge but no real LeetCode / competitive programming experience, so I wanted time to prepare properly.

There was a lot of back-and-forth to get the interview scheduled, but the Google candidate support team was helpful, and I eventually got a confirmed slot.

My preparation (1 month)

During this month, I focused only on Google-style DSA patterns and the most common topics.

Problems solved: ~60 LeetCode (Easy + Medium)
Reality: Managing this alongside a full-time job and family (with a kid) was challenging, but I genuinely feel I gave it my best shot.

Preparation material (most helpful first):

Striver’s YouTube DSA tutorials
Abdul Bari’s YouTube playlist (very beginner-friendly)
Data Structures and Algorithms Made Easy (great reference; the hard copy has small font—PDF is easier)
Cracking the Coding Interview

Interview day experience

The interviewer (EU region) joined right on time and was kind and polite.

The initial prompt felt ambiguous, so I asked clarifying questions to arrive at a clear final problem statement.

The question I was asked

Design a logger system that receives a stream of messages along with their timestamps. Each unique message should only be printed at most every 10 seconds. If a message is printed at timestamp t, the same message should not be printed again until t + 10.

(“Logger Rate Limiter” style problem.)

My solution (high level)

I solved it using a hash map:

Store message -> lastPrintedTimestamp
For each (timestamp, message):
- If the message is new → print, store timestamp
- Else if timestamp - lastPrintedTimestamp >= 10 → print, update timestamp
- Else skip

I completed the solution with ~5 minutes left. In the last few minutes, the interviewer asked for complexity, and I wrote + explained:

Time complexity: O(1) average per event
Space complexity: O(n) for the number of unique messages tracked

Result: No Hire

Verdict was No hire.

In the follow-up, HR mentioned that my solution was not the optimal one (they didn’t specify the better approach).

I was told I can re-apply after the 12-month window.

What I learned / what I’d do differently

This is what I’d improve if I were doing it again:

Don’t stop at “a working solution” — explicitly discuss optimality

Even if the approach is standard, clearly justify why it’s optimal under the given constraints (or ask which constraints matter most).

Be proactive about assumptions + edge cases

State assumptions early, like:

Are timestamps guaranteed to be non-decreasing?
Can the same message arrive multiple times at the same timestamp?
Are we expected to control memory growth (cleanup old keys), or is it okay to store all unique messages?

Walk through examples out loud

Do 2–3 quick dry runs (including the boundary at exactly 10 seconds). It helps catch mistakes and shows rigor.

Final note

This wasn’t the outcome I wanted, but it was still valuable: it showed me what the “Google bar” feels like under time pressure, and where my prep needs to level up.

If you’re preparing with a full-time job and family responsibilities—you’re not alone.