Back to Get Hired
The technical roundNail the interview12 min read

The technical round: live coding, take-homes, and practical tests

The round that actually decides junior hires, and the one most guides skip. How to handle live problem-solving, take-home projects, and cloud/DevOps practical tasks without freezing.

On this page

The round that actually decides it

Who this is for

You can talk about yourself and your projects, but the technical screen (live coding, a take-home, or a hands-on cloud task) is the part that makes you sweat. This is how to survive it.

For technical roles, this is usually the round that decides the hire. The good news: interviewers assessing juniors are watching how you think and work, not whether you produce flawless code instantly. A calm, communicative "didn't quite finish but reasoned well" often beats a silent person who got the answer by luck.

Live coding / problem-solving: think out loud

The single biggest mistake in a live technical round is going silent. The interviewer can't read your mind, if you say nothing and get stuck, they see a blank. Narrate your thinking so they can follow (and help).

  1. 1

    Clarify before you code

    Restate the problem and ask about inputs, edge cases, and constraints. Jumping straight in is a red flag; clarifying is a green one.

  2. 2

    Talk through your plan

    Say your approach out loud before writing. They can nudge you early instead of watching you go wrong in silence.

  3. 3

    Narrate as you go

    "I'll start with the simple version, then handle the empty case." It shows structured thinking even if the code isn't perfect.

  4. 4

    If stuck, say so, out loud

    "I'm blanking on the syntax here, but the idea is…" Most interviewers will help. Suffering in silence helps no one.

Pro tip

"I don't know, but here's how I'd find out" is a strong answer, not a weak one. Juniors aren't expected to know everything, they're expected to be resourceful and honest about gaps.

Take-home assignments: scope, polish, and limits

A take-home is a chance to shine on your own time, but also a place people over-invest or get exploited. Treat it deliberately.

  1. Respect the stated time box. If it says "~3 hours," don't spend 20 polishing it to perfection, that distorts the signal and burns you out. Do the core well, then note what you'd add with more time.
  2. Make it run for them. A clear README with setup steps matters as much as the code. If they can't run it, it doesn't count.
  3. Cover the basics that signal care: a few tests, sensible naming, error handling, a note on trade-offs you made.
  4. Read the brief like a spec. Doing exactly what's asked, cleanly, beats an impressive thing that ignores the requirements.

When a take-home is too much

An unpaid take-home that demands many hours, or looks like real production work you're doing for free, is a legitimate red flag about how the company treats people. It's reasonable to ask about scope, propose a time-boxed version, or decline. Wanting to be paid for your time isn't entitlement.

Cloud / DevOps practical rounds

For infra roles the technical round is often scenario-based rather than algorithm puzzles: "walk me through how you'd deploy this," "this Terraform is failing, debug it," or "how would you investigate a service that's suddenly slow?" They're testing practical judgement and a debugging method.

  • Have a debugging method. Symptom → check logs → check metrics → form a hypothesis → test it. Naming the method matters as much as the answer.
  • Reason about trade-offs, not just "the right answer." Cost, reliability, and simplicity are usually in tension, show you see that.
  • It's fine to say "I'd look this up." Real engineers reference docs constantly; pretending to memorise everything reads as fake.

Pro tip

This is exactly what hands-on practice builds. Working in real terminals, breaking and fixing things, is what turns "I read about it" into "I can do it under light pressure." The [labs](/labs) are built for that kind of reps.

Key takeaways

  • For technical roles this round usually decides it, they watch how you think.
  • Never go silent: clarify, plan out loud, narrate, and say when you're stuck.
  • "I don't know, but here's how I'd find out" is a strong answer.
  • Take-homes: respect the time box, make it run, note trade-offs, and it's okay to push back on an unreasonable one.
  • Cloud/DevOps: show a debugging method and trade-off reasoning, not memorised trivia.

Reading is step one. Now do it for real.

Rehearse this with the platform's live tools, the first time you say it out loud shouldn't be the time that counts.

This is general, educational career guidance, not legal, financial, immigration, or professional advice. Examples are illustrative and simplified. Norms vary widely by country, company, role, and over time, so always verify what applies to your own situation. Nothing here guarantees an interview, an offer, or any particular outcome.