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.
- PennApps Labs pays ~5 students a semester TA-like wages to create new applications or update existing ones.
- Funding comes from the school’s administration and Student Government, which makes cooperation with existing organizations substantially less painful.
- Other successful student-created projects are supported and promoted, with a potential goal of adoption. Labs helps good projects from becoming stale and lost in the sands of time.
- PennApps Labs projects strive to be open. That means open-sourcing whenever possible, accepting and soliciting community contributions, and establishing open APIs for any data created as a side-effect.
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: </img>
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.
I still remember the first project I ever worked on that went viral.
Cobol on Rails was a re-design of the Penn’s online Course Review system. The original was written as a Senior Design project a decade ago and kept on life support by the University IT. It was (by the time we got to it) rather outdated. It looked like this.
Cobol on Rails was built in PHP and mySQL. It was the first serious web project that a few friends and I undertook. The Course Review folks were a student-run group who had been trying to find somebody to take over web responsibilities. They were willing to share the data.
We worked weekend after weekend, in 12-hour sprints, learning things like what the hell a border-radius was. I still recall var_dump as a fond friend; good times.
It worked. I emailed a link the Course Review folks. “We’re done, check it out!” A few of the others emailed their friends.
A few days later, we were on Under the Button, a well-read student newspaper blog. The initial emails had gone viral as students started to pick their next classes., leading to a couple of thousand unique visitors a day. Every minute between classes that day was spent glued to email, responding to feedback and answering questions. My heart was racing.
The Course Review folks emailed us too. “I can’t believe you guys did this,” they wrote. “You promised not to start a competitor! The Dean is not happy.”
We had to password-protect the thing (the password was ‘password’, and you could tell it you viewed the source). Students went back to using the crappy old site, and the Course Review folks were mad enough at us to not take any of our advice about UX improvements seriously. The experience stuck with me - the substantial improvement we made, and the politics that brought back the status quo.
I was friends with Cynthia from Penn’s Student Government.
She was spending the summer working on student textbooks. The problem was this: Penn’s bookstore made absurd margins buying back used books.
The old, student-run book exchange (BetterThanTheBookstore.com) had closed. In the summer of 2010, following Princeton’s lead, Penn’s Student Government decided to start their own Book Exchange, Penn Book Bazaar.
** Cynthia **: “You know Django, can you make this thing work for us?”
I had no desire whatsoever to be a peon for the Student Government. They went ahead and did it on their own. The result was simple but not ugly and pretty successful.
Marketing isn’t so hard if you can email the entire school whenever you’d like.
Meanwhile, we hosted our first undergraduate hackathon, PennApps.
The winning team built an app called SEASPrint, which let students print anywhere in the engineering school directly from their phone.
SEASPrint was awesome, and was more than a prototype - it worked. I used it all throughout college. With time, it would probably start to fall over unless somebody made sure it was up-to-date, and would be forgotten unless discoverable. But the team had no particular interest in supporting it long term. That sucked.
Eventually, it clicked
Campus tech does not have to suck. Apps do not have to become outdated or unsupported. Developers don’t have to quarrel with the administration.
Working on campus tech can be rewarding, and deserving of talented engineers’ time. Building something your friends use feels great.
And so, we started PennApps Labs, a student-run development shop that creates, adopts and maintains student-run campus tech.
** PennApps Labs in a nutshell **
I believe Labs is a model worth forking. The problems Penn’s campus tech faces are not substantially different from the problems at scores of other schools. The sorts of problems that Labs aims to fix benefit from outside collaboration and contributions.
I am working on a README that should serve as a guide for starting a sister organization at another school. Drop me a line if you’d be interested in trying something similar are your school, and I’ll make it a priority.
Warning: Boris and Alex are friends and former classmates. I am utterly biased.
Crowdfunding doesn’t work.
It just doesn’t. You can’t get the top-tier guys to crowd-raise. “What for? It’s just more complicated.” If you can’t get the top-tier companies, you can’t get the companies that follow whatever top-tier companies do. You end up with wanterpreneurs tricking Grandmas out of their paychecks. You’ve already lost.
As a result, Crowdfunding-ish startups have been tiptoeing around the idea. AngelList will make introductions but not facilitate the financial exchange. KickStarter focuses on sponsorship rewards, but stays away from offering equity. SecondMarket works with later-stage companies and requires 6-figure minimums.
** Tis a shame. ** A world with crowd-funding for early stage startups would be pretty fun. Imagine a company being able to reach out to its early users and saying “We’re starting to raise our next round of funding, and you’re welcome to be part of it.”
Nobody does that, though - the legal hassle of figuring out what it would take is too great and takes time away from what the company actually does. Crowdfunding doesn’t work.
Except that it does.
Boris and Alex of FundersClub have found a way around the credibility problem, by having it to start with. As part of the summer 2012 YCombinator class, the team has the implicit (and explicit) endorsement of Paul Graham, godfather of legit startups. The two themselves have a rather impressive background As a result, the initial 5 companies raising money on FundersClub are some of the most interesting startups of the group.
These are the cream of the crop. Most are likely to be over-subscribed come Demo Day. As an investor, if you aren’t well connected to YCombinator (and probably even if you are), you’ll be stuck on the sidelines wishing you had a way into their seed rounds.
And with FundersClub, you do. The two have spent several months figuring out how to make everything work legally. Details are on their website, but briefly: when you invest in a company, you become a limited partner in a FundersClub investment fund which then in turn invests in the company. As in traditional angel investments, accreditation is required (a minimum of $200k income or $1MM in assets). No grandma paychecks allowed, no dependency on the JOBS act.
FundersClub has raised almost $1MM on behalf of its launch startups so far, and an investment (and glowing review) from First Round Capital and Josh Kopelman, respectively. Not bad for its first two weeks.
They’ve got a ways to go, but I for one am looking forward to being able to read a TechCrunch article about a startup and being able to click the “Invest” button at the bottom, adorned with a nice FC logo.
Good luck guys.