I've heard that some interviewers will intentionally not mention testing when asking a coding question to see if the interviewee will bring it up themselves and prove that they actually consider testing when they write code.
When I'm writing a function in an interview, I like to start out by defining what some unit tests would look like (not actually writing tests, more of a mapping of the expected outputs given certain inputs). Not only does this show that you're thinking about tests, but it gives you a chance to confirm that you understand the intended functionality before you write the code
I love your approach with starting out by defining what unit tests would look like.
Please encourage anyone you meet who thinks that not mentioning testing in an interview to see if the interviewee will bring it up to knock it off. That's obnoxious and an example of a toxic interviewing habit IMO. Here's just a few reasons why. First, how do they know that the interviewee is not doing the same thing, and specifically omitting mention of tests to see if the company they are interviewing for tests anything? That's a zero sum game when both walk away thinking the other doesn't test for no reason other than that they are bad communicators. Second, interviewing should never be a guessing game. There's (usually) only 45 minutes with each other and there's far more content to cover than the time allows. If testing is important it needs to be a focus. Finally, interviewees are in a situation with a huge power imbalance and even the most experienced person can overlook one thing or another in the moment.
I've heard that some interviewers will intentionally not mention testing when asking a coding question to see if the interviewee will bring it up themselves and prove that they actually consider testing when they write code.
When I'm writing a function in an interview, I like to start out by defining what some unit tests would look like (not actually writing tests, more of a mapping of the expected outputs given certain inputs). Not only does this show that you're thinking about tests, but it gives you a chance to confirm that you understand the intended functionality before you write the code
I love your approach with starting out by defining what unit tests would look like.
Please encourage anyone you meet who thinks that not mentioning testing in an interview to see if the interviewee will bring it up to knock it off. That's obnoxious and an example of a toxic interviewing habit IMO. Here's just a few reasons why. First, how do they know that the interviewee is not doing the same thing, and specifically omitting mention of tests to see if the company they are interviewing for tests anything? That's a zero sum game when both walk away thinking the other doesn't test for no reason other than that they are bad communicators. Second, interviewing should never be a guessing game. There's (usually) only 45 minutes with each other and there's far more content to cover than the time allows. If testing is important it needs to be a focus. Finally, interviewees are in a situation with a huge power imbalance and even the most experienced person can overlook one thing or another in the moment.
Oh I totally agree. There should be clear communication about the expectations in an interview, and it's a bit of a red flag when there isn't.
Unfortunately, job interviews can often become a platform for people to exercise their own personal psychology theories.