Live Coding and Project Explanation Rounds

The live coding round

You are given a task and a time limit, usually with someone watching. It is uncomfortable and it is not testing what most candidates think.

What is actually assessed

Being stuck is expected. What is assessed is what you do next: whether you narrow the problem, whether you say what you are thinking, and whether you ask.

Tasks that get set

Fifteen to twenty minutes

1. Mark up a recipe with ingredients, method and timing.
2. Build an accessible navigation bar with the current page marked.
3. Build a form with five fields, labels and validation.
4. Mark up a table of results with headers on both axes.
5. Build a card component that is entirely clickable.
6. Take this page and fix its heading structure and alt text.

Thirty to forty five minutes

7. Build a responsive card grid from a screenshot.
8. Build a disclosure or accordion component, and justify your approach.
9. Take this inaccessible page and fix it without changing how it looks.
10. Build a form with an accessible error summary.
11. Make this eight column table usable on a phone.
12. Add complete metadata and structured data to this page.

How to run the round well

Before you type

• Restate the requirement in your own words. It catches misunderstandings immediately and buys thinking time.
• Ask what matters most. Should I prioritise the markup or get something on screen?
• Ask about constraints. Framework, browser support, whether it must work without JavaScript.
• Say your plan out loud. Thirty seconds naming the structure you intend to build.

While you work

• Structure first. Get the semantic markup down before any styling. If time runs out you have the part being assessed.
• Narrate. I am using a button here rather than a div because it needs to be keyboard operable. This is where most of the marks are.
• Open the browser early and keep checking.
• Say when you are unsure. I think it is aria-expanded but let me check is a good answer.
• Do not silently panic. Say what you are stuck on. The interviewer will usually help, and how you ask is part of the assessment.

Before you finish

• Tab through it. It takes twenty seconds and interviewers notice.
• Say what you would do with more time. It shows you know what is missing.
• Name one thing you are not happy with.

The project explanation round

You are asked to walk through something you built. This is where junior candidates most often undersell themselves.

The structure that works

1. What it is, in one sentence. Who it is for and what it does.
2. Why you built it. A real reason is better than to learn HTML.
3. Three decisions. Not features - decisions. Where you chose between two options and why.
4. One problem. Something that did not work, how you diagnosed it, how you fixed it.
5. One regret. What you would do differently now.

Three minutes. Practise it out loud until it flows.

Questions you will be asked about it

1. Why did you use that element there?
2. What would happen if JavaScript failed to load?
3. How does this behave on a phone?
4. Is it accessible? How do you know?
5. What is the largest thing on the page and how long does it take to load?
6. How would you add a new page to this?
7. What was the hardest part?
8. What would you change if you had another week?
9. How did you decide on this structure?
10. Did anyone else use it? What did they say?

Question 1 is asked constantly and is the reason to be deliberate about element choice in everything you build. Why did you use a div there? has only one good answer: because nothing meaningful applied.

Undersell traps to avoid

• It is only a small project. Never open with this. Describe what it does.
• I followed a tutorial. If you did, say what you changed and why.
• I did not have time to do it properly. Say what you prioritised instead, and why that was the right call.
• It is not finished. Nothing is. Say what state it is in and what is next.

If you cannot answer something

Say so, then say how you would find out. I am not certain how that behaves in Safari - I would check the support table and then test it.

This scores better than guessing. An interviewer knows the answer; a confident wrong one is far more damaging than an honest gap, because it raises the question of what else you might be confidently wrong about.

Practice

1. Set a timer for twenty minutes and complete task 3 while narrating out loud.
2. Record your project walkthrough and listen for underselling.
3. Have someone ask the ten project questions without warning.
4. Do one live coding task with someone watching, and note where you went quiet.