What’s OICE? Oh that’s niceee…

A Setup Framework to Technical Interviews and White Boarding

If you’ve ever done a technical interview before, you realize that frameworks are one of the best ways to help you calmly think about a problem and work through the steps to your solution. Whether these are for management consultant positions with case interviews or in my case — technical questions for software developers, systematizing a way to handle interviews are often one of the key differentiators in helping you land the job.

I know that Gayle McDowell in her famous Cracking the Coding Interview offers a 7 step framework to handle technical questions (she is awesome by the way). Now her approach is a great way to actually work through the actual problem solving process, but OICE is a great mechanism I’ve learned to help you with the initial setup to tackle the problem.

The Setup

So you’re beginning your interview and you get through all the formalities with the interviewer. Then he/she asks you, “How about we walk through a technical question together?” Of course you should respond enthusiastically, ready to crush all challenges ahead of you. But, before you dive straight in, be sure to give time to setting up the parameters of the question.

Something along the lines of: “That sounds great! Would you mind if I spent some time walking through a framework to help position ourselves to think through this problem better?”

You’ve instantly separated yourself from the competition by:

1. Showing poise and opening a line of communication with your interviewer — I have been told so many times that the #1 mistake interviewees make is freaking out and shutting down in silent doom.
2. Giving yourself some time to logically think through the given question. The stress of technical interviews have a way of making even the brightest people shut down. The interviewer wants to see your critical reasoning and problem solving skills, not just if you can get the right code.
3. Flexing your knowledge about this cool way to approach technical problems. It shows that you are really prepared and have taken this interview process seriously.

Now for OICE…

Outputs

• Think through the outputs that are expected from you. Ask informative and clarifying questions to your interviewer: “So this solution should involve me creating a function that returns an array of sorted strings? If the answer is 0 then should I return 0, null, or undefined?”

Inputs

• Initially you may have certain assumptions about what you may be taking in. Clarifying exactly what your solution (most likely in a function) should be taking in as an input will help you think through what you could do with that input. “Will this input type always be a number or string? Will it be a whole number or negative value? Should I return an error if the input is incorrect?”

Constraints / Complexities

• “Is there an expected time or space complexity? Are there any other constraints I should be aware of?” On the topic of constraints, it’s definitely critical to train yourself to write cleanly and clearly enough on a whiteboard to have enough space for both your setting up and code. This probably means you should practice by using pen and paper or a whiteboard. The sweet irony of technical or whiteboarding problems is that you usually can’t use a computer…

Examples / Edge Cases

• Come up with a couple test cases to give yourself a bearing on working through the problem. Also, coming up with some more difficult edge cases may help give you a better grasp on exactly what you should be doing to shape your solution.

Well that’s the OICE framework for you. It may seem silly at first, but this setup process is make a day and night difference in helping you work through a solution.

Here are also a list of some great resources to help you on your technical coding interview journey:

• Cracking the Coding Interview
• Elements of Programming Interviews
• Algorithm Design Manual
• Programming Interviews Exposed