The technical interview guide.

The four formats, and which one you're facing.

Before you prepare for anything, find out what round you actually have. A recruiter will tell you if you ask, and the format changes what good preparation looks like more than the role title does.

• Live coding. A synchronous session, in person or on a shared screen, where you solve a problem while someone watches. Common for engineering roles at every level.
• Take-home assignment. A self-directed task with a deadline, days rather than minutes. Common for engineering, data, product, and increasingly marketing and analytics roles.
• System design. A whiteboard or virtual-whiteboard session where you design a system out loud, usually for mid-level and senior engineering roles.
• Case study. A business problem you work through and present, live or as a write-up. Standard for product management, and common for data and marketing or analytics roles that never touch a line of code.

None of these are a knowledge quiz. Every one of them is watching how you think when you do not already know the answer, which is the actual job.

Live coding: thinking out loud under pressure.

The biggest mistake in a live coding round has nothing to do with code. It is silence. An interviewer watching you think in total quiet has no way to tell the difference between “working through a hard problem” and “stuck and out of ideas.” Both look identical from the outside. Your job is to narrate the difference.

“I am going to start with the simplest version of this and get something working, then improve it. Let me restate the problem to make sure I have it right, then talk through two approaches before I pick one.”

That single habit, restate, narrate, commit, does more for how you come across than any amount of algorithm memorization. State your understanding of the problem before you start. Say which approach you are choosing and why. When you change your mind mid-problem, say that out loud too. An interviewer who can follow your reasoning will give you partial credit for a good process even when the final code is not perfect.

When you get stuck

Getting stuck is not the failure. Going quiet is. When you hit a wall, say so plainly: “I am stuck on this part, let me think through what I know and what I do not.” Then narrow the problem: try the smallest input, try a brute-force version first, or ask a clarifying question you should have asked earlier. Interviewers expect false starts. What they remember is whether you recovered with a method or froze.

Take-home assignments: scope, write-up, and AI.

A take-home is a time-management test wearing the costume of a skills test. The most common failure is not a weak solution, it is running out of time to explain the solution well. Read the whole assignment before you touch a keyboard, and before you write a line of anything, decide what a strong submission actually needs to include.

Budget your hours on purpose. If you have a time box, spend real minutes deciding the split before you start the clock, rather than building until time runs out and writing whatever is left. Evaluators cannot grade thinking they cannot see, and a clean, well-reasoned write-up on a simpler solution beats an ambitious build with no explanation of the tradeoffs behind it.

What a strong write-up includes

• What you assumed. Every take-home has ambiguity. State the assumptions you made to resolve it, rather than silently picking one interpretation.
• What you would do with more time. A short, honest list shows you know the gaps in your own submission, which reads as maturity, not weakness.
• Why you chose what you chose. The reasoning behind a decision is worth more to an evaluator than the decision itself.

The honest line on using AI

Most evaluators today assume you have access to AI tools and design the assignment with that in mind. The mistake is not using AI. The mistake is presenting AI output as unaided work, or leaning on it so heavily that your own judgment never shows up in the submission. Use it transparently: say what you used it for, and make sure your own experience, corrections, and specific examples are visible throughout, not just AI-generated generalities. Orbyt's guide to demonstrating AI skills in a take-home goes deeper on how to document your process without it reading as a confession.

System design: tradeoffs beat a correct answer.

There is no single correct architecture in a system design interview, and treating it like a test with one right answer is the most common way to underperform in it. What the interviewer is actually grading is whether you can reason about tradeoffs out loud under ambiguity, which is the real shape of the job once you are hired.

1. Clarify requirements first. Ask about scale, read versus write patterns, and what matters most: latency, consistency, or cost. Do not start drawing boxes before you know what you are optimizing for.
2. State your assumptions out loud. If the interviewer does not give you a number, pick a reasonable one and say so, so your design has a stated target instead of a guessed one.
3. Name the bottleneck before you fix it. A design that jumps straight to a solution without naming what breaks first reads as memorized, not reasoned.
4. Say what you are giving up. Every real choice trades something away. A candidate who says “this gets us lower latency at the cost of eventual consistency, which is fine here because...” is doing the actual job of the round.

A rough diagram with clearly reasoned tradeoffs beats a polished diagram with none. Interviewers have seen the polished-but-hollow version too many times to reward it.

Case studies: the format for PM, data, and marketing.

A case study is a system design interview for people who do not write code. You get a business problem, sometimes with a dataset attached, and you have to reason through it and present a recommendation, whether that is live in the room or as a write-up you walk through.

The instinct to fight is jumping straight to a conclusion. Lead with your recommendation if the format calls for it, but the actual grade comes from the reasoning that follows, not the headline. Structure the readout the same way every time:

• State the problem as you understood it. Confirm you are solving the right thing before you show how you solved it.
• Name your key assumptions. Especially where the prompt was ambiguous or the data was incomplete.
• Walk through two or three options. Including the ones you rejected, and why. This is the part most candidates skip, and it is the part that shows structured thinking.
• Give your recommendation and its risk. No recommendation is risk-free. Naming the risk honestly is a stronger close than pretending there is none.

An evaluator watching a case-study readout is not asking “did they get the right answer.” Business problems rarely have one. They are asking “would I trust this person's reasoning on a problem where I do not already know the answer myself.”

After the round: following up and recovering from a fumble.

Every format ends the same way: you send a thank-you and you wait. If the round went well, keep the follow-up short and specific, referencing something real from the conversation rather than a generic thank-you note.

If you know you fumbled a section, a short, honest follow-up can still help. Name the miss plainly and add the better answer you would give now:

“Thank you for the conversation. On reflection, I do not think I gave the strongest answer on the caching question. What I would say now is [the better answer]. Wanted to make sure that was on the record.”

This will not erase a weak round on its own, and it is not a substitute for preparing well in the first place. But it gives the interviewer one more data point beyond the stumble, and it costs you five minutes to send. Track every round, what format it was, how it went, and what you would do differently, in one place so the pattern is visible across your search rather than lost after each individual conversation. If you are running your search in Orbyt, that note lives right next to the role it belongs to.

Walking into any technical round: six steps.

The same six moves apply whether you are coding live, writing up a take-home, or presenting a case study. This is the checklist version of everything above.

1. Identify the format before you prepare. Ask the recruiter what the round actually is: live coding, a take-home, a system design session, or a case study. Each rewards different behavior, and preparing for the wrong one wastes your time.
2. Narrate your thinking, don't just produce an answer. In any live round, say what you are trying, why, and what you expect to happen. The interviewer is grading your reasoning as much as your final answer, and silence gives them nothing to grade.
3. Scope a take-home to the time you were given. Read the assignment fully before opening any tool. Decide what a strong submission looks like, budget your hours across building and writing, and stop when the time box ends rather than chasing a perfect version.
4. State your tradeoffs out loud in design and case rounds. Whether it is a system or a business decision, name what you are optimizing for, what you are giving up, and why. A stated tradeoff is worth more than a confident answer with no reasoning behind it.
5. Handle being stuck with a method, not silence. When you hit a wall, say so, name what you know and don't know, and try the simplest version of the problem. Recovering with a visible process is what interviewers remember, not the stumble itself.
6. Follow up honestly if you know you fumbled. A short note naming the miss and adding the better answer shows self-awareness. It will not undo a weak round, but it gives the interviewer more to go on than the stumble alone.

Common questions.