Reading and Reference Materials

Solving Problems

How to Solve Programming Problems

• Common mistakes: 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,like is try to start writing code as soon as possible.

You really want to make sure you take enough time to understand the problem completely before attempting to solve it.

• A simple set of steps:
  1. Read the problem completely twice You want to make sure you completely understand the problem. A good test of this is whether or not you can explain the problem to someone else.

I cannot over-emphasize how important this step is!

If you don’t understand the problem, you cannot solve it. Do not worry about wasting time here, because the better you understand the problem, the easier it will be to solve it.

If you are given any examples along with the problem, make sure you have worked through the examples and understand why the answers are correct for each one.

1. Solve the problem manually Programming is automation plain and simple. You may have the ability to skip the manual steps and jump directly to code, but there is a manual process which is the foundation of any code you write.

It is very important to solve the problem manually first, so that you know what you are going to automate, otherwise you are just slinging code around. Which while can be fun, will make you look like an idiot in a programming interview and will probably cause you to sweat profusely.

I recommend that you solve the problem with at least three different inputs to make sure you really understand your solution and that it will work for more than one case.

1. Optimize the manual solution People often don’t realize how valuable this step is. It is much easier to rearrange and reconstruct and idea or algorithm in your head than it is in code.

It’s well worth the effort to try and optimize the actual solution or simplify it when it is still in the most easily malleable state.

What you want to do here is figure out if there is another way you can solve the problem easier, or if there are some steps you can cut our or simplify.

1. Write pseudo-code or comments Many times you can skip this step if you have a really good handle on the problem or your previous steps already created a detailed enough description of the solution that coding it is already a 1 to 1 translation.

If you are a beginner or struggle with these kinds of problems, I would go ahead and take the time to do this step anyway though.

What we want to do here is capture all the steps we created and now either put them into our editor as comments or write them as psuedo-code that we can translate to real code.

By doing this, we can know exactly what the structure of the code we are going to write is going to look like which makes the job of filling in the actual code later trivial.

1. Replace comments with real code This step should be extremely easy at this point. If you have done all the other steps, this step involves no problem solving at all.

All we do here is take each comment and convert it into a real line of code.

1. Optimize the real code Sometimes this step isn’t necessary, but it’s worth taking a look at your code and figuring out if you can cut out a few lines or do something simpler.

This is also a good place to make sure all your variables are named with long meaningful names. I cannot stress enough how important having good names for your variables and methods is for helping the person evaluating your code to understand what you were trying to do. This is especially important when you make a mistake!

1. A few final tips If you follow this template for solving algorithm type problem, you should do very well in programming interviews, but the key to doing so is having confidence in this process.

The only way you are going to have confidence in this process 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.

I’ve talked about using TopCoder to become a better programmer before, and I still recommend it. Codility.com is another great site I have recently been introduced to.

There is one important step I did not include in the outline above, because I didn’t want to make the process any more complicated than it needed to be.

Many times you will find that a problem itself involves multiple large steps or is very complicated. In those instances, you will want to try and find a way to cut the problem directly in half and then following the process above for each half.

This method of tackling a problem is called “divide and conquer” and is quite effective. A good way to know where to break a problem in half is to think about what part of the problem if already given to you would make solving the rest easy.

The programming interview is merely one battle in a larger war: marketing yourself.

Act like you make $1000/hr

• Pretend Your Time is Worth $1,000/Hour and You’ll Become 100x More Productive Most people have no clue what they are doing with their time but still complain that they don’t have enough.” -Grant Cardone, NYT best-selling author If you don’t treat yourself and your time with respect, you will become unhappy, resentful, and tired. Your body and mind long for mastery and freedom; you can’t have those things if your time is cheap and easily taken. Busyness and exhaustion should be your enemy. If you’re chronically stressed and up late working, you’re doing something wrong. Do less. But do what you do with complete, hard focus. Then when you’re done be done, and go enjoy the rest of your day.
• Extremely successful people don’t tolerate busywork or distraction. They have crystal clear vision on their goals, and do what they need to do to get there, every single day.

  As a man thinketh, so is he. As he continues to think, so he remains.” -James Allenlike

How to think like a programmer

If you’re interested in programming, you may well have seen this quote before:

“Everyone in this country should learn to program a computer, because it teaches you to think.” — Steve Jobs

1. Understand Know exactly what is being asked. Most hard problems are hard because you don’t understand them (hence why this is the first step).

How to know when you understand a problem? When you can explain it in plain English.

Do you remember being stuck on a problem, you start explaining it, and you instantly see holes in the logic you didn’t see before?

Most programmers know this feeling.

This is why you should write down your problem, doodle a diagram, or tell someone else about it (or thing… some people use a rubber duck).

“If you can’t explain something in simple terms, you don’t understand it.” — Richard Feynman

1. Plan Don’t dive right into solving without a plan (and somehow hope you can muddle your way through). Plan your solution!

Nothing can help you if you can’t write down the exact steps.

In programming, this means don’t start hacking straight away. Give your brain time to analyze the problem and process the information.

To get a good plan, answer this question:

“Given input X, what are the steps necessary to return output Y?”

Sidenote: Programmers have a great tool to help them with this… Comments!

1. Divide This is the most important step of all. Do not try to solve one big problem. You will cry.

Instead, break it into sub-problems. These sub-problems are much easier to solve.

Then, solve each sub-problem one by one. Begin with the simplest. Simplest means you know the answer (or are closer to that answer).

After that, simplest means this sub-problem being solved doesn’t depend on others being solved.

Once you solved every sub-problem, connect the dots.

Connecting all your “sub-solutions” will give you the solution to the original problem. Congratulations!

This technique is a cornerstone of problem-solving. Remember it (read this step again, if you must).

1. Stuck? By now, you’re probably sitting there thinking “Hey Richard… That’s cool and all, but what if I’m stuck and can’t even solve a sub-problem??”

First off, take a deep breath. Second, that’s fair.

Don’t worry though, friend. This happens to everyone!

The difference is the best programmers/problem-solvers are more curious about bugs/errors than irritated.

In fact, here are three things to try when facing a whammy:

Debug: Go step by step through your solution trying to find where you went wrong. Programmers call this debugging (in fact, this is all a debugger does).

1. Practice Don’t expect to be great after just one week. If you want to be a good problem-solver, solve a lot of problems!

Practice. Practice. Practice.

5 Whys

• The 5 Whys strategy is a simple, effective tool for uncovering the root of a problem. You can use it in troubleshooting, problem-solving, and quality-improvement initiatives.

• Start with a problem and ask why it is occurring. Make sure that your answer is grounded in fact, and then ask the question again. Continue the process until you reach the root cause of the problem, and you can identify a counter-measure that will prevent it from recurring.

• Bear in mind that this questioning process is best suited to simple or moderately difficult problems. Complex problems may benefit from a more detailed approach, although using 5 Whys will still give you useful insights.

Getting to the Root of a Problem Quickly

• The model follows a very simple seven-step process:
  1. Assemble a Team Gather together people who are familiar with the specifics of the problem, and with the process that you’re trying to fix. Include someone to act as a facilitator , who can keep the team focused on identifying effective counter-measures.

1. Define the Problem If you can, observe the problem in action. Discuss it with your team and write a brief, clear problem statement that you all agree on. For example, “Team A isn’t meeting its response time targets” or “Software release B resulted in too many rollback failures.”

Then, write your statement on a whiteboard or sticky note, leaving enough space around it to add your answers to the repeated question, “Why?”

1. Ask the First “Why?” Ask your team why the problem is occurring. (For example, “Why isn’t Team A meeting its response time targets?”)

Asking “Why?” sounds simple, but answering it requires serious thought. Search for answers that are grounded in fact: they must be accounts of things that have actually happened, not guesses at what might have happened.

This prevents 5 Whys from becoming just a process of deductive reasoning, which can generate a large number of possible causes and, sometimes, create more confusion as you chase down hypothetical problems.

1. Ask “Why?” Four More Times For each of the answers that you generated in Step 3, ask four further “whys” in succession. Each time, frame the question in response to the answer you’ve just recorded.

2. Know When to Stop You’ll know that you’ve revealed the root cause of the problem when asking “why” produces no more useful responses, and you can go no further. An appropriate counter-measure or process change should then become evident. (As we said earlier, if you’re not sure that you’ve uncovered the real root cause, consider using a more in-depth problem-solving technique like Cause and Effect Analysis , Root Cause Analysis , or FMEA .)

If you identified more than one reason in Step 3, repeat this process for each of the different branches of your analysis until you reach a root cause for each one.

1. Address the Root Cause(s) Now that you’ve identified at least one root cause, you need to discuss and agree on the counter-measures that will prevent the problem from recurring.

2. Monitor Your Measures Keep a close watch on how effectively your counter-measures eliminate or minimize the initial problem. You may need to amend them, or replace them entirely. If this happens, it’s a good idea to repeat the 5 Whys process to ensure that you’ve identified the correct root cause.

What the heck is the event loop anyway

JavaScript programmers like to use words like, “event-loop”, “non-blocking”, “callback”, “asynchronous”, “single-threaded” and “concurrency”.

We say things like “don’t block the event loop”, “make sure your code runs at 60 frames-per-second”, “well of course, it won’t work, that function is an asynchronous callback!”