My team allows candidates to use any editors during coding interviews. I noticed that during interviews, a lot of candidates are not using their tools to the full potential to assist their debugging. More people are used to whiteboard coding.

Different from whiteboard interview, you can't draw diagrams to aid your thought process. But coding in an editor is more close to a real dev environment. How a candidate behavior can better reflect how he/she would perform when working here.

I have some tips that I gave to almost everybody I mocked interviewed with.

Code incrementally, test frequently

You should try running your program as soon as you have 10 lines of code on the screen (or even less). For example, try printing out an intermediate result. Don't wait until you finish your code, and find that you made a mistake somewhere along the way.

Test all test cases, not one by one

The interview question usually comes with some examples. Combined with some edge cases that you found, you should have a set of inputs and expected outputs. I have seen people testing them one by one by . They hardcoded the input in the program and hit the run button. If it works, they change the input to test the next test case. If it doesn't work, they fix the program, but now they need to test any test cases that they already tested before.

Why not call your code with all the test cases at once. If you change the code, you can just run it.

// no
function myInterviewQuestion() {
    var input = "my current input";
    ....
}
myInterviewQuestion();

// yes
function myInterviewQuestion(input) {
    ....
}
myInterviewQuestion(input1);
myInterviewQuestion(input2);
...

Printing is fine, but watcher is better

With an IDE (Integrated Development Environment), it's very easy to get feedback on your code. Let the tools do the calculation for you. You can print the intermediate values out. However, make sure to organize your logs. If you are printing a number, make sure you understand what it means in the log. You can do so by printing some prefix like "currentCount=".

// no
LOG: 23
LOG: 10

// yes
LOG: age is 23
LOG: length of the array is 10

Printing is helpful, but if you have too many outputs, you might get lost. Also you can't add a print statement in runtime. How many time have you regretted: "Ah, I want to know this value. I should have added a print statement there."

Well, IDE comes with more powerful tools. You can set breakpoints, you can inspect a variable, you can evaluate an expression, you can view a call stack. Those are super useful when debugging. I would recommend everybody before going into an interview that allows IDE, to learn your tool well.

Avoid programming by coincidence

Programming by coincidence is a concept from The Pragmatic Programmer. The ease of just running the program and getting feedback sometimes encourages people to make changes blindly, and run the program to see if it works, instead of thinking through the problem. Note that this is different from testing incrementally. Programming by coincidence usually happens when the candidate finishes the code, and are trying to debug some problem. Programming by coincidence is detrimental in coding interview. It will waste a lot of time and also delivers a bad signal to interviewers.