The technical interview guide.

The four formats, and which one you are facing.

Before you prepare for anything, find out what round you actually have. A recruiter will tell you if you ask, so ask in the email confirming the time: “What format is this round, and how long is it?” Two questions, one line, sent days before you need the answer. 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 is the habit: restate, narrate, commit. Rehearse it out loud before the round, on a problem you have already solved, because talking through your reasoning while you type is a separate skill from having the reasoning. 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 can give you credit for the process even when the final code is not finished.

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. Read the whole assignment before you touch a keyboard. Then, before you write a line of anything, write down what a strong submission has to contain and what you are willing to leave out of it.

Split the time box before you start the clock. Decide the hours for the build and a fixed block for the write-up, then protect the write-up block when the build runs long, even if that means shipping something smaller. An evaluator cannot grade reasoning you did not write down, and a clean explanation of a simpler solution gives them more to work with than an ambitious build with no account 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

Do not guess at the rules here. Read the assignment for a stated AI policy first. If there is not one, ask the recruiter in writing before you start and keep the reply: “Is using AI tooling in scope for this assignment, and would you like me to note where I used it?” Companies differ, the answer costs you one email, and having it in writing settles the question for both of you.

Where AI is allowed, the mistake is not using it. The mistake is presenting its output as unaided work, or leaning on it so hard that your own judgment never shows up. Say what you used it for, in a line or two in the write-up. Then make sure your own corrections, your own examples, and your own reasoning about the tradeoffs are visible in the submission, because that is the part the tool cannot supply for you. 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. Treat it like a test with one right answer and you will spend the round defending a design instead of reasoning about one. What the interviewer is grading is whether you can think 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. So draw fast, keep the boxes ugly, and spend the time you save saying why.

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. A readout that shows only the winner gives an evaluator no way to see how you chose, which is the thing they are in the room to watch.
• 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, do not 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 what you do not, 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.