-
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.
-
The most common mistake in interviews or or try to solve a programming problem is that 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.
-
Read the problem completely twice, This is the single most important step You may even want to read the problem 3 or 4 times,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.
-
Solve the problem manually with 3 sets of sample data, 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.
-
Optimize the manual steps, It is much easier to rearrange and reconstruct and idea or algorithm in your head than it is in code.
-
Write the manual steps as comments or pseudo-code, 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.
-
Replace the comments or pseudo-code with real code, is take each comment and convert it into a real line of code.
-
Optimize the real code, taking a look at your code and figuring out if you can cut out a few lines or do something simpler and to make sure all your variables are named with long meaningful names.
“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
“Being busy is a form of mental laziness.” -Tim Ferriss
- 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.
“Everyone in this country should learn to program a computer, because it teaches you to think.” — Steve Jobs
- this is probably how you “solve” problems
-
Try a solution.
-
If that doesn’t work, try another one.
-
If that doesn’t work, repeat step 2 until you luck out.
- what should you do when you encounter a new problem
-
Understand, Know exactly what is being asked. Most hard problems are hard because you don’t understand them,
-
Plan, in programming, this means don’t start hacking straight away. Give your brain time to analyze the problem and process the information.
-
Divide, break it into sub-problems. These sub-problems are much easier to solve. Then, solve each sub-problem one by one.
-
Stuck?, here are three things to try
Debug: Go step by step through your solution trying to find where you went wrong.
Reassess: Take a step back. Look at the problem from another perspective.
Research: No matter what problem you have, someone has probably solved it.
- When to Use a 5 Whys Analysis
You can use 5 Whys for troubleshooting, quality improvement, and problem solving, but it is most effective when used to resolve simple or moderately difficult problems.
- How to Use the 5 Whys
-
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.
-
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.
-
Ask the First "Why?", Ask your team why the problem is occurring.
-
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.
-
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.
-
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.
-
Keep a close watch on how effectively your counter-measures eliminate or minimize the initial problem.