By May 10, 2018

Improving Your Coding Problem Solving Skills

Coding problem solving is kind of a pain in the a** for some software developers.

When most programmers are given a programming problem in an interview, they make several key mistakes. The most severe of those is the improper allocation of time. If you have heard the saying “measure twice and cut once,” then you are probably familiar with the idea of spending upfront time to make sure something is done right, rather than diving right in.

The most common mistake I see when conducting interviews or watching someone try to solve a programming problem is they try to start writing code as soon as possible. The only way you are going to have confidence in getting better is to practice it.

It takes a good amount of faith to believe that spending 70% of your 30 minutes to solve a problem just thinking about the problem and not writing any code is the right approach, so make sure you have that faith when you need it.

In this video, I'll teach you how you can get better at coding problem solving.

Transcript Of The Video

John Sonmez: 

Hey, what's up? I'm John Sonmez from So I'm going to do a video today about solving problems with code. I got a question about this from Ken, but before we get into that, I do want to take a moment to thank the sponsor for this video, which is You can check them out by going to and, if you go there, all you got to do is fill an application and what will happen is that if you meet some of the criteria that Hired has – I don't know what they are, don't ask me, all right?

It has something to do with where you're located and what kind of skills you have and what kind of companies they have that match up with those skills, but if you're a good match-up and you're a good candidate for the platform, you'll get on the platform but what will happen is a bunch of employers will see you. They'll look and they'll search the database, and they'll find you and, when they do, they can send you an interview request – in fact, that's the only thing they can do – and they have to include what their salary is for that job – and you get interview requests directly. So that's a pretty cool system. I think you should check it out if you haven't already, so just go to and go ahead and at least check it out, even if you're not looking for a job. Just see how the system works so that the next time that you do look for a job, you can do that.

And if you use that link, by the way, you'll get $2,000 if you get a job through Hired instead of 1,000, so you'll definitely want to go to and tell them John Sonmez sent you. Yeah. Tell them that. As if that will matter, but … No, tell them. That will matter. Tell Noah. Say, “Noah, John Sonmez sent me.”

All right. Let's talk about solving problems with code here.

This question is from Ken D., he says “Hi, John. I'm wondering if you have input and how one can become a better problem-solver. I don't get discouraged when I'm stuck so long as I find and understand why a solution works. I'm nervous I'm wasting time and can be more effective. Can you suggest ways to perfect problem solving methods, whether that's books, tutorials, et cetera? I'm taking CS classes part-time and learning code outside of the class. I work full-time and want my learning to be as effective as possible. Thanks for the videos, John.”

Okay, so let's talk about problem solving. I'm going to talk about algorithm stuff first. Obviously, one of the easiest ways to get good at solving problems is to solve a lot of problems, right? So, let's talk about, let's go to the playlist. You can check out the playlist on solving algorithms or coding algorithms. I've talked about this a lot, so I'm not going to totally rehash that.

I'm going to promote a book that I promote all the time, which is Cracking the Coding Interview. That's a good book. Go through that book, that will teach you how to solve algorithm type of problems. That's not exactly problem solving in general, but if you get good at solving those types of problems and you recognize those problems in the CS computer science domain, then you'll be good at them and it will be easy for you to solve those types of problems, right? Or it'll be a lot easier.

But let's talk about actually solving problems, okay? So I'm going to point to one more resource here, which is a blog post I made, I think it's called “Solving Problems, Breaking them Down”. Actually, I lied. I'm going to do a bunch of resources, one more resource. So that one is free blog post that I have that talks about it. That's kind of an older blog post, so excuse my immaturity in my voice, writing style? I don't know. It's not my best work, okay? But it's got some good content.

Okay, what is really good is I did the Pluralsight Course- you can check that out – on job interviews and, in there, I actually show you how to break down a problem. I actually go through, for those of you who haven't see me code, oh yeah. You better check out that course. You'll see me code. No, all my Pluralsight courses I coded, pretty much all of them. But I go through and I show you how to actually break down a problem, what I'm going to talk to you about here, briefly.

So one of the key things, okay, with becoming a good problem solver is that you've got to take your time. A lot of people, the reason why they suck at solving problems is they rush. They get nervous, like you said here, Ken, and they rush into it and they jump into it and they just want to start pounding out code and they just want to jump on the solution. What you really have to do is, the very step is this: first, you're going to read and make sure you understand the problem, okay? If that's problem that's given to you or if you're solving a problem at work, you need to get a full understanding: what is the problem I'm trying to solve? Because, I guarantee you, you cannot solve a problem that you do not understand. You'll either get the wrong solution or you just won't have the ability to do it, because how can you? The better that you understand, a lot of times, problems, like there's a certain percentage of problems that will instantly be solved as soon as you actually understand what the problem is, right?

Most people, they panic. They get a problem, they're not actually thinking about what the problem is, so they can't solve the problem and the solution would be obvious if they just understood what the actual problem was.

So, take the time, if you're doing a question, re-read the question. If you're investigating something at work, go through the source code, go through the thing and clearly understand in your head what is the problem? What are you trying to solve, okay? You know, I'm trying to reverse a string. Okay. I can't use string reverse functions. I have to manually reverse a string that's in an array. Okay. That's the problem that I have. You see what I'm saying? You got to have that level of knowledge where you totally understand what the problem is. So read it through multiple times, make sure that you really, really understand. If there's some part of it, some word, some question, some piece of it you don't understand, ask questions. Research stuff. Try to think about it and figure that out, okay?

Once you understand the problem, here's the next thing. Then what you want to do is you want to solve a simpler version of the problem, okay? So, you may have heard of this in mathematics because it's a similar technique that you do. I think you probably [inaudible 00:05:41] foundational mathematics, it's been a while since I've taken a course like that, but you want to solve, basically, x = 1. What I mean by that is that you want to say, okay, let's say reversing a string, for example, to use a real example.

What if the string just had two letters in it? What if it just had one? Then reversing it is the string, you just return, right? But let's look at the case where it had two. Well, we're just swapping it, right? It's really easy when you make the problem real small. You make the scope really, really small. Let's us the smallest instance. What's the smallest instance of this problem that we could solve, the simplest version of it? Okay? Solving for x = 1, or something like that. You see what I'm saying?

You start there and you figure out how to do that manually, okay? Then you expand it. Oh, like, you say, well, how about a slightly harder version or a different version of it? It might be the same level of complexity, but a different one. So you get the second one, so maybe it's a three letter string. We need to reverse that. Okay, so now I guess what we could do is we start at the end and then we grab that letter and then we set our counter, we go back one, and we grab the next letter, right. And you manually do this, right. You manually say, okay, what would I do manually? Manually. Not in code. Manually. How would you manually reverse a string? How would you manually solve this problem?

Now, you go to x = 3, okay? And three is- I'm not going to go through 100, okay. But usually around three, that's where, you know how you need to have three points to determine the slope of a line, like which direction that it's ultimately going to go? Is that true? Isn't two enough? Why do I think that you need three? Because if it's … To make a straight line, if you're going to draw a straight line, if you just have … No, forget that.

There's something here about having three that you need, but it's not that … There's something in my mind, surely, I'm thinking about, like, a string bowing and having two dots, but you have the third one that really … I don't know. I don't know. I don't know. I don't know. Forget about that. Look, I'm just confusing you now.

Okay, but let's get back to this. Be serious here, okay. Enough kidding around. What you want to do is, if you solve the third one, then you're going to find a pattern, usually, and you want to find that pattern. You want to say what could I do that would, how could I genericize this solution, again, manually? What's some set of rules that I could apply to this problem that, in this case, let's say reversing a string, would work no matter how long a string was? Bam. Now you've got the solution. You've still done it manually.

Next, if you're writing code, here's what you do. You write out the pseudo-code. You write out the comments of the steps. Step one, step two, step three, step four. The manual stuff that you did. Next, you translate each one of those pseudo-code, each one of those comments into actual code that does it – bam, bam, bam – and then you've got the problem solved.

Now you test it for inputs. Now you test a wide array of inputs and then, finally, you're not done yet. Now, you try to break the thing. Now you say, oh, what if I had some weird inputs? Now you turn on your tester's cap and you say, would this work with a negative number? Would this work with … whatever, you see what I'm saying? And you try to break it and you look for those edge cases and then, if you find some, you figure out how to fix those particular cases and then you're done. And that's it. That's how you solve problems.

And I'm giving you this sort of kind of an algorithm perspective, but this works for whatever kind of problem that you're trying to solve. If you're trying to solve some kind of problem that you have at work, a non-coding problem, but a technical problem, it's the same thing. It's the same variation of this. You want to understand the thing first, you want to break it down. You want to solve the simpler cases of it, how can you simplify the problem as much as possible, and then you want to basically take a manual process, see what could work at the simple solution, and then scale that up to x = any number. You don't know what x is, so it'll work, right? This is kind of an inductive method of doing this and there you go.

So that's how I solve problems, okay? And if you keep on going through that process and you take the time to do that, you'll become a better problem solver.

All right, if you liked this video, if you didn't like this video, if you're just like, man, I just got to see what kind of crazy shit that John is going to do. I heard that this guy, this John Sonmez guy, that he does videos where he takes off his shirt and flexes. You want to see that? Click the subscribe button.

I don't know. I just want you to click the subscribe button so we can get, like, a million subscribers and get one of those gold YouTube things that I can cut in half. I guess I'm not supposed to cut it in half unless I have a channel that cuts shit in half, but all right.

I'll talk to you next time. Take care.

About the author

John Sonmez

John Sonmez is the founder of Simple Programmer and a life coach for software developers. He is the best selling author of the book "Soft Skills: The Software Developer's Life Manual."