Stripe and Retool both have a debugging interview — Stripe asks it in the onsite, while Retool uses it as a first-round interview. I ended up receiving offers from both of these companies, so I wanted to share how my experience for these debugging interviews went.

How the interview usually starts

After exchanging pleasantries, your interviewer will ask you to clone a repo on Github (or they'll send you the code via email). Don't worry if your Github is acting up and the good ol' git clone isn't working— you can just download a ZIP of the repository directly and open it within your editor. The interviewer won't care— this is a debugging interview, not a "how do I fix my Git" interview, so just do what's fastest.

There will usually be a README which has instructions, which contains instructions on how to run a test that's — surprise! — failing.

The Stripe interview involved fixing a single bug, while Retool presented multiple. Stripe used code from a popular open-source library, and Retool provided a custom codebase, relatively smaller in size.

How to approach this interview

Study the failing test

Read the prompt carefully. Run the test, make sure it is indeed failing. Quickly confirm with the interviewer that you're looking at the right test.

There's no way you'll be able to read through all the code in the repository during the hour you have to debug. Be efficient with your time. Start reading the code containing the failing test, and figure out what the test is trying to do. At a high level, you're trying to answer these questions:

• What does this function expect the value to be? Why?
• What is the current value? Why?

Locate the problematic function.

Make sure it's the right function. Add a print statement or a debugger to be absolutely sure that you are looking at the right spot. Function names are not always unique (e.g. same function name within different modules) — but if you have a decent code editor that lets you right click into a function and jump to the definition, you're golden. I still recommend the print/debugger to be very sure you're in the right spot.

Study the function

Read the function carefully. Say out loud what each line of code is doing. Annotate the code — you don't have that much time to reread these functions, so I suggest using comments to cache the work you're doing here. If your interview is friendly, they might correct your statements in real-time. I find it helpful to write a one or two sentence summary of what the function does at the top — though it wouldn't be overkill to add annotations every few lines in the function.

Repeat as needed as you move from function to function.

Find code that looks suspicious.

This often comes with experience. For example, there might be an issue with slicing a list in Python; the code might've treated the ending index as inclusive of the element. Or, there's an off-by-one in a for loop somewhere. Or, the list is being mutated but not saved, or the list wasn't supposed to be mutated but was.

Start by saying a few theories — then validate. I used Python's pdb to walk through each line of the function to confirm what the values of each variable were and if they were what I expected them to be.

Repeat until you find the bug.

A well-designed bug squash interview won't be straightforward — you'll likely need to go through multiple layers of code, following functions from one to the next. There might be multiple issues with the code, or it may be costly to invalidate theories about which part of the code is wrong.

Fix the bug.

Write code that solves the bug, but is also easy to understand. Consider whether your edits affect the runtime of the code or mutate the returned output in some other undesired way, and clarify with the interviewer if your suggestion on how to fix the bug is acceptable.

Tips for Success

Verbalize your thought process.

Let me repeat that again. Verbalize your thought process. Is there a worse way to spend this interview than to just sit in silence and try random theories in your head? What do you think the interviewer is going to write for interview feedback? If you at least tell the interviewer your theories on where the issues are, they have some gauge on what and how you're thinking about the problem. I'm fairly certain my explanations of what I was doing and why I was doing it was what got me a passing mark in the Stripe debugging round — I could find the bug, and I knew why the code wasn't working, but I wasn't sure how to fix it (it involved a bit more specific knowledge that I didn't have at the time).

Know how to use the debugger.

If you're going into a Python debugging interview and you've never used pdb before, you're at a significant disadvantage. Figure out the debugging tools for your language of choice and learn how to use them effectively.

Keep track of time.

If you've made near 0 progress in the first 20 minutes, I'd recommend asking for a hint. If your interviewer has mercy, they'll give you one — and hopefully it's enough for you to unblock yourself and make more progress in the rest of the interview.

Annotate the code.

It's like leaving breadcrumbs for yourself as you navigate this foreign, confusing land. Save yourself some mental cycles and cache the work you've done already via code comments (or even write out what the code is doing on a separate file if you really need to).

Thanks for reading and best of luck on your interviews!

For more articles like this, follow me on Medium. Not a member yet? Join the community. Want more software engineering interview guides and coding question tips? Check out my site at santal.tech.

If you have any requests for what I should write, please let me know!