- I did some engineering consulting work, with the bulk of the time spent working for Baydin, Tencent and Dropbox.
- Started The InternProject, a "let's make sure interns in the bay area have a great time" non-profit with Alex, with major help from Tess, Geoff, James and countless others.
- Became a real open-source contributor via ZMA, a CRUD Admin tool for Meteor, with Geoff and Greg. Greg's been keeping the project updated. I need to contribute more.
- Worked with Amy to start the Campus Data Summit, creating the Campus Data Guidebook for students starting PennAppsLabs-like organizations at their schools.
- Generally speaking, figured out what I enjoy and what I don't enjoy, and what I want to do next.
I'm not sriracha. I don't go well with absolutely everything. Some teams and environments make me dramatically more happy and productive than others. In the future, I'll be a lot more picky and careful about who I work with, both for their sake and for mine.
Date before Marriage. I was very hesitant to join my 2012 team, since we hadn't worked much before. In retrospect, the apprehensions were correct, and ignoring a wealth of advice about having worked together before was wrong.
- Office Hours. Greylock Hackathon from this summer (and I'm sure others before them) have explored the possibility of having Tech luminaries drop by and take meetings during the hackathon. The best time for office hours is probably about half or two-thirds of the way through the event, once participants already have a sense of what they're working on but are not so close to the end that they only have time for small changes.
- Swag Raffles I picked this idea up from Philly Game Jam in 2010, and it was deployed to great success throughout various PennAppses. The basic premise is simple: offer participants a chance to win free stuff given out by sponsors if they meet some criteria (usually, being up late or answering a trivia question).
- Late Night Athletics There's a kind of euphoria I tend to get around 2 or 3 in the morning, after spending more time than is reasonable working and knowing that the end is not yet in sight. Euphoria with a good mix of fatigue.
- Bubble Tea and other excesses Some of the more fun food hacks/surprises involve ordering several gallons of Bubble Tea (at PennApps), Red Bull Jello Shots (really) at the Greylock Hackathon, and late night cheese-steaks (via Venmo at now-every PennApps), and Ice Cream Sandwiches (HackNY).
- Catering Figuring out catering for a hackathon ends up being rather non-trivial; the location you're having may have union or contract rules that say you can't bring in outside vendors, and traditional catering options are expensive and kind of 'meh' (no, we don't want another sandwich plate).
- Room For Improvement: Organizers' Sleep Schedules. PennApps recently moved to a "who sleeps on what night" rotation, meaning that event organizers will likely get a reasonable night's sleep on the first night or the second. This is certainly better than the previous ordeal (organizers sleep when they can no longer stay awake) but can still lead to an organizing team in charge of demos at less than 100%.
- Room for Improvement: Drinks Vendors.
- Demoing mobile apps
- Preparing teams for their demo:
- Demo Order Use things like HackerLeague (or just Google Forms) to organize the demo submissions and order.
- Needs Improvement: Demoing with >50 teams If you have more than 30 or so teams demoing (and especially more than 50), consider exploring ways to cut down to either about 30 demos or about 15 demos with judge interaction. I've heard about the LinkedIn Intern hackathons doing this well, and Greylock Hackathon and AngelHack both did a good job as well.
- A couple of minor fixes. Thanks to DJ, Ayaka, Jennifer and Jonathan!
- See the HN Commentary, for discussion on Multi-Tier Voting and charging attendees; in particular, Greg (from AngelHack)'s post on his experience fund-raising for grown-up (non-college) hackathon.
- Check out my other hackathon posts, and are curious about advice on fundraising and timing, and lots of other goodness.
2013 hasn't been a great year for new content on this blog. Let me try to change that.
First, what've I been up to since January?
It took a while to get my first gig - the first 7 or 8 companies I spoke with all ended up passing, for various reasons, which put a fair bit of dent in my plans. I came up with lots of ways to get more inbound flow, but didn't have the energy to execute any of it because I was so tired of rejection. Basically, if you're burnt out and trying to recover, putting yourself in a position to get rejected a lot is not a great idea.
Eventually, I refined and simplified my pitch, going from "co-founder for rent"/"on-demand hiring manager" to a much simpler one - "I can code, and I don't need to be micro-managed on product." That worked.
I spent the first ~10 weeks at Baydin, the makers of Boomerang for Gmail, pitching and then adding a feature to Boomerang Calendar. I've been fascinated by scheduling tools ever since I saw Tungle.me, so it was tremendously rewarding to work on this problem, and the Boomerang team both provided awesome leverage and feedback, as well as giving me a lot more autonomy than should be reasonable. An awesome and very small (<10) person team in Mountain View - a fantastic place to work. My updates to Boomerang Calendar deserve their own blog post. Hopefully.
Next, I worked at Tencent, a giant Chinese tech company (think AOL or IAC, but more successful) with an office in a church in Palo Alto. The people were great and I appreciated the opportunity to work with them, but the biggest thing I learned was that larger, more traditional companies are not places I thrive.
Finally, I spent two and a half months at Dropbox, working on Dropbox for Business. From Soleio to Guido to Aditya and Ruchi, to (more anecdotally) a few friends I have a ton of respect for, Dropbox has been making some killer hires over the past year and I couldn't help but want to see why. Now I know (hint: it's the cafeteria). Dropbox is an absolutely fantastic company with a rather talented group of people, and (I imagine) a lot like what Facebook felt like in 2008 or 2009. Drew is a fantastic public speaker and generally an affable guy.
Each of the three gigs above was a 4-day-a-week kind of job, and I learned a lot from each. The thing that most stuck with me - and I was a little surprised by this - was how much fun I had working on Boomerang Calendar. I worked in a mostly-solo capacity, but with design and library engineering support when needed and great product people to brainstorm and prioritize with. I want to do more of that.
I've written a whole bunch about recruiting and internships in the Bay before, and started the 2012 Bay Area interns Facebook group. Still, the problem of "how do you make sure people doing internships in the Bay Area get the value out of it that they can" - admittedly a first-world problem, but my first-world problem, didn't feel completely-solved.
I had met Alex Poon the prior year, when he organized a number of intern dinners. We brainstormed about what the ideal solution would look like - a single website with everything you need to know, a big kick-off event for interns from small companies to meet others to hang out with during the summer, and a way to generally keep in the loop on what the good events were. Out of this came the InternProject, which (it seems, so far) met our goals for the summer and then exceeded them.
We're still figuring out how to transition the project to being student run - Alex and Tess dropped out of school and I graduated. We'll see. The important thing is that the ~2,500 students on our list-serv found it to be valuable, according to click and open rates.
I've begun to consider folks like Marco Arment and Loren Bricter as role models rather than just fascinating people. In the long run, I'd love to get into a place where I can make apps that I consider interesting, ideally focused on productivity or developer tools, and have the occassional engineering/design/product support necessary to keep me focused, all the while avoiding management as much as possible. Baydin was a ton of fun. I'd love to replicate that experience, if I can.
In the meanwhile, I'm playing with an entirely different idea that probably deserves its own blog post.
I want to explore whether the reasons that recruiters have a poor reputation in the industry (spam, sketchiness, competence) are an unavoidable side-effect of the industry model.
To do that, I'm spending the next few months figuring what its like to be a full-time technical recruiter, but eliminating all the parts I don't like.
We're focusing on seeing if we can be Talent Advocates, helping rising seniors in CS figure out what to do with their lives and monetizing by putting students in touch with companies that help them get there. I want to know if (1) there's a business here, (2) if I can add enough value to have a clean conscience, and (3) if I can do the work. Follow along at threesat.com.
I've been using Divvy the tiling tool for OSX (and windows) ever since I switched to using Macs full-time in 2010. It's great.
Migrating it between installs isn't so great, and unfortunately googling "migrate divvy preferences" doesn't help. So, while moving to yet another Mac, I emailed support@mizage and asked what to do.
Here (with their permission) is how to migrate your divvy settings / preferences / configurations / setup / whatever to a new computer:
If you're on Windows:
0) Quit Divvy on both PCs.
1) Click Start > Run, and paste in this command:
%USERPROFILE%\Local Settings\Application Data\Mizage LLC\Divvy
2) This should open a new Explorer window.
3) Locate the file shortcuts.db
4) Copy that file to the same location on your second computer.
If you're on Mac:
0) Quit Divvy on both Macs.
1a) If you're on Snow Leopard, go into your User's Library folder in Finder.
1b) If you're on Lion or later, open a Finder window, now hold the Option (alt) key and choose the "Go > Library" menu item.
(AMK Note: this is at ~/Library/Preferences)
2) Go into the Preferences folder.
3) Locate the file com.mizage.Divvy.plist
4) Copy that file to the same location on your second Mac.
At an event last week, I was introduced to the CEO of a post series-A startup I'd been following and found quite interesting. We spoke about his company for a few minutes, and he asked me to email him in case there were any opportunities for me as a freelancer to help.
I followed up. A few days later, I got the following email:
Thanks for your interest in [Company]. We don't have immediate needs for hiring more engineers at the moment but would be happy to keep you on file for future opportunities.
Please let me know if you have additional questions.
- [Recruiter], [Company]
Who are you, again?
I spent a good portion of 2012 running recruiting for the company I'd helped start, growing our team from 3 to 12. I've had a chance to deal a few dozen candidate rejections, and made my fair share of mistakes. Before that, I spent two years applying to internships. As such, some advice for would-be rejection-letter writers:
The effort going into the rejection should match the effort spent in the process.
At my last company, we flew a candidate in for a trial and ended up passing. The next day, I sent a two paragraph email saying, effectively, thank you but no thank you.
That was wrong. The guy deserved at least a phone call after giving us a week of his time.
Last week's CEO asked me to email him; I was interested in the possibility of work, but I also just wanted to have a chance to chat and seek his advice. I got a response, without context, from somebody else entirely, treating me as yet another applicant. I hadn't even sent in a resume.
Not that every possible candidate deserves a 500-word essay; a generic application or cold-email, ("Dear Sir or Madam...") should absolutely receive a friendly, templated rejection.
There's a difference between a euphemism and a lie.
On Tuesday, the CEO told me they were looking for engineers. On Thursday, I was told the opposite. Either their hiring priorities changed on Wednesday, or (hint: it's this one) 'not hiring' was an excuse. As a candidate I can tell, and it reflects poorly on the company.
The flip-side is, of course, you don't want to be incredibly specific in every rejection, because the occassional candidate is going to argue that in fact they ARE great at X and were just having a bad day and now you're in this terrible position of saying "dude, no." The industry standard seems to be some variant of "not a fit" or "no positions available that you would be well-suited for," ending with "at this time."
If you have an opportunity for a cop-out, take it!
A rejection is a bit like an needle injection; yeah, it's not going to be pleasant, but at least you can make an effort to minimize the discomfort.
In this case, I was rejected because they didn't want to deal with contractors, or my background isn't impressive enough, or I wouldn't fit in; who knows. Regardless, you could say:
Thanks for following up, it was good to meet you.
Unfortunately, I checked with our head of recruiting and we're focused entirely on full-time roles right now for engineering. Thanks again for following up after we met on Tuesday and best of luck with your career!
And it's not like I have grounds to be upset: I get it, and you haven't told me that there's something wrong with me. Other effective cop-outs that help a candidate save face including H1-B difficulties for internationals or a lack of experience or exposure to a particular technology or industry.
Why does this even matter?
From a friend at Google, their philosophy on recruiting is, roughly, "we should be really nice to the engineers we interview, because most engineers out there will remember Google as that company they applied to and got rejected from, and these are the people recommending technology to their parents and advising friends on where to apply."
In 2011, I was introduced to Stripe (/dev/payments at the time) as a potential summer intern, and had a great conversation with Patrick. They asked for a code sample, and I sent them one.
It wasn't very good.
They rejected me, going with something along the lines of "we realized we didn't have nearly the bandwidth for interns this summer as we had hoped." Since then, I've sent or recommended Stripe to several of my most impressive friends as potential hires because of the goodwill generated from that process.
Rejecting candidates correctly isn't the most glamorous part of starting a company.
Still, it's worth getting right.
1. Where were you in 2012?
Fourteen months ago, in my last semester of college, I began working on a start-up idea with a few folks I had met through school. The company we started is off to a good start.
As it turned out, (as it surprisingly often does) it's not always a great idea to start companies with people you know only by reputation. We spent quite a bit of time over the second half of 2012 looking for ways to work together productively, and then separately came to the same conclusion: I had to go.
2. What's it like?
It sucks. Leaving a cause that you spent the last 12 months of your life enveloped in, is a painful experience even when the departure is as amicable and unanimous as ours. Nothing really compares to the satisfaction gained from throwing all of your available energy, every day, to a cause you believe in on a fundamental level.
Still, there are upsides. More time with the girlfriend, more catching up with old friends and fascinating acquaintances, a chance to get in better shape, write, maybe travel. I've had a chance to step off the high school to college to job conveyer belt before, and was better off as a result. The important thing (I hope) is to take note of lessons learned and keep my eyes open.
3. Lessons Learned
From now on, if (and when) I start a new venture, it'll be with folks I've worked with before successfully, or at least after a non-trivial trial period.
4. What now? [Update: April 2013]
I'm currently spending 3 days a week working freelance for Baydin, the creators of the Boomerang Gmail plug-in. I'm working on Boomerang Calendar, trying to make the ping-pong that is meeting scheduling over email a little bit less painful. Baydin are an awesome bunch of folks (who deserve their own blog post), and I've been thinking about scheduling as a problem before, so the gig has been pretty fantastic.
Hackathons are a thing now. Over the past two years I've had the benefit of participating, helping organize, watching demos for, and (soon) judging more than 15 hackathons. One of my favorite things about the hackathon community has been how quickly best practices have spread from organizer to organizer.
To that end, here are some "hackathon hacks" I've noticed or come up with over the past few years. If you're working on putting together your next hackathon, I hope they help!
Events around the hackathon
Originally, this was (largely) a ploy to get students to have a reason to stay late, since drawings occurred every hour from midnight to 6AM, and the prizes (as well as your odds) got better the later you stayed. Since then, it's become a great way to distribute swag available in limited quantities, get participants to follow you on twitter (by announcing winners there), and generally create a fun environment for everybody. I worry about the impact of too many disruptions, but using something like Twitter to announce winners (and setting a time limit to collect) has mitigated the concern.
Athletics help. Taking a bunch of friends and strangers and going "alright, now let's do something silly" is fun. PennApps has a midnight run tradition that is exactly what it sounds like: at midnight (really, closer to 1:20 AM) everybody who is up for it heads out and goes for a 10-minute jog around campus, jeans and not-quite-running shoes and everything. Tis a blast; highlights include the time when we jogged Dave from Andreessen Horowitz back to his hotel. More recently, a 3AM game of ultimate frisbee (complete with glow-in-the-dark frisbee) made me happy the organizers had not neglected gatorade a drink option. I've also heard of impromptu juggling lessons.
Late night athletic events have the benefit of being both fun and sufficiently out of place to be memorable. Plus, it's nice to get out and stretch your legs.
I'm still waiting for somebody to cater a pancake/crepe maker to make breakfast crepes on demand, for the morning of demos. There's probably no better sign of how hackathon-spoiled I am that I'm waiting for that.
Update: HackNY and Michigan email/tweet me to provide photo evidence of said crepes/pancakes. I love the internet.
Michigan's Learn To Hack:
Some of the best food I've seen at hackathons comes from working with existing favorite choices, from bringing in popular food carts or popular choices from campus or the city, and getting a bulk discount based on the traditional pitch that you are exposing desirable customers to their menu. I've also heard that Chipotle and Red Bull representatives (amongst others) don't have a problem providing some amount of free or heavily discounted merchandise to hackathon organizers.
Provide variety throughout the event, provide (reasonably healthy) and vegetarian options. Whatever you do, don't order Pizza. Not even once. OK, maybe once if you get desperate.
Here's my proposal: break the organizing team into two: a Hackerspace team responsible for during-the-hacking events, and an Event team in charge of everything surrounding the hacking: Kickoff and API Tutorials before the start, and the Demo Session and Awards after. A dedicated event team means folks that have gotten a ton of sleep before each event and are wide awake to move quickly and deal with any issues that come up at the last minute. I'd love to hear from anybody that has an approach they've tried and liked, and that works.
Anybody who's had a summer internship at a big-enough, 'tech' company knows about the contents of the Facebook/Google/Twitter beverage fridge, full of fresh fruit juices and various ice teas and all sorts of goodness. Since the first PennApps, I did my best to replicate that experience, to make (by any means necessary) to make the point that there were some benefits to working at a startup, and look: here they are, an always stocked, no limits free fridge of goodness.
I learned that getting a see-through beverage fridge, as well as actually obtaining the necessary drinks for the fridge (Honest Tea, anybody) is a bit of a challenge. Those types of fridges are a headache to rent, and Honest Tea is just not for sale at Costco.
I've since learned that O'Sullivan Vending provides drink catering to Google, Facebook, and most tech companies in the Bay Area. They are expanding to other areas, though not quickly enough.
If anybody has seen any hackathon do an awesome job of their drinks catering, from the fridge to the selection to the constant availability, let me know - I'd love to learn and share how.
With a seemingly endless supply of teams hoping to demo and an exhausted audience, lots and lots of things are continuously trying to go wrong. Some hacks towards making demos run more smoothly:
Ideally, obtain a document projector (like back in middle school) a few days before the event, set the focus (once) properly, and put up a big sign saying "don't touch this knob." Explain this principle to demoers, and make it trivial to switch one of the on-screen views to the mobile projector.
If not, I've had a surprising amount of success with taking the demo laptop and using it's webcam to show off the mobile experience. It's hacky, and should be prepared way beforehand, but it works.
Emulators are a bad idea; they involve plugging in somebody else's laptop into the projector. Pain this way lies.
Folks, X by Y is the resolution you're going to demo on. Better be ready.
Don't rely on Wi-Fi working. There's no place like 127.0.0.1.
In general, if you have any special requirements let the organizers know way in advance.
No using your own laptop unless you absolutely, unequivocally, have no choice whatsoever (IE, desktop app). If so, let the organizers know in advance and we'll see how we can accommodate you.
Ideally, have a second (identical) set-up in a nearby room for teams to practice on a few minutes before they demo, as part of the demo queue. If not, at least make the demo setup available morning-of the demos and encourage teams taking a chance to practice.
Does anybody have to leave early? Put them in front. Otherwise, randomize demo order.
Publicize demo order ASAP, and make it obvious where it is. It really helps teams to know where they are in the queue in case any of them sneak out to the bathroom, etc..
The worry with multi-tiered judging is this: imagine you spent your entire weekend sleepless. Your implicit reward, prizes or not, is that a hundred or more people will get to see what you did and, prizes or not, applaud your effort. Instead, you go into a tiny closed conference with 4 older-looking folks who listen to you for two minutes and then wait for an email with the list of finalists - a list you're not on.
Multi-tiered demoing needs to be done in a way that recognizes the work hackers put in. I don't know how to do that yet; having three demo auditoriums for the first round feels a bit of a logistical mess. Open for ideas - email me on this one.