Perfect Practice Makes Perfect
Why is every engineering allegory either a sports or military reference? This one is sports. Sorry.
After hundreds of hours of sessions, and years of studying my notes, I see a lot of patterns. Some are more blatant than others, such as today’s topic:
If you’re struggling to ace your technical interviews, you’re not practicing right.
I’ve seen it happen too many times to count. Smart engineer, multiple years of experience, has never come up against a technical challenge they couldn’t handle. Sits down for a LeetCode interview, freezes. Leaves the interview and returns to grinding dozens of problems every day. Rinses and repeats. They are wrong, and so is everyone who tells them they just need to practice more.
Everyone knows I love allegorical asides. As usual, bear with me.
I’m not one for sports- team activities never really clicked with me, and most sports didn’t do enough to engage my ADHD. I didn’t really have any hobbies as a kid that took me out of my room where my books and art supplies were.
And then I saw Rumble In The Bronx, Jackie Chan’s 1995 masterpiece. If you haven’t seen the movie, all you need to know is Jackie Chan is a badass, and if you don’t believe me, search “Jackie Chan Hovercraft vs. Lamborghini” on YouTube. Thus began an 8+ year practice of Shaolin Dragon Style Kung Fu at a world class gym above a shoe store. It was an individual practice, it tickled my brain in all the right ways, and if I ever came across a rogue Hovercraft I too could be a badass hero.
I approached this practice the way I thought anyone would: focusing on strength. I crushed pushups, practiced punching, and tried to be as loud and aggressive as I could. I was strong! I was loud! So... why did my instructors shake their heads? I was practicing every day but getting nowhere.
One day, my favorite instructor pulled me into another room. The conversation went like this:
Me: What are we doing, sparring?
Instructor Dave: No. We’re meditating.
Me: But I’m here to practice
Instructor Dave: This is practice. Perfect Practice Makes Perfect.
Me: Ok, you keep saying that, and I clearly don’t get it.
Instructor Dave: When you come in for your tests, you fail. Not because you aren’t strong. But because you aren’t confident. You aren’t mindful. You aren’t intentional.
Me: I’m confident in my strength!
Instructor Dave: Your strength covers your anxiety. Focus on being mindful. Focus on being confident. Focus on where you put your feet and your hands, not how quickly or how aggressively you do it.
The lesson I learned is that I was focusing on the “obvious” thing to practice, not the thing that would actually improve my performance. And I shit you not- that changed everything. I climbed the ranks at my school, I won a gold medal in a state tournament, and I learned how to actually harness my abilities.
Let’s talk about Technical Interview Practice.
Here’s why this story comes to mind when I’m asked “I spent 20 hours last week studying for technical interviews, and I’m getting nowhere. Am I not spending enough time?”
You’re a software engineer. You have solved every challenge you’ve come across at work, and you know that you can do that for the company that is interviewing you.
So then why are you drilling LeetCode? The only way that will result in acing an interview is if you get lucky enough to be quizzed on a problem you’ve recently studied.
Day after day, crushing mediums and hards. Two Sum. Three Sum. Sudoku Solver. Greedy. Backtracking. Increasing Monotonic Stacks.
If you get lucky and they ask you a question you studied, great. But as soon as there’s a twist in the road, a wrench to dodge, you’re back to feeling like you can’t do it. Because the one tool you brought in your toolkit just isn’t the right one.
The real issue isn’t lack of technical skill- it’s the pressure of the interview that’s short-circuiting your problem-solving ability. You’re not thinking like an engineer anymore, you’re thinking like an automaton. Engineers don’t approach each problem knowing exactly how to solve it. They look for a pattern, find it, intuit a solution, and implement it. They use reasoning and first principles, not rote memorization. They trust that they can figure it out- because that is literally the job.
Interviewers are not looking for you to memorize a solution. If they were, they’d be less coy about telling you what to study ahead of time. They wouldn’t introduce interesting modifications to their interview problems.
Rather, they want to see:
Can you think through a problem?
Can you communicate your reasoning?
Can you thoughtfully debug your own code without running it?
Can you stay calm when you don’t immediately know the answer?
Can you get excited by the challenge?
That’s engineering.
So what do you do to win?
Stop drilling LeetCode like you’re cramming for a final exam, and start building confidence in your ability to figure things out.
Here’s what I tell my clients to do instead:
Build your confidence through actual building. Build something. Anything. A tool you wish existed, a side project, a better version or even just a clone of a tool you use, a stripped down version of an app. This is how you remember that you’re an engineer and you can solve problems.
Practice thinking out loud. Explain to another engineer what you’re doing, how, and why. Or explain it to your friend who isn’t an engineer. Or your dog. Just get talking.
Embrace uncertainty. Get comfortable with “I don’t know, but I’ll figure it out”. Spend some time coding without an internet connection, or just avoid using AI or Google. Spend time being uncomfortable.
Build speed through repetition. Practice where you place your feet, not how aggressively you do it. This one is subtle but it works. Spend a day building something- a simple version of Twitter, for example (maybe one with less shitposters). Give yourself a few hours to get as far as you can, and then the next day, start again from scratch. Use the inertia of the previous day to take you further today. Eventually, you will have a completed app from start to finish in just 3-4 hours. This is how you build speed.
Do some Leetcode, but do it differently. Don’t just memorize solutions. Use different problems every day. Write your own tests to make sure you understand the problem. Give yourself permission to struggle, and remind yourself over and over “I can do it”. Figure it out. Build confidence.
And before your next interview, focus on coming in not with all the answers, but with a calm, confident mindset. One that will guide you to the answers. Don’t worry about “How will I memorize all these algorithms?” Instead, focus on “How can I remove any doubt that I can figure this out?”
That’s the problem worth solving.