Before You Solve Another Interview Question, Try This 45 Minute Mock

One complete attempt, a useful debrief, and a much clearer idea of what to practice tomorrow.

Finishing a practice question can feel wonderfully reassuring, especially when the green checkmark arrives before your coffee gets cold.

But close the solution tab, start a timer, and explain your decisions out loud, and suddenly you are practicing something a little different.

Now you have to notice an ambiguous requirement, choose an approach, recover from a wrong turn, and leave enough time to check your work. Nobody has conveniently highlighted the part where your reasoning went sideways.

That gap interests me much more than the number beside a solved-problems counter.

Before adding another question to the pile, I prefer one practice session that leaves behind evidence of what actually happened. You can run it alone, and you do not need an elaborate setup or a friend who is free at exactly the right time.

Give yourself 45 minutes for the attempt, then another ten for the review. Those timings are a practice proposal, not a company’s interview format or a pass/fail rubric.

Set up a session you cannot accidentally turn into a tutorial

Choose a problem you have not recently solved, in a language you already use. Something modest is fine. An unfamiliar implementation of a familiar idea can reveal more than a famously difficult problem whose solution you remember.

Open a blank editor and a scratchpad. Decide which tools are allowed before starting, ideally using the rules for your upcoming interview. For an unaided baseline, keep AI assistance and solution tabs closed. If you use a reference or hint, record what it supplied instead of quietly rewriting the story afterward.

Talking through your decisions helps make the attempt reviewable. A private audio recording is optional; timestamped notes work too. You only need to capture moments such as when you settled the contract, chose an approach, found a bug, or changed your mind.

Microsoft’s technical interview guidance explicitly discusses clarifying ambiguity, planning a solution, and testing it. So this practice includes the work around the code, too.

For an accessible practice option, this session-log exercise asks you to count sessions per user from possibly unsorted event logs. Its full prompt, constraints and examples are publicly readable. You can use it with the timing plan below and review your attempt against its own rules.

The worked examples below use a separate sign-in/sign-out exercise, which you can attempt directly from this prompt. Given chronological log records of the form user_id timestamp action, with integer user IDs, integer timestamps in seconds and actions sign-in or sign-out, return each user who has at least one completed session lasting at most a nonnegative duration limit, once, in ascending numerical order. Each user can have several sessions, has at most one open session at a time, and every sign-in has a matching sign-out. Events from different users can overlap. Return an empty list when nobody qualifies.

For a clean attempt, choose either the linked counting exercise or the self-contained sign-in/sign-out exercise and run the mock before reading the worked debrief below. The sign-in/sign-out details in that debrief apply to the self-contained exercise. If you already know the problem you chose, pick a different one rather than timing your memory.

Give each part of the attempt a visible finish line

Minutes 0–5 should leave you with a contract

Write down the input, output, and a rule that could change the answer. Then predict the result of one tiny example before touching the keyboard.

For the session exercise, users qualify when any completed session is short enough. That is different from requiring every session to be short. Results must contain each qualifying user once, in ascending numerical order.

Also notice what the prompt already guarantees. Logs arrive chronologically, and each user’s sign-ins and sign-outs are well formed. You can mention those assumptions without spending your practice time designing a repair system for malformed logs.

By minute five, another person should be able to read your notes and understand what your function promises.

Minutes 5–12 should leave you with an explainable plan

Describe a straightforward approach first, even if you expect to improve it. Walk through a small input and say what information must survive from one step to the next.

For this exercise, ask yourself how an overlapping session from a second user affects the information you need to remember. Explain why the state belongs to a particular user rather than to the log as a whole.

Do not settle for naming a data structure. Explain what one entry means and when it changes. That sentence is often where a fuzzy plan becomes a plan you can implement.

If you are stuck, write down the exact obstacle. Being unsure how to match events needs a different next step from being unsure how to sort the result.

Minutes 12–30 should leave you with a working path

Implement the approach you can currently defend. Keep the function close to the contract and resist building helpers for situations the prompt explicitly excludes.

When something breaks, describe the smallest input that exposes it before changing the code. Otherwise, a quick fix can become a little guessing game with very convincing variable names.

If you need a hint, pause long enough to note the missing idea. Continue afterward, but mark that part of the attempt as assisted. There is useful information in both an independent solution and a solution completed with one well-chosen nudge.

Minutes 30–40 should leave you with justified tests

Predict expected outputs before running the cases. A program agreeing with your intuition is not much evidence if your intuition made the same mistake as the program.

Start with the smallest meaningful boundary, then use a case that distinguishes two plausible interpretations. For the session problem, equality with the duration limit matters, and so does a user who has a long session followed by a short one.

If the implementation is unfinished, test the completed part or trace the intended behavior. Do not erase ten minutes of review just to make the function look finished.

Minutes 40–45 should leave you with an honest explanation

Explain why the approach works, its time and memory costs, and one limitation that comes from the assumptions. Include the cost of producing the required output rather than stopping your analysis at the main loop.

Finish by stating what remains unverified. That might be a boundary case, an incomplete branch, or a complexity claim you have not worked through yet.

When the timer ends, preserve the code as it is. You can improve it afterward, but save the original attempt so the review has something real to examine.

Review the first wrong turn, not just the final answer

Here is why I like the session exercise for a debrief. Suppose the limit is five seconds and user 2 has sessions lasting 18 seconds and two seconds.

That user qualifies because the second session satisfies the rule. If your implementation excludes them, another hour of typing faster will not repair the original misunderstanding.

Now trace a few other claims independently.

• A session from time 10 to time 10 qualifies when the limit is zero, because its duration is zero.
• A session lasting exactly five seconds qualifies when the limit is five, so a strict less-than comparison is wrong.
• Two qualifying sessions for the same user still produce one user ID.
• If user 7 qualifies before user 2, the output must still place 2 before 7.

These cases help locate the break. Misreading the rule is a contract problem. Understanding the rule but writing the wrong comparison is an implementation problem. Never checking equality is a testing gap. They can produce similar symptoms, but they deserve different practice.

For a typical dictionary-and-set solution, scanning n events takes expected O(n) time, while sorting k qualifying IDs adds O(k log k). Storage grows with the users tracked and the qualifying IDs. If your explanation stopped at linear time, the output-order requirement gives you something precise to revisit.

Replace your verdict with three pieces of evidence

Please do not finish this session by declaring yourself terrible at interviews. That is an enormous conclusion to squeeze out of one function and a timer.

Use ten minutes to write three short notes instead. Each note should connect an observation to a next action.

Record the moment. Perhaps you spent 12 minutes discussing approaches before tracing a single example, or only noticed the output needed sorting after the timer ended.

Name the skill involved. Was the missing piece contract reading, choosing state, implementing a known plan, testing boundaries, or explaining complexity? Treat this as a working diagnosis, not a permanent label.

Choose a smaller repair. If you missed the word any, spend the next session turning requirements into examples and counterexamples. If dictionary operations interrupted your reasoning, practice those operations in your chosen language before another full mock.

For instance, an illustrative review note could say that at minute 34, a zero-duration test failed because the comparison excluded equality. The next action is to write boundary cases before implementation on an unfamiliar problem.

That note gives tomorrow a job. Feeling disappointed, unfortunately, does not.

Make the next attempt answer one question

Fixing today’s code is useful, but solving it again immediately mostly tells you whether you remember the repair.

After working on the gap, choose a fresh problem that uses the same skill in a different setting. If contract reading caused trouble, pick a prompt where exactly one, at least one, or all changes the result. If testing was weak, prepare expected outputs before execution and check whether you actually did so.

Keep a tiny practice record with the problem, the observed gap, the repair, and the evidence from your next attempt. There is no need to turn your evening into a project-management ceremony.

Also be fair about what a solo mock can tell you. It cannot reproduce another person’s interruptions or judge every aspect of your communication. A partner can help with those later. What you can inspect alone is whether you made assumptions visible, defended your choices, and checked the behavior you promised.

I want preparation to leave me with more than a comforting counter. A finished session should make the next one easier to choose.

So before opening another random question, save one honest attempt and find the first place where your reasoning needed help. Then give that specific gap your attention, because now you actually know what you are practicing.

~ Emily