Google · Primly Community

Google coding interview / online assessment, format and difficulty: my notes from 2026

backend_bekah · 4 replies

went through the Google SWE loop in April 2026 while still employed (yes, interviewing on lunch breaks, yes it's exhausting). here's what the coding rounds actually looked like.

OA (online assessment, if you get one): two questions, 70 minutes, via Codility. I got one medium-level graph problem (BFS variant, not hard if you recognize the pattern) and one medium-hard string manipulation thing. timed pressure matters more than raw difficulty here. they want to see you write clean, working code, not clever one-liners.

phone screen (technical): one interviewer, Google Meet + shared doc (no autocomplete, no syntax highlighting, yes it's intentional). 45 minutes. I got a single medium leetcode-style problem with two follow-ups. the follow-ups were the real test: first one pushed me to optimize from O(n^2) to O(n log n), second one added a constraint that changed the approach entirely. if you can only solve the base case, you're probably not moving forward.

onsite coding rounds: three of them in my loop. two felt like algorithm problems (one on arrays, one on trees), one was more 'coding in the large' style where I had to extend existing code they provided. the third one is where people get surprised. it's not about knowing the algorithm, it's about producing readable, maintainable code under pressure. naming things matters. structure matters.

difficulty range: mostly medium, occasional medium-hard. I didn't see any 'hard' in the pure leetcode sense. but the medium questions had layers that a lot of people don't drill.

one thing worth knowing: they do not hint you to the optimal solution. if you're stuck in an O(n^3) approach they might ask 'is there a way to do better' once, but that's it. so know when your approach is wrong and pivot cleanly.

overall: this process is grindable. it's not a gotcha. it's just high-reps medium leetcode until the patterns are automatic.

4 replies

newgrad_neil

the 'no autocomplete no syntax highlighting' thing in the phone screen is so stressful to me. do they penalize you for minor syntax errors, like a missing semicolon or wrong method name? or do they care more about the logic?

quietquit_quincy

logic first, always. my interviewer literally said 'don't worry about exact syntax, I can read the intent' when I apologized for forgetting a method name. what they care about is whether you can think out loud and recover from wrong turns. write pseudocode if you need to structure your thinking, then fill in real code.

de_derek

the 'coding in the large' round is interesting. I had something similar where they gave me a file with a partial implementation and asked me to add a feature. the trick is: read the existing code first. understand the patterns in use. don't introduce a totally different coding style. I think a lot of people just start typing and ignore the context.

pivot_pat

solid write-up. one add from my loop: they sometimes track how you handle time pressure explicitly. my recruiter told me after the fact that candidates who got panicked and stopped thinking out loud did worse even when they eventually got to the right answer. narrating your thought process isn't just for the interviewer's benefit.