Google Warsaw — L4 Software Engineer Onsite Interview Experience
I finally went through my Google onsite rounds, and the overall experience was excellent. In this article, I will share how the overall…
Google Warsaw — L4 Software Engineer Onsite Interview Experience
I finally went through my Google onsite rounds, and the overall experience was excellent. In this article, I will share how the overall process went and what each round looked like.
(Non-Medium members can READ the full article for FREE: here)
Photo by Mitchell Luo on Unsplash
Interview Process
Google conducted a phone screen interview as a preliminary screening, and I’ve explained how it went in the following article.
After successfully clearing the phone screen, I got matched with a team for an L4 position and the onsite loop was scheduled, consisting of the following:
- On-site Technical Coding Interview — I
- Googlyness/Behavioural Interview — Hiring Manager
- On-site Technical Coding Interview — II
- On-site Technical Coding Interview — III
Coding Round 1 (45 minutes)
The interviewer started with a brief introduction. He was going through my resume, and his eyes caught the word “scalability challenges” in my resume. He asked me to explain a situation where I solved a scalability problem. I had a recent example of reducing the search latency of our product offers from 5 sec to 1 sec. I observed that he was very fast in grasping my problem space.
Then he gave me a coding challenge, and this belongs to the LeetCode hard category. I had broken down the problem into 2 parts, but I couldn't come to the right data structure or algorithm at that point. It was ultimately a graph question and needed topological sorting to reach the final answer. I had the chance to write some code, but it was not complete since I didn't realise I had to do a topological sort. At one point, I got some revealing hints from the interviewers, but while discussing some test cases, I had a feeling that he didn't have a good grasp on the question. There were times when he would prepare a testcase, and he couldn't explain why the testcase didn't work as he expected based on his problem description.
In the end, I asked him questions about his work, and we had some small talks related to Bazel build, which is an open-source project that his team is working on.
Googlyness Round (45 minutes)
This round was conducted by the Hiring manager from the team that I might be potentially joining. He started right away with behavioural questions where he covered various aspects such as team player skills, conflict resolution, dealing with a bad culture/bad teammate, helping new hires during onboarding, product inspirations, and understanding the community aspect of my product, etc. It’s very similar to Amazon Leadership principles questions, and using the STAR technique will help you a lot. I recommend practising the STAR technique for such interviews, and educative.io has a well-crafted course on this. In the last 5 minutes, he explained his team’s projects, but I did not have time to ask questions as time ran out.
💡 Want to ace behavioural interviews? I’ve written a comprehensive guide on exactly how to prepare for behavioural questions and deliver top-tier answers:
Coding Round 2 (45 minutes)
The interviewer asked me to solve a coding challenge involving intervals, and this one was also at a LeetCode hard difficulty level. The solution I came up with had to use an interval stored in a binary search tree, a.k.a Interval Trees, and I had never used it before. I ended up writing some code for insertion, but didn't handle overlapping interval cases. I took quite some time to write code for a BST insertion, which I think would have scored me low. There were discussions about self-balancing binary search trees, e.g., AVL/Red Black Trees, since there was a chance my implementation would create a skewed binary search tree. Later, he modified the problem with different input constraints, and this time, I solved it with a simple array.
In the end, I asked him about his work and what a day looks like for him at Google.
Coding Round 3 (45 minutes)
I was asked to solve a question related to an infinite complete binary tree whose node values have a derived pattern. I couldn't find this question anywhere, but I can strongly say it's at a LeetCode hard level. I was asked to write the code to build the tree and also do a level-order traversal, etc. I wrote these quickly, and he asked that if I were given a node value, how would I know its index in level order traversal? I gave him a brute-force solution, but he wanted something faster. I had the idea of deriving the parent node and then going up to the root. But I couldn't come up with a fully working idea to get the index. The time was too late, but he said I did pretty well since I was close to the final solution. The interviewer was very friendly and also gave hints on the way when I was in the right direction.
In the end, I asked him about his work and the tech stack he uses. He was from the London office, and he explained how things have changed since COVID.
The Team Matching Phase
A few weeks after the loop, my recruiter reached out to say my feedback was good enough to move into team matching, which at Google means finding a host team that actually wants to bring me on board. This is where my experience took a turn that I did not expect, so I want to share it openly because not many interview write-ups talk about what happens after the rounds are done.
The first team was the one building the UI for Google Kubernetes Engine, a full-stack group of around ten engineers working across Java, TypeScript and Angular. I had a project call with the hiring manager, and while the people and the product were clearly strong, the role itself sounded very full-stack and frontend-heavy, which is not really the kind of work I wanted to do. As a primarily backend engineer, I knew fairly quickly that it was not the right fit for me. Soon after, a second team came up on Cloud Data Catalogue, focused on backend security and compliance work in C++ and Java, and that one appealed to me much more. I told my recruiter I was keen to speak with them, and she advised me to stay open to both teams so that I would have options if more than one hiring manager was interested.
That is roughly where things slowed down. The project call with the Cloud Data Catalogue team was never actually scheduled, because that team had other candidates they wanted to close first and asked me to wait. Then the holidays arrived, and after the break, my recruiter let me know she was finding it hard to source any new teams for me. Around the same time, the news about the large layoffs at Google started coming out, and I wrote to ask whether this would affect my process. The honest answer was that all the roles were going through re-prioritisation again, and everything had become slow and uncertain.
The part that finally made me step back came in the next update. I was told that, based on my feedback, I would be considered at L3, and there were no L3 roles open at the time. The options were to keep waiting for a team to open up or to close the application and interview all over again later in the year. This was confusing to me because the GKE UI team had been talking to me for an L4 position, so going a level down did not sit right. I replied that if I had to repeat the whole process from scratch, I would rather aim for a more senior opening instead.
Outcome
All the interviewers were very thorough and passionate about their work. The questions were hard but doable if you had practised well, specifically trying hard LeetCode questions related to graphs and trees. The interviewers were from all over the world and not specifically from Warsaw. They want to see you write some code, and all of them expect you to keep talking out your thought process since this is what matters the most. Overall, I feel I could have done much better if I had spent more time on LeetCode’s hard questions.
💡 Bonus: I’ve created a practice list on LeetCode after going through several Google interview experiences **here**.
In terms of the final result, my interview feedback came back mixed. Team matching is a standard step for every candidate at Google, but going in without a strong hire signal from the onsite made it much harder to land a team. After the conversations above, with the layoffs, the broader uncertainty and the suggestion of dropping to L3, the process quietly stalled, and there was less and less to update me on, so eventually I decided to step away.
Looking back, the biggest lesson for me was that clearing the loop is only half the story at a company like Google. A good result still has to find a team with open headcount, and when hiring freezes and re-prioritisation hit, even strong feedback can quietly go nowhere. I have no complaints about how I was treated, and the people I spoke to were impressive, but waiting indefinitely for an uncertain role costs more than it is worth, and I am at peace with the call I made to move on.
💡 Bonus: Want to know how I actually prepare for these coding rounds? Check out my preparation strategy here:
Thanks for reading! If this story resonated with you, I’d appreciate a few claps 👏. It really helps more people discover this post.
If my work provided some value today, you can support me here 🤝.
To view my full portfolio or connect with me on other platforms, visit:
For anyone interested, check out all my interview experiences here:
메타데이터
- post_id
- 3b035eb9e9f1
- slug
- google-onsite-interviews-3b035eb9e9f1
- url
- https://medium.com/the-modern-scientist/google-onsite-interviews-3b035eb9e9f1
- canonical_url
- https://medium.com/the-modern-scientist/google-onsite-interviews-3b035eb9e9f1
- author_url
- https://medium.com/@freezefrancis
- status
- ok
- fetched_at
- 2026-06-14 16:15:44
