A software developer with no formal algorithms training used Gemini Pro as a personal tutor to cram for a Google technical interview in seven days. He completed 34 LeetCode problems, passed the screening round, and got invited to on-site interviews.
The developer, Dominik Rudnik, works in telecommunications and had spent over a decade failing to learn classical algorithms through traditional methods - books, YouTube videos, grinding LeetCode solo. When Google contacted him about a year-old application and scheduled interviews for the following week, he tried something different.
The Method: AI as Tutor, Not Crutch
Rudnik set strict rules for how Gemini Pro could help him. The model was not allowed to output code. Instead, it could only provide conceptual hints, real-world analogies, and "attack vectors" for approaching problems. When he got stuck, the LLM would explain the concept using metaphors from domains he already understood, like game development and telecom routing.
After each problem, he would show his code to the model and ask for a better approach. But he had a hard rule: never copy AI-generated code directly. Every solution had to be rewritten in his own variable naming style and logic flow. His reasoning was that forcing concepts through his own coding patterns mapped them deeper into muscle memory.
The progression was deliberate. Day 1 was warm-up problems like "Best Time to Buy and Sell Stock" to build basic confidence. Day 2 was a nine-hour marathon covering 15 problems across linked lists, trees, and graphs, with a 30-minute timebox per problem. By Day 3, he moved to Medium-difficulty problems and noticed something surprising: the "Easy" problems were often harder because they introduced entirely new concepts, while Medium problems were just trickier versions of patterns he had already seen.
He also noticed the LLM's context quality degraded after about five problems in a single chat session, so he started splitting conversations - one for generating problem lists, and separate short sessions for two to three problems each.
34 Problems Later
By interview day, Rudnik had completed 34 LeetCode problems (18 Medium, 1 Hard). The technical assessment combined graph traversal with binary search. He nailed the graph portion but choked on the iterative binary search syntax under time pressure - his working memory dumped the implementation pattern even though he understood the concept perfectly.
He passed anyway. Google noted he needed to "pay more attention to code debuggability" but invited him to on-site technical interviews.
What This Actually Shows About LLMs and Learning
This is a useful case study in what LLMs are genuinely good at: adaptive, personalized explanation. Rudnik points out that the model could describe algorithmic concepts using analogies from game development or telecom routing - something a static textbook cannot do and most YouTube tutorials do not bother with.
But the limitations are just as instructive. Seven days of LLM-assisted cramming gave him enough conceptual understanding to recognize problems and propose approaches, but not enough fluency to execute cleanly under pressure. The knowledge was there; the speed was not. That gap between understanding and performance under stress is something no AI tutor has solved yet.
The approach also required significant discipline from the learner. Most people using ChatGPT or Gemini for coding default to "give me the answer." Rudnik's no-code-output rule forced genuine learning instead of pattern matching against AI-generated solutions. That distinction matters enormously, and most people will not make it voluntarily.