This is Going to Hurt You More than Me

Greetings from the ending of a self-imposed blogging silence: I got the aforementioned email and am happy to state that I will shortly be joining Microsoft.  Sur La Table was very diverting and offered many challenges with respect to data, but it’s hard to pass up an opportunity to work in, and with, big data.

As a result of that interview loop, plus some interviews I did for an open position we have at Sur La Table, I’m here to write something Very Important: Don’t Lie on Your Resume.

Typically when I am called in to conduct a technical interview, I read the candidate’s resume, and then ask the hiring manager how technical they want me to get. If it’s me, and I’m hiring for a developer, I’m going to get very technical, and you’re going to spend 100% of your time with me at the whiteboard. If it’s for someone else, and I’m hiring for say, a PM, or a QC, or technically-minded-but-not-otherwise-a-developer role, I’m still going to test you on skills you state in your resume.

So when you tell me that you have a lot of experience with SQL, or that you’ve been using SQL for five or six years, I’m going to run you through the basics. Either of those statements will tell me that you know the four major joins, you know the simplest way to avoid a Cartesian product, you know how to create data filtration in a join or in a where statement, and you know how to subquery. I’m not even getting to more advanced parts like transactions with rollbacks, while loops, or indexing — the aforementioned list are what I would characterize as basic, everyday SQL use.

Imagine my dismay, then, as an interviewer, when after declaring (either verbally or on your resume) that you are a SQL expert, you can’t name the joins. Or describe them. Or (worse) describe them incorrectly. When you say you know SQL, and then prove that you don’t, it makes me wonder what else is on your resume that you “know”, that is less hard to prove (in the interview) that you don’t. The default assumption, for the protection of the company, is that your entire resume is a raft of lies. It’s the surest way to earn a “no hire”.

It would have been far better to state the truth: someone else wrote SQL scripts for you, told you what they did, and you were adept enough to figure out when there was a disparity in the output. That does not mean you “know” SQL, it means you know how to run a SQL script. This gives the interviewer an honest window and the ability to tailor your time together (remember, they’re getting paid by the company to spend time with you, if it’s productive it is not a waste of money) to figure out your strengths and weaknesses. Having just been hired into a position that works with big data, where I was honest that the largest db I have worked in and with was about 3TB, I can attest that it’s really hard to have to look a hiring manager smack in the eye and say: “I have 90% of what you have asked for but I’m missing that last 10%”. It gives them the opportunity, however, to decide if they’re going to take the chance that you can learn.

If they’ve already learned you’re honest, then that chance-taking looks better in comparison.

I hate waiting.

For reasons that I can’t (and therefore won’t) get in to right now, I’m obsessively waiting on an email. One. Specific. Email.

This sort of obsession is hindered by the very reality that on any given day, I get about 200 work-related emails (if you include the junk mail from vendors who seem to think I’m hiring scads of people or want to outsource scads of work) and probably 50-70 personal emails (not including the invitations to enlarge my manhood or acquire millions from a long-lost eccentric cousin in Nigeria). The fact that this one particular email will come within a 5 to 10 day period, which means it represents 0.04-0.6% of my LEV (Legitimate Email Volume) does not help.

When waiting for that one email, a couple of behavioral shifts occur, including, but not limited to:

  1. Obsessively checking the iPhone to see if it arrived there
  2. Re-checking the desktop browser to see if it arrived there
  3. Keeping a browser tab open to email to see when the tab status changes to indicate a new mail has happened, and when you notice it does your stomach gets all giddy, and then you change tabs to open this one and discover that your Amazon order has shipped, and the giddy excitement crashes away into a wave of “meh”. Inbox(1) does not necessarily equal joy.
  4. Questioning whether or not you really expected the mail to come between 3:20am and 5:20am, which was this morning’s particular brand of insomnia (no, that wasn’t reasonable). Neither was it reasonable to expect it before 8am yesterday, or after 8pm, either.
  5. Trying to convince yourself that when they said 5-10 days they really meant “don’t expect it before 5 days, and from then on expect it within five days of that”, and not believing that *at all*
  6. Repeat steps 1-5.

There are two possible outcomes to this email: one is Tigger-esque mind-blinding joy and excitement. The other is a sense of doubt, self-questioning, and (eventually) redoubled efforts. There does not appear to be a contingency I can plan for beside these two results.

I am on day 2 of 10.