Most interview practice stops at a green check mark. Real interviews start there: you have written something that works, and now somebody asks you why you did it that way, what it costs, and what breaks it. That conversation is the part almost nobody practices, and it is the part people fail. This is where you practice it, with an interviewer that watches you work and a hiring manager's write-up at the end.
Take the ranked run: four puzzles in sixty minutes, typed from scratch, with the interviewer asking while you work and, once your tests pass, asking you to defend the solution before you move on. Each puzzle gets its own share of the hour, weighted by difficulty, and the interviewer checks the time against that share the way a real panel would. Or open any puzzle at level 3, where you write the solution yourself, and press Interview me. The editor clears, a clock starts against a par time set by the difficulty (fifteen minutes for easy, twenty-five for medium, thirty-five for hard), and the whole interview happens on that one problem, from the first question to the verdict.
A real interviewer is reading you the whole time, and so is this one. Sit in front of a blank editor for a minute and it asks you to think out loud. Start typing without a plan and that goes on the record. At the halfway mark it asks where you are and what is left. Rerun failing code three times in quick succession and it asks what you are changing between runs. Break through after a long pause and it asks what clicked. Finish well inside par and it asks what changes if the input were a thousand times bigger. Run past par and it asks how you would spend five more minutes.
When your tests pass, the interviewer reads the code you submitted and asks about what it finds. A loop inside a loop gets asked about quadratic cost. A function that calls itself gets asked what happens to the call stack at a hundred thousand elements. A solution that sorts the array it was handed gets asked what the caller sees afterwards. Two people who solve the same puzzle different ways get different interviews.
Answer well and it goes deeper instead of moving on. Miss the point and it narrows, pointing at the mechanism without handing over the conclusion, so the second attempt is still worth attempting. Miss twice and it stops asking and explains what it was after, which is the one thing a real interview never gives you. It also notices hedging: answer correctly but say "I think" and it will push you to commit, because sounding unsure is scored in a real interview too.
The questions are the ones real interviewers ask about working code. Time and space complexity, and the input that forces the worst case. Edge cases: an empty input, a single element, duplicates, values large enough to overflow. Why a hash map instead of a scan, and what the map costs in memory. What happens to the call stack when recursion goes a hundred thousand levels deep. What a sort costs and whether you needed the full ordering. Why two pointers never skip the answer, and what makes a binary search correct. What one cell of a dynamic programming table means, in a sentence. Whether your function changes the array the caller handed it. And, when a test fails, which case is failing and what that tells you.
Treat every session as the real thing. Say your plan and what it will cost before you write a line, because that is what gets graded before any code exists. Write the simple correct version first, then improve it, and be ready to say what the first version was doing twice. Test the smallest inputs by hand before you press Run. When the tests pass, state the time and space complexity and the input that makes it slow, without hedging. Then read the scorecard for the one area marked weakest and pick your next puzzle to practice exactly that. A few short interviews spread across a week build the habit faster than one long session.
A real technical interview is spoken, so this one can be too. Turn the voice on and the interviewer asks its questions out loud. Press the microphone and answer out loud: your words appear in the answer box so you can fix a misheard word before you send it, and nothing is recorded or kept. Or type a sentence or two, the way you would say it. There is no multiple choice anywhere in it, on purpose: the moment you list four options you have told the candidate one of them is right, and turned reasoning into elimination.
When the interview ends you get the write-up a hiring manager would send the panel. Five areas are rated from Concerning to Strong: problem solving, coding and correctness, testing and debugging, complexity and trade-offs, and communication. Every rating lists the evidence behind it, taken from what you did and what you said. A timeline shows when you wrote the first line, every test run, every question and where the time went. It closes with a verdict on the scale real hiring panels use, from No hire through Lean hire to Strong hire.
Finish a ranked run and your code is re-run on the server rather than trusted from the browser, and the result moves a Glicko-2 rating. The ladder means something because the verification is real. The interview debrief sits alongside it: which topics you answered cleanly, which needed a nudge, and which are worth going back to.
Yes. Open any puzzle at level 3 and press Interview me. You get the full interview on that one problem: a par clock set by the difficulty, questions while you work, follow-ups on your answers, and the hiring manager's scorecard when you finish or end it.
Five things a hiring panel scores: problem solving, coding and correctness, testing and debugging, complexity and trade-offs, and communication. Each is rated from Concerning to Strong with the evidence listed underneath, and the whole interview gets a verdict from No hire to Strong hire. Where an interview did not produce enough signal for an area, the scorecard says so rather than guessing.
A practice interview where software, rather than a person, asks the follow-up questions. Here it reads the code you submitted, picks questions from what that code actually does, and branches depending on how you answer, so the session adapts to you instead of running a fixed script.
The puzzle library is free to practice on and many puzzles are free to solve. Everyone gets one free interview with no account needed: two classic puzzles in twenty minutes, the live interviewer and the hiring scorecard at the end. After that, the AI interviewer, on a single puzzle or across a ranked run, is part of premium, along with its scorecard.
It judges whether your answer covers the ideas the question was testing. It is good at spotting a concept you left out and less good at judging style, so treat the debrief as a checklist of what to revisit rather than as a grade.
Yes. Turn the voice on and the interviewer reads its questions aloud. Press the microphone beside any question and speak your answer; the words appear in the box so you can check them before sending. Speaking is optional, and typing works everywhere.
Questions about the code you are writing: its time and space complexity, the edge cases it handles or misses, why you chose a particular data structure, recursion depth, sorting cost, loop invariants, and what a failing test tells you. It also asks about your process, such as your plan before you start, what clicked after a long pause, and how you would spend five more minutes.
Most coding practice ends when the tests pass. A real interview is mostly what happens around that: explaining your plan, defending your complexity, handling the follow-up. This interviewer asks those questions while you work and after you finish, and the scorecard rates the conversation as well as the code.
Python, JavaScript and C++. The interviewer reads all three, so the questions match the solution you actually wrote rather than a translation of it.
A single-puzzle interview is paced against par: fifteen minutes for an easy problem, twenty-five for a medium and thirty-five for a hard one, the way a real interview loop budgets its time. A ranked run is four puzzles in a sixty-minute window, with a few questions while you work on each and one closing question once its tests pass. You can end a single-puzzle interview at any point and still get the write-up.
Learn the patterns first in the DSA bootcamp, see what premium includes, or browse all 576 practice puzzles.