# Would You Like Some O.I.C.E With That

As a student of Hack Reactor, I’m currently on the road to becoming a software engineer. My former career allowed to flex my creative muscles, but in recent times, I’ve had to develop a more technical way of thinking. One way in which I have learned to think with a problem solvers mindset, is to think in O.I.C.E.

Let’s break it down!:

O: Outputs

I: Inputs

C: Constraints

E: Edge cases

O.I.C.E. is a simple acronym that anyone can asks themselves to aid in solving computer science problems. Let’s start with the “O” first.

O: The “O” stands for output. An output is what should be returned when a function is complete. In terms of the O in O.I.C.E, given a problem, what are your outputs? Is it going to return a number, a string, or some other function? Or will it be in some sort of collection? What will be the final form of the result?

Here is some code I wrote. Can you identify what the output will look like?

You might’ve guessed an array of arrays and you’re right! In the commented out code, it states that we write a function which converts an object literal into…..an array of arrays. So we can logically assume that is what our output will be when the function executes and returns.

I: The “I” stands for input. An input can be any form of an object. Strings, integers, collections are all valid. Some functions can even receive no inputs and be used anonymously. Ask yourself what are my inputs? Are they integers, strings, arrays, etc? Can you identify the input below?

You probably figured out the input quickly. It’s takes in an object literal as stated in the comments. It’s literally simple as that.

C: We have arrived at the “C”. This represents constraints. A constraint is something that limits your capabilities. Meaning some specific rules are in place that restrict access to certain methods you may use. What are the constraints of the problem? Are there any? If there are, try to recognize them and work within the limit. In this case they’re aren’t any specified.

It’s good practice to think about constraints for future problems.

E: “E” is for edge cases. Edge cases are things that you may not have accounted for. Your problem might be dealing with numbers but what happens if a negative number gets thrown in the mix?

A possible edge case for this may be that input values were arrays or objects themselves. Would they have to be split up into array of arrays themselves? Here is the final solution and it works.

Had I known about this simple approach to solving problems, I would have saved myself a lot of pain and suffering. At first, I would just brute force my way through a problem without considering these questions. I’ve made many mistakes when I didn’t know where to start (input) or where I was going (output). I just kept trying things without understanding what the prompt was originally asking me. O.I.C.E could’ve saved me tons of time.

Using O.I.C.E can be a very powerful tool. But if you’re unsure about something, don’t be afraid to ask questions. If you’re in an interview, get clarification by asking your interviewer a question that will help you get a better understanding of the problem. Try to get the O.I.C.E questions answered first. It will help you go further than you can imagine.

When you’re trying to learn something new for the first time, it can be frustrating. But after you know it, you won’t have to think about it too hard. You’ll become autonomous to small problems and big problems alike. Pretty soon you won’t even freak out when you hit a big problem and you’ll be able to break it down into small parts. Hence the beauty of such a simple but effective method, O.I.C.E.

One clap, two clap, three clap, forty?

By clapping more or less, you can signal to us which stories really stand out.