In this 45-minute Google L4 interview, the coding problem was a graph question about task dependencies. The algorithm was around LeetCode Medium; the harder part was clarifying assumptions, testing the implementation, and adapting quickly when the follow-ups changed the problem.
Interview Experience | SDE | 🔥🔥 | Google
2026 · L4 · United States · first interview · 45 minutes.
The interviewer briefly introduced themselves, then asked for a short self-introduction. We did not spend much time on my resume before starting the coding problem.
This is a translated editorial version of the original Google L4 interview report. It records one interviewer's session, not a guaranteed Google question or hiring standard.
Coding: task dependencies
The prompt gave a set of tasks and dependencies and asked me to return a valid execution order.
Before coding, I asked whether the input could contain duplicate dependencies and whether a cycle was possible. I used an indegree count and breadth-first search to implement a topological sort. The first version was finished in roughly ten minutes.
The follow-ups were:
- What should happen if there is a cycle?
- Can you return the actual cycle?
- What changes if dependencies can be added dynamically?
- What are the time and space complexities?
For returning a cycle, I initially wanted to keep the BFS approach. I realized that depth-first search would be a cleaner fit, explained that change to the interviewer, and switched approaches. The interviewer did not give much guidance; they expected me to continue working through it.
Near the end, I ran several test cases myself. I noticed that duplicate edges could make the indegree count incorrect and added a fix.
Questions at the end
With a few minutes left, I asked what the team was currently working on and what scope an L4 engineer would normally own after joining.
Overall impression
The problem was not unusually difficult, but Google seemed to care about communication throughout the round. In particular:
- clarify assumptions before writing code
- test the implementation yourself
- explain complexity clearly
- adjust your approach when a follow-up changes the problem
The first solution is only part of the interview. The way you inspect the assumptions and respond to a new constraint matters just as much.
These behaviours reflect one candidate's experience, not a universal Google scorecard. For a broader candidate-facing explanation of the observable signals that technical interviews often assess — including problem framing, testing, communication, and complexity — see PracHub's technical interview rubric.