What Technical Rounds Look Like and How to Solve Out Loud

In an assessment, the platform sees only your final code. In a live interview, a person watches you get there. Two candidates can write the same correct solution and receive opposite feedback: one explained the problem back, considered two approaches, chose one with a reason, tested an edge case and stated the complexity; the other typed in silence for twenty minutes and said "done".

Interviewers are trying to imagine working with you. Your reasoning, made audible, is most of what they evaluate. This article covers the rounds you will meet and a method that makes your thinking visible.

• The kinds of technical rounds freshers face, by kind of employer.
• A six-step method for any live coding problem.
• What useful thinking aloud sounds like.
• How to recover when stuck, and how to use hints.
• How to handle take-home assignments, fundamentals questions and project deep-dives.
• How to practise, including with AI.

Processes vary by company and change over time; ask the recruiter (article 27). Typical patterns:

Across all of them, two things recur: solving a problem while explaining, and explaining your own project in depth.

A widely taught version of this method is called UMPIRE: Understand, Match, Plan, Implement, Review, Evaluate. The names matter less than the habit of doing all six.

Restate the problem in your own words and confirm it. Ask about anything unclear:

• Input size and ranges. Can values be negative? Can the input be empty?
• What to return if there is no answer.
• Whether the input is sorted, unique or can be modified.

Work through the given example by hand, and try one small example of your own.

Say which pattern it resembles and why: "We need the longest contiguous range satisfying a condition, which suggests a sliding window." If nothing matches, say so and start from brute force.

Describe the approach before coding, including its complexity: "I'll keep a map of counts in the window and move the left pointer while there are more than k distinct characters. Each character enters and leaves once, so O(n) time and O(k) space." Ask: "Does that sound reasonable, or should I start with something simpler?"

Many interviewers will tell you at this point if you are heading somewhere unproductive. That is a gift; take it.

Write clean code with meaningful names, narrating the main steps, not every keystroke. If the editor has no autocomplete, write what you know and say when you are unsure of an exact method name ("I believe it's getOrDefault; I'll use that and check").

Before saying "done", trace your code with the example, line by line, out loud. Then try an edge case: empty input, one element, all equal. Find your own bugs before the interviewer does; it is one of the strongest signals you can give.

State the time and space complexity and why. Mention what you would improve with more time, and how the solution changes if constraints change ("if the data didn't fit in memory, I would…").

Useful narration explains choices and trade-offs:

If you need a moment to think, say so: "Can I take thirty seconds to think about this?" Silence that you announce is fine. Unexplained silence is hard for an interviewer to read.

Getting stuck is normal and expected; interviewers often choose problems where most candidates struggle somewhere. What they watch is how you handle it.

1. Say where you are. "I have an O(n^2) approach. I think it can be faster because we recompute sums; I'm looking for a way to reuse them."
2. Fall back to brute force. Code a correct, slow solution if you have time. It shows you can deliver, and optimising from working code is easier.
3. Try small examples and look for a pattern in them.
4. Accept hints gracefully. If the interviewer suggests something, build on it ("That's useful: if we keep prefix sums, the range sum becomes a subtraction") rather than ignoring it or defending your old approach.

Startups often send a small project to build in a few hours or days.

• Read the brief twice and list the requirements. Ask questions early if something is unclear.
• Scope honestly. Deliver the core requirements well before adding extras.
• Show engineering judgement: sensible structure, input validation, error handling, a few meaningful tests and a README with how to run it, your assumptions, the trade-offs you made and what you would do with more time.
• Respect the time guidance. If they say three hours, a solution that obviously took three days can count against you. Note in the README how long you spent.
• Follow their rules on AI tools. Some companies allow AI assistance, some forbid it, some ask you to disclose it. If allowed, you must still understand and be able to explain every line; the follow-up interview usually walks through your code.

Many interviews, especially at capability centres and services companies, ask core CS questions. Prepare them through your own project, which makes the answers concrete:

Expect an interviewer to pick one project from your resume and go deep: "Why this database?", "What happens if two users book the same slot?", "How would it handle a hundred times the users?", "What would you change?" Your decisions file (article 7) is your preparation. Practise explaining your project in two minutes, then in ten, and answer the "why" behind every major choice.

• Use a plain editor at least once a week, without autocomplete, to mimic shared interview editors.
• Time yourself on the six steps: aim to reach the plan within the first ten minutes of a 45-minute problem.
• Record yourself solving one problem aloud each week, and listen for silence and vague narration.
• Practise with people where you can (article 33): peers, seniors, mock interview platforms.

After you solve a practice problem, ask an assistant to review, not to solve:

Here is a practice problem and my solution, with the complexity I stated.1. Is my complexity analysis correct? Walk through the code to justify it.2. List edge cases my code fails, with the input and expected output.3. What would an interviewer likely ask as a follow-up?4. Comment on readability: names, structure, anything confusing.Do not rewrite the whole solution.[problem, my code, my stated complexity]

Then run the edge cases it lists. Assistants sometimes claim a bug that is not there, so trust the run, not the claim.

Problem: "Given a list of meeting intervals, find the minimum number of rooms needed."

• Understand: "So intervals are start and end times, and I need the maximum number of meetings happening at once? If one ends at 10 and another starts at 10, do they conflict?" (Interviewer: no.)
• Match: "This feels like an interval problem: sort by start, and track ongoing meetings."
• Plan: "Sort by start time. Keep a min-heap of end times for rooms in use. For each meeting, if the earliest-ending room is free by this start, reuse it; otherwise add a room. The answer is the heap's maximum size. O(n log n) time, O(n) space. Does that sound right?"
• Implement with narration.
• Review: traces the meetings (0, 30), (5, 10) and (15, 20) and gets 2; tries (1, 5) and (5, 10) and gets 1, matching the clarification.
• Evaluate: states the complexity; mentions an alternative of sorting start and end times separately with two pointers.

Even if a bug had appeared, the interviewer would have seen a clear thinker.

• Coding immediately without clarifying or planning.
• Long silences or vague narration.
• Saying "done" without tracing an example.
• Ignoring or arguing with hints.
• Not knowing your own project's design choices.
• Wrong complexity stated confidently. "I believe it's O(n log n) because of the sort" is better than a confident wrong answer.

• Next: Machine Coding and Low-Level Design for Freshers prepares the round most freshers have never practised.
• For a step-by-step coding interview workflow, see The Interview Problem-Solving Workflow.
• For Java-specific interview questions, see Java Interview Concepts, Part 1: Core Java, Collections, Functional Java, the JVM and Concurrency.