Month: September 2018

Sending Cold Emails

Andrew MinerLeave a comment

This is part 2 of a series on interviewing.  Check here for part 1 on setting up an interviewing team.

✧✧✧

At a rough guess, I get about 4–5 recruiting emails every week.  Sometimes more, sometimes less.  I only bother to even say “no” to perhaps 1 in 100.  The others go straight to the trash: often unread.  For the benefit of all my recruiter friends, I’d like to explain why.

First, I should mention that I’m a software engineer with roughly 20 years experience.  In that time, I’ve worked up and down the technology stack from web to mobile to back-end to dev-ops: you name it.  I’ve also worked for companies from IBM to a freshly-minted startup.  So, I imagine I’ve gotten on a lot of lists.

 

Getting it Wrong

The common thread in the 99% of emails I don’t answer is that they’re really just spam.  They obviously take no time to pitch me on why the job fits my interests, talents, or would be better than the job I currently have.  The worst offenders are the bulk emails which invite me to peruse a “jobs” page and apply.  Slightly less obnoxious are the “we saw your resume and think you’d be a good fit…” emails. However, they all focus on what the company wants: not what I might want.  Fire and forget may be a good tactic for filling some positions, but you’re never going to pull a qualified senior person out of their current company that way.

 

Getting it Right

The tiny fraction of emails I do answer have at least one of the following traits:

  • they come from the hiring manager / founder
  • they clearly demonstrate some specific knowledge about me
  • they clearly tell me why I—me in particular—would enjoy the work
  • they clearly reference that this is a referral from someone I’ve worked with

 

An Example

One email I recall getting recently was from Matt Lott, the co-founder of CodeCombat: a startup which is trying to help kids learn coding by making a (really cool) game out of it.  He nailed nearly every point on my check-list. Here’s the actual text:

Hi Andrew,

Fellow co-founder here. I checked out Crafting Guide – kudos on
building a really cool guide to everything Minecraft-related :). I
also read on your LinkedIn profile that you enjoy mentoring others so
I thought I’d reach out. Our “World of Warcraft”-inspired game teaches
kids how to become programmers; to climb between levels, students
write code to navigate mazes and defeat savage monsters. More than
20,000 teachers currently use CodeCombat, and our investors include
Andreessen Horowitz and YC.

So far, we’ve built a popular single-player game, and we have many
cool challenges on the horizon – like building real-time multiplayer
mechanics and revamping our graphics engine. With your experience, I
thought you’d be interested in leading these initiatives.

If you’re interested in helping kids learn, I’d love to chat. How
about a phone call or coffee next week?

Matt Lott
CTO, CodeCombat

First, this is clearly coming from the hiring manager / co-founder.  This means that someone who has many other responsibilities thinks there’s a good enough chance that we’d want to work together that it’s worth his time to contact me in person.

Second, Matt clearly did his homework here.  He obviously read my LinkedIn profile carefully; he noted that we’re both co-founders, and that I mention enjoying teaching.  He also found the gaming-related hobby site I made, and he obviously spent some time figuring out what it is all about.

Third, while a big chunk of the email is clearly pretty general-purpose, he starts by calling out the why my specific interests—teaching & gaming—would lead me to being interested in working on their product—which is all about teaching through gaming.  Then, he gracefully transitions from the more personalized part to the less personalized part.

In fact, the only point he didn’t hit was mentioning this as a referral, but hey… sometimes that’s just not the case.  Still, 3 out of 4 is better than 99.99% of recruiting emails I get.

And, for the record, while I didn’t accept Matt’s offer for coffee, we did have a very nice email exchange.  Of greater importance, though, is that if I heard back from him under different circumstances, I’d be happy to renew the acquaintance.

✧✧✧

I don’t need to tell anyone that there’s a lot more open headcount for senior people than there are actual people willing to join your company.  I also don’t need to tell anyone that, in general, we are well-paid, and have our choice of jobs.  Naturally, that implies that everything in recruiting is backwards compared to other more junior positions.

If I could make every recruiter understand one thing about recruiting senior-level professionals, it would be: you are in sales.  I’m a prospect, and you’re pitching a product to me.  You need to learn enough about me to understand what will motivate me to buy, and then sell it to me.  You’ve got one email to convince me that you’ve made an effort to pitch me on something that I actually want.  Don’t blow it on cheap form letters or junk mail.

Conducting an Interview Loop—Part 1: Setting up the Team

Andrew Miner2 Comments

I’ve worked at a pretty diverse range of companies from the massive (IBM, Microsoft) to the merely large (Amazon, Groupon), to the small (Boom, Pelago), to the positively tiny (Kima Labs, Redwood Labs).  In every place I’ve worked, interviews are conducted according to the same general pattern, but with a lot of differences in the details.  This series will explore what I think are the best practices I’ve seen across all those different places.

✧✧✧

Even before a candidate has been identified, the hiring manager should have prepared the team for the potential interview loop(s).  The first step is to actually have a team.  That is, a dedicated group of people for interviewing all the people coming in for a certain position.   This has several advantages:

  • the team can form a “group memory” of all the candidate who have interviewed
  • the team can coordinate on “focus areas” and even individual questions
  • the team will get to know each other’s questions, and therefore save time in debriefing about the candidates

I’d like to talk more about assigning “focus areas”.  Each member of the team should be assigned a couple of very specific areas to focus on.  For example, in the case of hiring a software engineer, one person might be asked to look at algorithms, another object-oriented design, and yet another front-end development skills.  In additional to technical areas, people are generally also asked to investigate some cultural value of the company’s.  For example, at Boom, we value people who like to make things in their spare time, so we might have someone assigned specifically to dig into that a little bit.

Once assigned an area(s) to focus on, each interviewer should plan out what questions they want to ask in order to learn the most possible about that area.  Here it works best to develop questions in two different ways: a simulation of actual job skills, and asking the candidate to relate a story.

Simulating actual job skills works best for technical areas of focus, and the best questions are those which are closest to the real task involved.  So, in the case of assessing programming skills, I’ll always make sure to have a computer on hand, and a set of real development tools installed and ready to go.  Finally, I’ll have made up a question which is a simplified version of some actual challenge I’ve had to solve at work.  The goal is to come up with a question which, as nearly as possible, uses the tools and skills the candidate will actually have to demonstrate at work every day.

Asking a candidate to tell a story (i.e., Behavioral Interviews) work very well in cases where a skill is hard to demonstrate on the spot, or when trying to understand a candidate’s culture fit.  In this style of questioning, you ask the candidate to tell a story about a time when… you fill the blank.  These are often things like: you had to deal with a difficult customer, you missed a deadline, you were forced to be innovative, etc.  These can also be much more specific.  For example, I might ask a software engineering candidate to tell me a story about when they had to fix a particularly nasty bug in a piece of code they weren’t already familiar with.

It’s extremely helpful for each member of the interview team to use the same questions for each candidate for a particular position.  This allows them to:

  • get better at asking the question in a clear way
  • get a sense of what good and bad answers look like
  • figure out what guidance works to help a candidate if they get “stuck”
  • be able to compare answers directly between individual candidates

This also allows the other members of the interview team to plan their own questions to avoid any possible overlap: especially when multiple people share the same areas of focus.

✧✧✧

At this point, you’ve got your team together, and you’re ready to start talking with candidates.  In future posts, I’ll talk the best practices I’ve seen around getting candidates to show up, what to do before they arrive, how to conduct the loop, etc.

Trash Trolley Mk. II

Gallery Andrew MinerLeave a comment

When I moved into my current house, there was a lot of work to be done.  One tiny piece of that was to remove / replace a long since broken trash compactor in the kitchen.  As one of the first projects I undertook in my wood shop, I tried to build a replacement.  It was… fragile, and is no longer with us.  So, I’ve just finished designing Trash Trolly Mk. II using what I’ve learned about furniture making since then to make it considerably more sturdy.  Here’s what I’ve got:

This slideshow requires JavaScript.

This uses a combination of mortis & tenon, lap, dovetail, and bridle joints to provide a sturdy frame which should be able to resist being dragged around the kitchen, and then a nice facade to match the rest of the cabinetry.  Hopefully, this one lasts longer than the first one did!

Choosing a product name

Andrew MinerLeave a comment

I started my company with a reasonably clear idea in mind of what product I wanted to build. The hard part was deciding what to call it. After doing a lot of reading and receiving a lot of advice, I decided the general criteria I needed to satisfy was:

  1. Relates a clear idea of what the product is about
  2. Is easy to pronounce correctly from just the written form
  3. Is reasonably easy to tell people how to spell it
  4. Has a domain name available

My next step was to generate a list of candidate product names. To start, I listed all the words I could think of which related to my product, and to ask other people to do the same. Here’s a small sample of that list: metrics, metric, graph, graphic, graphics, graphing, tinker, savant, guru, sage, insight, insights, workbench, toolbox

As you can see, the words generally grouped around certain themes, or were variations on the same word. Then, I started putting together combinations of words to form potential product names. At the same time, I started looking for available domain names to match. For each name, I looked for variants using the .com and .io top level domains (TLD), and with the words either run together or separated by dashes. Here’s a small sample of that list:

  • Metrics Workbench (all domains available)
  • Metrics Savant (all domains available)
  • Metrics Toolbox (metricstoolbox.com taken)
  • Graphic Insights (only dashed versions available)
  • Graphic Guru (all available, plus: “graphing.guru”)
  • Tinker Graphics (all available, plus: “tinker.graphics”)

As I was working through the process, I found that a dozen or so new TLDs had been added to the usual set, and so I started looking at names which used them (e.g., “Tinker Graphics” uses the .graphics TLD).

I then shopped these around with my friends, family and colleagues by asking these questions:

  1. What are your three favorites?
  2. For each favorite, which domain name do you prefer?
  3. Do any of these create a strong positive or negative association? With what?
  4. Do any of these spark better ideas?

Unfortunately, I found that none of my candidates did very well with my test group, but I got a lot of good feedback:

  • Don’t use dashes in your domain name (for SEO reasons)
  • Don’t use the new non-standard TLDs (e.g., .graphics)
  • Older non-standard TLDs were okay (e.g., .co or .io)
  • Try to find a single-word product name, even if you have to mis-spell it.
  • Suggestions of new words or themes to add to my mix of candidate words
  • Positive and negative associations (e.g., that words sounds cliched, that sounds like a porn site, etc.)

On my next round, I tried inventing single-word product names which sounded vaguely like real words, but weren’t. It was while brainstorming names with a CEO friend when I came up with “Graffer”, and we were both so immediately struck with the appropriateness of it for my product that I knew I’d found it.

The value of stepping away from your desk

Andrew MinerLeave a comment

As a solo founder, there were a lot of times when I felt very conflicted about an important decision I needed to make.  As an engineer, I often find myself vacillating on some tradeoff between various approaches to a problem.  As a programmer, I (all too) frequently find myself stuck trying to figure out some weird bug.

In each of these cases, my natural inclination is to stick with it, and struggle through the problem until I’ve got it all worked out.  Sometimes, this can even go on for hours late into the night.  However, I’ve become convinced that’s really the wrong approach.

After much painful experience, I’ve taught myself to step away from my desk and go for a 20 minute walk when I find myself in that situation.  While walking, I don’t particularly try to solve the problem (though I don’t deliberately avoid it either).  Whenever possible, I ask my wife to go along with me.

That 20 minutes away, and especially the mild exercise and change of scenery, resets my brain.  When I come back to the problem, I’ve forgotten all of the little details of exactly where I was with it, and I have to start over again.  While this seems extremely counter-productive, it’s actually extremely helpful.  The process of having to pick up the pieces again resets any erroneous assumptions I’d made about what I thought I understood about the problem, and it forces me to check my premisses about exactly what I think I know.  Nine times out of ten, this is exactly what I need to get back on track.

Landing on Both Feet in a New Industry

Andrew MinerLeave a comment

I recently started a new job in the aerospace industry at Boom Supersonic as a Software Engineer.  For those who don’t know, we’re trying to revive supersonic passenger travel (i.e., think: a modern Concorde).  Before starting at Boom, I’d never worked in aerospace, never worked with mechanical or aerodynamic engineers, and pretty much knew next to nothing about what the company has to do in order to be successful.  Given that, you’d have to think me a bit crazy, and the folks who hired me even more crazy.  Except, everything has gone great; let me elaborate on why.

The first part has to do with the company I joined.  Boom specifically looks for people who are excellent at their specialty, and are good at explaining it to other people.  This means that a new person has a ton of people around who are very happy to answer questions at length, and don’t consider any question a stupid one.  This has made making the jump a lot easier, but, of course, not everyone will be so lucky.

The second part is to deliberately study materials which provide an introduction to the field, and never gloss over anything.  Since there’s so much I didn’t recognize even in the introductory material, the temptation to allow it to just wash over me was constant.  However, allowing that to happen means that nearly everything I would learn afterward would be “floating”; that is, I wouldn’t be able to really explain it all the way back to something I could see and touch.  The difficulty, is that avoiding that trap is a ton of work.  As I progressed through that particular gauntlet, there were a number of techniques I used to help.

First, each time I ran across a term I didn’t understand, I paused in my reading to look it up.  As I was reading the explanation, if I saw another team I didn’t recognize, I’d pause again, and look that one up.  In getting into the aerospace industry, it would be common for me to get 3–4 layers deep before I’d get back to the original topic.  The benefit here is that by the time I did get back to the original subject, I’d be in a position for the reading to actually register with real understanding, instead of a vague notion of having seen certain words before.

There were a lot of times when even that didn’t help, because the term as used in the aerospace world was buried by search results of how the term is used outside the aerospace world.  In those cases, I needed to fall back to my second trick: write down questions as I go along. Then, when I’d finished a section of reading, I’d find someone (often multiple someones) who could answer my questions.  And, as before, I didn’t let their answers swim past me.  I’d challenge them to explain in terms I could deeply understand.  Not surprisingly, some people were better at this than others, and I quickly picked out the people who I found I could learn most easily from.  Then, as they were explaining, I’d try to echo their answers back my own words so that they could correct any misconceptions I had, or areas where I was fuzzy on certain ideas.

Finally, as I was going along, I’d write down the things I’d been learning in a document aimed at my fellow novices.  This extra pass through the material is where all the hard work of learning really got cemented.  First, it required me to go broad on what I’d learned in order to organize it into some coherent form.  Then, it required me to go deep into each of the subjects I’d been learning about to explain it clearly.  Since it’s a written document, I could take time to look things up again to refresh my memory on those things I’d forgotten, or never did completely understand.  I then went back to the same people of whom I’d asked my questions in the first place, and asked them look over my document.  This allowed them to clarify any points I’d gotten wrong and/or add extra details I had forgotten.  In the end, I’d created a resource for all my fellow aviation newbs who will followed in my footsteps.

✧✧✧

At Boom, I followed this advice and created a combined glossary of aerospace terms and FAQ about general aerospace topics.  Not only did this help me rapidly get up to speed on this difficult and complex new industry, but I’ve gotten complimented—from both novices and veterans alike—that the document was very helpful in learning something new.  Best of all, the document has since been added to by nearly every new person who’s joined the company from outside the aerospace industry.

Gotchas with using JSDOM for client-side testing

Andrew MinerLeave a comment

I’ve recently started using JSDOM for testing my client-side code. While I’ve been very impressed with how simple it is to set up, and how fast it is, there has been one major obstacle which I didn’t see documented anywhere else: it doesn’t actually lay out the HTML elements.

In other words, JSDOM supports creating the in-memory structure of the web page, even running JavaScript code and altering CSS attributes. However, it doesn’t actually assign the height, width, or other such attributes to the elements. They are perpetually all zero.

Despite this, you can do a lot of rigorous testing, and in a way which is completely identical to how your might set up server-side tests. In fact, I use exactly the same project & test set-up for testing both my regular Node.js modules as I do for the client-side ones. All you need is a little bit of pre-test set-up code to construct the JSDOM window and load a test page, and you’re ready to go.

However, if you want to write tests which verify the layout of things, you’ll need to use another solution.

Forming a legal entity (part 6): Open a checking account

Andrew MinerLeave a comment

After the long wait to get back my incorporation papers, the first thing I did was to open a checking account.  The most important reason this was first was that I’d been told many times that it’s crucial to keep the company’s finances completely separate from my personal finances.  This is one of the cornerstones of making the company a separate legal entity, and is crucial for the limited liability of an S-Corp to hold up in court.

A second reason to do this first was that, as a founder, I needed to “buy” the company, and the company needed a place to put the cash.  To make a long story short, when you create a company, you file with the state to create a new, completely independent, legal entity.  This entity is created with some number of shares of stock which it owns.  As the founder, and in order to become the owner, you must buy those shares from the company.  This, of course, is what gives the company its initial operating cash, and the company needs a place to park those funds (legal entities not having mattresses).

The final reason I started by creating a bank account is the obvious one: they’re pretty handy for paying bills.  I knew I wanted to buy some stuff for the business (e.g., a laptop, some office supplies, etc.), and I knew I wanted to sign up for various services (e.g., email, web hosting, etc.).  To do so, I needed a debit/credit card which would be accepted for these various online and offline transactions.

How to choose?

It turns out that business accounts, unlike many personal accounts, cost more, and come with many fewer benefits. After doing a bunch of research, I found banks generally varied by:

  • Quality of online banking access
  • Amount of annual fees
  • Minimum balance required (particularly to waive the annual fees)
  • Convenient branch locations
  • Extra services available (e.g., notary, support during acquisition, etc)

I think all the banks I looked at had an annual fee which could be waived if you kept enough money in your account (the particular amounts, of course, varied).  The banks varied considerably in the level of online banking support (from extensive to none) based mostly on the size of the bank (i.e. the local credit unions generally don’t have great websites, whereas national banks generally do).

I went with Bank of America (BoA), but there were a bunch of others which were close seconds (Comerica and Sillicon Valley Bank, in particular).  I liked BoA because its minimum balance to avoid fees was relatively low, it has good web banking (though online bill pay costs extra), and there’s a convenient branch location near my office.

Forming a legal entity (part 5): Filing incorporation papers

Andrew MinerLeave a comment

CAVEAT: I am not a lawyer, and I got legal advice before making any of the choices described in this post. If you are making similar choices, you should definitely should do the same.

Filing incorporation papers was a big moment.  It was when all the dreaming, planning, and preparations became for real.  It also involved a lot of reading, learning, and making decisions which would be with me for a while, and could be expensive to unravel if done badly.  However, before it could happen, there were a few questions I had to answer.

The most immediate was what kind of legal entity to create.  While there are a ton of options, the ones which were on the table for me were: a C-corp (a traditional corporation), an S-Corp (essentially, a C-corp which jointly files taxes with the owner/s), an LLC (a roll-your-own legal entity for small business), or a Sole Proprietorship (a formality with little or no legal protection for your assets).

In my case, I knew that I didn’t plan to hire employees soon, nor did I expect to raise money soon.  Therefore, the tax benefits of an S-Corp made it more attractive than a C-Corp.  There was also the fact that I could “upgrade” from an S-Corp to a C-Corp by filing a simple, single form in case something changed with made a C-Corp more desirable.

I didn’t choose an LLC because, according to my lawyer, their open-ended nature makes them more complicated for investors/acquirers, and there weren’t any substantial benefits for me over an S-Corp.  I also didn’t choose a Sole Proprietorship because I wanted more legal separation between my assets and the company’s assets than that offers.

I also needed to decide which state to incorporate in.  Surprisingly, there’s really nothing preventing you from incorporating in whatever state you want.  The reasons to choose one or the other basically come down to how expensive it is, and, most importantly, what laws that state has regulating businesses.  The most popular state for tech-startups, because of its business-friendly laws, is Delaware.  However, incorporating out of state has a number of extra costs associated with it, and it’s always possible to re-incorporate in another state should be it become necessary (e.g., if an acquirer doesn’t like something about how your company is set up).

So, I decided to just stick with California (where I lived at the time) to avoid the extra expenses.  Since I’d be primarily operating in CA, I’d have to file for a business license there anyway, and, for what I expected from my business, it didn’t make enough difference to warrant the extra expense of officially incorporating out of state.

There were a bunch of other little things, and perhaps I’ll write about them in the future, but they were all incidental and easily resolved once those two big questions were settled.

Forming a legal entity (part 4): Registering a domain name

Andrew MinerLeave a comment

Fortunately, I’ve worked as a sys-admin at several past jobs, and so have gotten pretty familiar with setting up domain names and such. In any case, it’s very easy. Go to your favorite domain registrar (I use Hover, and type your desired name into the big search box. They’ll tell you whether you can have that domain.

Unfortunately, chances are, unless you have chosen a deliberately mis-spelled name for your company (cough tumblr cough), you’ll find that your first choice is probably taken. In fact, I was in exactly this situation. My company was named “Redwood Labs”, and I found I faced a few different choices:

  1. Rename the company to something available (redwoodsoftwareco.com)
  2. Use a common abbreviation (redwlabs.com)
  3. Use a hyphen between words (redwood-labs.com)
  4. Choose a different top-level-domain (redwoodlabs.co)

Of these, I choose #3, redwood-labs.com. In my case, I knew my product name would be something else, and that I was going to register a different domain name for that. Therefore, it was less important to get a short, simple, easy-to-pronounce domain name. As I’ll talk about later, it was much more involved to find a domain name for the product itself.