Free Online Whiteboard
The canvas above is free, opens instantly, and needs no account. This guide covers what a whiteboard round is actually testing, how to structure a system design answer on an empty canvas, the keyboard shortcuts that make drawing keep pace with talking, how to run a remote pair session, and where your drawings live.
An online whiteboard is a shared blank canvas for drawing boxes, arrows, and labels while you talk. In technical interviews it is used for system design and architecture discussions, where the diagram carries the answer. It replaces the physical whiteboard in a remote interview, and it is the right tool for design rounds rather than coding rounds.
The whiteboard above is free, needs no account, and opens on a blank canvas. It is built on Excalidraw, so shapes get a hand drawn look that is deliberately rough. That roughness helps in an interview, because a sketchy diagram reads as a work in progress and invites the interviewer to push on it, while a polished diagram reads as a finished answer nobody is meant to question.
The most common mistake is treating the canvas as the answer instead of as a record of the conversation. Interviewers score the reasoning, not the drawing. A clean diagram with no stated tradeoffs loses to a messy one where you explained why you chose a queue over a direct call and what breaks when the queue backs up.
A design interview looks like a drawing exercise and is actually a communication exercise. The interviewer wants to know whether you can take an ambiguous problem, decide what matters, choose between imperfect options, and explain the choice to someone who will have to maintain it. The canvas is only the medium.
That has a practical consequence for how you use the whiteboard. Every mark should either record a decision or ask a question. Boxes with no labels, arrows with no direction, and clouds labelled with a vendor name record nothing. A rectangle labelled write service with an arrow labelled one row per event pointing at a store labelled events, partitioned by user id records four decisions in one glance.
The second thing under test is scope control. A senior candidate narrows an open question quickly, says which parts they are deliberately ignoring, and keeps the diagram small enough to reason about. A weaker answer tries to cover everything and produces a canvas nobody, including the candidate, can walk through by the end.
The third is honesty about limits. Interviewers are used to candidates who know one architecture and bend every question towards it. Saying that you have not run a system at that scale, then reasoning from what you have run, scores better than confidently inventing operational detail. If you get pressed on something you do not know, say so and say how you would find out.
A blank canvas is the hardest part of a design round, because there is no prompt telling you what to do first. This is an order that works, and the first step is not drawing.
Start by writing text, not shapes. Put the question at the top of the canvas, then list the functional requirements underneath it and the non functional ones beside them. Read them back to the interviewer and ask what you have missed. Candidates who start drawing immediately end up redrawing, and redrawing burns the clock.
Reserve a corner of the canvas for scale estimates and leave them visible for the rest of the interview. Daily active users, writes per second, reads per second, average object size, and total storage per year. You will refer back to these when you justify a cache, a shard, or a queue.
List three or four endpoints or operations as plain text: the name, the inputs, and what comes back. This is the smallest amount of drawing that pins down what the system actually does, and it stops the classic failure where a candidate produces a beautiful box diagram that does not support the feature they were asked for.
Client, edge, service, store. One row, four or five boxes, arrows in the direction data flows. Nothing else yet. Say the sentence out loud as you draw it: a request comes in here, this service validates it, it writes here, and the response goes back. If you cannot say the sentence, the diagram is wrong.
This is where design rounds are won and lost. State what the primary entities are, what the access patterns are, and which store fits them. Then give the reason. A relational store because you need transactions across two entities. A key value store because every read is by a single known key and you need it in single digit milliseconds.
Now bring in caches, queues, replicas, and shards, and attach each one to a number from step two. A cache because the read to write ratio is a hundred to one. A queue because the write path calls a slow third party. Sharding because a single node cannot hold a year of data. Every added box should have a stated reason.
Pick the component most likely to fail and trace what happens with your finger on the canvas. The cache goes cold. The queue consumer dies. A region drops. Say what the user sees, what recovers automatically, and what needs a human. This is usually the highest scoring five minutes of a design interview and most candidates never get to it.
Spend the last two minutes stating what you traded away and what you would build differently with more time or more information. This is not a confession, it is the part that shows judgement. Then export the canvas so you can review it afterwards, because your own diagram is the best study material you will get.
The interviewer controls whether a design round produces a signal or a mess. The most common failure is a question so open that the first ten minutes are guesswork, followed by a rushed second half. Give the candidate a concrete brief, one sentence of context about the constraints you care about, and a clear statement of how long they have.
Say up front what you want to see. Something like: I care most about the data model and the write path, and I would rather go deep on those than cover everything. That is not making it easy, it is removing the part of the exercise that measures mind reading rather than engineering.
Then stay quiet and let them draw. Interrupting a candidate mid diagram is the fastest way to lose the signal you are looking for, because they will start optimising for your reactions instead of the problem. Note the questions you want to ask and ask them when a section is finished. If they go badly wrong, one nudge is fair and three is coaching.
Push on one thing deeply rather than five things shallowly. Pick the component they are most confident about and ask what happens when it fails, how they would migrate it, or what they would do at ten times the volume. Depth separates candidates. Breadth mostly separates who has read the same blog posts as you.
Finally, write your notes before you talk to anyone else, and write them against the behaviours you saw rather than an overall feeling. Requirements clarified without prompting. Chose a store and justified it with the read pattern. Did not consider what happens when the cache is cold. Notes in that form are usable in a hiring discussion. A number out of ten is not.
Speed on a canvas comes almost entirely from keyboard shortcuts, because reaching for the toolbar between every shape is what makes remote whiteboarding feel slow. This whiteboard uses the standard Excalidraw bindings, so the four you need are the tool keys, drag to pan, scroll to zoom, and the arrow tool.
Tools are bound to both a letter and a number. Press V or 1 for selection, R or 2 for a rectangle, D or 3 for a diamond, O or 4 for an ellipse, A or 5 for an arrow, L or 6 for a line, P or 7 for freehand drawing, T or 8 for text, 9 for an image, and E or 0 for the eraser. F gives you a frame, which is useful for grouping a subsystem so you can move it as a unit.
The single highest value habit is binding arrows to shapes. Start an arrow on the edge of a box and end it on the edge of another, and the arrow stays attached when you move either box. Once your diagram is bound, rearranging it costs nothing, which means you will actually rearrange it instead of leaving a tangled layout because fixing it looks expensive.
For text, remember that double clicking on a shape puts the label inside it and keeps the two together. Double clicking on empty canvas creates standalone text. Use in shape labels for component names and standalone text for annotations, assumptions, and the running list of numbers, so you can move annotations around without dragging components with them.
Two more that pay for themselves in an interview: use a second colour for anything you add in the second half, so the interviewer can see how the design evolved, and use the frame tool or a large rectangle to mark the boundary of a service or a region. Reviewers reading an exported diagram later understand boundaries far faster than they understand a flat mesh of boxes.
This whiteboard does not have a live collaboration mode, so two people cannot draw on the same canvas at the same time here. That sounds like a limitation and in interview practice it mostly is not, because the usual setup is one person drawing while the other watches and asks questions. Share your screen over the video call you are already on and you have exactly that.
Get the mechanics right before the session rather than during it. Share the browser tab rather than the whole screen, so notifications stay private and the canvas gets the full frame. Check that the person watching can read your labels, because text that is comfortable on your monitor is often unreadable after video compression. Zoom in one step further than feels natural and keep your labels short.
Decide who drives. In a mock interview the candidate should hold the pen for the whole session, including when the interviewer suggests a change, because the interview is a test of their ability to express a design. In a working session with a colleague, swap after each major section and re share the screen, which is clumsy but keeps both people engaged.
Because nothing is saved automatically, agree on who exports at the end. The person driving should save the file and export a PNG, then share both. The file reopens on any Excalidraw canvas so the diagram can be edited later, and the image is what you paste into notes or a document. Doing this consistently gives you a folder of your own design answers, which is the most useful revision material you can have.
One more practicality: if you are the candidate in a real interview, ask which whiteboard the company uses and open it once beforehand. Every tool has different shortcuts, and spending the first three minutes of a design round hunting for the arrow tool is an avoidable way to look flustered.
The whiteboard runs entirely in your browser. The canvas is a client side application, so the shapes you draw exist in the memory of the page you have open and are not transmitted to a HireCade server. There is no account, so there is nothing for us to attach a drawing to even if we wanted to.
The direct consequence is that nothing is saved for you. Refreshing the page, closing the tab, or navigating away clears the canvas, and it cannot be recovered. This is the one thing to internalise before you use it for something you care about: if the drawing matters, export it.
Saving is manual and it is in the menu at the top left of the canvas. Save to disk writes an Excalidraw file that you can reopen and keep editing. Export image writes a PNG or an SVG for pasting into a document or a message. Open loads a previously saved file back onto the canvas. Between them, that is a complete workflow, it just needs you to remember to use it.
Because there is no live collaboration here, there is also no session link and no shared room. If you need a persistent shared canvas across a team, that is a different tool and you should use one. What this page is for is drawing something quickly, on a machine you control, without signing up for anything, and that includes drawing things you would rather not upload to a service at all.
A whiteboard is the wrong tool for a coding interview and using it as one is a common self inflicted wound. Code on a canvas cannot be run, cannot be tested, and cannot be indented reliably, so you spend your attention on transcription instead of on the problem. Almost no company asks candidates to write code on a whiteboard any more, and the ones that do are usually testing whether you push back.
For practising algorithm problems, use an editor that executes. The Python runner on HireCade runs code in the browser with no setup, which is enough for the vast majority of interview problems: it supports input and print, so you can paste a problem, type a solution, and see whether it works. When you need packages, files, or a debugger, move to a local environment.
Where a canvas does help a coding round is before you write anything. Drawing the shape of the input, the state of a data structure after three operations, or the tree you are about to traverse is faster than describing it, and it prevents the off by one errors that come from holding a structure in your head. Draw the picture, then switch to the editor and write the code.
The same split applies to preparation. Use the whiteboard for design practice, sequence diagrams, data models, and tracing algorithms visually. Use the code runner for anything you need to execute. Use a document for behavioural stories, because those need editing rather than drawing.
Picking the wrong surface is a common way to make an interview harder than it needs to be. This is the short version of which tool suits which situation.
| Situation | This whiteboard | Shared code editor | Slides or a document |
|---|---|---|---|
| System design round | The right tool: free form boxes and arrows keep pace with the discussion | Wrong shape for diagrams | Too slow to edit live |
| Coding round | Avoid: code cannot be run or indented reliably | The right tool: you can execute and test | No |
| Two people editing at once | Not supported here. Share your screen instead | Usually supported | Usually supported |
| Persistence | Manual. Save a file or export an image before you leave | Depends on the tool | Saved by default |
| Setup cost | None. Open the page and draw | Usually a link or an account | A document to create first |
| Privacy | Stays in your browser | Sent to whichever service hosts it | Sent to whichever service hosts it |
Yes. It is free to use, there is no account, no sign up, and no trial period. Open the page and the canvas is ready.
There is nothing gated behind a paywall on this page, including saving and exporting, because both of those happen on your own machine.
No. The whiteboard runs entirely in your browser and what you draw is not sent to a HireCade server. Because there is no account, there is nothing for a drawing to be attached to.
The other side of that is that nothing is saved for you either. Refreshing or closing the tab clears the canvas and it cannot be recovered, so use Save to disk or Export image from the menu before you leave.
Open the menu at the top left of the canvas. Save to disk writes an Excalidraw file you can reopen and keep editing. Export image writes a PNG or an SVG. Open loads a saved file back onto the canvas.
For interview practice, do both: save the file so you can revise the design later, and export a PNG so you can paste it into your notes.
Not on this page. There is no live collaboration mode here, so there is no shared room or session link.
For interview practice that is rarely a problem, because the normal shape of a design round is one person drawing while the other asks questions. Share your browser tab over the video call you are already on and the person watching sees the canvas update live.
Tools are bound to a letter and a number: V or 1 for selection, R or 2 for a rectangle, D or 3 for a diamond, O or 4 for an ellipse, A or 5 for an arrow, L or 6 for a line, P or 7 for freehand drawing, T or 8 for text, 9 for an image, and E or 0 for the eraser. F selects the frame tool.
Scroll to zoom and hold the space bar while dragging to pan without changing tools. Double click a shape to put a label inside it, or double click empty canvas for standalone text.
No. Code on a canvas cannot be run or tested, so you end up spending your attention on transcription. Use an editor that executes, such as the browser based Python runner on HireCade, or a local environment.
A canvas is still useful before you code. Sketching the input, a data structure after a few operations, or the tree you are about to traverse is faster than describing it and prevents a lot of off by one mistakes.
Write before you draw. Put the question at the top, list functional and non functional requirements, then put your scale estimates in a corner where they stay visible. Only then sketch the happy path as a single row of labelled boxes.
After the happy path, choose the data model and justify it with the access pattern, add caches or queues only where a number demands them, then trace one failure through the diagram and finish with tradeoffs. The step by step section above walks through all eight stages.
It is built on Excalidraw, which renders shapes with a deliberately sketchy style. That is a feature rather than a limitation in an interview setting.
A rough diagram reads as a work in progress, which invites the interviewer to challenge it and gives you room to change your mind. A polished diagram reads as a finished answer, which quietly discourages the discussion the round is meant to produce.
It runs in any modern browser, and drawing with a stylus on a tablet works well. A phone screen is usually too small to hold a design diagram you can reason about.
For interview practice specifically, use the largest screen you have. You will be reading the whole diagram at once while you talk, and that is hard on a small display.
Once the page has loaded, drawing does not need a connection, because the canvas runs locally in your browser.
You do need a connection to load the page in the first place, and to load a font or an image you have not used before in that session.
Most design rounds run forty five to sixty minutes, and a common budget is five minutes on requirements, five on scale and the API, fifteen to twenty on the core design, ten on deepening one component, and the last five on failure modes and tradeoffs.
The part candidates skip is the last five minutes, and it is the part interviewers weight most heavily. Practise finishing on time with a failure walkthrough rather than practising the first half twice.
Pick three or four systems and draw each one from a blank canvas until you can do it in twenty minutes while talking. A URL shortener, a news feed, a chat system, and a rate limiter between them cover most of the patterns.
Then export each diagram and review it a day later. Reading your own diagram cold is the fastest way to find the parts you left unlabelled, which are usually the parts you did not really understand.
A whiteboard makes you fluent at drawing a design. These are the pages that give you a design worth drawing.
A structured path through the design round, from requirements and scale to storage choices and tradeoffs.
The other half of a technical loop, built for people starting without a computer science background.
The language patterns interview problems need, so the coding rounds stop eating your preparation time.
A full programme covering the whole loop when you want more than one round at a time.
Every HireCade course, including AI engineering and English for job interviews.
Spoken practice sessions with an AI interviewer, with written feedback at the end of each one.
Sixty minute sessions with engineers and hiring managers, with feedback and a recording afterwards.
Questions by role and company, so you know which rounds a loop is likely to contain.
Ask people who sat the design round at your target company what it actually covered.
Run Python in the browser with no installation, which is the right tool for coding practice.
Build a resume that survives an automated screen, then export a clean PDF.
The whole path in order: learn, practise, build a resume, apply, interview, and negotiate.
How titles map to levels, which tells you how deep a design round is likely to go.
Compensation ranges by role and company, for when the design round is behind you.
Longer articles on interviews, hiring, and engineering careers.
