Job interviews can really suck, but I don’t dread interviewing nearly as much as I used to. This is the second post in a series about how I manage my interview processes to achieve that. Maybe some of my methods will work for you, too.

In the previous post, we talked about a batch of tactics for increasing touch points during the interview process.

Today we’ll talk about establishing success metrics for interviews.

Interview processes are scary, in part, because we rely on external validation.

When we think about whether it was worthwhile to do an interview, we tend to focus on the outcome. We worry about “how we did,” and we use our success in getting to the next round or getting an offer as the success metric.

So we rely on a decision that is out of our control to provide us with external validation.

I try not to rely on external validation like this.

I want the decision about whether the interview was worth my time to belong to me. So I don’t need the company to make me an offer for me to feel like my decision to take the interview, or my decision about how to take the interview, to have been a good one.

Instead, I go into each interview with two goals of my own:

 1. To meet someone.

I go into interviews with a plan to get to know some of the interviewers a little bit. Then, if I have a particularly interesting conversation with any of them, I try to get their contact information so we can connect afterward. First, it’s good to know folks that I can call and ask for their thoughts on technical decisions. Second, they might be looking for a job one day, and maybe I can help. Third, even if I don’t end up at the company they’re currently at, if we had a good interview, they might call me at their next company.

 2. To learn something.

I want to come out of every interview with a bigger skill set than I had when I went in.

First, I make sure that the programming challenge, if there is one, is something from which I can learn something. Can I do it in a language I have been meaning to try? Does this give me an opportunity to test out an architecture pattern?

If there is no code challenge or if they have used some of my previous code in lieu of the code challenge, I’ll look for the same in the technical portions of the in-person interview. I’ll ask questions of the interviewer during these technical interviews about the things that make me curious, or about areas where I don’t know as much as I’d like.

Finally, I ask for the interviewers’ feedback regardless of the outcome of the interview. If I got moved on or got accepted, I’ll reach out to the folks whose contact information I got to ask them for their feedback. If I did not get moved on or accepted, often the hiring manager will send me a form email. So I have a rejection script that I use on these occasions to minimize emotional labor for me while still capitalizing on the possibility that they’ll send me feedback. Having this script also reminds me that rejection is normal and happens sometimes, and I have a step to follow in the event that it happens (send the email with the script). I find that having steps to follow in unpleasant situations helps me cope with them and reduce overall anxiety.

Here is the script:

Sounds good. Thank you for letting me know, and thanks for taking the time to chat with me.

I’d love to hear a little more about [COMPANY]’s decision, if you have that information

Was the team looking for a specific perspective or experience that I didn’t have? This info will help me determine where to level up in the meantime, and whether it makes sense for me to apply again at some point in the future

If, instead, it was something about what I’m looking for that doesn’t fit with [COMPANY], then I can keep that in mind for referring colleagues who might have different goals than me, and for whom [COMPANY] might be a good fit

Thanks!

Conclusion

When we think about whether it was worthwhile to do an interview, we tend to focus on the outcome. We worry about “how we did,” and we use our success in getting to the next round or getting an offer as the success metric.

So we rely on a decision that is out of our control to provide us with external validation.

Instead, I use my own success metrics about whether the interview was worth my time. These metrics are more in my control than the outcome of the interview.

The metrics:

1. Did I meet someone?
2. Did I learn something?

I have a few techniques that I use to improve my success on those two metrics, and they help me feel like the interview was worthwhile and helpful to my career even if the company doesn’t move me forward. In the next post, I talk about finding the companies where this strategy will produce the most benefit.

If you liked this piece, you might also like:

The Behind the Scenes post series (about doing podcasts, talks, and teaching in tech)

The Leveling Up Series (about improving your own skills as a technologist)

This transcript of a lecture on giving and receiving feedback (another excellent anxiety-reducing skill!)