Interviewee's T-tests
2024-10-17I've been running a lot of coding interviews lately, especially for people coming directly from university. And it strikes me that many candidates will keep only a single informal test that they write and rewrite as they want to check things about their code.
This always sort of bothers me because when you delete a test the first time it passes, you lose the ability to catch regressions. But also because what a "test" is is so informal when you're rewriting the same piece of code over and over, many candidates don't really think about what exactly the goal is of any given test and won't comprehensively test their code.
The easy and practical way to avoid these pitfalls is to keep your old tests and copy-and-paste a new one instead of rewriting the same one over and over. But I'm going to propose a swaggier solution: the T test framework.
The test framework is called T because it's meant to be extremely short and easy to understand (plus it makes joke in the the title work). My hope is that you can read this post and then weeks later reproduce the test framework from memory and explain how it works in under a minute.
You can find the T framework for all the programming languages I feel comfortable doing interviews in—Rust, Python, and C—with their output below the code. But it should be easy to write versions in your programming language of choice.
Rust
=== failing
thread 'main' panicked at src/main.rs:12:9:
assertion failed: false
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
=== FAIL
=== passing
=== PASS
Python
assert False
assert True
=== failing
Traceback (most recent call last):
File "/Users/eli.hunter/t.py", line 6, in test
t()
File "/Users/eli.hunter/t.py", line 14, in failing
assert False
AssertionError
=== FAIL
=== passing
=== PASS
C
int
int
void
int
=== failing
returned 1
=== FAIL
=== passing
=== PASS