# Solving your Problem Solving Problem It could be argued that a strong problem-solving ability is the most fundamental skill a software developer must possess. So I wondered, why do some industry professionals feel that so many candidates lack it? It's a skill we all have to varying degrees. Here are some suggestions to help you develop your problem-solving ability alongside your analytical skill to strengthen your position during the hiring process. It wasn't so long ago that I came across the post entitled [_"Why Can't Programmers... Program?"_](https://blog.codinghorror.com/why-cant-programmers-program/) written by Jeff Atwood. If that name doesn't ring any bells at the moment - he's one of the co-founders of the [Stack Exchange](https://stackexchange.com/sites#) network. This is a great resource for professionals and novice programmers alike, so long as it's understood that it has a reliance upon users understanding their problem domain and being able to ask specific questions showing their efforts. It's all about community contributions. Anyway, I digress. The fundamental meaning behind the post was to communicate the notable lack of problem-solving ability presented by candidates applying for developer positions. An apparently frustratingly recurring problem witnessed by those giving the interviews. More often than not, these variations of skills are tested whether that be pre-interview or during. However, the issue is the various methods used to evaluate these skills. The most common being a practical exercise to demonstrate your technical abilities using logic, forethought, and rationale. Exercises such as Fizzbuzz - the programmatic representation of the [popular classroom game](https://www.dr-mikes-math-games-for-kids.com/fizz-buzz.html) wherein children incrementally count from 1 to a predetermined number, shouting "fizz" on multiples of 3, "buzz" on those multiples of 5, and "fizzbuzz" on those multiples which are composed of both (the original game gets more complex when also having to do the same if the number contains a 3, 5, or 7!). Yet the solution presents a further problem - as the popularity of Fizzbuzz grew, as did the number of potential developers practising it like their right of passage. > _"It certainly wasn't my intention, but a large portion of the audience interpreted [FizzBuzz](http://blog.codinghorror.com/why-cant-programmers-program/) as a challenge. I suppose it's like walking into Guitar Center and yelling 'most guitarists can't play Stairway to Heaven!'"_ > > \- Jeff Atwood; _[FizzBuzz: the Programmer's Stairway to Heaven](https://blog.codinghorror.com/fizzbuzz-the-programmers-stairway-to-heaven/)_ Dumping grounds for Fizzbuzz solutions are scattered across the Internet providing great practice for variations on how to solve the same problem, yet fail to address the idea behind it. Quite plainly, they defeat the point of the exercise as it becomes a process of memorization rather than analysis. Therefore, companies have to find ways to adapt to this such as establishing new, simple exercises to test the core technical and analytical skill. Or, in some cases, resort to abstract questions which supposedly give insight into the candidate's thought journey from problem to solution, [but are declining in popularity for sure.](http://uk.businessinsider.com/google-brain-teaser-interview-questions-dont-work-2015-10) For anyone reading who feels their ability to analyse or work through a problem is untrained or unfamiliar; who look on at those who make it seem so effortless and tell themselves "I'll never get to that level." - fear not. It's a common feeling, and there is a name for it - [imposter syndrome](https://en.wikipedia.org/wiki/Impostor_syndrome). The feeling that you don't rival your peers, or that somehow, your achievements and progress was born of chance rather than skill, determination, and passion. It's a peculiar psychological phenomenon whereby we're fooled into believing we have it when actually, you could argue it does not truly exist. [Nickolas Means](https://twitter.com/nmeans) gave a memorable speech on this very topic at [RailsConf back in 2014](https://www.youtube.com/watch?v=l_Vqp1dPuPo) in which he describes how it makes you feel and gives you a term to describe it with before guiding you along the path to realise - you don't have it. Yet it is something I, and 70% of others believe they suffer from and is particularly prevalent in the Scientific disciplines. However, I feel analytical skills such as problem-solving boil down to self-belief. The belief that you can reach that daunting end-goal you face is a powerful ally both before and during your tackling of the various problems you encounter. But how? As a species, we have proven throughout history how our constant curiosity leads to questions, which through persistence and initiative, ultimately lead to ingenuity. That may be little comfort when you can't see the path ahead through the fog, but I hope to instil belief into you that there is always a way. So, here two effective ways to clear that fog. > _"Once you eliminate the impossible, whatever remains, no matter how improbable, must be the truth."_ > > \- Arthur Conan Doyle ### The 'TL;DR' How Firstly, **IDEAL**. The simplest and quickest way to get your boots dirty with problem-solving. - **I**dentify the problem space - question what, why and gather resources for how. What is it, but more importantly, what is it not? - **D**efine the problem - A formal definition of the end goal; define & divide the problem into smaller and more specific tasks. - **E**xamine various options - Reflect on initial hypothesis; question them with why and how; formulate the process and the expected outcome of each option. - **A**ct on these options - Test each option and reflect upon its expected results vs. actual results. - **L**ook at the process used and the outcome - Evaluation is key to learning. Monitor and evaluate with a fine toothed comb, not just the resulting destination (whether right or wrong), but the journey taken. Why was it wrong? Can you verify it was right, repeatedly? This can be elaborated into greater detail, so I encourage you to view my source for this strategy from which I've delved into based on personal experience - [The University of Kent](https://www.kent.ac.uk/careers/sk/problem-solving-skills.htm). There is also fantastic advice and "food-for-thought" upon that page for impressing potential employers with professional skills. ### The 'grab a coffee' How However, my preferred method comes from the book '[Think Like a Programmer](http://www.amazon.co.uk/dp/1593274246)' by V. Anton Spraul, which I recommend. It's great for re-wiring your brain to effectively analyse situations and problems before approaching them. I'm the kind of person who needs structure. So the general problem-solving model presented in chapter one of this book is excellent for me as it allows me to structure and step through the problem-solving process initially before it becomes a more automated task in my mind. Spraul gives vast amounts of detail on each of these steps and goes into even greater detail with them later in the book with examples, so absolutely pick up a copy and read it. I'll give my personal interpretation of each element within the model: #### "Always have a Plan" A solid plan is critical in mapping out the road ahead, identifying milestones and goals, and monitoring progress. But, let's not forget that _"The best-laid plans of mice and men often go awry"_. So don't get hung up on change; prepare for it and adapt to it when it does happen... because trust me, it will. #### "Restate the Problem" Rewriting or rewording the problem from another perspective is a fantastic way to ensure you understand the scope of the problem at hand. When I'm developing, I often feel that if I can't explain my problem aloud and in-depth to myself, I'm not ready to begin comparing it to mathematical models or formulating code solutions. You might get a _"eureka!"_ moment, or, it might just give you that reassurance and confirmation from a peer that you've grasped what the task you've been set is. #### "Divide the Problem" Arguably the most important step in approaching a problem, both in mentality and ability. Break it down into sub-problems. Perspective is everything - If I view my task as "Build the Eiffel Tower", it's so daunting I've no idea where to start. So I'd break this down into its constituent parts and tackle each one, step by step, breaking them down further as needed, it's far more manageable. #### "Start with What You Know" This makes perfect sense, no? A great deal of problem-solving is having the confidence that you'll succeed and what better way to increase that confidence when starting by tackling those earlier identified sub-problems you already know how to do using your existing knowledge? Do this before running off and finding more complex or better ways to solve it and you'll be golden. Why buy new tools from the hardware store before trying your old ones? Think inside the box. #### "Reduce the Problem" Reducing scope. It comes in really handy when you just can't get your head around how to approach a problem. Similar to _"Start with What You Know"_, this one is all about making whatever progress possible while you research or engineer a more fitting solution. Kobayashi Maru that problem! If you feel you're in a no-win situation, remove the rules and constraints - now it's much simpler to solve! Then reintroduce them and adapt the solution, or, find a new one based on your new knowledge of the problem! Here, think outside the box. #### "Look for Analogies" I tell myself _"Make it relatable and it makes itself simple"_. Imagine a non-programmer friend asks you _"So, what is an algorithm in programming?"_, how would you respond? Would you say that an algorithm is complex a set of pre-defined rules and procedures executed recursively, which can only be defined as an algorithm should they not execute infinitely? Or would you say _"Think of it like making a sandwich_. _You gather your ingredients, prepare the bread, layer your cheese and salad on one slice, add a condiment and finally, place the other slice of bread atop and cut it in half. There is a set of rules which define the quickest and most effective way to achieve an end goal. Some things happen more than once such as buttering slices of bread, while other tasks must happen before others in order to end up with the correct result such as cutting before you've put the top slice of bread on. Other can happen at the same time."_. Much simpler, no? Look for analogies of problems you've already solved, or problems that someone else has solved and apply those characteristics to your problem. [Schrödinger's cat](https://en.wikipedia.org/wiki/Schr%C3%B6dinger%27s_cat) is a great example of a simple analogy to explain The Copenhagen interpretation of Quantum Mechanics. #### "Experiment" The most self-explanatory element to this model. What better way to get familiar and understand something new than to experiment? Try to understand what the experiment needs to do and what you expect the results to be. Run it, and evaluate the actual results according to your expectations. Don't match? Great! Now you're about to learn something new - why it didn't work! #### "Don't get Frustrated" Easier said than done, huh? Well, no, actually. It's all too easy to believe you're frustrated at your code for not compiling when actually, you're frustrated at yourself for not being able to figure something out. In my experience, the two worst things to do here are: Allowing yourself to fall ever deeper into the self-feeding pit that is frustration, and, Thinking "This is easy, I should be able to do this. I must be stupid - I'll never be a good developer!" - no good will come of hitting yourself. Take a break. Step back from the computer (aka. the idiot zone) and go and do something else. Walk; wash your pet goldfish; solve a different problem. The important thing is, relax! Come back to it later with a clearer mind and forget the trouble you had before - start over. Go through your plan again; determine what should happen and evaluate what is, and experiment. But you're not alone - there's plenty of resources and [forums willing to help you learn so long as you show you've put in the effort](https://stackoverflow.com/help/how-to-ask). You will get there. Trust yourself and be confident - it makes it so much easier. > "_I changed the conditions of the test. Got a commendation for original thinking. I don't like to lose"_ > > \- James T. Kirk Of course, how you implement and adopt these methods is up to you. You may wish, as I have, to follow them strictly in written form at first until the process becomes a matter of instinct. Or, you may wish to loosely consider the steps as high-level mental questions. Whatever works best for you - do it.  Something which greatly complements these methods is the well-known [Rubber duck debugging](http://www.rubberduckdebugging.com/). It's a simple, effective paradigm whereby during the process of explaining your problem to an inanimate object (usually a duck) aloud, you begin to piece together and solve your problem. It's great. My duck is called Gandalf. He is the keeper of all knowledge. To complement all of this, head over and check out the poster entitled [_"Troubleshooting in Black and White"_](https://i.imgur.com/RrdwDgd.png) by Reddit user [jmnugent](https://www.reddit.com/user/jmnugent). It's a great presentation of how to problem solve specifically when dealing with tech support, however, a great deal of it is translatable into general problem-solving. Finally, to wrap this biblical length article up, I'll leave you with one of my favourite programming-oriented quotes... > _"Constantly learning is a feature of being a developer; not a bug."_ > > \- Gina Trapani ([_Twitter_](https://twitter.com/ginatrapani?lang=en-gb)) ... and a piece of advice. Remember - someone created the system you're using, not to be abstract and "magic", but to be adaptable and developed further by people such as you - explorers. So you can figure it out with time, dedication, and a little help from the internet or friends. [And always, RSA - Read, Search, Ask.](https://medium.freecodecamp.org/read-search-dont-be-afraid-to-ask-743a23c411b4)