Question 1

How do you approach a live coding task? Walk me through your process.

Accepted Answer

Sometimes this is asked directly (on a screening call) and sometimes it is simply read off your behaviour. Either way the answer should be a structured process. "I go in seven steps: (1) Clarify — input format, size limits, duplicates, empty input, what I return. It takes 2-3 minutes and often changes the solution itself. (2) State examples and edge cases — the expected answer on one normal example, then the boundary cases. (3) State the brute force and its complexity — so I always have a working plan. (4) Propose the optimisation with its reason — showing which repeated work it eliminates. (5) Write the code while narrating. (6) Dry-run a small example — I try to find my own bug. (7) Discuss complexity and trade-offs." Then justify the process in one sentence — that turns the answer from a memorised list into an engineering position: "This sequence is a miniature of how I work for real: I don't write code before the requirement is clear, I keep a working simple version in hand, and I optimise after measuring." If they ask "what if you run out of time", have the answer ready: "I finish the working simple solution and describe the optimisation in words. An unfinished clever solution demonstrates nothing."

Question 2

You're completely stuck in live coding and haven't moved for five minutes. What do you do?

Accepted Answer

This question tests behaviour under pressure, and the most important thing to convey is that silence is not an option. "First, I don't go silent. The interviewer can't see inside my head, so I say I'm stuck out loud: 'I'm stuck at this step — here's what I'm thinking right now...' That's honest and it gives them a chance to steer me. Then I use four tactics: (1) Shrink it — take a concrete case at n = 3 and solve it by hand. The general rule usually surfaces from the concrete example. (2) Simplify it — temporarily drop one constraint: 'let me first assume all the numbers are positive'. Solving the simplified case beats stalling, and it often opens the road to the full solution. (3) Fall back — to the brute force, then re-approach the optimisation with the question 'what work is being repeated here?'. (4) Ask for a hint — not weakness but respect for the time: 'am I on the right track, or should I look at a different approach?' That question almost always earns a useful answer." Close with time management, because that is senior behaviour: "If half the time is gone, I decide to write the working brute force and spend the rest explaining the optimisation. A working O(n²) plus a well-explained O(n) plan is far better than finishing with a blank board." If you can give a real example, do — an answer that starts "last time I was in this situation..." is always more convincing.

Question 3

While you're coding the interviewer points out a mistake. What is the ideal reaction?

Accepted Answer

This is not a technical question — it is a collaboration behaviour question, and it often weighs more than the solution itself. The ideal reaction is four steps: (1) Stop and listen — stop typing. Continuing to type while being corrected signals "I'm not hearing you". (2) Accept it without excuses — "You're right, I missed that." One sentence is enough. A long explanation or a defence costs far more than the mistake did. (3) Say out loud what it changes — "So on an empty array a[0] is undefined and the comparison silently returns false. I'll add a length check at the top." That shows you didn't just patch it, you understood it. (4) Fix it and check for siblings — "The same problem is in the loop at the bottom, let me fix that too." Drawing a systemic conclusion from one bug is a strong signal. The three worst reactions: Defending — "Actually this works, because..." (doubly bad if it doesn't) Silence — hearing the correction and saying nothing, as if you hadn't Over-apologising — "I'm so sorry, I don't normally make this kind of mistake, I'm nervous..." That moves attention from the solution to you and reads as insecure. One "you're right, fixing it" is enough One more nuance: sometimes the interviewer points at something that isn't a bug — to see what you do. Then hold your position respectfully and with reasoning: "Let me check... I think this is fine, because i runs to length - 1 and a[i + 1] is the last element. But tell me if I'm missing something." That shows both collaboration and technical confidence — better than agreeing blindly.

Question 4

Why say the brute force out loud — isn't it a waste of time?

Accepted Answer

On the contrary: stating the brute force takes 60 seconds and buys four different things. 1. It gives you a working plan at all times. If the optimal solution doesn't come together, you have somewhere to fall back to. Without it, when time runs out you have nothing — and a blank board is the worst possible interview outcome. 2. It confirms you understood the problem. While you explain the brute force the interviewer sees your reading of the task. If you misread it, it surfaces there — far cheaper than 20 minutes of coding in the wrong direction. 3. It creates the baseline for the optimisation. The sentence "this is O(n²), let me get it to O(n)" only means something against a baseline. Without one, the optimal solution invites "where did that come from?" and looks memorised. 4. Sometimes the brute force IS the required answer. If n ≤ 100, O(n²) is entirely fine and writing something elaborate is a negative signal — over-engineering. That is one reason you ask about size limits. How to say it — keep it to 30-60 seconds: "The simplest solution is two nested loops, O(n²) time and O(1) memory. With n up to 10⁵ that's too slow, so I'll try to improve it." Then move straight to the optimisation. What not to do: actually writing out the brute force (unless asked) — that really is a waste of time. Saying it and writing it are different things. Tie it to real work — this sentence strengthens the answer: "It's the same habit I have on the job: write the simple version that works, measure, then optimise if needed. Premature optimisation is one of the biggest time sinks in real projects too."

Question 5

How important is perfect syntax in live coding?

Accepted Answer

Short answer: not very — but that isn't "not at all", and the distinction matters. Why it's not very important: real work has an IDE, autocomplete, docs and a compiler. The interviewer isn't checking whether you've memorised the argument order of Array.prototype.splice — they're checking whether you can solve the problem. Small syntax slips are almost always overlooked. How to handle a forgotten API — the practical part of the answer: don't stall trying to remember. Instead, state the intent and move on: "I don't recall the exact method name here, but the logic is: remove one element starting at index i. I'll write removeAt(i) as a placeholder and fix it later." That is completely acceptable, and often the interviewer supplies the name. When it does matter: (1) when a syntax slip hides a logic bug — mixing up = and ==, say; (2) when you don't know the language's core semantics — that JavaScript's default sort compares strings, the == versus === distinction in Kotlin, that Dart's List.sort mutates in place. Those aren't syntax, they're knowledge of the language, and they are tested; (3) when the role names a specific language ("Kotlin developer"), idiomatic code in that language is expected. What is irreplaceable: readable names (left, right, seen — not i, j, temp2), consistent structure, sensible decomposition into functions. Those aren't syntax, they're style, and their value on a real team is high. Closing sentence: "Rather than perfect syntax I focus on code that reads well and can be explained — because in real work more people read the code than write it."

Step	Rough time (45-min session)	What is assessed
Clarifying questions	2-4 minutes	Not coding before checking requirements — the most important habit in real work
Examples and edge cases	2-3 minutes	A testing mindset; seeing boundary cases in advance
Brute force + complexity	2-3 minutes	Always having a working plan; naming complexity correctly
Optimisation and justification	3-5 minutes	Pattern recognition; answering "why"
Writing code (narrating)	15-20 minutes	Code cleanliness, naming, traceable thinking
Dry-run	3-5 minutes	Finding your own bug — one of the strongest signals
Complexity and trade-offs	3-5 minutes	Engineering maturity: a choice, not a single solution

The live coding process