Update interviewees_t_test

content/blog/interviewees_t_test.md

@@ -7,11 +7,11 @@ I've been running a lot of coding interviews lately, especially for people comin
 
 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 that I call **Interviewee's T-tests**.
+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 idea with T-tests is that they are an _extremely_ small and easy to understand test framework that you could write from memory and explain in less than a minute.
+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](https://en.wikipedia.org/wiki/Student%27s_t-test)). 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.
 
-Below I've written some T-tests in all the programming languages I feel comfortable doing interviews in, with their output below the code. But it should be easy to write versions in your programming language of choice.
+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
 ```rust