As anyone who's spent an afternoon Googling for interviewing tips can tell you, the post-interview thank you (PITY?) email is a commonly recommended and yet underutilized technique for distinguishing yourself as a candidate. That said, I've proctored and been the subject of dozens of technical interviews, and I honestly can't think of a receiving a single PITY email. Perhaps this is a demonstration of how underutilized the practice is, but I'm more inclined to believe that it's simply less of a thing in more technical fields where a candidate's technical skills and ability to simulate realistic human social interactions are often the differentiating factors. It certainly doesn't help that it often feels like you're more likely to run into an engineer with a comprehensive understanding of Brainfuck than you are to run into an engineer with a business card.

This post isn't intended to convince you that you should write PITY emails. I like to write them because having been involved in dozens of interviews, I know how disruptive interviews can be to flow and I really do appreciate people taking the time to consider me for a role. Whether PITY emails distinguish me as a candidate or flag me as a lunatic is the subject of open debate. Regardless, PITY emails are at least one last opportunity to make a positive impression before the interview team gets together to discuss whether all that spasming and twitching was nervousness or indicative of a deeper problem, but also more ideally, whether you are the right candidate for the job.

This post also isn't intended to teach you how to write a good PITY email. I like to write PITY emails, but I have no delusions that I'm good at them. I'm, personally, very against form letters so my approach to PITY emails tends to be to say thank you and reference some discussion, joke, or event that helps show that, of the horde of humans I probably met that day, I remember that they are the one designated Jessi. This approach is also useful to remind them who you are because for all you know they had seven other interviews that day and though I know you're not just a unique snowflake, you're a fortress of solitude of unique snowflakes, you should understand that interviews blur together and they probably could use a reminder of which one you were. This approach also tends to mean that my PITY emails are relatively short, which I think is a good thing.

The real goal of this post is to empower you with new magical abilities for figuring out where to send those PITY emails, should you decide to write them.

I certainly can't speak for others, but I've found that putting in the leg work to be effective with PITY emails can be hard. As I said before, engineers rarely offer business cards and demanding the email address of everyone you meet with during interview sessions (that are already cramped for time) tends to feel, even in the best scenarios, awkward.

Sure, services like LinkedIn can make it easier to connect with other professionals, but sending a PITY email via LinkedIn feels like the wrong context to me. Beyond that, current employees of the company you're interviewing for, ideally, shouldn't be checking their LinkedIn for new messages everyday, which means either they won't see your PITY email until next week or you should be concerned that current employees are so desperate for new job opportunities. Another downside of LinkedIn is that more cautious individuals will tend to check LinkedIn at home and I am strongly of the opinion that any PITY emails I send should be received (and inevitably flagged as spam) exclusively during business hours.

Telnet + SMTP for fun and profit

So, excessive preamble out of the way, here's how you can use UNIX command line tools like nslookup and telnet to dispatch a few basic, low-level SMTP commands to aid in your quest to map interviewer name to interviewer email address. This is by no means a complete tutorial and the procedure outlined below will not work for all domains. That said, if you run into such a scenario, please feel free to share it so we can work together to make this process more robust. Depending on your level of experience, what follows may seem difficult, but it's really not so bad once you get the hang of it.

For the examples that follow I will be querying the gocatalant.com domain. I recently interviewed there and went through this process to work out the email addresses of those I interviewed with, so I know, at least as of October 2016, that this process works for that domain.

If you're not familiar with Catalant, you should check them out. They seem like an awesome group of smart people with some great ideas around disrupting the future of work. It also doesn't hurt that I have a few friends there that we can lookup, plus I get the impression that their co-founder Patrick Petitti wouldn't mind being called out in a technical post like this one. Famous last words?

Step 1: Determine the mail exchanger for the given domain

As you are probably aware, a domain's MX record is a type of DNS resource record that specifies the server that accepts email messages on behalf of the domain. Ultimately, a domain's set of MX records describes how emails should be routed over SMTP.

In order to connect to the domain's MX server with telnet so that we can issue a handful of SMTP commands, we must first find the address of the server we want to connect to. There are a number of different ways of doing this that are mostly equivalent, but depending on your OS and the tools available to you, you may find one more convenient than the others.

nslookup

Command:

nslookup -q=mx gocatalant.com

Output:

Server:         8.8.8.8
Address:        8.8.8.8#53

Non-authoritative answer:
gocatalant.com  mail exchanger = 0 gocatalant-com.mail.protection.outlook.com.

Authoritative answers can be found from:

host

Command:

host -t mx gocatalant.com

Output:

gocatalant.com mail is handled by 0 gocatalant-com.mail.protection.outlook.com.

dig

Command:

dig -t mx mydomain.com

Output:

; <<>> DiG 9.10.3-P4-Ubuntu <<>> -t mx gocatalant.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 14549
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;gocatalant.com.                        IN      MX

;; ANSWER SECTION:
gocatalant.com.         641     IN      MX      0 gocatalant-com.mail.protection.outlook.com.

;; Query time: 25 msec
;; SERVER: 8.8.8.8#53(8.8.8.8)
;; WHEN: Wed Oct 19 15:21:14 UTC 2016
;; MSG SIZE  rcvd: 98

Good news, everyone! All signs point to gocatalant.com using gocatalant-com.mail.protection.outlook.com for their mail exchanger. Now let's use that address to assist with our email probing.

Step 2: Connect to the MX server with telnet

If you've never run across telnet before, I'd describe telnet as a command shell for interacting with text-based TCP protocols. If you've never played with it before, I'd definitely recommend taking a few minutes to poke around. It can be very handy for debugging connection issues. It can also be a neat way of getting a glimpse of how popular text-based protocols like HTTP and SMTP work at a low level. If you've heard people remark that HTTP/2 is harder to debug than the previous HTTP spec, telnet will definitely give you a better sense of why.

The syntax for telnet is pretty simple. At it's most basic it's simply the telnet command, what host it should connect to, and what port on that host it should connect to. We've already figured out that the host we want to connect to is gocatalant-com.mail.protection.outlook.com and luckily, port 25 is the standard port used for SMTP. If you're unsure what port to use for a particular protocol, IANA's Service Name and Transport Protocol Port Number Registry can be a very useful resource.

Now that we have all the info we need, here's how we can start a telnet session with the MX server:

Command:

telnet mail-sn10106.inbound.protection.outlook.com 25

Output:

Trying 207.46.163.106...
Connected to mail-sn10106.inbound.protection.outlook.com.
Escape character is '^]'.
220 SN1NAM01FT053.mail.protection.outlook.com Microsoft ESMTP MAIL Service ready at Wed, 19 Oct 2016 15:43:23 +0000

Success!

It's worth noting that unlike the other commands we executed to find the MX server for the gocatalant.com domain that printed their output and then exited, telnet doesn't exit immediately. Instead, telnet starts a new shell session that remains open until the escape character is received (typically CTRL-]).

If telnet is unable to connect or the output doesn't seem right, it may be worth trying other means of looking up the domain's MX record to be sure you're attempting to connect to the right host. For the purposes of this exercise, the port of public SMTP servers should almost always be port 25 so if there's a problem it's probably an issue related to the host.

Now that we've got telnet running and connected to the desired host, it's time to delve into the dark magic of SMTP.

Step 3: Execute the SMTP commands to query if an email address exists

Until next time...

I think figuring out a way to communicate that you wanted to say thank you, but not only that, you also used your radical technical skills to ensure you were successful in that endeavor could be a really great way to distinguish yourself technically and as a decent human being. I haven't yet figured out a way to do this that isn't excessively long or boastful, so instead, I blog about it.