System Design test to assess software architecture skills

It's a question format in which the candidate answers by drawing: they get an open-ended prompt and build the diagram right on the platform, with the option to attach supporting images. It's used to assess what code doesn't show: system architecture, data flows, process design, journeys, and integrations. It's the natural format for system design exercises in engineering roles, but it works just as well for mapping a sales funnel, a customer service flow, or a business process in non-tech roles.

Yes, and for most stages of the funnel it's the fairest way. In a live system design interview, the candidate draws under pressure, with an evaluator watching, in 45 rushed minutes; part of what gets measured is how well they handle an audience. In the asynchronous format, they get the scenario and the time set by the company to think and draw, and the evaluator reviews whenever and as many times as they want, comparing candidates who answered exactly the same problem. Coodesh recommends pairing the diagram with a video or audio question in the same assessment, in which the candidate explains their choices: the drawing shows the solution, the explanation shows the reasoning.

A scenario with explicit constraints, because system design without constraints has no wrong answer. Instead of "design a messaging system," go for "design a notification service for 2 million users, with a peak of 10,000 sends per second, tolerance for up to 1 minute of delay, and a limited infrastructure budget; point out where the system fails first." Constraints force trade-offs, and trade-offs are what set a senior apart from someone who memorized a reference diagram. In the review guidelines field, describe what a good answer covers (partitioning, queues, single point of failure, cost) so every review follows the same yardstick.

The review is done by a person, supported by the review guidelines defined when the question is created: the goal of the exercise and the evaluation method are stored with the question and guide both the reviewer and the AI-assisted review, when used. In practice, the evaluator opens the diagram, plus the video or audio explanation if there is one, and scores it against the criteria. This solves the classic problem of architecture interviews: every interviewer valuing something different. With written criteria, two evaluators look at the same diagram with the same yardstick, and the decision becomes auditable.

They can try, and the design of the assessment is what makes it pointless. First, the format allows image attachments because there are legitimate uses, such as photographing a paper sketch; if the company wants the drawing done on the platform, it just needs to say in the prompt that attachments won't be considered. Second, the assessment's integrity features log tab switching, second screens, and pastes, so the reviewer can see whether the candidate spent the whole question outside the platform. Third, and most effective: with a follow-up video explanation question or AI interview, anyone who uploaded a diagram they didn't draw gets stuck on the first question about why they chose that queue or where the system breaks under double the load. A pretty diagram without a defense is a signal, not a pass.

For engineering, from mid-level up, when architecture decisions become part of the job, and it's a must in senior, staff, and tech lead hiring, where the diagram says more than the code. Outside engineering, it works for any role whose job is designing systems of another kind: process analysts (As-Is and To-Be flows), product managers (journeys and feature architecture), data (pipelines), and operations. For junior developers, a coding challenge usually measures better; the whiteboard comes in when what matters is structure, not syntax.

Yes. In Library, when creating a question, choose the Whiteboard type, write the title and the prompt, set the language (Portuguese, English, or Spanish), time, level, weight, and skills assessed, and fill in the review guidelines with the question's goal and evaluation method. Questions you create stay in your company's private library, accessible only to your team, and can be combined with any other format in an assessment. You can save it as a draft and publish it when it's ready.

It can be. It inherits the integrity features configured in the assessment: tab-switch monitoring, full screen, second-screen detection, paste logging, browsing recording, and, if enabled, webcam proctoring. For system design exercises, the most useful set is tab monitoring and browsing recording, which show how the diagram was built, not just the result. Details on each feature are on Coodesh's integrity and proctoring page.