Know your environment.
Once the races begin it's more difficult and there is never that much time for testing. (Valentino Rossi)
Something that comes up often in interviews is manual testing. In the age of in-person interviews, you could often wave your hand and say "imagine I have a working heap class". The interviewer might have prompted you to explain the properties of a heap, but that was about it. Implementation could be left to the imagination.
Facebook and a few other companies still have no-compile environments, meaning you can't run your code. Obviously, this can create problems when testing that your underlying data structure implementation works properly, so most interviewers will just let it slide. But this is not the norm.
The large majority of companies in the post-COVID age require you to run your code. Personally, if they also allow you to look up things (eg: documentation) during an interview, I think this is completely fair. What boggles my mind is interviewers who would demand the correctness and execution of someone with internet access, but ask you to pretend like there are no resources that exist.
Do large companies store all of their knowledge and data in memory? I don't think so. The internet is one big distributed database, and you should be able to use it. Enough on this, back to testing...
Verify your logic.
After you're done crafting your initial solution to a problem, you may spend lots of time manually verifying your code.
If you're in a no-compile environment, it would benefit you to prepare like it. This means doing manual walkthroughs of your code's logic, copying down the state as you go.
If you're in a runnable IDE-like tool (Coderpad, CodeSignal, etc) like the rest of us,
When syntax errors or minor logical issues can make or break your interview success, being able to test without thinking is essential.
Use a standardized template.
If you haven't practiced the skill, you should. You can and should use a template/framework to test your code. In most languages, a test array is the optimal approach.
Instead of having print(...) statements for every test case, write your test logic like you would write any other piece of code. DRY.
That's all – as promised, here are the templates:
Javascript
/* Create test table with results and assertions */
const tests = [
solution([5, 3, 2, 4, 1], 14) === 1,
solution([5, 3, 2, 4, 1], 15) === 1,
solution([5, 3, 2, 4, 1], 16) === 0,
]
/* Use console.table to print out assertions in tabular format */
console.table(tests)This is particularly cool in Javascript, and provides a solution much cleaner than most other languages. It usually ends up looking something like this:
┌─────────┬────────┐
│ (index) │ Values │
├─────────┼────────┤
│ 0 │ true │
│ 1 │ true │
│ 2 │ true │
└─────────┴────────┘Python
# Create an array of test cases:
tests = [
(params1, expected1),
(params2, expected2),
...
]
for params, expected in tests:
actual = f(*params)
if actual != expected:
print(f"Test failed for {params}. Expected: {expected}, Actual: {actual}")
else:
print(f"Works fine for {params}.")The version for Python is slightly less cool, but it gets the job done. Your interview will still appreciate you for it.