If you've ever prepared for technical interviews, you know the drill: LeetCode grinding, watching YouTube explanations, and the constant hunt for someone to do mock interviews with.
The problem? Good mock interview partners are hard to find. Paid services like Pramp matching can be hit-or-miss. Professional mock interviews cost $100-300 per session, not exactly student-friendly. And practicing alone means you miss out on the most important part: the back-and-forth dialogue that real interviews demand.
I stumbled onto something that's been working surprisingly well for me, and I wanted to share it in case it helps anyone else in the same boat.
The Setup
I've been using Claude as my mock interviewer. Not just to solve problems, but to actually simulate the interview experience, complete with clarifying questions, hints when I'm stuck, pushback on my approach, and follow-up questions.
Here's how simple it is to start. I paste the problem, then add one line:
"I want you to act as my interviewer who has asked me this question and we carry on from there"
That's it. From there, it stops being a "give me the answer" interaction and becomes an actual interview simulation.
What This Actually Looks Like
Let me walk you through a real example. I was practicing the Skyline Problem, a classic hard problem involving buildings, coordinates, and finding the silhouette outline.
Starting the Conversation
I pasted the problem and asked Claude to act as my interviewer. Instead of jumping to a solution, it responded like an actual interviewer would:
"Alright, so I've just walked you through the Skyline Problem. Before you dive into coding, I'd love to hear your initial thoughts. Take a moment to think about it. How would you approach this problem? Feel free to ask any clarifying questions if something isn't clear, or walk me through your thought process."
No solution. No hints yet. Just: "What are you thinking?"
The Back-and-Forth
I started explaining my understanding of the problem, that we need to find "key points" where the skyline height changes. The response pushed me further:
"That's exactly right, you've nailed the problem understanding... Now here's where it gets interesting. What makes this problem tricky? Think about it: if you had just one building, it's trivial, just two key points. But when buildings start overlapping, hiding behind each other, or sharing edges... What's your intuition for how to handle those overlapping cases?"
This is exactly what happens in real interviews. You give an answer, and they probe deeper.
Getting Unstuck (Without Being Handed the Answer)
When I was circling around the right idea but not quite landing on it, instead of just telling me "use a heap," I got this:
"You're circling around the right ideas, but let me push you to be more precise... Say you're at some x-coordinate and three buildings are currently overlapping there with heights 10, 25, and 15. What determines the skyline height at that point? And now, what happens if the building with height 25 ends? How do you quickly know what the new skyline height becomes?"
That question made me arrive at "max-heap" on my own. Much more memorable than being told.
Catching My Mistakes
When I wrote pseudocode that iterated through every x-coordinate from 1 to the last building's edge, I got called out:
"Look at the constraints again:
0 <= lefti < righti <= 2³¹ - 1. The x-coordinates can go up to about 2 billion. You can't iterate through every integer, that would be catastrophically slow."
A real interviewer would catch this. And now I'll never make that mistake again.
Handling Edge Cases
One subtle issue I hadn't considered: what happens when multiple buildings start at the same x-coordinate? The response walked me through why processing order matters:
"When multiple events happen at the same x, the order you process them matters. Consider: Building A ends at x=5 (height 20), Building B starts at x=5 (height 15). If you process the end before the start, you might record a drop to 0, then immediately a rise to 15, creating a spurious key point."
Then it gave me a concrete technique (negative heights for sorting) rather than just pointing out the problem.
Code Review
After I wrote my solution, it traced through an example to verify correctness, then asked for complexity analysis:
"One last thing before we wrap up. Can you give me the time and space complexity analysis? Think about: How many events do you create? What's the cost of sorting them? What's the total cost of all heap operations?"
Just like a real interview would end.
Follow-Up Questions
After solving it one way, I got asked about an alternative approach:
"There's actually an alternative approach to this problem using divide and conquer (similar to merge sort)... Want to explore that, or move on to a different problem?"
I said yes, and we worked through that too, including debugging my merge logic when I had bugs.
Why This Works (For Me)
A few things make this effective:
It's not just Q&A. The back-and-forth forces me to articulate my thinking, which is half the battle in real interviews.
I get unstuck without being handed answers. The hints are calibrated: enough to nudge me forward, not so much that I skip the learning.
My bugs get caught. Subtle issues like off-by-one errors, wrong comparisons, or algorithmic flaws get flagged with explanations.
I can go deep. If I want to explore multiple approaches to the same problem, I can. No time pressure.
It's always available. 2 AM on a Sunday? No problem. No scheduling, no awkward small talk.
Tips I've Picked Up
The prompt matters. Simply asking "solve this problem" gives you a solution. Asking it to "act as my interviewer" changes the dynamic completely.
Talk through your thinking. The more you explain your reasoning, the better the follow-up questions and feedback.
Don't skip to code too fast. Just like in real interviews, spend time on approach before implementation.
Ask for complexity analysis. Make it a habit to end with Big O discussion. Interviewers almost always ask.
Explore alternative solutions. After solving a problem one way, ask if there are other approaches. This builds flexibility.
What This Isn't
I want to be clear about something: this is just what's worked for me personally.
I'm not saying this is better than practicing with humans. It's not a replacement for that. Real human mocks have their own value: reading body language, handling pressure, getting feedback on communication style.
What I am saying is that this has been incredibly useful as a first line of preparation. When you can't find a partner, when you can't afford paid mocks, or when you just want more reps, this fills that gap.
There might be better ways to do this. Other people might have different approaches that work better for them. I just wanted to share what's been helping me, in case it helps someone else too.
Getting Started
If you want to try this yourself:
- Pick a problem (LeetCode, HackerRank, wherever)
- Paste the problem statement
- Add: "I want you to act as my interviewer who has asked me this question and we carry on from there"
- Engage like it's a real interview: explain your thinking, ask clarifying questions, talk through trade-offs
That's really all there is to it.
Good luck with your prep. Feel free to reach out if you have questions or want to share your own experience with this approach.
Top comments (0)