The REACTO! Pattern for Acing Technical Interviews

As you may know, interviews for software engineering roles involve a technical component. Over many years of interviewing (and being interviewed), Nimit and I have developed a mnemonic for how to handle interviewing questions that we call REACTO! (exclamation optional). REACTO! stands for:

REPEAT
EXAMPLES
APPROACHES
CODE
TEST
OPTIMIZATION AND COMPLEXITY (BIG-O)

To elaborate…

1. REPEAT the question. You’d be surprised how many times I’ve seen a recruit start coding while completely misunderstanding what I’m asking of them. Repeating the question also gives you the chance to gather your thoughts and get over the initial butterflies in your stomach.

2. EXAMPLES Play out various examples on the board. For example, if you’re working on a merge-sort algorithm, write out a list and then what the list would look like after several levels of recursion.

3. APPROACHES Start talking about the approach you’re going to take: recursive, iterative, heuristic? Giving the interviewer some insight into your logic and thought process helps them track what direction you are going.

4. CODE Author Gayle Laakmann McDowell gave a talk at Fullstack recently and gave a great tip for coding on the exam (if you’re interested in seeing her full video of tips, feel free to email us). She calls this “Breadth-First Coding”. The core idea is to write out the steps of your solution first before diving into the details, then implement the details. This is good development practice and you won’t get bogged in minutia and run out of time.

Some additional tips:

• Leave yourself room between each line for later edits
• Star things you’re not sure about
• Pseudocode things that you know you can do but can’t figure out right now

5. TEST When you’re finished, Run an example line by line through your code. Use space on the side to write down the current state of data. Go back and run your examples and see if they work.

6. OPTIMIZATION AND RUNTIME O(n), O(n^2) - how would this perform for large data sets? This is often something you would want to address as you discuss different options and approaches you could take to solve the problem. Perhaps you went with a brute force approach to get it done but have an idea for a better method. There is lots of great advice for approximating big-O but the main thing to remember is: what will be painful for my algorithm if one of these inputs got significantly larger?

Additional Advice

When you first hear the question your mind kicks into overdrive and it’s easy to find yourself overwhelmed. But if you break down the process into these smaller steps it becomes a matter of simply making the next logical jump.

We’ve compiled some other tips that we think are helpful as you seek to prepare and practice coding interview questions:

1. Stay Calm. You aren’t expected to know the answer immediately; if you do then you’re probably wrong. These problems are meant to take some thought and be worked through. Focus on breaking down the problem.

2. Remember to ask questions when you get stuck. Did you hear the interviewer right? Are you clear on what they asked? Draw out a new example case. What have you not taken into account?

3. Don’t start writing right away! I see this so many times and I know it’s a reflex reaction from nervousness - but take a breath and… REACTO!

And most importantly, practice, practice, practice! Interviewing is a skill like any other. Get together with friends and work out problems on a white board or a piece of paper. Practice speaking and writing code in front of other people. The more comfortable you are doing that the more you can think about how to answer the question. If you’d like to share some of your tips, feel free to email them to me at david@fullstackacademy.com!