Every great developer you know got there by solving problems they were unqualified to solve until they actually did it.
— Patrick McKenzie

Where to Start 

QUESTION: If you were handed a problem right now and were asked to write some code to solve it, where would you start?


If you said something like "I would start writing some code" or something more specific like "I would start declaring variables", you are jumping WAYYY too far ahead.  This is a terrible idea.

If you said something like "I would think about the problem and ask some questions", you are on the right track.  However, this isn't super specific and is not a strategy we can uniformly apply to all toy problems.  Wouldn't it be great to have a set of steps you could apply to every toy problem in order to solve them effectively and think about them in a useful and consistent way?

Enter the procedure 

Here is the procedure I have learned to use to approach any toy problem, or really any problem in programming: 

Clarify the problem

Make sure you understand the problem.  Ask the following questions about the problem: 

  • What sort of input should I expect? 
  • What is the expected output? 
  • Ask for, or provide, an example of a valid input and the desired output for that input
  • Verbalize any edge cases you can think of (e.g., input is invalid, input does not exist) 
  • Ask if there are any limits on the time complexity for your solution
  • Ask if there are any limits on space complexity for your solution


Don't skip this step!  I prefer to do this with an actual, physical whiteboard.  You can also use a number of free simple online whiteboards, such as awwapp.  I personally never liked fumbling around with a mouse trying to draw on web whiteboards, but if you have a drawing tablet or don't mind using a mouse these are fine options.


While drawing on a whiteboard, try to be as visual as you can.  Try to avoid writing walls of text, pseudo code, or code during white boarding.  If you are in an interview, be vocal and verbalize your thoughts and the reasons for each thing you draw.  If you're not sure about something but have an intuition, say so.

Pseudo code

The next step after white boarding is to write out pseudo code.  You can think of pseudo code as a plain English, simplified version of what your code should be doing.  When writing out pseudo code, try not to use any language specific constructs or raw code.  You want your pseudo code to be readable and understandable by non-programmers.  Pseudo code should be implementable  in any programming language.

You can do this in a text editor in comments, or just write it out on a whiteboard or text document.  It's up to you.  I personally like to write out my pseudo code as comments in the text editor I will use to solve the problem, so that I can easily reference my pseudo code as I am coding out the solution.  If you wrote good pseudo code, you can keep the comments in after the toy problem is coded.  These comments will serve as useful documentation about what each step in your solution is doing.


Writing actual code should always be the last step in this process.  If you feel stuck during this step, you can return to your whiteboard and/or do a mini white boarding session on a blank board to help clarify and solidify your mental model of the problem.  If you feel really stuck and are not in a time crunch situation (such as an interview), step away from the problem and come back to it.  If your solution feels excessively complicated or not workable, don't be afraid to start over again from scratch, especially if you have a good idea for a better approach.