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.
You must resist this urge.
-
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 els.
-
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. Which while can be fun, will make you look like an idiot in a programming interview and will probably cause you to sweat profusely.
-
Optimize the manual steps. We should be able to immediately recognize that we can use a loop here to reduce the manual steps. Our duplicate why’s for most of our steps tell us that we are doing the same thing over and over for each step, just with different data.
- Write “Zebra” down.
- Start at the last letter in the word and - create a new empty word.
- Append the current letter to the new word If there is a previous letter, make the - previous letter the current letter and start back at 3.
-
Write the manual steps as comments or pseudo-code.
-
Replace the comments or pseudo-code with real code. 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.
// NewWord = “”
// Loop backwards through word to reverse
// NewWord += CurrentLetter
// Return NewWord
- Optimize the real code. 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!
“Being busy is a form of mental laziness.” -Tim Ferriss.
“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.”
“People think focus means saying yes to the thing you’ve got to focus on. But that’s not what it means at all. It means saying no to the hundred other good ideas that there are. You have to pick carefully. I’m actually as proud of the things we haven’t done as the things I have done. Innovation is saying no to 1,000 things.”
Unless you have a system, this is probably how you “solve” problems (which is what I did when I started coding ):
- Try a solution.
- If that doesn’t work, try another one.
- If that doesn’t work, repeat step 2 until you luck out.
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.
- Assemble a Team
- Define the Problem
- Ask the First “Why?”
- Ask “Why?” Four More Times
- Know When to Stop
- Address the Root Cause(s)
- Monitor Your Measures
Email: [email protected]