My patent-pending 3 question technical interview

I’ve done a lot of interviewing, hiring, and firing in my career. It’s inevitable as you start to build your own companies, become a team leader, or move into management. I fully subscribe to the notion that you should hire slowly and fire quickly. That being said, triaging candidates quickly is also important if you don’t want to spend half your time vetting candidates. Adding to the complexity of hiring an individual is that it can be extremely difficult to get to the heart of someone’s technical abilities without pairing with them.

In general my interview process is as follows:

  1. Stalk the candidate on the internet via Twitter, LinkedIn, and GitHub. I look at Twitter to see what they talk about, what interests them, etc. I look at LinkedIn for obvious reasons. On GitHub I pay special attention to their commit frequency, what projects they’ve forked, and considerable attention to any repositories that they’ve created and put out there.
  2. Meet with them for a coffee or have a short 30 minute phone conversation with them. This is when I’ll put them through my patent-pending 3 question technical interview. Due to the resources required for the next two steps, it’s imperative that I triage candidates quickly and effectively.
  3. Bring the candidate in for a full day of pair programming across the stack. Spend half of the day fixing a frontend ticket and the second half of the day working on a backend ticket. I do this regardless of skill or specialties in an effort to evaluate problem solving skills, how candidates work others, and how candidates approach problems that they know little about.
  4. A final, and optional, step is a 30 to 90 day contract. I consider this step to be not optional if the candidate lacks an established track record, wasn’t personally referred to me, or is an early hire at a startup when each hire has an enormous impact on company culture.

I actually have a mixed bag of questions that I’ve slowly added to over time. When talking with a candidate I attempt to match up questions with their experience and generally never go beyond three of them. Before asking them any of these questions I ask the candidate to tell me, on a scale of 1 to 10, where their expertise sits on each question’s topic (e.g. “On a scale of 1 to 10 how capable are you with the Unix command line?”).

So, without further ado…

There is a multi-level directory tree, say a local git checkout, that has a number of files all with the extension .tmp. How would you delete all files with the .tmp extension in a single command regardless of where they sit in the directory tree?

I’ve had candidates who will tell me they’re an 11 on a 10 point scale answer this question with rm -r *.tmp. In fact, I got into an argument with an existing Digg employee about that answer and how patently wrong it is. Overall, I’d say my pass rate on this question is below 20% Pretty poor, especially considering I’ve resorted to accepting any answer that mentions using the find command.

In PHP, what is the difference between isset() and empty()?

Every language has its edge cases and gotchas. This just happens to be one of my favorites from PHP because, quite frankly, PHP is a fucking moron when it comes to types. What I like about these edge case gotcha questions about languages is it really allows the language wonks and those who are true blue veterans of a language geek out and really shine. I’ve found that the pass rate on this, even with fairly seasoned PHP developers, was hit or miss. Maybe 50%

What is the -i option on grep used for?

I probably use grep a 100 times a day when I’m doing full-time development. Particularly when I’ve put my DevOps hat on. When I was in college I made myself read one man page a day on all of the major Gnu/Unix command line tools. Want to know what the flags on wc are for? Or how to scp a directory? I know this off the top of my head and I expect seasoned developers to as well. If you don’t know what the -i option on grep means, it likely means you’ve not committed yourself to ninja level status on the Unix command line. The pass rate on this question is also abysmal. Maybe 20-30%

What is the difference between an abstract class and an interface?

This is more of a theory question as it kind of spans languages. Anyone who has coded in PHP, C++, Java, etc. should have a pretty good handle on the fact that these two are different beasts. What I like about this question is that anyone who really, truly knows how to implement really effective OOP code will absolutely know the subtle differences between the two and how to most effectively use them. The pass rate on this has also been abysmal. At most 10% of developers have been able to clearly articulate the difference between the two.

What is the difference between an INNER and OUTER JOIN in SQL?

I love this question because it washes out every idiot who learned how to use the Rails or Django ORM and now thinks they’re some wizard at SQL. The most common answer to this question, I shit you not, is, “I don’t know. I just let the ORM handle that.” As my basketball coaches always would say, “It’s about the fundamentals!” Pass rate on this is also below 10% Bonus related question: What field of mathematics are RDBMSs based on?

What is your favorite OOP design pattern and why?

Another language theory question. I like this question because it doesn’t seem like a pass or fail question at first, but you’d be shocked how many developers have no idea what a design pattern is, much less their formal names, how to implement them, or where to use them most effectively. This is another question where true language polyglots will really shine. A true star candidate will find a way to talk about patterns that are more esoteric, such as the chain of responsibility pattern. While I’ll accept things like the factory or singleton patterns, I’m looking for more substance and look at those answers as a net neutral.

These days I don’t waste my time unless the developer can answer all three to my satisfaction. There is enough latitude in the questions that they work equally well for systems engineers, application engineers, and backend engineers. Any failures from someone purporting to be an architect should be seen as enormous red flags.

To raise or not to raise

If you follow startups at all, you’ll likely notice that there are precisely two camps when it comes to raising venture funding of any sort: those who trumpet each new round as if the company won the Super Bowl and those who believe bootstrapping is the only legitimate way to build a business. There are, of course, merits to both camps’ arguments, but, as with all things, reality tends to live somewhere in the middle. There are dozens of reasons why raising money could be a good idea and dozens of reasons why raising money might not be a good idea.

Whether or not to raise funding is an extremely complicated question with dozens of angles, numerous points of data, and, in the end, gut instinct and your emotions. Your company is a very personal topic. Don’t forget that, because your emotions will effect your business decisions.

I look at capital, whether it comes from an angel, a VC, or a traditional bank loan, as an accelerant. It’s like gas. Sometimes your fire is burning nice and bright. You’re warm and have plenty of heat so why pour more gas on the fire? Sometimes, however, you’d like to start another fire, or maybe you’d like to burn down a house, or, possibly, you’d like your little glowing embers to be a fire more quickly than is otherwise naturally possible. These are all great reasons to reach for the can of gas.

There are, literally, hundreds of reasons why you might consider raising money. The following is a small list of reasons that I think are in support of raising funding:

  • You’d like to create a product which requires you to build hardware, open storefronts, or otherwise produce something physical. Manufacturing is a capital intensive adventure. I doubt someone could easily bootstrap the Tesla or the Nest.
  • You’d like to focus all of your resources on getting the product to a new level. Sometimes your company’s bottom line isn’t growing quickly enough for your product’s needs. Do you think Steve Jobs would have hesitated to raise capital for Apple if they needed it to ship the iPhone? Investors call this an “inflection point” and love to invest in companies at these stages. Could you wait a year and save your pennies? Sure, but you could give up couple of points on a convertible note and be in a position to get there in a few months instead. And, in this industry, a year is a long time.
  • You’ve built a successful business, which you have no interest in selling, and would like to extract some liquidity. We’ve all seen this, but nobody ever talks about it. Some company raises $10’s of millions and people wonder why a company making that much money would need it. They don’t, but their founders are now multimillionaires and free to get back to building that 50-year business without wondering when the big payday will come.
  • Not everyone is in a position, financially, to pursue their dreams. There are a litany of reasons why this might be, but you’d have to be a gigantic asshole to pooh-pooh someone for raising capital for this reason. Kids, family, mortgages, salary requirements, and time constraints are all legitimate reasons to say, “I either hunker down at this giant corporation for the rest of my life or I raise some capital, mitigate my family’s risk, and chase my dream.”
  • It can, at times, make sense to raise capital simply to gain access. Many large corporations have investment arms that keep an eye out for promising young companies and products that could help the mother ship out. Raising capital from Verizon or Salesforce is a great way to gain access to lucrative partnerships, which, of course, you’ll parlay into partnerships with other companies.

That being said, there are legitimate pitfalls to raising capital. Luckily, there is a solid book, Venture Deals, that very clearly and plainly lays out your options, how such deals are structured, and what to look out for. If you are considering seeking capital, or even if you are not, this is a must-read book.

Venture Deals raises a number of concerns, though not directly, about raising capital for founders. For every reason to raise money there is likely a good reason to not raise money. Specifically, I’ll talk about reasons related to what investors call a “priced round”, rather than convertible notes, which I find to be spectacular vehicles for founders seeking to take investment. A few reasons you might want to second-guess your decision to raise capital:

  • Raising capital is an enormously distracting process. Your company, product, and sanity will absolutely take a hit throughout the process. If you’re in the middle of a major product push, or negotiating a big contract, do not think for a second you should be out looking for money – you’ve got more important work at the moment.
  • There is such a thing as raising too much capital. If you raise too much money in an early round, you’re likely going to get severely pinched in future rounds. It’s not fun to hit your Series B and realize that you only own 7% of your own company (Yes, I know founders who’ve been in that position. Yes, they were at companies you’ve heard of.).
  • There is such a thing as too high of a valuation. I’m going to tell you a dirty little secret – investors think valuations are bullshit too. The real issue, though, is raising at a valuation that takes other options off the table. Setting the bar too high in your Series A or Seed can take early exits off the table.
  • When you set up two classes of stock and structure your company the way VCs usually require them to be configured, you give up all control of your company. Yes, you’re on the board and, yes, you’re CEO, but that hasn’t stopped Sequoia from (proudly, no less) firing 45% of their founding CEOs within 18 months. Remember, you’re on a vesting schedule too, so you’ll lose all of the equity that’s unvested.
  • Investors can be a huge distraction. It takes time to keep them up-to-date, coordinate conversations, extract input and insights. Additionally, 99% of the investors you’ll work with haven’t built a product like yours (if they’ve even built one), worked at a company like yours, interacted with users like yours, etc. They’ll suggest things to you that are completely insane. Stay the course – nobody, including your investors, know your business, product, and customers like you do.
  • Investors play portfolio theory. If you’re one of the ones they think are going to strike it big, you’ll be showered with praise and attention. If you’re not, you’re in for a rough reality – you’re now competing for their attention with the dozens of other losers in their portfolio.

I don’t have any hard and fast rules when it comes to raising capital. I think every business, product, and team are unique with their own unique set of challenges. That being said, I do have a set of guidelines I like to follow when raising early stage capital, which are as follows:

  • Don’t raise money before you have a working prototype. If at all possible, wait until you’ve launched a private beta. Every line of code you write, every beta signup, will lead to better terms with any investor. The downside, of course, is that you might prove to yourself and potential investors that your idea is dumb.
  • Only raise money from people with their own money in play. With the advent of the “super angel”, we’re now seeing many angels who are not, in reality, investing their own money. Investors who invest their own money tend to be a lot more attentive.
  • Look for investors with a low “deal flow”. Do you honestly think the guy funding 20 startups a year is going to have a whole hell of a lot of time to help you out? I’d shoot for people that do 3-5 deals a year.
  • Whenever possible, take money from the former founder. I jokingly refer to being a founder as being a member of the Fraternal Order of Founders. You simply don’t know what it’s like until you’ve been there and tried it. Having an investor with the “founder context” is going to be hugely important when you hit rough waters.
  • Seek out investors who have skillsets that compliment your own. If you’re a coder and your cofounder is a designer, look for a guy who used to be VP of Business Development somewhere or find a former COO/CEO. Those skills are not the bullshit most makers would have you believe. The tricky part is finding someone who treats those trades as craft and science rather than pure hustle or vapor.

In the end, do what you feel is best for your product and business. No book or blog post (including this one) can replace your insight into your own business.

Year in Review

2011 was a tumultuous year for just about everyone in the world, particularly Osama bin Laden. I’m no different than the average person on the planet and can be included in the masses thankful that an extremely stressful year has come to a close. 2012 is already shaping up to be an exciting time for myself and Diana, but more on that next year. The following is a highlight reel of my 2011.

  1. January started out with me working at SimpleGeo in San Francisco, Diana in Denver, and SimpleGeo’s team still split between Boulder and San Francisco. All three of these facts would be upended by the end of the year.
  2. Also in January, I went out to the UK to work with Holiday Extras for the second time. I made three more trips to Hythe, UK and have been extremely impressed with the team. It’s been a pleasure to watch passionate people reinvent many aspects of their technology stack, team, and processes in such a short period of time.
  3. The beginning of the year brought more tattoo work. I’ve been slowly, but surely, working on finishing the rest of my left arm. I don’t think I planned on getting two full sleeves when I started out, but I strangely find that it’s completing me in some weird way.
  4. I went to Grand Rapids, MI to talk to a local user group there about scaling, managing engineers, and general geekery. Thanks to Atomic Object for having me out!
  5. In early February my dear friend Josh “Dorkboy” Lynn came out to San Francisco for a trip. We drove down HWY 1, went to a basketball game, and ate a few hundred burritos.
  6. February also brought the closing of the Boulder office. A few people moved to San Francisco to join us and a few people moved on to other opportunities. The lesson learned is that startups are far too small to sustain two offices unless absolutely necessary.
  7. Finally, in February,, a side project of mine that ended up becoming a company with two amazing founders, received $500k in seed funding from the Foundry Group. I continue to be impressed with the hustle and professionalism of Ben and Jesse.
  8. In March I went to the entirety of SXSW. Diana joined me for the last day of Interactive and all of the Music portion. I nearly didn’t get out of Austin at the end due to craziness at the airport and was thoroughly burnt out on the entire event. It’s too big, too corporate, and far too hectic for my taste. I doubt I’ll be spending as much time there this year.
  9. In late March, SimpleGeo launched SimpleGeo Storage, which was built entirely on top of a distributed graph database system that our team developed internally. This patent pending technology is some of the most impressive technical work I’ve seen happen in a startup and I’m proud as hell with the team and their work. In particular, it was a pleasure to watch Mike Malone challenge himself and grow into an absolutely spectacular engineer.
  10. In April I went out to Denver a few times to see Diana showcase her artwork for her senior thesis. In May I once again traveled to Denver to watch Diana graduate from Metro State. We then packed up her apartment and moved her out to SF so that we could live together. This March 2nd will be two years. I can’t imagine someone filling a void in my life as completely as Diana has.
  11. Also in May was a trip to Amsterdam to speak at a location related conference. I managed to visit Amsterdam three times this last year and would happily visit it three hundred more times. I’ve never felt so at home in a foreign country as I do walking the canals of Amsterdam.
  12. May and June also brought the first serious interest from potential acquirers at SimpleGeo. We got pretty far down the road with one potential acquirer before walking away. This was my first foray into the dreaded M&A process and it set the tone for all future discussions with acquirers.
  13. In June Diana and I went to Vegas for the Future of Web Apps conference. The Carsonified crew are, in my opinion, some of the very best in the business. I gave a talk titled Starting Your Startup, which appeared to be well received.
  14. In June I started following the Four Hour Body’s Slow Carb diet. I ended up losing 35 pounds over the next five months and now weigh under 200 pounds for the first time since high school.
  15. July brought a trip to Europe with Diana. We went to Paris, Amsterdam, Rome and the UK. It pretty much rained the entire time we were in Europe and we both got sick. We tried to make the best of it and managed to take in some great sites in Rome and Paris. We had a great time hanging out with friends in Amsterdam. I think Diana might share my feelings on Amsterdam after the trip.
  16. In September conversations to sell SimpleGeo started to pick up steam. We talked with quite a few companies about the possibility and, at the end of October, ended up being acquired by Urban Airship. As part of the acquisition, I moved on from the company.
  17. After leaving SimpleGeo, I dedicated myself full-time to, a product management tool that I’ve been wanting to build for almost my entire career. We launched as an invite-only beta on the 3rd of December.
  18. At the beginning of November Diana and I bought an RV with the hopes of driving around the Southwest all winter. We made it as far as San Diego before and a new puppy caused us to rethink the trip. Our current plan is to head up to Seattle for a couple of months.
  19. Puppy? Yes, we got a puppy. He’s a Lhasapoo and his name is Sheldon.

Another year, another ridiculous amount of travel. I flew over 110,000 miles to two different continents and visited 17 different cities throughout the year. Needless to say, jet lag is my copilot. My year in cities follows.

  • San Francisco, CA
  • Denver, CO
  • Portland, OR
  • San Diego, CA
  • Chicago, IL
  • Grand Rapids, MI
  • Ann Arbor, MI
  • East Jordan, MI
  • Amsterdam, The Netherlands
  • Rome, Italy
  • Hythe, UK
  • London, UK
  • Paris, France
  • New York, New York
  • Austin, TX
  • Las Vegas, NV
  • Orlando, FL
  • Seattle, WA