I vividly remember the day of my first job interview. My first conversation was with someone in recruiting, which I had assumed was a programmer but when I was about 10-15 minutes deep in technical jargon, I noticed they were... confused. Anyways, that day, after 3-4 30 minutes conversations with various people in the company I got presented with a test... a set of 10 or so questions printed on a sheet of paper, and a stack of blank printer paper to write my answers on, I was both baffled and excited. The questions ranged from the purely theoretical (e.g. describe the main tenets of object oriented programming, pros and cons, etc.) to problems I had to code on paper. Since I had all the time I wanted, I wrote some 10-15 pages of stuff... poor soul who had to read through my handwriting.

We don't do interviews that way anymore, but almost all tech interviews today include a system design section that is conducted in front of a whiteboard or through an online "virtual" whiteboard. This medium allows us to express abstract concepts, communicate, analyze, "poke" at it, without a compiler or interpreter breathing down your neck. As far as I know, all software gets drawn and re-drawn many times before the first line of code is written.

But JP, stop! Are you advocating for a waterfall process? No, I'm not, definitely not. And if you don't know what I'm referring to with waterfall, don't worry, it's something that should have never existed.

You see, when you start working on a new problem, you have to understand it first, or at least start to understand it... start falling in love with said problem. Drawing boxes with text in them and arrows connecting those seems to be some sort of universal engineering language that we all gravitate to. Flow charts have been used since the dawn of computer science to describe algorithms. When you draw a flow chart, you are not only making something that will allow you to better communicate with others, but also will allow you to better communicate with yourself, as you work through the problem.

Pseudocode (i.e. text that resembles code but doesn't conform to a specific language syntax) serves a similar purpose, although I was never a big fan of using it, for no reason other than personal preference.

So, when you start working on a problem try drawing it up first, the problem and the solution. Before you shackle yourself to a specific language or syntax, allow yourself to explore options. In an interview setting you will be expected to analyze the pros and cons of different solutions; being able to quickly visualize those solutions will be a key skill that you will use for your entire career.

You can use whatever you want to draw, but if you want a recommendation, I like Excalidraw, it's free, simple and fun!